Hi, Sounds good to me. I guess there are no really use-cases for VLAN on WLAN interfaces anyway :-)
I can take this and implement it - if noone is already being. Cheers, Marcus On Wed, Apr 08, 2015 at 02:04:52PM +0300, Patrik Flykt wrote: > > Hi, > > I looked through both Marcus Folkesson's and Justin Maggard's patches > and here's what I'd like to do for VLAN support. > > Since VLANs are only applicable to ethernet networks, I'd keep VLAN > handling inside plugins/ethernet.c. This ends up using > CONNMAN_SERVICE_TYPE_ETHERNET also for VLANs. With this, no extra code > is needed to power off a VLAN technology when ethernet technology is > powered off, etc. > > From Marcus' patch I noticed udev will report VLANs with 'DEVTYPE=vlan' > starting with some recent kernel version. For other older versions > without a devtype ethernet is assumed. So both of these methods need to > be supported. > > Creating a VLAN interface in plugins/ethernet.c should be a straight > forward affair. For VLANs I suggest adding the VLAN tag id in > hexadecimal right before the _cable suffix so that one gets an > 'ethernet_XXXXX_<vlan id>_cable' service. For normal ethernet services > the service identifier needs to stay the same 'ethernet_XXXXX_cable' as > before not to break existing setups. The VLAN id discovery function from > Justin's patch could at the moment live in plugins/ethernet.c as it is > not needed anywhere else. > > Configuring and creating VLANs I'd leave out from ConnMan. There are > other, more capable, applications such as systemd-networkd that can > assemble and create the lower level networking details. This way > ConnMan's role is to work on the interface IP configuration level > selecting the best network from the available ones. > > How does this sound? Any takers? > > > Cheers, > > Patrik > > _______________________________________________ connman mailing list [email protected] https://lists.connman.net/mailman/listinfo/connman
