1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

detaching wifi from the br0 bridge - dhcp?

Discussion in 'Tomato Firmware' started by bogderpirat, Jul 25, 2009.

  1. bogderpirat

    bogderpirat Network Guru Member

    hi guyse,
    since i got my iptv working (somewhat), my wifi wouldn't work. this is due to the fact that whenever someone watches iptv, the igmpproxy i use floods the entire lan with multicast packets, which results in the wifi-access being hugely sluggish at best.

    i am trying to solve this issue by removing the wifi interface from the bridge, putting it into its own subnet and making routing possible between the two subnets.
    br0's ip is

    i have done this to remove eth1 (wifi-if) from the bridge:
    brctl delif br0 eth1
    then gave the wifi channel an ip:
    ifconfig eth1
    as the routes are automatically added upon setting the ip, i added iptables rules for the two subnets to see each other:
    iptables -A FORWARD -i br0 -o eth1 -j ACCEPT
    iptables -A FORWARD -i eth1 -o br0 -j ACCEPT
    and added forward acceptance so the wifi-clients can access the interwebs:
    iptables -A FORWARD -i eth1 -j ACCEPT

    alright, so far, so good. stuff seems to be working if my wireless client is connected before step one and has a staticly set ip in the .1.x subnet, BUT if i remove eth1 from the br0 bridge and try to associate with the AP afterwards, it always just fails.

    i have tried doing the br0-reconfiguration via nvram, took an educated guess that lan_ifnames (which by default is "vlan0, eth1, eth2, eth3") holds the ifnames for the br0 bridge and changed it to "vlan0". that changed nothing, same behavior as previously mentioned.

    also, there is the issue of dhcp on eth1. i have tried these dnsmasq-options:
    , assuming that dnsmasq would be clever enough to find out that it's supposed to use that ip-range on the eth1 interface (as there, the ip/subnet fits), but they wouldn't work when i rebooted, or killed and had dnsmasq restart again. there's just no dhcp response from that interface to the client.

    i'd greatly appreciate if anyone had a couple of pointers as to how to solve these precarious issues.
  2. bogderpirat

    bogderpirat Network Guru Member

    alright, figured it out.

    first, the wifi-ap-daemon "nas" apparently requires its strict parameter set in order to work.
    what i have done is the following:

    1. remove eth1 (wifi interface) from the lan-bridge (br0)
    [b]brctl delif br0 eth1[/b]
    2. create a new bridge and add the wifi interface to it - this seems to be necessary as "nas" will only allow bridges passed on with the -l parameter.
    [b]brctl addbr br1
    brctl addif br1 eth1[/b]
    3. assign an ip to the new bridge - this should be different from the ip on your br0 bridge.
    [b]ifconfig br1 netmask[/b]
    4. next, we need to restart "nas". since the configuration is apparently saved into /etc/nas.conf upon init, we can extract a valid command line with the contents of the settings we made to the basic/wireless section of the webif. we determine the current settings like so:
    # cat /etc/nas.conf
    nas -P /var/run/nas.pid -l br0 -H 34954
    -i eth1 -A -m 132 -k <wifi psk> -s <wifi ssid> -w 6 -g 3600
    where -l sets the bridge to use, -i the wifi-interface, -g sets the wpa rekey-interval and -m and -w together make up the kind of wpa-encryption and authentication (tkip, aes, tkip/aes).
    since we have our command, we restart nas and bring the wifi device up:
    [b]killall nas
    nas -P /var/run/nas.pid -l br1 -H 35954 -i $(nvram get wl_ifname) -A -m 132 -k $(nvram get wl_wpa_psk) -s $(nvram get wl_ssid) -w 6 -g $(nvram get wl_wpa_gtk_rekey) &
    pause 2
    wlconf $(nvram get wl_ifname) up[/b]
    this should leave us with a working, associateable wifi-network. you should go and test whether it is connectable. you won't get an ip right away, as dnsmasq won't give you an ip, but for the sake of testing, being able to associate with it is enough.

    if this works, we can go on to the second-to last step: the dhcp server:

    5. we adapt our dnsmasq configuration to accommodate for the new subnet on the wifi bridge: in the web-interface, we go to advanced -> dhcp/dns. as the default configuration only uses the br0 bridge for dhcp distribution, we need to add our new bridge as an interface, then create a dhcp range and set both gateway(3) and dns-server(6) to the router's wifi bridge interface ip. hence, under "custom configuration", enter these lines:
    the "wifi"-label here serves to bind the last three lines together, so as to give the dhcp-clients the wifi bridge's ip as gateway and dns-server. this only leaves the last step;

    6. allowing connections from and to the interface, communication between the two bridges and allowing for the wifi bridge's clients to access the internet. this is accomplished using a total of five iptables rules:
    [b]iptables -I INPUT -i br1 -j ACCEPT
    iptables -I OUTPUT -o br1 -j ACCEPT
    iptables -A FORWARD -i br0 -o br1 -j ACCEPT
    iptables -A FORWARD -i br1 -o br0 -j ACCEPT
    iptables -A FORWARD -i br1 -j ACCEPT[/b]
    at this point, you should try to reconnect to your AP and see whether the wireless client gets an ip. if it does, you should be all set to automate the process, which leads us to...

    7. automation: i have formatted those commands we will need to input to the web-interface at one time to bold, so you know which commands you can leave out in this step.
    in the web interface, we navigate to administration/scripts/init, here we enter the lines from steps 1-3 in sequence.
    since nas appears to require some time for the rest of the init process to complete, we have to wait a while, hence after step three's command, insert:
    [b]pause 30[/b]
    you can probably tweak this, but i've seen 30 seconds give the wanted result, and i'm not touching it ever again.
    next, add the commands from step 4.
    step 5 only needs a one time save, so you should have already done this.
    next, navigate to the firewall-script tab and insert the commands from step 6.

    that should be all. broadcast traffic cannot pass from the lan-bridge br0 to our wifi-bridge br1 - which saves us from a dying wifi if we have continuous multicast traffic in our lan.

Share This Page