Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#449 - relayd can cause dropped packets if client has /proc/sys/net/ipv4/conf/*/rp_filter=1 #5490

Open
openwrt-bot opened this issue Feb 1, 2017 · 1 comment
Labels

Comments

@openwrt-bot
Copy link

@openwrt-bot openwrt-bot commented Feb 1, 2017

troth:

DEVICE: N/A (can be reproduced on any system running relayd)
LEDE version: N/A (can be reproduced on a VM running debian with relayd installed)

Steps to reproduce:

  • Run relayd on a system (aka router)with two interfaces.
  • Run a stock Ubuntu-16.04 system (aka client) connected to the managed interface.
  • Run another system (aka server) on the other interface of relayd system.
  • Have server ping client and watch connectivity drop out periodically.
  • Have client ping server and watch connectivity drop out periodically.

Our fix for the problem need two changes:

  • Add arptables rules to system to handle kernel level arp requests properly via mangling the source address in the arp requests
  • Modify relayd to send the correct src addr in the arp requests that it generates.

Our changes to relayd are here:

From commit message for my fix:

Add option to set arp src addr for managed interfaces.
Relayd will send arp requests out a managed interface like this:

    Who has 192.168.1.40, tell 192.168.2.1

In most cases, this works, but some clients will not send a reply (on
linux, client will not reply if /proc/sys/net/ipv4/conf/*/rp_filter is
set to 1, which happens to be the default on ubuntu-16.04).

Add '-s' option to tell relayd to use the specified addr as the arp src
addr for managed interfaces. The arp requests would then look like:

    Who has 192.168.1.40, tell 192.168.1.100

for which the client properly sends a reply.

The symptoms of the problem manifest as dropped packets due to the
kernel marking the arp entry for the client as FAILED due to lack of
responses to the arp requests. Eventually (10-30 seconds later), the arp
table is updated and connectivity is restored.
@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Nov 20, 2019

SamuelH91:

I have observed same issue as reported in this. I haven't tried the custom build fix yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant