Bit of openwrt Vlan newbie here
I want to create a single vlan on port 4, seemed straight forward...
default install then I add the following nvram vars & reboot then the router is not pingable
but with the right timing on the reset button  it back in failsafe & I can unset the vars & reboot

nvram set vlan0ports="1 2 3 5*"
nvram set lan_ifnames="vlan0 eth1 vlan2"
nvram set lan2_hwaddr="00:0F:66:C5:D2:93"
nvram set lan2_iface="vlan2"
nvram set lan2_ifname="vlan2"
nvram set lan2_ifnames="vlan2"
nvram set lan2_ipaddr="192.168.2.2"
nvram set lan2_netmask="255.255.255.0"
nvram set lan2_proto="static"
nvram set vlan2ports="4 5"
nvram set vlan2hwname="et0"
nvram commit

interesting if i dont set lan2_ipaddr,  lan2_netmask,  lan2_proto
and just reboot then ifconfig vlan2 192.168.2.2 netmask 255.255.255.0
it still works the interface on vlan2 is self pingable

@OpenWrt:/# ping 192.168.2.2
PING 192.168.2.2 (192.168.2.2): 56 data bytes
64 bytes from 192.168.2.2: icmp_seq=0 ttl=64 time=1.7 ms
64 bytes from 192.168.2.2: icmp_seq=1 ttl=64 time=1.0 ms

but it will not ping another box on the same subnet conncted to port 4

and the route looks I think OK
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.2.0     *               255.255.255.0   U     0      0        0 vlan2
192.168.1.0     *               255.255.255.0   U     0      0        0 br0
24.68.216.0     *               255.255.252.0   U     0      0        0 vlan1
default         24.68.216.1     0.0.0.0         UG    0      0        0 vlan1

and the ifconfig

@OpenWrt:/# ifconfig
br0       Link encap:Ethernet  HWaddr 00:0F:66:C5:D2:93
          inet addr:192.168.1.254  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:270 errors:0 dropped:0 overruns:0 frame:0
          TX packets:206 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:20439 (19.9 KiB)  TX bytes:22233 (21.7 KiB)

eth0      Link encap:Ethernet  HWaddr 00:0F:66:C5:D2:93
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:478 errors:0 dropped:0 overruns:0 frame:0
          TX packets:446 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:48770 (47.6 KiB)  TX bytes:49861 (48.6 KiB)
          Interrupt:5 Base address:0x2000

eth1      Link encap:Ethernet  HWaddr 00:0F:66:C5:D2:95
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:38
          TX packets:3 errors:25 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:1794 (1.7 KiB)
          Interrupt:4 Base address:0x1000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  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)

vlan0     Link encap:Ethernet  HWaddr 00:0F:66:C5:D2:93
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:272 errors:0 dropped:0 overruns:0 frame:0
          TX packets:206 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:21787 (21.2 KiB)  TX bytes:23057 (22.5 KiB)

vlan1     Link encap:Ethernet  HWaddr 00:0F:66:C5:D2:93
          inet addr:XX.XX.XX.XX  Bcast:255.255.255.255  Mask:255.255.252.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:204 errors:0 dropped:0 overruns:0 frame:0
          TX packets:212 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:18241 (17.8 KiB)  TX bytes:22497 (21.9 KiB)

vlan2     Link encap:Ethernet  HWaddr 00:0F:66:C5:D2:93
          inet addr:192.168.2.2  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:28 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:4307 (4.2 KiB)

(Last edited by tclark on 6 Nov 2005, 00:28)

So just for the archives i was told on irc that the /etc/init.d/S40network scripts
ignore *_iface nvram settings, and also 1 interface should not be in multiple *_ifname(s)

So i tried

nvram set lan_ifnames="vlan0 eth1"
nvram set vlan0ports="1 2 3 5*"
nvram unset lan4_hwaddr
nvram unset lan4_iface
nvram unset lan4_ifname
nvram unset lan4_ifnames
nvram unset lan4_ipaddr
nvram unset lan4_netmask
nvram unset lan4_proto
nvram unset vlan4ports
nvram unset vlan4hwname

nvram set lan4_hwaddr="00:0F:66:C5:D2:93"
nvram set lan4_ifname="vlan4"
nvram set lan4_ifnames="vlan4"
nvram set lan4_ipaddr="192.168.4.1"
nvram set lan4_netmask="255.255.255.0"
nvram set lan4_proto="static"
nvram set vlan4ports="4 5"
nvram set vlan4hwname=et0
nvram commit

Then edit S40netwrok to bring up lan4
cp /etc/inid.d/S40network S40network.std
rm  /etc/inid.d/S40network
mv  /etc/inid.d/S40network.std S40network
#!/bin/sh
case "$1" in
  start|restart)
    ifup lan
    ifup lan4
    ifup wan
    ifup wifi
    wifi up

    for route in $(nvram get static_route); do {
      eval "set $(echo $route | sed 's/:/ /g')"
      $DEBUG route add -net $1 netmask $2 gw $3 metric $4 dev $5
    } done
    ;;
esac

Well at least the box does not lock up but after a reboot and vlan4 is there & has an ip
and now responds to an internal ping to 192.168.4.1 on the open wrt
**BUT**
wont respond to external ping to a box at 192.168.4.2 connected to port 4
some iptables rules missing ?

closer ...:) but not quite there

(Last edited by tclark on 6 Nov 2005, 18:11)

We went through similar exercises in these threads:

http://forum.openwrt.org/viewtopic.php?id=2656
http://forum.openwrt.org/viewtopic.php?id=2438

- lan4_ifnames should not be set since lan4_ifname isn't a bridge (the *_ifnames are only used when *_ifname starts with br*)

- the vlans are set when the et.o driver loads, if you change the vlan*ports you'll need to reload the et.o module or simply reboot.

- the firewall defaults to "DROP", prohibiting connections between interfaces. An exception for lan is made in S45firewall but for extra interfaces you'll want to edit firewall.user

Well the lastest in vlan wars from last nite

1st 54gs 192.168.1.1
-----------------------
WAN | 1 | 2 | 3 | 4 |  vlan4 port 4 192.168.4.1
------------------------
                           |
                           |
                           |
2nd 54gs 192.168.1.254                       
-----------------------
WAN | 1 | 2 | 3 | 4 |  vlan4 port 4 192.168.4.2
------------------------
          |
          |
   192.168.1.201

nvram set lan4_hwaddr="00:13:10:EA:D7:38"
nvram set lan4_ifname="vlan4"
nvram set lan4_ipaddr="192.168.4.1"
nvram set lan4_netmask="255.255.255.0"
nvram set lan4_proto="static"
nvram set vlan4ports="4 5"
nvram set vlan4hwname=et0
nvram commit

nvram set lan4_hwaddr="00:0F:66:C5:D2:93"
nvram set lan4_ifname="vlan4"
nvram set lan4_ipaddr="192.168.4.2"
nvram set lan4_netmask="255.255.255.0"
nvram set lan4_proto="static"
nvram set vlan4ports="4 5"
nvram set vlan4hwname=et0
nvram commit

#reboot both wrtg4s's
#then added ifup lan4 to /etc/init.d/S40network
added this to  /etc/firewall.user
iptables -I FORWARD -i vlan4 -j ACCEPT
iptables -I INPUT -i vlan4 -j ACCEPT
iptables -I OUTPUT -o vlan4 -j ACCEPT

1) both vlan4 comes up
2) ping between both vlan4 ..OK
3) ping from  192.168.1.201 192.168.4.2 ..OK
4) ping from a 192.168.1.201  to 192.168.4.1 fails
6) ping from a 192.168.4.1 to 192.168.1.201   fails

OK I put a sniffer on the vlan4 on 192.168.4.1
I C the ping request going to the 1st  wrt54gs port 4 on subnet 192.168.4.1

this is the tcpdump of the vlan4 on 192.168.4.1
00:35:18.884888 IP 192.168.1.201 > 192.168.4.1: icmp 40: echo request seq 26881
00:35:18.885708 arp who-has 192.168.1.201 tell 192.168.4.1
00:35:19.880102 arp who-has 192.168.1.201 tell 192.168.4.1

the arp table on  192.168.1.1
IP address       HW type     Flags       HW address            Mask     Device
192.168.1.201    0x1         0x0         00:00:00:00:00:00     *        vlan4
192.168.1.9      0x1         0x2         00:06:29:F7:48:39     *        br0
24.68.XX.XX      0x1         0x2         00:00:77:95:EC:F8     *        vlan1
192.168.4.2      0x1         0x2         00:0F:66:C5:D2:96     *        vlan4

so i added
route add -net 192.168.1.201 netmask 255.255.255.255 gw 192.168.4.1
(route add -host 192.168.1.201  gw 192.168.4.1)

192.168.1.201   192.168.4.1     255.255.255.255 UGH   0      0        0 vlan4
192.168.4.0     *               255.255.255.0   U     0      0        0 vlan4
192.168.1.0     *               255.255.255.0   U     0      0        0 br0
24.68.XX.XX     *               255.255.252.0   U     0      0        0 vlan1
default         24.68.216.1     0.0.0.0         UG    0      0        0 vla

Thinking that this should help those lost packets on 192.168.4.1 find their
way back out 192.168.4.1 to the 192.168.4.2
but arps still wants some one to tell 192.168.4.1 where 201 is

I thought in this situation the arp table should have the mac address of  vlan4
why is my 201's all 0's after adding the route between subnets ?

I assume this is not an iptables issue ..
but some simple routing rule that is staring me iin the face

(Last edited by tclark on 9 Nov 2005, 03:34)

Well this is just to tell this continuing saga

mbm pointed out incorrect firewall rules (yup my bad ..)
so I did a (also rm /etc/init.d/S45firewall out of the way & rebooted for good measure)
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

which iptables -l confirms we now only any accpet policy

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

yet arp is still complaining from the tcpdump -ivlan4
00:10:26.228044 IP 192.168.1.201 > 192.168.4.1: icmp 40: echo request seq 42753
00:10:26.228813 arp who-has 192.168.1.201 tell 192.168.4.1
00:10:27.220091 arp who-has 192.168.1.201 tell 192.168.4.1
00:10:27.650509 IP 192.168.1.201 > 192.168.4.1: icmp 40: echo request seq 43009
00:10:28.220091 arp who-has 192.168.1.201 tell 192.168.4.1
00:10:28.651727 IP 192.168.1.201 > 192.168.4.1: icmp 40: echo request seq 43265
00:10:29.652903 IP 192.168.1.201 > 192.168.4.1: icmp 40: echo request seq 43521
00:10:29.653486 arp who-has 192.168.1.201 tell 192.168.4.1
00:10:30.650082 arp who-has 192.168.1.201 tell 192.168.4.1
00:10:31.650080 arp who-has 192.168.1.201 tell 192.168.4.1

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.201   192.168.4.1     255.255.255.255 UGH   0      0        0 vlan4
192.168.4.0     *               255.255.255.0   U     0      0        0 vlan4
192.168.1.0     *               255.255.255.0   U     0      0        0 br0
24.68.216.0     *               255.255.252.0   U     0      0        0 vlan1
default         24.68.216.1     0.0.0.0         UG    0      0        0 vlan1

I am open to any thoughts as to what is going on here
Is this an issue where I need a metrics in the table I thought that the most specfic dest ip is matched 1st
so i should not be getting conflict with the
192.168.1.0     *               255.255.255.0   U     0      0        0 br0

Is there any way to see inside the routing table in real time to see what the
Kernel IP routing is realy doing ??

(Last edited by tclark on 9 Nov 2005, 17:51)

OK finally found a way to do this, after googling around on iptables MASQUERADE voodo
and mbm heavy hints   to look at *_rules in firewall.user more closely
#1st 54gs 192.168.1.1
iptables -t nat -A postrouting_rule -o $LAN4 -j MASQUERADE
#2nd 54gs 192.168.1.254
iptables -t nat -A postrouting_rule -o $LAN4 -j MASQUERADE

But
I guess if anyone would like to clarify why this can't be done with the simple static route on
1st 54gs 192.168.1.1
with a default iptable policy of accept on each router I'd luv to have them fill into those blanks

(Last edited by tclark on 10 Nov 2005, 01:08)