Ethernet to phone fails since 4.3.21 firmware

On an Opal routeur I use it for the internet connection of my smartphone, and since this firmware update, I get frequent deconnections. When it happens, it may be long to get the internet back, most of the time I prefer to stop, do something else and come back later to it.
When it is on my computer, there is not such problem, but I don't use an high bandwith on it.
On my phone I watch videos, not on my computer.

I wonder if that can be related to this ..
"Sat Dec 14 18:21:17 2024 daemon.notice netifd: sf_eth_event port 1 updown 1 is_wan 0 vlanid 1 ifname eth0" repeatedly

Is indeed something 4.3.21 does on OPAL.

The beta 4.7.2 version is very stable on OPAL compared to 4.3.21 which does bring down the WAN connection and firewall rules when roaming. Roaming happens when there are multiple AP with the same SSID, or when the OPAL knows passwords for other SSID.

BSSID lock is not simple in 4.3.21 and 4.7.2beta has also more options to control multiWAN.

1 Like

I don't use the wireless (wifi) so I am not sure to understand.
Though I have used it before and I ve let some AP configurations, could it be this that causes trouble ?

If no repeater is used then that roaming is not relevant.
But 4.3.21 and older versions do have some other problems.

See the LOG for any clue.
-MWAN3 load balancing checks, if they see a drop in Internet access (eg PING tests), do reload the firewall rules and drop tracked connections. Recovery might take longer than expected.
-To my understanding the AMPDU packet with more than 31 MPDU packets aggregated are not fully processed. Probably triggered with large volume transfers only.

OK, if I understand well, I must disable the VLAN, and the MWAN3.
I allready disabled VLAN but I still have deconnections.

Notice that I use an ethernet-USB adapter, on an OTG-micro-USB adapter, but at the beginning all that was working well with it.

I was surprised that in the main interface we cannot disable both "Failover" and "Load balancing"

AFAIK the VLAN in OPAL is something internal, and not visible in the GL.inet GUI.
One can see it in the LOG and in the LUCI interface.
AFAIK One VLAN is used for the WAN and one other for the LAN interfaces.

Tue Jan 21 22:14:09 2025 kern.warn kernel: [ 56.729979] set port:1 pvid:1
Tue Jan 21 22:14:09 2025 kern.warn kernel: [ 56.733272] set port:2 pvid:1
Tue Jan 21 22:14:09 2025 kern.warn kernel: [ 56.737154] add port:1 for vlan:1 tagged:0
Tue Jan 21 22:14:09 2025 kern.warn kernel: [ 56.741980] add port:2 for vlan:1 tagged:0
Tue Jan 21 22:14:09 2025 kern.warn kernel: [ 56.746623] add port:5 for vlan:1 tagged:1
Tue Jan 21 22:14:09 2025 kern.warn kernel: [ 56.751086] set port:0 pvid:2
Tue Jan 21 22:14:09 2025 kern.warn kernel: [ 56.754914] add port:0 for vlan:2 tagged:0
Tue Jan 21 22:14:09 2025 kern.warn kernel: [ 56.759536] add port:5 for vlan:2 tagged:1
Tue Jan 21 22:14:09 2025 kern.warn kernel: [ 56.763970] set port:5 pvid:2

In VLAN terminology:

  • port 5 is a trunk port with tagged VLANid 1 and hybrid for VLANid 2 (tagged and probably untagged as pvid=2 is set)
  • port 0,1,2 are Access ports for resp port 0=VLANid 2 , and port1 & 2 for VLANid 1

Disable failover and load-balancing , indeed no. But if you disable the interface status tracking, failover will not happen.

The firewall reload done by the "Hotplug" handlers can be stopped in LUCI (=Force Link). My experience: Giving the interface a fixed IP address (and not DHCP) will set the "Force Link" on as seen in LUCI

Force link

Set interface properties regardless of the link carrier (If set, carrier sense events do not invoke hotplug handlers).

I use a fixed IP address for all my devices

I deleted all that is in Wi-fi in LuCi but that didn't fix the problem, or perhaps it is better.
I disabled the interface status tracking too.

I think this error message is about the WAN ethernet port going down.
Some wifi clients (smartphone) disconnect wifi when they cannot reach internet on the current wifi link. With ethernet WAN failing, the internet will not be reachable.

I am with 4.7.2 now but I ve still some deconnections. Perhaps it is different now because the connection is back after I re-plug the ethernet or the USB. It is to early to be sure.


Update
It is weird because yesterday night I had the best connection in a long time, and this morning it was the worse in all time. I finally ended by stopping it because when after re-plugged the connection was not back most of the time and if it was back, it lasted only some seconds...

While this happened I plugged the computer on LAN1 to check, and thre was no deconnections at continuous pings.

As this beta version didn't fix the problem as also a new ethernet cable, I am going to try to reset the routeur. Is there a chance ?
If this is not enough I ll downgrade to 4.3.19, in that case I d like to know what sort of risks I take, in which function.

I am now back with the 4.3.19 firmware but I am still with these problems....
So now I begin to wonder if it is not a problem as my Ethernet-USB adapter broke or what.

Have you tried a different power supply for the Opal?

update :
Some evolution appears : more and more it is from the start that the ethernet connexion doesn't establish... I mean, as soon as I connect the USB to the phone. And in this case, nothing works, disconnecting reconnecting doesn't work anymore. So yesterday I had to try something else.
So I connected this phone from the same LAN slot (on gl-inet) to the computer and then the connection was established immediately (without internet). And after this I connected the phone to my ISP's box (bridge mode), and the connection was established immediately too. The connection was quite good, I could swipe on videos. I had some deconnections too but finally it worked quite well compared to the opal access.

I am with this system : Internet (cable) --- Sagemcom (bridge) -- ethernet -- Opal -- ethernet -- computer (LAN 1) or phone (LAN2)

@hecatae
Have you tried a different power supply for the Opal?

No

Chatgpt told me to buy some one in one ethernet-microUSB adapter with USB-A for an additionnal power supply.

It cannot be the power supply because my phone is 720p ... and USB 2.0

1 Like