OpenWrt/LEDE Project

Welcome to the OpenWrt/LEDE Project bug reporting and issue tracking system

Problems to be reported here are for the OpenWrt/LEDE Project targets, sources, toolchain, core packages, build procedures, distribution and infrastructure. Guidelines for submitting a good bug report can be found at the OpenWrt/LEDE Project website. Problems related to LuCI or OpenWrt packages need to be reported in their repositories:

Notifications of all submissions and task changes are sent to lede-bugs@infradead.org.

OpenedIDCategoryTask TypePrioritySeveritySummaryReported InStatus
06.02.20202816Base systemBug ReportVery LowLowPoor upload speed with Relayd and Mediatek SoCsTrunkUnconfirmed Task Description

Raising a bug report to highlight there may be a problem with relayd performance issues with MT7621 and MT7628 SoCs

Wireless signal strength and link speeds reported by the devices are OK when displayed in LuCI, but the measured data throughput on upload link is extremely poor. Less than 1 Mbps.

Examples of affected devices include Xiaomi R3G, RT-AC57U and C50 v4.

Xiaomi R3G & RT-AC57U

Archer C50 v4

When using prebuilt owrt images, there is nothing in system log to indicate there are any problems.

01.02.2017449Base systemBug ReportVery LowLowrelayd can cause dropped packets if client has /proc/sy...TrunkUnconfirmed Task Description

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:

* https://github.com/troth/relayd/commit/c8d895ee71be59262f01c3fdf50f307ebf1593e7

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.
03.12.2016320Base systemFeature RequestVery LowLowrelayd feature requestTrunkUnconfirmed Task Description

I found a couple of bugs with relayd based bridge configuration and I would like to suggest a feature request. Will fill one entry per issue:

On today’s trunk

3- in a configuration where the network attached to the wireless radio is configured via DHCP, the listening interface is not set up automatically. DD-WRT and Gargoyle do this automatically ( they overwrite the config/network file with the gateway parameter and reload relayd.

 


Showing tasks 1 - 3 of 3 Page 1 of 1

Available keyboard shortcuts

Tasklist

Task Details

Task Editing