1 (edited by essdz 2010-03-23 13:44:22)

Topic: Fails to forward ARP with hostapd using multiple virtual interfaces

All,

I'm using trunk r20254, WNDR3700 router (ath9k on 2.4 GHz and 5 GHz) with wpad-mini...but I think my test case should apply to even a standard single-band router. Testing this doesn't require anything other than an OpenWrt router.

I previously reported a problem when trying to use some wireless speakers via AirTunes across the 5 GHz interface of my router. After pulling out much hair, I finally found the source of the problem, and it applies to . It actually relates to the usage of hostapd in a multi-VIF configuration when WPA2-PSK is enabled. If I have only one VIF in use, or if I have multiple VIFs but the connection is unencrypted, everything works fine. (In my referenced AirTunes post, I had multiple VIFs on 5 GHz and only a single VIF on 2.4 GHz, so I originally thought that the problem was 5G-related, but that turns out not to be the case.)

Would someone else be willing to try this test to confirm this issue too? If so, I will go ahead and file a bug.

TEST SEQUENCE (WORKING):

- Router is configured as 192.168.1.1.
- Set up your wireless interface to use WPA2-PSK, and enable only one virtual interface on the radio (in AP mode). This interface should be bridged to your wired Ethernet ports as usual.
- SSH into the router and try to continuously ping a nonexistent IP address on the local subnet (eg. 192.168.1.123).
- Using a client computer connected to the router wirelessly, run tcpdump with an arp filter (eg. "tcpdump -i <wlan_device> arp") on the wireless interface.
- If you see ARP who-has requests for 192.168.1.123 coming into the wireless interface at a periodic interval, everything works.

TEST SEQUENCE (BROKEN):

- Do everything as above, except set up two VIFs on the *same* radio (both also in AP mode). Ensure that WPA2-PSK is used on both.
- Now connect the client to each wireless interface in turn, listening for the same ARP requests from your ping.
- If you see ARP requests on only one (or neither) of the interfaces, something is presumably broken.

Note that the presence of multiple interfaces seems to be a problem even when all of the multiple VIFs are assigned to different local networks! (In other words, even when only one WLAN is assigned to the br-lan network that should be receiving the corresponding ARP traffic, the mere presence of additional VIFs attached to OTHER different LAN segments causes it to break.)

I'd really appreciate it if someone could help confirm this for me. If it works for you (or not), please state your platform, wireless chipset and build version.

2 (edited by zorxd 2010-03-23 13:20:55)

Re: Fails to forward ARP with hostapd using multiple virtual interfaces

I can confirm the bug with r20299 on a WNDR3700

Re: Fails to forward ARP with hostapd using multiple virtual interfaces

I did a little searching before submitting a bug report, and I ran across some old messages on the linux-wireless list stating that the "nohwcrypt" parameter had to be enabled with ath9k in order to use wireless interfaces.

So, I wrote to the ath9k-devel list myself, and sure enough, virtual interfaces with encryption still seem to be broken unless that module parameter is used.

Thus, if you want to use virtual interfaces with encryption on (presumably) any ath9k platform, one must enable the nohwcrypt module parameter.

To make this happen automatically at OpenWrt bootup, edit the last line of /etc/modules.d/27-ath9k to read:

ath9k nohwcrypt=1

The downside of adding this param is that, not surprisingly, your wireless performance gets decimated. I am seeing a 10X slowdown in transfer rates when I disable hardware encryption!

I believe that the NETGEAR manufacturer's firmware supports a guest virtual interface on the same radio, so this leads me to suspect that this is just a driver issue and that the hardware is capable of doing what we want.

Re: Fails to forward ARP with hostapd using multiple virtual interfaces

There is a tentative patch available for this issue here.

5 (edited by todada 2010-05-06 20:39:00)

Re: Fails to forward ARP with hostapd using multiple virtual interfaces

Is this is supposed to be a problem also if encryption is used on both radios?

I use the WNDR3700 (trunk 21239) with radio0 connected as client to a router, and providing an AP over radio1. Both using WPA2-PSK.

The client connection over radio0 works fine. But as soon as traffic starts on radio1, the connection to the router is lost.

Are both radios handled independently, or is there a chance to fix this issue using the patch?


EDIT
After having a quick look at the patch I just tried setting the same key for both radios. Seems now to work much better (I will do more tests, though).

Re: Fails to forward ARP with hostapd using multiple virtual interfaces

todada wrote:

Is this is supposed to be a problem also if encryption is used on both radios?

I use the WNDR3700 (trunk 21239) with radio0 connected as client to a router, and providing an AP over radio1. Both using WPA2-PSK.

The client connection over radio0 works fine. But as soon as traffic starts on radio1, the connection to the router is lost.

Are both radios handled independently, or is there a chance to fix this issue using the patch?


EDIT
After having a quick look at the patch I just tried setting the same key for both radios. Seems now to work much better (I will do more tests, though).

I believe that the driver has (in theory) one instance per radio, so I think different encryption configs on different physical radios should have no impact. (Someone, feel free to correct me if I'm wrong!) The issue is apparently related to the keycache in the actual hardware chip.

I also noticed that the patch for this issue was applied into the Linux wireless-testing branch a while ago. I have not yet checked to see if it has made it into the latest OpenWRT compat-wireless release, but I am sure that it will get here sooner or later...

Re: Fails to forward ARP with hostapd using multiple virtual interfaces

Wow - thanks for posting this. I was wondering what was going on with this. Is there a way to set the module to actually load with this config in an existing build? Do we just use modprobe.d?