Gargoyle Forum

Posted: **Fri Jun 25, 2010 7:04 pm**

Care to share your tweaks/changes, and the rationale behind them? I'm always looking to improve.

By the way, there should be 2.6.32 support in the default patch in the source repository now, though this has NOT been thoroughly tested. Right now it's at the "yay, it compiles!" stage for 2.6.32, though it is working/tested for 2.6.30.

Posted: **Sat Jun 26, 2010 2:52 am**

Eric wrote:Care to share your tweaks/changes, and the rationale behind them? I'm always looking to improve.

Of course I do. Sorry - it was quite late at my end of the world when I posted.

Basically everything worked just fine out of the box using gargoyle/patches-generic-backfire/04-arpnat.patch against the OpenWRT backfire tree from SVN (substituting 2.6.32 for 2.6.30 where appropriate).

The only thing I really had to change was the EXPORT_SYMBOL line in 701-arpnat.patch / linux-2.6.32.10/net/bridge/br_fdb.c because the compiler complained about br_fdb_get missing. Someone seems to have added two underscores in the meantime:

Code: Select all

+--- linux-old/net/bridge/br_fdb.c      2009-09-15 13:46:05.000000000 -0400
++++ linux-2.6.32.10/net/bridge/br_fdb.c        2009-09-22 19:52:51.000000000 -0400
+@@ -415,3 +415,5 @@
+               spin_unlock(&br->hash_lock);
+       }
+ }
++EXPORT_SYMBOL(__br_fdb_get);
++

For some strange reason, things compiled, linked and generally work, so I figure I'm fine with that change. As I said, I'm not much into the gory details of Linux driver development.

The other thing I changed was the /etc/hotplug.d/net/20-client_bridge script. I moved it to the ebtables package, because I wouldn't install madwifi, and I felt it could just belong there. And I changed the first two lines to check for Broadcom, too:

Code: Select all

is_wlan=$(echo $INTERFACE | grep -e wlan -e ath)
if [ -n "$is_wlan" ] ; then
        if [ "$ACTION" = "add" -o "$ACTION" = "register" ] ; then
                sleep 2

That was about it. Compiled, flashed my router, arpnat works like a charm.

I guess I'll give it some testing now, which in my case means using it in sort of production mode on a box connecting my desktop PC via WLAN to the rest of my network. (Of course, I do have a working 2.4 Broadcom firmware around, just in case.) Given the amount of data flowing over that link, I'd run into trouble very soon if things failed. I'll keep you posted.

Posted: **Wed Jun 30, 2010 8:48 am**

Thanks! I had already found the __br_fdb_get issue, but you're right that ebtables is a much better place for the hotplug script than the madwifi package. I'll plan on moving it in the near future.

Posted: **Thu Jul 01, 2010 3:30 pm**

So far I've got two days of continuous uptime now, and no obvious problems. By the way, I just noticed that

Code: Select all

grep -e wlan -e ath

is probably too specific, especially if that script is moved to ebtables.

Posted: **Thu Aug 05, 2010 5:15 pm**

I have made some minor modifications to the latest arpnat patch from the repository so that it would work against the trunk from OpenWRT. I using r22340, and 5160499e for OpenWRT and 04-arpnat.patch respectively.

The only change required was a directory renaming issue (there is no generic-2.6/ directory, only generic/).

I added what I felt was a nice enhancement that eliminates the necessity for the "client_bridge" flag, and the associated hotplug script. The ebtables setup in this patch is handled in the lib/madwifi.sh script instead. There is a section that detects when the interface is being added to a bridge. In this case, the script now checks to see if the interface mode=sta and wds=0, and, if so, sets up the arpnat configuration. Here is a highlight of the relevant code in the enable_atheros function:

Code: Select all

    local net_cfg bridge
    net_cfg="$(find_net_config "$vif")"
    [ -z "$net_cfg" ] || {
        bridge="$(bridge_interface "$net_cfg")"
        config_set "$vif" bridge "$bridge"
        start_net "$ifname" "$net_cfg"

        [ "$mode" = "sta" -a "$wds" = "0" ] && {
        if_mac=$(ifconfig "$ifname" | grep HWaddr | awk '{ print $5 }')
        ifconfig "$bridge" hw ether "$if_mac"

        clear_ebtables "$ifname"
        setup_ebtables "$ifname"
    }

clear_ebtables and setup_ebtables are ripped from the hotplug script and basically handle all the ebtables commands. clear_ebtables is also called in the disable_atheros() function.

It seems reasonable to me that if you are in sta mode and bridged (and have the arpnat patch installed) that this should just work, which it does without any necessity to manually edit the configuration files. Also, it requires no modification to the web UI.

Anyhow, I've attached the complete patch if anyone is interested.

Posted: **Thu Sep 02, 2010 1:24 pm**

MacFrog: Your enhancement has now been incorporated into the latest experimental branch. Sorry it took so long to get around to this, but I'm only now looking at adding mac80211 support.

valenumr: Actually, just because a wireless interface is part of a bridge doesn't mean arpnat needs to be active. It's only if it's part of a bridge with more than one interface in it that arpnat is necessary. For ease of configuration the routed client mode is implemented with the wan interface as a bridge with a single wireless interface in it, and in this case arpnat is not necessary. Also, the client_bridge flag in the uci config is useful for the configuration in the web interface, not just the hotplug script. Therfore, I've decided not to include your suggested patch at this time, but I appreciate your suggestion.

Gargoyle Forum

arpnat 2.6.32 and Later

Re: arpnat 2.6.32 and Later

Re: arpnat 2.6.32 and Later

Re: arpnat 2.6.32 and Later

Re: arpnat 2.6.32 and Later

Re: arpnat 2.6.32 and Later

Re: arpnat 2.6.32 and Later