bridge mode PS5 stops forwarding ARPs to wireless network

[ctaylor]

A few times I've noticed that I loose connectivity with a station connected to a PS5 in bridge mode running 3.1.1.3498. Some nodes on the wired side can talk to the station but others can't. The problem seems to be that we stop getting ARP responses from the station, so only nodes that have the station in their ARP cache can talk to the station.

If I ssh into the AP and ping the station, I don't get a response, but if I ssh into the station and ping the AP, then the AP is suddenly able to ping the station. If I stop the pings on the AP and wait for the ARP cache on the station to timeout, then I stop being able to ping the station. If I run tcpdump on the station and look for "arp or icmp", then I don't see the ARP requests from the AP to the station.

It seems like at some point the AP isn't forwarding all the ARP requests to the wireless side. This isn't a packet loss problem, the link seems just fine. This didn't happen right away the PS5 had been up for ~15 days before we noticed a problem and it went away when I rebooted the AP.

Any ideas?
Clem

[UBNT-keba]

Are you using WDS?

[ctaylor]

Are you using WDS?


I'm not using WDS, QOS, or any of the firewall functionality.

The PS5 AP is in bridge mode and there are typically 50-60 entries in the bridge table and the arp cache typically only has 1 or 2 entries. I'm using the PS5 and NS5s to move video streams, so they are in continuous use (most of the APs are running at 10-20mbps all the time).

[sldnkarm]

Have you looked at arpnat_cache in /proc/net/ directory to see if you see all the entries?

I have tried to setup a 'bridge' with Station Mode, and ran into a problem when a client hooked up a Cisco Firewall configured with two separate IP's on one external interface. We could only reach one IP at a time, and found that arpnat_cache would only keep track of one IP-MAC relationship for each MAC. As long as I tied one IP to one MAC and a second IP to a second MAC, the bridge works fine. But most of the time, our customers will already be utilizing a firewall with this setup. Is WDS the only way to support a Multi-IP-single-MAC relationship? Is this just a shortfall of linux and the way ebtables works, or a shortfall of the 802.11 protocol?

[sldnkarm]

This has been 'fixed' in release 3.5. I have tested the release earlier this afternoon on a CPE (PS2 running station mode) for a client but due to thier setup I could only ping one of the ip's tied to thier edge mac, but we did confirm with a packet capture that both ip's were in fact being utilized.

I reverified the setup tonight on my home connection which uses the same hardware. Three ip's tied to one mac behind the station-bridge PS2. All looks good and is behaving well at this point. Take a look at the /proc/net/arpnat_cache file contents. You will see changes in behavior in the contents of that file.

Anyone know if this new code will support mulit-mac/multi-ip while running in station mode? Previously this was only possible by running the CPE in station-wds mode.

[UBNT-Mike.Ford]

This has been 'fixed' in release 3.5. I have tested the release earlier this afternoon on a CPE (PS2 running station mode) for a client but due to thier setup I could only ping one of the ip's tied to thier edge mac, but we did confirm with a packet capture that both ip's were in fact being utilized.

I reverified the setup tonight on my home connection which uses the same hardware. Three ip's tied to one mac behind the station-bridge PS2. All looks good and is behaving well at this point. Take a look at the /proc/net/arpnat_cache file contents. You will see changes in behavior in the contents of that file.

Anyone know if this new code will support mulit-mac/multi-ip while running in station mode? Previously this was only possible by running the CPE in station-wds mode.

Hello,

For Multi-MAC mode you will still have to use WDS mode.

Thanks,

Mike

[sldnkarm]

Mike,
have you verified this function in your lab? I just tested this function today and to my delight I was able to support multi-MAC/multi-IP while the unit was running in station(wireless)/bridge(network) modes.

If you could provide anymore details on the changes made to the arpnat function, it would help a great deal. We are looking for any details regarding any limitations to the number of supported mac/ip combinations.

Let me know if you need any additional details of our test setup. This is a huge improvement to the units, as it removes our dependancy on having to use WDS to support these types of connections. As you know, manufacture inter-operability when using WDS is a royal PITA.

This makes the UbNT line of products that much more valuable to us...

[gunther_01]

WDS is the only way to have "true" bridging capabilities in 802.11x.. It would probably be better for you to route if you need to assign multiple IP's per interface MAC. If I'm not mistaken, anything else would be ARP-proxy which can cause lots of weird issues. Like the ones your seeing

[sldnkarm]

Gunther/Mike/All,

You will get no argument from me that to create a "true" bridge via 802.11 bridges is to have the units configured in a WDS manner. The thing I would like answered is what are the limitations of using the arpnap function now available in the units? I have just verified once again that I can support a pseudo "true" bridge like installation without enabling WDS.

Here is the layout of the test setup.
AP_MikroTik ---> RF <--CPE_PS2 <--Ethernet-->Switch_HP<--Ethernet-->Server_1&2

MikroTik - reg table not reporting a wds connection for the PS2 associated.
PS2 - configured for station(wireless) bridge(network)
HP - combines the connections of the two linux servers (these devices hold the two interfaces that are outlined in the 'arpnat_cache' file.

XS2.ar2316.v3.5.4494.091109.1451# cat arpnat_cache
00:0e:0c:d9:6e:81 24909.13 192.168.10.3 0
00:0e:0c:d9:6e:81 25184.33 10.100.1.46 0
00:0e:0c:d9:64:ec 24890.15 192.168.10.2 0
00:0e:0c:d9:64:ec 25185.27 10.100.1.44 0

I can transfer files (four at a time to each IP listed above with no issues). These are all being transferred via SCP (port22). Here are the results:
back-test.mdb 100% 60MB 176.1KB/s 05:48 (to 10.100.1.44)
back-test.mdb 100% 60MB 171.7KB/s 05:57 (to 10.100.1.46)
test.back.mdb 100% 60MB 177.6KB/s 05:45 (to 192.168.10.3)
test.back.mdb 100% 60MB 169.3KB/s 06:02 (to 192.168.10.2)

I fully understand that there may be limitations with using the above configuration. Our reasoning behind it is that trying to support (and find) successful WDS connections between multiple vendors is a major hurdle and very difficult to support into the future. We just need more information to be aware of the limitations when using arpnat so that we can make a decision on how to deploy and support these types of connections. Keep in mind that on many different vendors, there are limitations of just how many WDS can be supported simultaneously by an access point. Were just trying to compare limitations on both side.

[gunther_01]

It would still be better to route ;).. but since you can proxy-ARP and if there isn't a hard number for the pairings (Mike?) It will be probably processor and RAM limited. Which ultimately will slow down your max transfer rates from the overhead.

Just be carefull if you intend to continue your network (through) such a set-up. Like adding a repeater or something of that nature.. We lost proxy-arp a while back with Star-OS, so we route everything and never looked back.