We have a VLAN implementation for Connman that associates the virtual interfaces with the ethernet interface. It creates and deletes the VLAN interfaces as needed based on the events from the underlying ethernet service. If this is something of interest to the wider Connman audience, maybe we can clean it up and get it merged. I'll send it shortly.
-Justin On Wed, Apr 1, 2015 at 2:12 AM, Marcus Folkesson <[email protected]> wrote: > 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 _______________________________________________ connman mailing list [email protected] https://lists.connman.net/mailman/listinfo/connman
