You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, we discussed this in the matrix chat and here is a concise description of the issue.
The neighbor cache does not prioritize active connections, so when on a noisy network the active connection will stop sending/receiving sometimes.
I'm testing on a "noisy" network and the connection gets glitches of 1 second every time the active connection's IP is evicted from the cache and needs to do an ARP.
I propose that active connections (on a successful RX) to have their expiry time reset on every successful packet, so they are not evicted from the cache.
My reasoning is that since the connection is functioning and we are getting packet with the correct IP/MAC combo there is no need to do ARPs.
@thvdveld agreed on my analysis in the chat and recommended to look at how Linux solves this.
Hi, we discussed this in the matrix chat and here is a concise description of the issue.
The neighbor cache does not prioritize active connections, so when on a noisy network the active connection will stop sending/receiving sometimes.
I'm testing on a "noisy" network and the connection gets glitches of 1 second every time the active connection's IP is evicted from the cache and needs to do an ARP.
I propose that active connections (on a successful RX) to have their expiry time reset on every successful packet, so they are not evicted from the cache.
My reasoning is that since the connection is functioning and we are getting packet with the correct IP/MAC combo there is no need to do ARPs.
@thvdveld agreed on my analysis in the chat and recommended to look at how Linux solves this.
Here is a log of the issue:
The text was updated successfully, but these errors were encountered: