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#612 - WAN to LAN leakage on MT7620 devices #5625
Comments
kristrev: This bug is probably related to FS#103, which was fixed with commit 566de81. However, this fix does not seem to work for me on the devices I am testing. |
kristrev: After taking a closer look at the commit mentioned in my previous comment, I forced global_vlan_enable to be 0 in mt7530_probed for mt7620-devices. This seems to have solved the leak and without any side-effects. My VLANs, etc. still work fine. I do not know if this an acceptable solution to the problem and if I should send a patch, or I should regard it as an ugly hack and keep it in my own tree? :) |
psyborg55: do you know why input delay (boot timeout?) would be relevant in this case? also check that some similar commit did not cause this? |
kristrev: Hi, Thanks for the reply. I had already removed the script in you link, but with no effect. The reason I suspect the timeout has an impact, is that when I remove the timeout then the switch will already be properly initialized before my server has time to send a DHCP reply. However, I don't think spending time on timeout is worth it, it is not a fix anyway. -Kristian |
kristrev: I did some more testing. I compiled a new bootloader with WAN/LAN partitioning available and then two firmware images, one with my crude fix and another without the fix. For both images, I also instrumented the kernel to write a debug message when mt7530_apply_config() is called. When booting the router, I ran arping querying for the IP of the upstream router. Without my fix, I see roughly ten ARP replies. The time of the first replies matches with the first time apply_config is called, while the number of replies matches pretty well with the time it takes from apply_config() is called for the first time and until the actual switch config is set (i.e., my network config). With my fix (and WAN/LAN partitioning) I saw no ARP replies from the upstream router across ~50 reboots of the router. I also tried to replicate the partitioning steps of the bootloader in the mt7620 switch driver, but I saw some leakage during some boots. If anyone is interested in looking at my mt7620 configuration code, please let me know and I will share it here. I suspect this issue can be fixed without flashing the bootloader, just by setting up the switch correctly. |
jow-: Please share your patch here so that a proper solution can be implemented. |
kristrev: Hi, Sorry for my slow reply, here is the patch (for 4.4). I have to admit that I don't remember all the details and I can't find my notes, but the purpose of the change is to ensure that the code at the top of mt7530_apply_config() is run once on boot. This seemed to be required to isolate the ports properly during boot, before the correct vlan configuration is applied. This fix is not perfect, in the sense that I still sometimes see a few packages leaking if the bootloader is not updated. As I wrote earlier, I tried to replicate all configuration steps from the Mediatek driver, as wel as compare with the one in LEDE, but was not sucessful. -Kristian |
JamesT42: This also affects MT7628 devices like the new TP-Link TL-WR841N V13 |
Crazy: This problem affects also DIR-300 B1 and DIR-615 H1 with LEDE 17.01.3 |
tpham3783: Hi, I just want to share my patch which resolved the issue w/ the leakage, and also enable gigabit speed on the mt7530. Feel free to adopt it if you feel it could be useful. thanks, TP
|
nanixu: This also affects mi wifi nano. i compiled 15.05 as base 7628 borad, but firmware limit to 4m, and don't know how to extend . if anyone can help, i@nanixu.com very appreciated |
sweroam-mibr: I have this issue also, and also a other problem. the default port-map like llllw or wllll etc will create leak between lan ports also. I use some port as trunk ports later in openwrt... i wrote a test patch to the driver that does the following config instead of dts wllll or llllw etc..: this is the result that openwrt gets before the switch is initialized.. result: it works well to prevent leak between all ports on init (fixes: lan to wan lek, lan to lan leak) i then let openwrt initialize the switch using my configuration.. with correct cpu port and config. |
@kristrev just fishing through old issues here, is this still an issue in 22-03/master? ramips was moved to the dsa driver, right? |
kristrev:
I am currently testing two MT7620 devices - the ZBT WE826 and the Sanlinking D240. During the first seconds of the boot, I see that packets leak between the WAN and LAN ports. Typically, this results in clients receiving a DHCP reply from my upstream router, rendering the clients without connectivity when the switch is properly initialized. I have also tested with the default firmware and do not see this behavior. Also, if I stop the devices in the bootloader, then packets do not leak until I resume boot again.
In order to try to solve this bug, I have tried to port some (at least to me) missing steps from the bootloader switch code and to the mt7620 switch driver in LEDE. This did not have an effect, at least not on the packet leak. A work-around I have found is to update u-boot and remove the input delay, so that the device will boot immediately. However, this is quite cumbersome to install and not very reliable. I suspect my luck with this work-around is more due to the timing of the DHCP clients in Ubuntu and Windows 10.
Does anyone have any idea as to what could be wrong and where to start looking?
Thanks in advance for any help.
The text was updated successfully, but these errors were encountered: