Hi Erich,
It is working for me with 2.4.34 in one office and on my test LAN. I will be
rolling it out in 12 other offices in the next month or so. Here is my
configuration.
>From /etc/interfaces
# Step 2: configure internal interface
auto eth1
iface eth1 inet static
address 192.168.101.254
netmask 255.255.255.0
broadcast 192.168.101.255
vlan_raw_device eth1
# Add VLANS
auto eth1.5
iface eth1.5 inet static
address 192.168.201.254
netmask 255.255.255.0
broadcast 192.168.201.255
vlan_raw_device eth1
up echo 1 > /proc/sys/net/ipv4/conf/eth1.5/arp_filter
up echo 2 > /proc/sys/net/ipv4/conf/eth1.5/arp_ignore
up echo 1 > /proc/sys/net/ipv4/conf/eth1.5/rp_filter
ip addr shows
4: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:40:63:ef:c4:b1 brd ff:ff:ff:ff:ff:ff
inet 192.168.101.254/24 brd 192.168.101.255 scope global eth1
6: eth1.5: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
link/ether 00:40:63:ef:c4:b1 brd ff:ff:ff:ff:ff:ff
inet 192.168.201.254/24 brd 192.168.201.255 scope global eth1.5
The tagged VLAN is being used for public Internet access in a few meeting rooms
and with a WiFi access point. I am using HP 2600 series switches to tie it all
together.
The LEAF hardware is a VIA Mini-ITX EK10000G which uses the via-rhine driver. I
also have a couple of Intel boards in the system which use the eepro100 driver
but I am only using VLANs on the via-rhine interface.
The system has been in place for about 2 months without issues with light
loading.
Let me know if you need any other details.
Dave
-----Original Message-----
From: Erich Titl [mailto:erich.t...@think.ch]
Sent: Wednesday, August 12, 2009 5:10 AM
To: leaf-user@lists.sourceforge.net
Subject: [leaf-user] Kernel crash with vlan on Bering 3.1 Kernel 2.4.34
Hi folks
has anyone successfully used vlan tagging on the above mentioned release.
I have the folowing set up on a WRAP with natsemi interfaces
################################################################
#
# eth2 / Fixed IP
#
auto eth2
iface eth2 inet static
address 10.250.21.1
netmask 255.255.255.0
################################################################
# end of generated interface file
################################################################
auto eth2.34
iface eth2.34 inet static
address 192.168.223.1
netmask 255.255.255.0
################################################################
So eth2 is untagged while eth2.34 is a tagged interface
it shows up like
5: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0d:b9:00:80:42 brd ff:ff:ff:ff:ff:ff
inet 10.250.21.1/24 scope global eth2
6: ipsec0: <NOARP> mtu 0 qdisc noop qlen 10
link/void
7: ipsec1: <NOARP> mtu 0 qdisc noop qlen 10
link/void
8: ipsec2: <NOARP> mtu 0 qdisc noop qlen 10
link/void
9: ipsec3: <NOARP> mtu 0 qdisc noop qlen 10
link/void
10: eth2.34: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
link/ether 00:0d:b9:00:80:42 brd ff:ff:ff:ff:ff:ff
inet 192.168.223.1/24 scope global eth2.34
so basically it looks like the vlan tagging is enabled and working, but
as soon as I try to use the eth2.34 interface, for example to ping a
station on that vlan like 192.168.223.11 the kernel panics with a NULL
pointer dereference.
STYX# ping 192.168.223.11
PING 192.168.223.11 (192.168.223.11): 56 data bytes
Unable to handle kernel NULL pointer dereference at virtual address 0000003c
*pgd = 0
*pmd = 0
Oops: 0000
CPU: 0
EIP: 0010:[<c48c31ae>] Not tainted
EFLAGS: 00010206
eax: 00000000 ebx: 00000022 ecx: c391af00 edx: c48c5af4
esi: 00000000 edi: 00000081 ebp: 00000040 esp: c0229f0c
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, stackpage=c0229000)
Stack: c37bd81e c48c41b2 00000000 00000022 c391af00 00000000 00000081
00000040
c01920c3 c391af00 00000000 c48c5af4 c345e000 c0226b28 00000000
c019215b
c391af00 00036ca3 c0226bf0 c0226b28 00036ca3 00000046 c0192242
c0226b28
Call Trace: [<c48c41b2>] [<c01920c3>] [<c48c5af4>] [<c019215b>]
[<c0192242>]
[<c0121df2>] [<c011492c>] [<c0111c0e>] [<c01167b8>] [<c0111c0e>]
[<c0110018>]
[<c0111c31>] [<c0111c89>] [<c01039c7>] [<c0110199>]
Code: ff 70 3c e8 65 ff ff ff 89 c2 31 c0 85 d2 59 74 07 0f b7 c3
<0>Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
Thanks for pointers
Erich
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
------------------------------------------------------------------------
leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/
