Vlan between a windows pc and raspbian

grip

Hi Nami,
maybe we could have some hint now: I first applied only untagged VLAN10 on port 3 and nothing changed, when I applied also PVID 10 on port 3 the communication with RPi (on VLAN 1 subnet also) stopped working.

That could be because there is something wrong on the RPi side...

- this is the output of lsmod | grep 8021q

8021q                  32768  0

garp                   16384  1 8021q

-  this is the output of modinfo 8021q

filename:       /lib/modules/5.15.84-v7+/kernel/net/8021q/8021q.ko.xz

version:        1.8

license:        GPL

alias:          rtnl-link-vlan

srcversion:     2027994B2785298484F5DDF

depends:        garp

intree:         Y

name:           8021q

vermagic:       5.15.84-v7+ SMP mod_unload modversions ARMv7 p2v8

- this is the content of /etc/network/interfaces

# interfaces(5) file used by ifup(8) and ifdown(8)

# Include files from /etc/network/interfaces.d:

source /etc/network/interfaces.d/*

- this is the content of /etc/network/interfaces.d/vlans

auto eth0 eth0.10

iface eth0 inet manual

        up ifup eth0.10

iface eth0.10 inet manual

#       vlan-raw-device eth0

- this is the content of /etc/dhcpcd.conf

interface eth0

noipv6

noipv6rs

static ip_address=192.168.1.212/24

static routers=192.168.1.1

static domain_name_servers=1.1.1.1

#interfaccia eth0.10 VLAN10

interface eth0.10

noipv6

noipv6rs

static ip_address=192.168.10.10/24

static routers=192.168.10.1

I add also something else, if I do a ping from RPi and use tcpdump to analyze packets exiting from (in my mind) eth0.10 I see nothing at all otherwise  using the flag -i eth0 instead of -i eth0.10 I can see from tcpdump (on eth0) the vlan packets.
now I'm getting a bit confused... 

tcpdump -e vlan -i eth0 -nn

tcpdump: verbose output suppressed, use -v[v]... for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

12:33:16.708766 xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 10, p 0, ethertype ARP (0x0806), Request who-has 192.168.10.100 tell 192.168.10.10, length 28

12:33:17.715786 xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 10, p 0, ethertype ARP (0x0806), Request who-has 192.168.10.100 tell 192.168.10.10, length 28

12:33:18.755784 xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 10, p 0, ethertype ARP (0x0806), Request who-has 192.168.10.100 tell 192.168.10.10, length 28

12:33:19.796516 xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 10, p 0, ethertype ARP (0x0806), Request who-has 192.168.10.100 tell 192.168.10.10, length 28

obviously nothing changes about the ping test.

let me know if you need other infos.

Regards

PeterUK

grip said:

The above looks correct

Realtek utility doing VLANs should work but not that great MTU reduced.

Better way is to enable Hyper-V services

Then use Windows PowerShell

New-VMSwitch -Name "External_network" -NetAdapterName "Ethernet"

Add-VMNetworkAdapter -ManagementOS -Name VLAN10 -SwitchName External_network

Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName VLAN10 -Access -VlanID 10

PeterUK

Zyxel_Nami said:

we advise that you may check the packet frame by Wireshark on both hosts to see if the packets sending from these two hosts are really added VLAN 10 tags or not. 

Not possible as the VLAN tags is removed before & after Wireshark can see it

Zyxel_Nami

Hi @grip   

PVID configuration is for incoming untagged packets to every port that if NIC doesn’t support VLAN tagging then the switch will add specified PVID on the packets.  

For Tag Egress/Untag Egress Member configuration, Switch decides whether outgoing frame should carry VLAN tags or not.   

Regarding to our recent advice of changing into PVID 10 on port 3, the communication with RPi stopped working on VLAN 1 subnet because eth0 (192.168.1.212) on RPi was untagged, then when the packet came to port 3, it was assigned PVID 10 and it couldn’t ping 192.168.1.156 since they were not in same VLAN anymore.  

Also, when you changed into PVID 10 and untagged VLAN 10 on port 7 while port 3 remained tagged VLAN 10 and PVID 1, the outgoing frame from port 3 to host 192.168.10.10 (eth0.10) should be successful. 

Therefore, we would like to ask if you can test VLAN 1/ VLAN 10 communication on only physical interface as below illustration:  

VLAN 1 

 

 

VLAN 10  

 

If VLAN 1/VLAN 10 hosts can communicate with each other on the physical interface, then we would like to advise you to check on your settings of virtual interface. 

Hi @PeterUK  

If NIC supports VLAN tagging, you can see it on 802.1Q tab in Wireshark. This tab can be added on Wireshark setting. 

Best Regards

Nami 

grip

Hi Peter,
I did what you suggested (I have to better understand the issue with the MTU): deleted any new interface created by the Realtek utility and created the new one with Hyper-V tools

Scheda Ethernet vEthernet (VLAN10):

   Suffisso DNS specifico per connessione:

   Descrizione . . . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #3

   Indirizzo fisico. . . . . . . . . . . : xx-xx-xx-xx-xx-xx

   DHCP abilitato. . . . . . . . . . . . : No

   Configurazione automatica abilitata   : Sì

   Indirizzo IPv6 locale rispetto al collegamento . : fe80::5cb9:xxxx:xxxx:xxxx%60(Preferenziale)

   Indirizzo IPv4. . . . . . . . . . . . : 192.168.10.100(Preferenziale)

   Subnet mask . . . . . . . . . . . . . : 255.255.255.0

   Gateway predefinito . . . . . . . . . :

   IAID DHCPv6 . . . . . . . . . . . : 1006638429

   DUID Client DHCPv6. . . . . . . . : 00-01-00-01-27-AD-xx-xx-xx-xx-xx-xx-xx-xx

   Server DNS . . . . . . . . . . . . .  : fec0:0:0:ffff::1%1

                                           fec0:0:0:ffff::2%1

                                           fec0:0:0:ffff::3%1

   NetBIOS su TCP/IP . . . . . . . . . . : Attivato 

but nothing changed...

Regards

Zyxel_Nami

Hi @grip

We reproduced the environment using Realtek Diagnostic Utility and Raspberry Pi:

 

• Switch GS1200-8HPv2: VLAN configuration as below image: 

• Windows PC: we added VLAN 10 by Realtek Diagnostic Utility 

After adding VLAN 10 successfully by Realtek Diagnostic Utility, we assigned static IP 192.168.10.100 for Realtek Virtual Adapter at Network Connections > choose Realtek Virtual Adapter > Properties > Internet Protocol Version 4 (TCP/IPv4).

Then checking information of Realtek Virtual Adapter on the utility, IP 192.168.10.100 was assigned on this adapter as below image:

Also, we checked on CMD that showed successfully IP address 192.168.10.100 and the original one as 192.168.1.100.

And here is the result of ping from Windows side:

• Raspberry Pi: please check the interface and ping result as following image: 

eth0: 192.168.1.10 

eth0.10: 192.168.10.10 

Everything seems normal as shown. Therefore, in order to solve your issue, we would like to share our experiences when we did the test that may help you with finding the reason: 

• We encountered the failed settings on Realtek Diagnostic Utility at the first time that made the original one (192.168.1.100) disappeared. Then we uninstalled and installed it again, after that we assigned static IP 192.168.10.100 for Realtek Virtual Adapter as above instruction. Please double check your settings for VLAN 10 on Windows. 

• On your first message, there is ‘vlan protocol 802.1Q id 10’ on the interface eth0.10, meanwhile we don’t have this line on our eth0.10 interface. When setting VLAN on Raspberry, we followed the instruction of this blog, please check if it helps. https://engineerworkshop.com/blog/raspberry-pi-vlan-how-to-connect-your-rpi-to-multiple-networks/

• Windows can ping Raspberry Pi, but the Raspberry Pi can’t ping Windows. It was because Firewall was enabled on Windows, please check this also. You may try to disable Firewall policy build-in on Windows temporary for test.

For identifying whose settings aren’t correct, please try ping test at the same time: 

• Windows pings Pi’s VLAN 1, VLAN 10 

• Pi pings Windows’s VLAN 1, VLAN 10

Hope these inputs help to fix your issue
Nami