(In reply to Uday Patel from comment #0)
> Description of problem:
> 
> Customer is getting core dump while executing command  "teamdctl <non team
> interface name> state dump"
Hi, Uday,
Sorry for late.

I didn't get any core dump when running this cmd, and I couldn't see how this happens from code side.
can you please double check if that core dump was really caused by this cmd in Customer's environment? or can they deliver the core file to us?

> 
> libteamdctl: teamdctl_connect: Failed to connect using all CLIs.
> teamdctl_connect failed (Invalid argument)
> 

Currently, netlink API is used by 'teamd' only, 'teamdctl' is to check the device by using ioctl syscall where we can only check if this device exists and can't check the type of the device.  That's why when <interface name> exists, it could go to teamdctl_connect().

Then in teamdctl_connect() it connects to the 'teamd' daemon by "interface name", as the teamd daemon uses "interface name" to create the unix sock server. This part doesn't really check if team device exits, although one teamd daemon normally binds to a team device. So "Failed to connect using all CLIs" can give you an idea that the unix sock server doesn't exist, and the team device may not exist either.

(In reply to Xin Long from comment #1)
> (In reply to Uday Patel from comment #0)
> > Description of problem:
> > 
> > Customer is getting core dump while executing command  "teamdctl <non team
> > interface name> state dump"
> Hi, Uday,
> Sorry for late.
> 
> I didn't get any core dump when running this cmd, and I couldn't see how
> this happens from code side.
> can you please double check if that core dump was really caused by this cmd
> in Customer's environment? or can they deliver the core file to us?
> 
After checking customer's case, I can reproduce the core dump by using device name including ".", like vlan device.
The core dump is actually a dbus error, before calling cli_method_call() -> dbus_message_new_method_call(), the dbus name should have been validated first:

diff --git a/libteamdctl/cli_dbus.c b/libteamdctl/cli_dbus.c
index dfef5c4..a2fe4ac 100644
--- a/libteamdctl/cli_dbus.c
+++ b/libteamdctl/cli_dbus.c
@@ -184,17 +184,18 @@ static int cli_dbus_init(struct teamdctl *tdc, const char *team_name, void *priv
                return -errno;

        dbus_error_init(&error);
+       if (!dbus_validate_bus_name(cli_dbus->service_name, &error))
+               goto free_service_name;

I will post the fix on upstream first.

Thanks.

reproduced:

[root@dell-per740-83 mode4]# rpm -q teamd
teamd-1.31-2.el8.x86_64
[root@dell-per740-83 mode4]# rpm -q libteam
libteam-1.31-2.el8.x86_64

[root@dell-per740-83 mode4]# cat re
slave1=ens1
slave2=ens5

teamd -d
ip link set team0 up
ip link set $slave1 down
ip link set $slave2 down
teamdctl team0 port add $slave1
teamdctl team0 port add $slave2

ip link add link team0 name team0.3 type vlan id 3
ip link set team0.3 up

teamdctl team0.3 state dump
[root@dell-per740-83 mode4]# source re
This program is not intended to be run as root.
dbus[27095]: arguments to dbus_message_new_method_call() were incorrect, assertion "destination == NULL || _dbus_check_is_valid_bus_name (destination)" failed in file ../../dbus/dbus-message.c line 1365.
This is normally a bug in some application using the D-Bus library.

  D-Bus not built with -rdynamic so unable to print a backtrace
Aborted (core dumped)

Tested:

[root@dell-per740-83 mode4]# rpm -q libteam
libteam-1.31-3.el8.x86_64
[root@dell-per740-83 mode4]# rpm -q teamd
teamd-1.31-3.el8.x86_64
[root@dell-per740-83 mode4]# source re
This program is not intended to be run as root.
RTNETLINK answers: File exists
libteamdctl: teamdctl_connect: Failed to connect using all CLIs.
teamdctl_connect failed (Invalid argument)
[root@dell-per740-83 mode4]# cat re
slave1=ens1
slave2=ens5

teamd -d
ip link set team0 up
ip link set $slave1 down
ip link set $slave2 down
teamdctl team0 port add $slave1
teamdctl team0 port add $slave2

ip link add link team0 name team0.3 type vlan id 3
ip link set team0.3 up

teamdctl team0.3 state dump

https://beaker.engineering.redhat.com/recipes/12690270#tasks

verified https://beaker.engineering.redhat.com/recipes/12694247#tasks

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (libteam bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:2956