1897

I think the mistake is mainly due to the file names :slight_smile: Too complicated and too little difference between them.

1 Like
1898

I was never able to get hw offloading + PPPoE + firewall4 fully working. I had connectivity with offloading back in January but devices like the Philips Hue hub and IP cameras with cloud functionality were not reliably connecting even though I had 1G WAN connectivity.

There is an open issue here so I am confident the OpenWrt devs will ultimately get it working:

1899

I think you are OK. I don't remember what the LuCi message said about being in intramfs mode (intramfs recovery is part of the installer file name though).

As long as you are certain you flashed the ubi installer image from the Belkin upgrade page, you should be safe. I would recommend using the 0.6.2 sysupgrade to complete the process then you can configure connectivity and update to the latest snapshots from there.

1 Like
1900

If what you did was flashing the recovery-installer image, then yes, you can now flash a snapshot sysupgrade image for the UBI variant.
If what you did was only flashing the recovery image up to now then you need to power-cycle the device to go back to the vendor/stock firmware.

If you are not sure, login to the device via SSH (ssh root@192.168.1.1) and see if fw_printenv gives you an error. If it correctly prints the environment including ver=U-Boot 2022.01 ..., then you have successfully run the installer and the device is ready to boot from UBI, you can go ahead and flash a snapshot sysupgrade image.

2 Likes
1901

Now it's working. Using kernel 5.15. Thanks, I haven't imagined so much modifications were needed...
CPU1

1902

When wed is not enabled, although the cpu usage is less than 50%, it can be seen through htop that one cpu core is almost fully loaded. But it is very strange that when I did not modify this patch, pppoe offload used to work successfully, but only once.

1903

i wanted to report a successful cross-grade to version 22.03 snapshot, r19200, from 21.02 snapshot r19293 .
i used sysupgrade from an image built with the asu online imagebuilder. i kept settings and used the 'force' option. i'm still trying to keep track of all the tweaks and options but great work so far.

1904

Why did you need to use the force option (ie. which were the two different device identifier strings it would complain about)?

1905

yes - the identifiers were not the same so i got the red box warning. same thing with upgrading to a new custom image with different packages from/to 22.03 r19200

1906

Sorry I wasn't clear. I did reboot, got in the Belkin firmware, flashed the recovery-installer image. ver=U-boot 2022.01... is in fw_printenv. So I flased a snapshot sysupgrade image. Next stop is to get it on the internet: first attempt was not successfull. My internetconnection uses PPPoE so I altered the network file in /etc/config but that didn't help. Aside from trying to get this working I could also change it into an access point via ssh (change ip adress & turn off DCHP) and then connect it to my existing network.

1907

There is some confusion, as to my knowledge the RT3200/E8450 has never existed in 21.02 branch. (You have likely sysupgraded from a master snapshot. Based on those revision numbers, actually you downgraded a bit...)

2 Likes
1908

@hnyman -yes, you are correct; it was the master snapshot from which the 22.03 diverged a little bit ago - so yes, it was a back-grade; not sure if it's a down-grade. it is my understanding that development in the two branches can proceed differently and that not all commits in the master snapshot branch will be identical in the branches. so maybe we should be clear about which branch we are testing and reporting on for further problem identiifcation and resolution?
thank you for keeping people with far lesser knowledge (me) closer to target.

1909

I added some observation of the issue here. Hopefully someone who knows the switch hardware better can comment.

1910

Almost a day without crashes, I am impressed so far. I've made some more tests with qosify on/off (the default config edited just with the up/down bandwidth = 1000mbit). I know that the perception is "any kind of offloading breaks QoS" but I don't have an explanation for the results (see the graph with settings and D/U speeds):

  • using SW offloading, qosify on limits the transfer speed to ~500Mbps and slightly increases CPU usage. Does this mean that qosify is running, consuming CPU, but in vain?
  • using HW offloading, qosify seem to affect just the upload speed and also very slightly increases CPU usage (I tested twice to be sure). So there seems to be an impact with it on, but smaller if compared to the impact when only SW offloading is used. I suppose qosify is running 100% on CPU (i.e. not using the HNAT HQoS engine), so I expected to see the same impact. Or, it could be that the impact in CPU is the same but having more available time due to wed, it can support the downloading transfer rate. What do you think?

Anyway I don't know how to verify if qosify is having a real effect on the actual traffic packages. I don't commonly use any QoS because I don't play mmorpg games and for voice and video calling/streaming I don't have any issues. The bufferbloat test from waveform (having qosify on) are not very concludent to me, usually it says grade A because the latency increases with 50-70% during download, doesn't matter if SW of HW offloading or no offloading is used.
CPU2

2 Likes
1911

This is because quosify does two things: It classified packets using BPF filters and sets their QoS/ToS/DiffServ field. And it sets up tc qdisc to then do packet scheduling based on that classification.
If you enable hw offloading, the scheduling will be carried out in hardware as well. The classifier (BPF) part, however, will still work and that may well result in different behavior from equipment further up the chain.

4 Likes
1912

I am sorry for my limited technical background regarding QoS qdisc etc, as I said it is not very important for my setup, but for others can be important, so I admit I am not clarified on the matter of SW or HW offloading breaking QoS. Does this mean that qosify is working fine, i.e. doing what it should do, even when using either type of offloading? Or only with HW offloading is working fine?

1 Like
1913

same question of gix qosify with sfo work ? and hwo work or broke qosify i'm very interested , thanks for test gix :wink:

1914

I am sure its known but just wanted to point out that after upgrading to SNAPSHOT r19314-8822a8d850 no longer is there a wireguard option under protocol anymore for me when adding new interface under network.

1915

Have you installed the wireguard package and protocol with opkg?
You need to install luci-app-wireguard, and it installs also the protocol and the kernel module)

1916

Hi all,

Looking for tester to test out the VLAN configuration patches I did to the mt753x DSA switch driver. The patch can be found here. I placed the patch file in the target/linux/generic/hack-5.10/ folder.

My E8450 has been running this patch for the past 1 day, without any issue that I can observe. It has 1000mbps and 100mbps clients connected to it, including an OpenVPN tap interface (with a 10mbps link speed according to Luci) that is assigned to the bridge device as well. My E8450 is configured as an AP at the moment tho.

While debugging the code, I noticed that for switch ports that are not assigned to a bridge device, the DSA framework will assign the ports to VLAN 0. This is actually not a good configuration, as VLAN 0 is reserved for priority tagged frames.

I would suggest to assign all switch ports to a bridge device, enable vlan filtering and split them into various VLANs. The default br-lan device can be used, but it doesn't make sense (being pedantic here) if the WAN port is also assigned there. So I remove br-lan and created a bridge called sw0 and assigned all switch ports and L2 logical devices (e.g. OpenVPN tap) to sw0.

Also, a switch port should only be configured as egress untagged for one and only one VLAN. Else depending on sequence the DSA framework (or uci?) add and delete VLANs from the switch ports, the PVID of the switch port may become indeterminate. My patch added warning logs for such a situation.

Do let me know how it goes for you if you decide to test my patch. The patch also works for mt7530 switch hardware, i.e. for the mt7621 routers, but I have not tested on such a router tho.

2 Likes