VLAN support

[Patrik Flykt]

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

[Marcus Folkesson]

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

Post by Patrik Flykt
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

[Slava Monich]

Post by Marcus Folkesson
Hi,
Sounds good to me.
I guess there are no really use-cases for VLAN on WLAN interfaces anyway
:-)

How about a mobile phone?

-Slava

[Patrik Flykt]

Hi,

Post by Slava Monich

Post by Marcus Folkesson
Hi,
Sounds good to me.
I guess there are no really use-cases for VLAN on WLAN interfaces anyway
:-)

How about a mobile phone?

WiFi network traffic is mapped to a suitable VLAN tag in the switch part
of the WiFi access point. For a mobile phone one can use Linux kernel
VLAN capabilites to map traffic from a cellular modem to a suitable VLAN
id.

Cheers,

Patrik

[Patrik Flykt]

Hi,

Post by Marcus Folkesson
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.

Go ahead, you're the first in line :-)

Cheers,

Patrik