MC7455 - RCC State goes to Idle after a time with Sprint


#1

Hello! I am using Sprint, and even after the latest firmware update, it seems that the modem periodically has RCC State go to Idle, which gets rid of the internet connection, and it stays that way until the modem is rebooted. It used to be really frequent, like every few seconds, but after the latest firmware upgrade it is now ever 30 minutes to an hour. Is there any way to get it to stop going idle?


#2

RRC idle is not your problem. It is perfectly normal for the NTWK to disconnect RRC when there is no data to be sent.

For example if you ping a host, RCC changes to connected state, when you stop pinging the NTWK tears down the radio channels after 10 secs (10 sec is the most common)

If you can’t send data I’d start with checking the signal strength and verify periodically the modem IP.

At!gstatus?

At+cgcontrdp – do you see the IP changing?

Thanks,

James


#3

The signal strength is well within decent bounds, and the IP isn’t changing until I reboot my modem each time it stops working. And I think it is something to do with RRC Idle since every time the internet connection stops, RRC is set to Idle. It is never idle otherwise.


#4

It is not RRC. if the IP remains the same then your problem is probably between the modem and host.( not between the modem and NTWK)
did you check the IP with At+cgcontrdp?


#5

I did. Even the modem/router can tell that the modem isn’t getting an internet connection, it is something to do with the MC7455.

Edit:

At+cgcontrdp
+CGCONTRDP: 1,5,r.ispsn,173.149.202.119,68.28.31.30,68.28.31.31

OK

Basically, it remains connected to the network without internet access.


#6

Do you have more routers? if yes all are failing the same way?

after the failure please collect these logs:

at!gstatus?
at+cfun=0
at!gstatus?
at+cfun=1
at!gstatus?
issue at!gstatus? a few times
at+cgcontrdp

thanks,
James


#7

Yeah, pretty much. I tried putting the SIM back into the device it came with and that hotspot works perfectly, so it isn’t the network itself. It shows a problem with the modem itself, most likely with the Sprint network. I saw the latest firmware updates had a fix that corrected a periodic crash due to RRC, as well as other problems, but it only helped a bit. I’ll try to get the logs once it goes out again.

Edit:
AT!GSTATUS?
!GSTATUS:
Current Time: 102 Temperature: 31
Reset Counter: 1 Mode: ONLINE
System mode: LTE PS state: Attached
LTE band: B25 LTE bw: 5 MHz
LTE Rx chan: 8309 LTE Tx chan: 26309
LTE CA state: NOT ASSIGNED
EMM state: Registered Normal Service
RRC state: RRC Idle
IMS reg state: No Srv
PCC RxM RSSI: -82 RSRP (dBm): -103
PCC RxD RSSI: -81 RSRP (dBm): -102
Tx Power: – TAC: 2115 (8469)
RSRQ (dB): -7.4 Cell ID: 03E2D509 (65197321)
SINR (dB): 15.6
OK


#8

Ok! So, I think I may have found part of the issue… It is indeed between the modem and host, but I have no idea where to begin solving how to fix it though. It seems to be an issue of communication. Basically, the modem seems like it can’t share the internet connection with the host router. I turned off connection monitoring so the modem wouldn’t auto-reset when the internet connection went down, and then I left it on for a while. I then ran a couple of commands… and lo and behold, it seems the modem itself has normal service,

at!gstatus?
!GSTATUS:
Current Time: 27617 Temperature: 27
Reset Counter: 3 Mode: ONLINE
System mode: LTE PS state: Attached
LTE band: B25 LTE bw: 5 MHz
LTE Rx chan: 8309 LTE Tx chan: 26309
LTE CA state: NOT ASSIGNED
EMM state: Registered Normal Service
RRC state: RRC Idle
IMS reg state: No Srv

PCC RxM RSSI: -70 RSRP (dBm): -94
PCC RxD RSSI: -74 RSRP (dBm): -97
Tx Power: – TAC: 2115 (8469)
RSRQ (dB): -8.1 Cell ID: 03E2D509 (65197321)
SINR (dB): 22.0

OK

At+cgcontrdp
+CGCONTRDP: 1,5,r.ispsn,173.127.25.187,68.28.31.30,68.28.31.31

OK

However, this was in the router’s system log file the exact moment the router stopped receiving internet from the MC7455:
Sat Sep 29 18:38:42 2018 user.notice MBIM Monitor: Modem 1 Connection is Down (activation state: deactivated)

So, while the modem is still technically connected, and can have commands issued to it, it seems like it can’t share the data connection? Is there any way to address that? Or see if that’s the actual problem?


#9

Hey there, I just signed up to the forum to say that I’m having the EXACT same issue. Connection is fine, signal stays strong, yet RRC goes “idle” and I lose internet until I reset the modem or, if I have connection monitoring on and it sees packet loss and reconnects the modem.

I’m using an MC7455 with sprint network in a WG3526.

For the guy saying RRC Idle isn’t the problem - I think it’s indicative of a problem, however. If you have an aggressive connection monitoring set (i.e. near constant packets being sent) then I don’t think you’d ever see RRC idle unless something else messes up (assuming your signal is continuous as it has been in these cases).

Have you flashed to the most recent firmware for your MC7455? Someone on the LTE hacks group suggested this and said it fixed it for them - they blamed the issue on Sprint messing with their towers recently. I haven’t yet but I plan on trying it soon.

Either way this is EXTREMELY frustrating and there is something screwy going on.


#10

Yeah, I’m using the most recent firmware update. It did seem to help at least somewhat, but it is still a huge issue. On the previous firmware, 2.24, it would lose internet every 5-30 minutes. With the latest firmware, it happens almost every hour or two.
RRC Idle is definitely indicative of an underlying issue, and I was mistaken in thinking it was the issue itself. I have tried almost everything I can think of, and nothing seems to work to make it any better or worse. I do hope something can be figured out soon.

I just find it strange that the connection stays fine, but the router just can’t seem to communicate data to the modem.


#11

Yep same here, every 20-30 minutes though today it seems to be every hour or so… yet I haven’t changed the firmware. It must be something on sprints side… what could they be doing or messing up? I’m using a calyx SIM card, what are you using?


#12

I’m using a PCsForPeople SIM myself. I have my MC7455 hooked up via USB to a Raspberry Pi running goldenorb. It has to be something that Sprint is doing, because my connection used to be way more stable. I would usually only have disconnects every 8-12 hours, which I could handle easily.


#13

Also having major issues with sprint on the em7565. Same kind of deal. My issue is once a 3xca connection is established on band 41 all packets are dropped until the other 2 CA bands go inactive. If I keep the 2 extra ca bands from becoming active, all is well. Since the em7565 doesn’t have the option to disable CA like the mc7455, I switched over to my mc7455. At first the issue still remained but then I installed the latest firmware and it seems to have helped. My em7565 is useless now unless they come up with a firmware upgrade to fix the issue.

My hunch is sprint is changing stuff around for 5g and our modems dont make the correct connections to these bands now. Also are any of you in these metropolitan areas? Im in kansas city.

“Sprint is still planning to launch a 5G network in 2019, and the carrier is moving toward building a next-generation network by announcing the first six cities where it plans to roll out Massive MIMO antenna technology: Atlanta, Chicago, Dallas, Houston, Kansas City, Los Angeles, and Washington, DC.”


#14

You are using MBIM mode under Linux. I’d recommend to switch to RMNET. At Sierra we only validate in RMNET mode with the Sierra drivers.

To confirm you are using MBIM:

at!entercnd="A710"
OK
at!usbcomp?
Config Index: 1
Config Type:  1 (Generic)
Interface bitmask: 0000010D (diag,nmea,modem,rmnet0)

OK
at!usbcomp=?
!USBCOMP:
AT!USBCOMP=<Config Index>,<Config Type>,<Interface bitmask>
  <Config Index>      - configuration index to which the composition applies, sh                          ould be 1

  <Config Type>       - 1:Generic, 2:USBIF-MBIM, 3:RNDIS
                    config type 2/3 should only be used for specific Sierra                           PIDs: 68B1, 9068
                    customized VID/PID should use config type 1

  <Interface bitmask> - DIAG     - 0x00000001,
                    NMEA     - 0x00000004,
                    MODEM    - 0x00000008,
                    RMNET0   - 0x00000100,
                    RMNET1   - 0x00000400,
                    MBIM     - 0x00001000,
  e.g.
  10D  - diag, nmea, modem, rmnet interfaces enabled
  1009 - diag, modem, mbim interfaces enabled

  The default configuration is:
  at!usbcomp=1,1,10F

OK

to switch to RMNET
at!usbcomp=1,1,10D

reset the modem.

install the Sierra drivers, bring up the connection with at!scact=1 then you can call dchp to transfer the IP context from the modem to the host.


#15

I’m not sure if ROOter will support RMNET, so before I switch to it, what is the difference between that and MBIM? Will it offer a more stable connection, or is it just a different mode?

EDIT: Nevermind, I found out that it’s QMI mode if I am not mistaken. I just hadn’t heard it called RMNET before. In this case, the latest version of ROOter does support it, however, QMI/RMNET mode still suffers from the disconnects sadly.


#16

Do you see the IP address changing when disconnected?
Your could write a script regularly monitor at!gstatus? and at+cgcontrdp
an IP change would indicated that the NTWK connection was lost but reestablished (detached, re-attached)

At+cgcontrdp
+CGCONTRDP: 1,5,r.ispsn,173.127.25.187,68.28.31.30,68.28.31.31

OK

possible explanation for disconnects over longer period:
Carriers may have inactivity timers and if no data transmitted the IP is released by the NTWK.
Basically the NTWK is sending a detach REQ with re-attach required type. so it will just disconnect and obtain another IP. On ATT & VZW the inactivity timer is 4hrs. I’m not sure about Sprint.


#17

IP stays the same. No disconnection happens. Just complete loss of packets. The mc7455 has always had an issue with the actual disconnect from sprint after a 12 to 24 hour time and was tolerable. This is a completely different issue and is happening to sprint users on both the mc7455 and em7565.

I have actually watched gstatus? and band? while these packets are being dropped. The cell ID shows fffffff and band shows as unknown until finally it comes back up about 20 sec later. Then all becomes normal for a short period of time all while never disconnecting from the carrier and keeping the same IP.

The mc7455 and em7565 is crashing on the sprint network.


#18

@westrem
Are you sure about the crashes?

Can you collect “at!gcdump” after a reset or crash?
Make sure that the MC7455 is upgraded to the latest FW : SWI9X30C_02.26.01.00

Where do you guys see these issues on Sprint?
Can you share the city?


#19

Kansas city here. I’ll check the gcdump and report back.


#20

@Oedenburger

at!gcdump

Src: FatalError
File: mutils_security.c
Line: 496
Str: Assertion E_SUCCESS == err failed
00000000 00000000 00000000 00000000
Prc: MPSS
Task: LTE
Time: 0252C4A7
R0: EC902000 R1: 8651B8E7 R2: 25B967D9 R3: 00E3B3B0 R4: 000025B9
R5: 00000000 R6: 000000B3 R7: 00000000 R8: 00E3B3B0 R9: 00000000
R10: 000000E3 R11: 92DBF0D3 R12: 000000E3 R13: 00000000 R14: 00000000
R15: 00000000 R16: 055196A0 R17: 00000000 R18: 00000000 R19: 00000000
R20: 0429F0A8 R21: 000007A0 R22: 0000000E R23: DD5F35EC R24: 03C3F030
R25: 03C3F030 R26: 00000002 R27: DD5F35D8 R28: 00000000 SP: DD5F3590
FP: DD5F3598 LR: 0212B988
PC: 01EBA90C
CPSR: 00000000
Mod: Unknown
TOS
DD5F35B0 0212B9C8 042A6D18 00000000 0000001F 00000000 DD5F3660
01EBA90C DD5F35D4 00000000 00000000 00000000 00000000 00000000
DD5F3684 57D0EF5E 00000000 00000000 00000000 00000000 00000000
0429F0A8 DD5F35D8 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
BOS
App ver: SWI9X30C_02.30.01.01

OK