Skip to content
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#3500 - umbim: problem registering to network with Huawei K5150 and a virtual movile operator #8369

Closed
openwrt-bot opened this issue Dec 9, 2020 · 10 comments · Fixed by #10456
Labels

Comments

@openwrt-bot
Copy link

mantinan:

Hi!

The problem is that the card registers to network in a weird way and thus the mbim.sh script stops and doesn't continue attaching to network, ...

The problem has been detected on a Huawei EchoLife HG556a (version C) but seems a general problem.

Also, the problem was with a ID 12d1:1f16 Huawei Technologies Co., Ltd. K5150 LTE modem but I believe that it can happens on other mbim devices as well.

I believe the problem is more related to the fact that the SIM is from a virtual movile operator which is then using the network from the real operator: Orange, but we didn't test any other SIMs, so we don't know if this is more general, if needed we could try to get some other SIMs for testing.

The problem is that when we do the network registration with umbim it gives an error, so it stops there, so we tried to remove that check like this:

--- mbim.sh.orig 2020-12-04 15:11:47.000000000 +0100
+++ mbim.sh 2020-12-03 16:30:34.000000000 +0100
@@ -99,11 +99,7 @@
tid=$((tid + 1))

    echo "mbim[$$]" "Register with network"
  •   umbim $DBG -n -t $tid -d $device registration || {
    
  •           echo "mbim[$$]" "Subscriber registration failed"
    
  •           proto_notify_error "$interface" NO_REGISTRATION
    
  •           return 1
    
  •   }
    
  •   umbim $DBG -n -t $tid -d $device registration
      tid=$((tid + 1))
    
      echo "mbim[$$]" "Attach to network"
    

So that it would continue no matter how the network registration felt, and it worked giving us this log:

Wed Dec 9 11:41:27 2020 daemon.notice netifd: wwan (1405): wwan[1405] Using proto:wwan device:/dev/cdc-wdm0 iface:wwan0 desc:Huawei K5150 composite
Wed Dec 9 11:41:27 2020 user.notice firewall: Reloading firewall due to ifup of lan (br-lan)
Wed Dec 9 11:41:28 2020 daemon.notice netifd: wwan (1405): mbim[1405] Reading capabilities
Wed Dec 9 11:41:28 2020 daemon.notice netifd: wwan (1405): devicetype: 0002 - removable
Wed Dec 9 11:41:28 2020 daemon.notice netifd: wwan (1405): cellularclass: 0001
Wed Dec 9 11:41:28 2020 daemon.notice netifd: wwan (1405): voiceclass: 0001 - no-voice
Wed Dec 9 11:41:28 2020 daemon.notice netifd: wwan (1405): simclass: 0002
Wed Dec 9 11:41:28 2020 daemon.notice netifd: wwan (1405): dataclass: 8000003F
Wed Dec 9 11:41:28 2020 daemon.notice netifd: wwan (1405): smscaps: 0003
Wed Dec 9 11:41:28 2020 daemon.notice netifd: wwan (1405): controlcaps: 0001
Wed Dec 9 11:41:28 2020 daemon.notice netifd: wwan (1405): maxsessions: 0003
Wed Dec 9 11:41:28 2020 daemon.notice netifd: wwan (1405): deviceid: 860112021925542
Wed Dec 9 11:41:28 2020 daemon.notice netifd: wwan (1405): firmwareinfo: V8.1
Wed Dec 9 11:41:28 2020 daemon.notice netifd: wwan (1405): hardwareinfo: CH1K5150M
Wed Dec 9 11:41:28 2020 daemon.notice netifd: wwan (1405): mbim[1405] Checking pin
Wed Dec 9 11:41:28 2020 daemon.notice netifd: wwan (1405): Pin Unlocked
Wed Dec 9 11:41:28 2020 daemon.notice netifd: wwan (1405): mbim[1405] Checking subscriber
Wed Dec 9 11:41:29 2020 daemon.notice netifd: wwan (1405): readystate: 0001 - initialized
Wed Dec 9 11:41:29 2020 daemon.notice netifd: wwan (1405): simiccid: 8934250220007795837F
Wed Dec 9 11:41:29 2020 daemon.notice netifd: wwan (1405): subscriberid: 214035090779583
Wed Dec 9 11:41:29 2020 daemon.notice netifd: wwan (1405): mbim[1405] Register with network
Wed Dec 9 11:41:29 2020 daemon.notice netifd: wwan (1405): nwerror: 0000 - unknown
Wed Dec 9 11:41:29 2020 daemon.notice netifd: wwan (1405): registerstate: 0004 - roaming
Wed Dec 9 11:41:29 2020 daemon.notice netifd: wwan (1405): registermode: 0001 - automatic
Wed Dec 9 11:41:29 2020 daemon.notice netifd: wwan (1405): availabledataclasses: 0020 - lte
Wed Dec 9 11:41:29 2020 daemon.notice netifd: wwan (1405): currentcellularclass: 0001 - gsm
Wed Dec 9 11:41:29 2020 daemon.notice netifd: wwan (1405): provider_id: 21403
Wed Dec 9 11:41:29 2020 daemon.notice netifd: wwan (1405): provider_name: Orange
Wed Dec 9 11:41:29 2020 daemon.notice netifd: wwan (1405): roamingtext: (null)
Wed Dec 9 11:41:29 2020 daemon.notice netifd: wwan (1405): mbim[1405] Attach to network
Wed Dec 9 11:41:29 2020 daemon.notice netifd: wwan (1405): nwerror: 0000 - unknown
Wed Dec 9 11:41:29 2020 daemon.notice netifd: wwan (1405): packetservicestate: 0002 - attached
Wed Dec 9 11:41:29 2020 daemon.notice netifd: wwan (1405): uplinkspeed: 0
Wed Dec 9 11:41:29 2020 daemon.notice netifd: wwan (1405): downlinkspeed: 0
Wed Dec 9 11:41:29 2020 daemon.notice netifd: wwan (1405): mbim[1405] Connect to network
Wed Dec 9 11:41:30 2020 daemon.notice netifd: wwan (1405): sessionid: 0
Wed Dec 9 11:41:30 2020 daemon.notice netifd: wwan (1405): activationstate: 0001 - activated
Wed Dec 9 11:41:30 2020 daemon.notice netifd: wwan (1405): voicecallstate: 0000 - none
Wed Dec 9 11:41:30 2020 daemon.notice netifd: wwan (1405): nwerror: 0000 - unknown
Wed Dec 9 11:41:30 2020 daemon.notice netifd: wwan (1405): iptype: 0003 - ipv4v6
Wed Dec 9 11:41:30 2020 daemon.notice netifd: wwan (1405): mbim[1405] Connected, starting DHCP

Network connection works ok like this and we can access Inet without any problem.

So... either umbim is not exiting with the right exit code, maybe because of that unknown status it says there, or if the exit code is ok, then we should somehow do farder tests and continue like we did, as the connection is good anyway.

This was also tested using latest available snapshot builds with the same results, we have gone back to stable (these logs are from 19.07.4) as the snapshot build was having trouble with the wifi on this router, but the umbim problem and the solution we applied worked the same on snapshot as it does on stable.

If you need any other info, just ask.

Regards.

@openwrt-bot
Copy link
Author

mantinan:

As you can see on the log this virtual movile network registration is carried like if we were roaming, this is quite typical here in Spain with all virtual operators, movile phones often tell you you are roaming and if you don't allow roaming it won't let you connect.

Maybe all the issue is just because of the roaming thing, I don't know, but then it would also affect all other roaming scenarios.

Regards.

@juliogonzalez
Copy link
Contributor

Somehow I think I hit this at https://forum.openwrt.org/t/huawei-k5150-uqmi-does-not-work/134482/13 (problem was not uqmi, as the K5150 does not support it)

@juliogonzalez
Copy link
Contributor

juliogonzalez commented Aug 13, 2022

I think the problem happpens at https://git.openwrt.org/?p=project/umbim.git;a=blob;f=cli.c;h=3a845d463d843040e19325de2098831ca47fb014;hb=HEAD#l153:

	if (le32toh(state->registerstate) == MBIM_REGISTER_STATE_HOME)
		return 0;

	return le32toh(state->registerstate);

According to https://git.openwrt.org/?p=project/umbim.git;a=blob;f=mbim-enum.h;h=3f6f414df4d5f144d6d355c321a4bd078277ed16;hb=HEAD#l511, 4 is the code for MBIM_REGISTER_STATE_HOME and 5 for MBIM_REGISTER_STATE_PARTNER

AFAIK in both situations the SIM is correctly registered, just not on the home network.

Of course, roaming can be dangerous because (at least if international), it can be costly. So to some extent it makes sense umbim does not blindy return 0 in such situations (at least not without a parameter that enables roaming).

So my guess is that it would be better to implement changes at https://github.com/openwrt/openwrt/blob/master/package/network/utils/umbim/files/lib/netifd/proto/mbim.sh, to add new proto options:

  • allow_roaming
  • allow_partner

And avoid considering 4 and 5 as errors if they are set.

Opinions?

@juliogonzalez
Copy link
Contributor

juliogonzalez commented Aug 13, 2022

As you can see on the log this virtual movile network registration is carried like if we were roaming, this is quite typical here in Spain with all virtual operators, movile phones often tell you you are roaming and if you don't allow roaming it won't let you connect.

BTW, beside the OMVs (Virtual Movile Operators, here in Spain), we also have https://en.wikipedia.org/wiki/European_Union_roaming_regulations.

@juliogonzalez
Copy link
Contributor

@mantinan, seems it seems you reported the issue, maybe you want to have a look at the PR (if you still need the fix)

@mantinan
Copy link

I have managed to get the devices back and update them to 22.03.0 and it works ok, I don't need anything for the sim to register, great. I believe that this issue can thus be closed, at least for my use case, that is.

@mantinan
Copy link

I have just realised that I tested just plain 22.03.0 without any additional changes and it worked, however... looks like the PR that @juliogonzalez sent is still not commited on master, so it was not on my tests using 22.03.0 that worked ok.

If the PR is not applied and it is working for me... maybe the PR is not needed anymore.

Regards.

@juliogonzalez
Copy link
Contributor

@mantinan are you using exactly the same SIM? Did your carrier changed since 2022?

Maybe it just doesn't use roaming anymore?

@mantinan
Copy link

Yes, looks like you are right, the SIM is from R, which was using the network from Orange, now Yoigo/Masmovil has bought R, so it is using Yoigo's network and thus this is not roaming anymore.

Here is the log where we can see the change in the network (provider now is yoigo):

Fri Sep 30 08:48:47 2022 daemon.notice netifd: wwan (2336): mbim[2336] Register with network
Fri Sep 30 08:48:48 2022 daemon.notice netifd: wwan (2336): nwerror: 0000 - unknown
Fri Sep 30 08:48:48 2022 daemon.notice netifd: wwan (2336): registerstate: 0003 - home
Fri Sep 30 08:48:48 2022 daemon.notice netifd: wwan (2336): registermode: 0001 - automatic
Fri Sep 30 08:48:48 2022 daemon.notice netifd: wwan (2336): availabledataclasses: 0020 - lte
Fri Sep 30 08:48:48 2022 daemon.notice netifd: wwan (2336): currentcellularclass: 0001 - gsm
Fri Sep 30 08:48:48 2022 daemon.notice netifd: wwan (2336): provider_id: 21404
Fri Sep 30 08:48:48 2022 daemon.notice netifd: wwan (2336): provider_name: YOIGO
Fri Sep 30 08:48:48 2022 daemon.notice netifd: wwan (2336): roamingtext: (null)
Fri Sep 30 08:48:48 2022 daemon.notice netifd: wwan (2336): mbim[2336] Attach to network
Fri Sep 30 08:48:48 2022 daemon.notice netifd: wwan (2336): nwerror: 0000 - unknown
Fri Sep 30 08:48:48 2022 daemon.notice netifd: wwan (2336): packetservicestate: 0002 - attached
Fri Sep 30 08:48:48 2022 daemon.notice netifd: wwan (2336): uplinkspeed: 0
Fri Sep 30 08:48:48 2022 daemon.notice netifd: wwan (2336): downlinkspeed: 0
Fri Sep 30 08:48:48 2022 daemon.notice netifd: wwan (2336): mbim[2336] Connect to network
Fri Sep 30 08:48:48 2022 daemon.notice netifd: wwan (2336): sessionid: 0
Fri Sep 30 08:48:48 2022 daemon.notice netifd: wwan (2336): activationstate: 0001 - activated
Fri Sep 30 08:48:48 2022 daemon.notice netifd: wwan (2336): voicecallstate: 0000 - none
Fri Sep 30 08:48:48 2022 daemon.notice netifd: wwan (2336): nwerror: 0000 - unknown
Fri Sep 30 08:48:48 2022 daemon.notice netifd: wwan (2336): iptype: 0003 - ipv4v6
Fri Sep 30 08:48:49 2022 daemon.notice netifd: wwan (2336): mbim[2336] Connected, starting DHCP

Sorry for the noise, but I cannot check if the fix works right now, given that I don't have a card that uses roaming :-(

@juliogonzalez
Copy link
Contributor

@mantinan not a problem.

Sadly I am still stuck with a Hits Mobile SIM that uses Vodafone ES in roaming mode (and for several reasons I can't change my network provider), so the bug report is still valid, and I'd say the PR.

Besides I am quite sure Hits Mobile is not the only network doing this, neither in Spain or other countries with national network agreements.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants