Hi! I was able to keep compiling by commenting out this part of the code:
/*WARN_ONCE(tag_ops->proto.needed_tailroom,
"The DSA TAG %s is added to the end of the packet."
"It will break HW and SW checksum for any driver "
"incompatible with that TAG (different vendor)",
tag_ops->proto->name);*/
But I believe this is part of the HW offload fix @luizluca created, right?
Hi luizluca, I'm trying to compile sysupgrade image for my C5 v4, using the branch tplink_c5v4_dsa_5.15up.
For config, select:
Target system : MediaTek Ralink MIPS
Subtarget : MT7620 based boards
Target profile : TP-Link Archer C5 v4
also
Enable experimental features by default
The image compiles successfully, but when flash it to the router, no ports seems to work (wan & lan). Only wifi works when enable it from serial console.
Am I missing something, or doing something wrong?
Thanks in advance!
i guess you are missing a kernel driver patch for the switch or not enabled the vendor specifc DSA tag + vendor specifc DSA switch support for your device..
Because the branch is specific for TP-Link Archer C5 v4 DSA, i suppose the necessary patches are included and the switch support is enabled when select the same model. Am I right?
i think this device isn't officially supported by openwrt
the releases available here https://github.com/benwht/openwrt/releases which work well, use a realtek switch patch
i remember bec i used the patch for building for my c5 v4 few years ago
Yes, I also used benwht's patch and know that his patch works. But because that patch is not applicable for OpenWrt 21.02, I decided to switch to luizluca's https://github.com/luizluca/openwrt/tree/tplink_c5v4_dsa_5.15up to try it.
And that's why I asked if anybody tried to compile luizluca's specific branch to help me set it correctly.
@luizluca, "Enable experimental features by default" auto-selects "Use the testing kernel version". The wan and lan ports don't work with neither tplink_c5v4_dsa_5.15up nor tplink_c5v4_dsa branches. There is Rx activity, but no Tx traffic.
It should have worked. You do need to have packages kmod-switch-realtek-mdio installed. If is selected by default in a clean config but nothing prevents the user to unselect it.
Did I do the right thing when I combined all the interfaces of the router into one bridge? Without this, nothing worked stably on the internal network connected to the router.
How to view all packets passing through all ports of the router to the outside and entering from the Internet? Is it possible to configure a SPAN port on this router?
I believe the port is finished. Again the repo is the same.
It requires testing kernel (CONFIG_HAS_TESTING_KERNEL=y) and it might automatically select CONFIG_PACKAGE_kmod-switch-realtek-mdio (menuconfig does not prevent you from removing it). Everything I tested worked as expected, even failsafe.
It include dozens of pending patches, but only for OpenWrt. Many of those patches for OpenWrt are related to mediatek network driver for mt7620. I might start to submit them soon. All required upstream changes are already merged (backported from 5.16 .. 5.19/net_next). However, I'm not sure it is safe (for other devices) to have that much of backported patches. DSA is still evolving upstream and the changes I picked might also break another DSA driver. Anyway, time is our ally and we'll get them for free as soon as OpenWrt goes to the next LTS kernel (post 5.15).
Changes since the last update:
Resets started to work (not fixed by me). I removed the hack and USB and both wireless started to work
The issue with only 1 LAN client was the internal mediatek switch not happy with realtek forwarding frames in CPU. I disabled the source mac learning and it now works as expected.
I don't believe the port can get much better than this. Except from a better switch driver (that actually does forwarding in HW) or a better 2.4G wifi (yes, it still sucks as before), there is no more room for large improvements. The mix "mediatek Soc + any non-mediatek DSA switch" might be slower than swconfig because mediatek cannot handle TCP checksum offload with a DSA tag. I didn't evaluated if an 802.1Q DSA tag might work better but the driver might need to improve before we try.
I didn't do a performance compassion between DSA, swconfig and factory but I expect DSA to be the slowest one. And don't expect good LAN to LAN performance until we get a proper fowarding in HW.
As I said, I might start to send some preliminary patches to the list soon. Even if all of them get merged, I might still wait for the next testing kernel before submitting the device port. The required backported patches might also be submitted by someone willing to use that Realtek driver for another device. @hauke submitted some upstream patches indicating he is working on another Realtek device. There are plenty of them already in OpenWrt.
Once all generic patches are applied, the device patch is a boring DTS declaration (with a minor LED config).
connect your device to the router LAN port (1-4)
to start the TFTP recovery process on the router, press and hold the “Reset button” and then power up the router. Keep the “Reset button” pressed until the WPS LED turns on (it's the LED with two arrows pointing in different directions)
If everything went well, you should see a read request on your TFTP server
There is no possible fix.
