1

I have come across a number of variations on the problem described below with router/access-points and WiFi range extenders from various manufacturers.

  • All devices are wireless.
  • LAN/WLAN made up of several general-purpose router/switch/access-point devices, or WLAN extenders, all working on the same SSID. These are from common manufacturers such as NETGEAR and TP-Link.
  • Only a single device acts as an Internet router.
  • There is only a single DHCP server.
  • Access-point-A and Access-point-B are connected by wired LAN.

The following sequence describes the scenario:

  1. Client-device-1 is connected to Access-point-A
  2. Client-device-2 is also connected to Access-point-A
  3. Applications on Client-device-2 are communicating with applications on Client-device-1, typically using TCP.
  4. Client-device-2 is moved in space so that it switches to Access-point-B.
  5. Communication between the applications ceases (fails).
  6. Network trace on Client-device-1 shows (TCP) packets arriving from Client-device-2 and packets being sent in the reverse direction but it seems that those packets fail to arrive at Client-device-2.
  7. Client-device-2 continues to have good Internet access (which actually goes via the router in Access-point-A).

To me it feels like the routing (packet-forwarding) cache in Access-point-A does not notice that Client-device-2 is no longer available via itself, even though packets from Client-device-2 are arriving via its wired interface.

If Client-device-2 is initially connected to Access-point-B then there are no problems.

enter image description here

Any suggestions as to the cause of the problem, other than just rubbish router/access-point firmware, would be appreciated.

Use of quality managed products such as Ubiquiti's UniFi never seems to show such issues.

Improve this question
6
  • 1
    what model of access points are these? Are they access point/routers or only access points. It sounds like you have a mac table issue. If they're all switches, no routing is involved. – Ron Trunk May 29 '20 at 15:36
  • To me, it looks like bad-behaving applications (e.g. not connecting after TCP RST, server session lingering too long, etc) or your access points act as gateway and breaking routing on roaming. Does resetting server, client, or both application resolves your issue; or you need to reconnect to your AP to re-establish your server-client connection? – mforsetti May 29 '20 at 15:53
  • @RonTrunk I'd rather not name specific models at this time. This bad behaviour has been observed with multiple devices from different manufacturers including both access point/routers and range extenders. I did wonder whether I should have used the term "forwarding" or "packet-forwarding" rather than "routing" - I do understand that no layer-3 routing is involved here. – awy May 30 '20 at 8:47
  • @mforsetti I have verified that it is not applications behaving badly with respect to TCP behaviour. Access-point-B in the example is an access-point/router but it is not acting as a gateway or DHCP server and its WAN port is not in use. As mentioned in my previous comment, the same behaviour has been observed with at least one model of range extender. – awy May 30 '20 at 8:51
  • 1
    I imagine what @RonTrunk is getting at is less about the brand, but what kind of device it is. For example, a Linksys WRT based router + AP can be plugged into an upstream router on a LAN link and people think it will "just be an AP." But unless you did special reprogramming, it is actually still a router and will maintain an internal ARP table with forwarding info. That'll cause it to blackhole connections until the ARP is updated. Same for some extenders (also, try to avoid extenders, they're evil and only to be used as an absolute last resort) – Ruscal Jun 14 '20 at 5:59
0

This happens because of shortcoming in 802.11 specifications. Specifically, wireless extenders cannot receive any other packets than the packets with their MAC address.

Short summary:

Client 1 still things that client 2 has the same MAC address, but when client 2 moves behind virtual extender, its client 1 facing MAC address changes. Therefore client 1 ARP table contains incorrect information.

Here is an example of packet flow when clients are under same AP and when another is behind wireless extender.

MAC addresses of different stations are:

Client 1: 00:11:22:33:44:55 Client 2: 00:11:22:33:44:66 Extender: 00:11:22:33:55:66

Clients under same AP

  1. Client 1 sends a packet to Client 2. Client 1 has resolved Client 2 address using ARP. Packet source MAC is 00:11:22:33:44:55 and destination 00:11:22:33:44:66
  2. Client 2 sends a response. Destination MAC has been resolved using ARP. Packet source MAC is 00:11:22:33:44:66, destination 00:11:22:33:44:55.

Client 2 behind wireless extender

In this case, wireless extender performs MAC address translation, because it cannot otherwise relay packets to client 2.

  1. Client 1 sends a packet to Client 2. The address was earlier resolved to be 00:11:22:33:44:66, so client 1 tries to send packet to that MAC. However, there is nothing in the current AP recognizing the MAC address, so sending fails.
  2. Client 1 tries to resolve eventually the MAC address of Client 2 using ARP. Wireless extender now can respond that "MAC address of Client 2 is 00:11:22:33:55:66 (extender MAC address)".
  3. Client 1 sends packet to wireless extender MAC address, which then forwards the packet to Client 2.

I don't know how this could be resolved.

Improve this answer
1
  • Thanks. My example was for a wired interconnect between APs (although I did also mention range extenders), and so in this case Client 2's MAC address, as seen by Client 1 and Access-point A, does not change. The layer-2 routing, possibly associated with the ARP-table entry, does change and I suppose this could be significant. – awy Jun 15 '20 at 8:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.