| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Fri, 13 Nov 2009 14:02:17 +1030
From: Kevin Shanahan <kmshanah@...enchant.net>
To: netdev@...r.kernel.org
Subject: Problem with VLANs and via-velocity driver
Hi,
I've had some problems with getting a fairly simple (I thought) VLAN
configuration working with the on board Via NICs on my Via M700
board. Looks like as soon as a tagged VLAN interface is added, the
underlying "raw" (untagged) interface stops responding.
E.g. this is my desired setup on eth1:
Untagged VLAN: 10.193.38.0/24
cubert (Linux 2.6.30.5) - 10.193.38.254
switch (HP ProCurve) - 10.193.38.1
Tagged VLAN (101): 10.193.39.192/26
cubert (Linux) - 10.193.39.254
switch (HP ProCurve) - 10.193.39.193
Starting with just eth1 configured, VLAN interfaces are down:
cubert:~# ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:40:63:fa:bb:80
inet addr:10.193.38.254 Bcast:10.193.38.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4504 errors:0 dropped:0 overruns:0 frame:0
TX packets:453 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:49136 (47.9 KiB) TX bytes:21066 (20.5 KiB)
Interrupt:36 Base address:0xdc00
cubert:~# ping 10.193.38.1
PING 10.193.38.1 (10.193.38.1) 56(84) bytes of data.
64 bytes from 10.193.38.1: icmp_seq=1 ttl=64 time=0.885 ms
64 bytes from 10.193.38.1: icmp_seq=2 ttl=64 time=0.889 ms
^C
--- 10.193.38.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.885/0.887/0.889/0.002 ms
cubert:~#
So far so good...
cubert:~# ifup vlan101
Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config
Added VLAN with VID == 101 to IF -:eth1:-
cubert:~# ifconfig vlan101
vlan101 Link encap:Ethernet HWaddr 00:40:63:fa:bb:80
inet addr:10.193.39.254 Bcast:10.193.39.255 Mask:255.255.255.192
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
cubert:~# ping 10.193.39.193
PING 10.193.39.193 (10.193.39.193) 56(84) bytes of data.
64 bytes from 10.193.39.193: icmp_seq=1 ttl=64 time=4.24 ms
64 bytes from 10.193.39.193: icmp_seq=2 ttl=64 time=1.11 ms
^C
--- 10.193.39.193 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.116/2.681/4.247/1.566 ms
cubert:~#
Also looking good, however:
cubert:~# ping 10.193.38.1
PING 10.193.38.1 (10.193.38.1) 56(84) bytes of data.
^C
--- 10.193.38.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1010ms
And eth1 won't respond again until I take down vlan101 and eth1 and
bring eth1 back up again.
cubert:~# ifdown vlan101
Removed VLAN -:vlan101:-
cubert:~# ping 10.193.38.1
PING 10.193.38.1 (10.193.38.1) 56(84) bytes of data.
^C
--- 10.193.38.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1011ms
cubert:~# ifdown eth1
cubert:~# ifup eth1
cubert:~# ping 10.193.38.1
PING 10.193.38.1 (10.193.38.1) 56(84) bytes of data.
64 bytes from 10.193.38.1: icmp_seq=1 ttl=64 time=0.869 ms
64 bytes from 10.193.38.1: icmp_seq=2 ttl=64 time=0.947 ms
^C
--- 10.193.38.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1003ms
rtt min/avg/max/mdev = 0.869/0.908/0.947/0.039 ms
Here is my configuration in /etc/network/interfaces (Debian/Lenny):
iface eth1 inet static
address 10.193.38.254
netmask 255.255.255.0
broadcast 10.193.38.255
network 10.193.38.0
iface vlan101 inet static
address 10.193.39.254
netmask 255.255.255.192
broadcast 10.193.39.255
network 10.193.39.192
vlan_raw_device eth1
A bit of searching found a few references to similar problems going
back a few years (2005, 2007). Sounded like there were some driver
issues, but it wasn't clear from the messages I found whether they
were believed to be fixed or not. I tried the same test using a
differnt NIC with the tg3 driver and there were no problems, so it
looks to me like it's still a via-velocity issue. Unfortunately I
don't have room to add NICs to this machine and need to use the on
board Via hardware.
This is the network hardware on the non-working Via board:
cubert:~# lspci -k
...
02:00.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter (rev 82)
Kernel driver in use: via-velocity
03:00.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter (rev 82)
Kernel driver in use: via-velocity
And on my laptop where this same config does work:
kulgan:~# lspci -k
...
09:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5752 Gigabit Ethernet PCI Express (rev 02)
Subsystem: Dell Device 01d6
Kernel driver in use: tg3
I understand that it's not best practice to combine tagged and
untagged frames on the same link (something to do with VLAN hopping
attacks), so perhaps this is not a priority to fix. However, I'm happy
to test patches if there are any.
Regards,
Kevin Shanahan.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists