I need to force an ARP poll in the following situation:
- Machine A is talking to machine B over a wireless bridge
between two LANs. The wireless bridge will forward broadcast
Ethernet packets like ARP polls, but otherwise will only send
a packet to a MAC address in its cache.
- The wireless bridge on the B side is power cycled, losing
its ARP cache.
- Machine A has the MAC address of B’s bridge cached,
so it doesn’t send ARP polls.
- B’s wireless bridge receives IP packets for B, but
doesn’t know the MAC address to use for them. So
it drops them.
I can get out of this situation manually by using “arp -d” to delete
all the machines on B’s LAN. This forces ARP polls, which
cause B’s bridge to be updated. But I need to make this work
without manual intervention. How?
John Nagle
In the absence of any indication from the bridge you’re
left with trying to detect the situation yourself via
some sort of poll. However this really sounds like a broken
bridge… Usually they record the source so the next time
it shows up as a dst it’s found. And if the dst isn’t
found, it goes out all interfaces whether it’s broadcast
or not.
Are you sure there’s no option to enable the above
behaviour?
-seanb
John Nagle <nagle@downside.com> wrote:
I need to force an ARP poll in the following situation:
- Machine A is talking to machine B over a wireless bridge
between two LANs. The wireless bridge will forward broadcast
Ethernet packets like ARP polls, but otherwise will only send
a packet to a MAC address in its cache.
- The wireless bridge on the B side is power cycled, losing
its ARP cache.
- Machine A has the MAC address of B’s bridge cached,
so it doesn’t send ARP polls.
- B’s wireless bridge receives IP packets for B, but
doesn’t know the MAC address to use for them. So
it drops them.
I can get out of this situation manually by using “arp -d” to delete
all the machines on B’s LAN. This forces ARP polls, which
cause B’s bridge to be updated. But I need to make this work
without manual intervention. How?
John Nagle
Sean Boudreau wrote:
In the absence of any indication from the bridge you’re
left with trying to detect the situation yourself via
some sort of poll. However this really sounds like a broken
bridge… Usually they record the source so the next time
it shows up as a dst it’s found. And if the dst isn’t
found, it goes out all interfaces whether it’s broadcast
or not.
Yes, the bridge is dumb.
The destination nodes don’t respond to broadcast
IP messages, which is correct behavior.
But part of the problem is that QNX continues to
keep the MAC address in the ARP cache when the
device is no longer responding. How does ARP
timeout work under QNX?
John Nagle
John Nagle <nagle@overbot.com> wrote:
Sean Boudreau wrote:
In the absence of any indication from the bridge you’re
left with trying to detect the situation yourself via
some sort of poll. However this really sounds like a broken
bridge… Usually they record the source so the next time
it shows up as a dst it’s found. And if the dst isn’t
found, it goes out all interfaces whether it’s broadcast
or not.
Yes, the bridge is dumb.
The destination nodes don’t respond to broadcast
IP messages, which is correct behavior.
But part of the problem is that QNX continues to
keep the MAC address in the ARP cache when the
device is no longer responding. How does ARP
timeout work under QNX?
It walks the arp cache every 5 minutes looking for entries
that are >= 20 minutes old and removes them. Same as in
NetBSD.
-seanb