On Wed, Apr 01, 2015 at 10:33:20AM +0300, Jukka Rissanen wrote: > Hi Marcus, > > On ti, 2015-03-31 at 20:08 +0200, Marcus Folkesson wrote: > > From: Marcus Folkesson <[email protected]> > > > > Support for multiple VLANs binded to the same interface. > > VLAN services appear as: > > vlan_<MAC to bounded IF>_<VLAN IFNAME> > > For example: > > vlan_5c260a4bf6a3_vlan3 > > > > Signed-off-by: Marcus Folkesson <[email protected]> > > diff --git a/src/rtnl.c b/src/rtnl.c > > index b8b02c4..15827ab 100644 > > --- a/src/rtnl.c > > +++ b/src/rtnl.c > > @@ -170,6 +170,9 @@ static void read_uevent(struct interface_data > > *interface) > > } else if (strcmp(line + 8, "gadget") == 0) { > > interface->service_type = CONNMAN_SERVICE_TYPE_GADGET; > > interface->device_type = CONNMAN_DEVICE_TYPE_GADGET; > > + } else if (strcmp(line + 8, "vlan") == 0) { > > + interface->service_type = CONNMAN_SERVICE_TYPE_VLAN; > > + interface->device_type = CONNMAN_DEVICE_TYPE_VLAN; > > > > } else { > > Checked this with ancient 3.2 kernel and for vlan interface there is no > DEVTYPE defined. For newer 3.19 kernel, the DEVTYPE is set to vlan as > expected. > > I just wonder would it be possible to treat vlan device as a normal > ethernet device without separation between vlan and ethernet types. This > would solve this issue with different kernel versions. > > > Cheers, > Jukka > >
Hi Jukka, I have now checked with v3.0.35 and DEVTYPE is indeed not there (not even for standard ethernet). If I read the code right, (rtnl.c:read_uevent()), the only types supported without DEVTYPE is just ethernet and wifi? The first implementation was to let the ethernet device handle vlans, but I was creating a separate class because I think it is a better mapping to the driver model in Connman. But yes, it is possible to treat VLANs normal ethernet-devices. The problem is that the vlan interface will then show up with the same technology (ethernet), the same MAC address, and the same group (cable), the service name will therefor be identical. I think both "ethernet" and "cable" is misleading since it should be clear that it is a vlan-interface, and the interface is not necessary cable-bound (could be bound to wifi, gadget and so on). The patch is replacing the group-name with the IFNAME, which also is not the preferred way, but that was the only way I saw to make it uniq. I think there is a structural point in keeping the seperation, but it should not get a too big impact on the usage, ofcause. Does connman make use of the group-name at all? One way may be to replace the group-name for the ethernet-class by the IFNAME and also keep the vlan technology. The result will be that if there is a ancient kernel, the ethernet device will handle the vlan interface. In newer kernels the vlan-device will take over. It makes it possible to extend the interface to set vlan-specific attributes such as VLAN ID and so on by connmanctl/dbus in the future. If that is the way forward, I may look at it. I'm currently in a project that needs the functionality (unfortunately on an ancient kernel....), but I think it would be terrific if we came up with a solution that also may be contributed to the Connman project. Cheers Marcus Folkesson _______________________________________________ connman mailing list [email protected] https://lists.connman.net/mailman/listinfo/connman
