I'm working on using the arpnat module in another project (well, basically the same project, only using ath9k instead of madwifi). I've gotten it to kinda work with 2.6.26, but the problem is, the ath9k driver, when used with 2.6.26 is flaky at best. I'd like to use a more recent kernel, but there seems to have been some significant changes to the ebtables/xbtables architecture in that timetable, and updating the arpnat module to the more recent kernel is beyond my skillset.
Has there been any work done to update this module to the 2.6.32.x series?
arpnat 2.6.32 and Later
Moderator: Moderators
Re: arpnat 2.6.32 and Later
I'll probably get to this in the next couple of months when I migrate to Backfire. However, Backfire hasn't officially branched off from OpenWrt trunk yet, so I'm not going to start work on this until it does.
Re: arpnat 2.6.32 and Later
Out of curiosity, are you its (arpnat) primary maintainer? Is there an actual project page somewhere for it I can't find?
Re: arpnat 2.6.32 and Later
Eh... it would be a stretch to describe me as the primary maintainer of arpnat. I just happen to be the only one (as far as i can tell) who has worked on this with some of the more recent kernels.
There really is no central project for maintaining arpnat. It's a hack devised by willigear which spread to both ubiquity networks and DD-WRT. The version I'm using was originally adapted from the version in the DD-WRT SVN repository.
There really is no central project for maintaining arpnat. It's a hack devised by willigear which spread to both ubiquity networks and DD-WRT. The version I'm using was originally adapted from the version in the DD-WRT SVN repository.
Re: arpnat 2.6.32 and Later
Sorry to bump this old thread. With the recent 1.3.0 release how's the arp-nat status? does it work with ath9k now?
Thanks.
Thanks.
Re: arpnat 2.6.32 and Later
There's support for the 2.6.30 kernel now, but I haven't yet tried it with 2.6.32.
Re: arpnat 2.6.32 and Later
I'm playing with arpnat now. Just got done building backfire+arpnat for my DIR-615 Rev C1. If it works, I'll add a little more generic approach to using arpnat to Luci/UCI.
Re: arpnat 2.6.32 and Later
I'm not sure which wireless driver you're using, but one thing to be aware of with madwifi:
There's a really strange bug that I run into when I try using madwifi+WPA. I'm fairly sure its not a bug in arpnat, but in madwifi. The problem is that when I have a device running madwifi in client mode with WPA, no initial ARP requests/broadcasts get through. Responses go through just fine, and it works fine with WEP/no encryption. I see all this without arpnat enabled or even compiled. So, what I find is that arpnat works fine with no encryption or wep, but in situations with WPA this bug prevents any ARP requests from the AP from getting through, and if an entry in the ARP cache on the AP side has expired, hosts on the AP side of the bridge can't resolve an address, and suddenly can't connect. The way the caches on the AP side get initialized in the first place, is from the initial gratuitous ARP broadcast.
If you run across this and/or have any suggestions about how to address it, that would be very helpful.
There's a really strange bug that I run into when I try using madwifi+WPA. I'm fairly sure its not a bug in arpnat, but in madwifi. The problem is that when I have a device running madwifi in client mode with WPA, no initial ARP requests/broadcasts get through. Responses go through just fine, and it works fine with WEP/no encryption. I see all this without arpnat enabled or even compiled. So, what I find is that arpnat works fine with no encryption or wep, but in situations with WPA this bug prevents any ARP requests from the AP from getting through, and if an entry in the ARP cache on the AP side has expired, hosts on the AP side of the bridge can't resolve an address, and suddenly can't connect. The way the caches on the AP side get initialized in the first place, is from the initial gratuitous ARP broadcast.
If you run across this and/or have any suggestions about how to address it, that would be very helpful.
Re: arpnat 2.6.32 and Later
not gotten a chance to reflash... but I'm using ath9k.
What you describe sounds like madwifi or the atheros hardware implementing some sort of mac filter, but there have been similar complaints about intel's radios on the linux wireless mailing list lately, so perhaps it's either a kernel/netdev issue, or wireless subsystem issue. I hadn't paid much attention to it.
What you describe sounds like madwifi or the atheros hardware implementing some sort of mac filter, but there have been similar complaints about intel's radios on the linux wireless mailing list lately, so perhaps it's either a kernel/netdev issue, or wireless subsystem issue. I hadn't paid much attention to it.
Re: arpnat 2.6.32 and Later
I just wanted to say thank you! arpnat for 2.6.32 was exactly what I had been looking for literally for years!
I'm using an unmodified ASUS WL500gP (original Broadcom chip set). So when I first started using OpenWRT on that device, I had to resort to the proprietary Broadcom driver, along with the 2.4 kernel series. I've been dying to upgrade to 2.6, though, for quite some time. Simply because it should be possible. And because I felt that 2.4 was rather old. And because I didn't believe there was such a big performance penalty. Using the proprietary Broadcom driver, that set-up had in fact already been working fine for me.
To cut a long story short: I've tweaked your patch to work with kernel 2.6.32, compiled and flashed my router. And it seems to work exceptionally well so far.
I'm not really versed in wireless / network / driver development, but if I can help out with testing new code against my hardware, I'll be glad to do so.
Again: Thanks a lot, Eric, and whoever else has contributed!
I'm using an unmodified ASUS WL500gP (original Broadcom chip set). So when I first started using OpenWRT on that device, I had to resort to the proprietary Broadcom driver, along with the 2.4 kernel series. I've been dying to upgrade to 2.6, though, for quite some time. Simply because it should be possible. And because I felt that 2.4 was rather old. And because I didn't believe there was such a big performance penalty. Using the proprietary Broadcom driver, that set-up had in fact already been working fine for me.
To cut a long story short: I've tweaked your patch to work with kernel 2.6.32, compiled and flashed my router. And it seems to work exceptionally well so far.
I'm not really versed in wireless / network / driver development, but if I can help out with testing new code against my hardware, I'll be glad to do so.
Again: Thanks a lot, Eric, and whoever else has contributed!