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.
arpnat 2.6.32 and Later
Moderator: Moderators
Re: arpnat 2.6.32 and Later
Of course I do. Sorry - it was quite late at my end of the world when I posted.Eric wrote:Care to share your tweaks/changes, and the rationale behind them? I'm always looking to improve.
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);
++
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
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.
Re: arpnat 2.6.32 and Later
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.
Re: arpnat 2.6.32 and Later
So far I've got two days of continuous uptime now, and no obvious problems. By the way, I just noticed that is probably too specific, especially if that script is moved to ebtables.
Code: Select all
grep -e wlan -e ath
Re: arpnat 2.6.32 and Later
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:
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.
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"
}
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.
- Attachments
-
- arpnat_backfire.tgz
- (26.62 KiB) Downloaded 453 times
Re: arpnat 2.6.32 and Later
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.
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.