New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VLAN overhaul #70345
VLAN overhaul #70345
Conversation
@pdgendt, this should simplify the VLAN support we discussed recently, the code does not yet work fully but I am working on it. |
8ab6c5b
to
002cac3
Compare
|
002cac3
to
3aee9bf
Compare
|
b7cd256
to
b597ad6
Compare
ca335a7
to
7c5e18f
Compare
As the description says, this refactors the VLAN support to use virtual network interfaces we have in zephyr. What this means in practice:
Setup Linux VLAN interfaces for simple testingIf using native_sim board, do this
And compile the exe like this
Currently supported boards that enable VLAN in driver capabilities:
This script could be used to compile and flash echo-server to a specific board:
Example:
The following script can be used in Linux to setup/remove the VLAN interfaces, IP addresses and routes.
Example:
will configure host VLANs to use Then
will send a ICMP Echo-Request to VLAN-100 interface in zephyr.
will send a ICMP Echo-Request to VLAN-200 interface in zephyr. If using the
The Zephyr interfaces look like this with this example
|
TODO:
|
7c5e18f
to
bc65927
Compare
The VLAN packets are prepared in Ethernet L2 so no need to have special handling in the driver. Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
The VLAN packets are prepared in Ethernet L2 so no need to have special handling in the driver. Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
…needed The VLAN packets are prepared in Ethernet L2 so no need to have special handling in the driver. Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
Rework the code to support VLAN properly. Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
The VLAN interfaces are now Virtual type so we need to collect only the Virtual interfaces and not Ethernet ones. Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
3950138
to
1d4d692
Compare
The echo-client VLAN code needed updating so that correct interfaces are in use. Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
The txtime VLAN code needed updating so that correct interfaces are in use. Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
The mdns-responder VLAN code needed updating so that correct interfaces are in use. Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
The lldp sample VLAN code needed updating so that correct interfaces are in use. Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
The gPTP is not suppose to be run on top of VLAN and the earlier support was just for testing purposes. Remove VLAN support now after the VLAN overhaul. Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
The Virtual LAN is changed to use the virtual network interfaces. Add information what changes might be needed because of this. Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
1d4d692
to
d756604
Compare
Changes:
@Dat-NguyenDuy the VLAN sample should work now, please take a look. |
Hi, i've tested the sample, but seems still doesn't work:
Do you see the similar issue on any boards? |
The interface is down so your ping is dropped. |
The error messages can be ignored, they are printed because the interface was down when doing IPv6 DAD. The operations will be re-done after interface is up. |
Thanks for the suggestions. After bring iface 2 and 3 up, i see only the iface 3 has unicast address then the ping is working with this iface. But not for iface 2. Perhaps the sample can be updated? I see that after |
The VLAN sample is only supporting 203.0.113.1/24 address range set to interface 3. Dunno why I did it like that, I can look into this in a separate PR and configure addresses to interface 2 too. The |
I do not have a boards using |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This one overhauls VLAN support to use virtual interfaces. When the VLAN support was originally created, there was no virtual interfaces so the VLAN support was implemented a bit hackish way.
This does not change user APIs related to VLANs, but the Ethernet drivers need to be changed meaning that most of the VLAN code can be removed from the driver.
Tested Ethernet drivers:
nucleo_f767zi
sam_e70_xplained
frdm-k64f
andmimxrt1050_evk
mimxrt1050_evk
qemu_x86