LTE5388-M804 loses network after some time

@RobTheNetworkGuy I have several SIMs and noticed the bug may occure mainly with one of them (not 100% sure, but I don't remember having the issue with the other SIM). As one difference is this LTE provider is IPv4 by default, I asked this LTE provider to enable IPv6 and changed APN configuration to IPv4+IPv6. FYI my network behind (pfSense) is IPv4 only, so IPv6 is only on LTE side. For now, every 12 hours the Zyxel detects "RILCMD: ConnState[0] is not attach in RS_READY." and then restarts the whole connection process including DHCP (udhcpc) with a new IPv4 address… but yet no connection loss during the last 36 hours.

Do you have an IPv6 address assigned, and if not maybe you could give it a try? Again, only on LTE side: no need to enable IPv6 on your pfSense.

Addendum: 48h and yet no network loss, except a few seconds every 12h. It seems to be that Zyxel fails to handle the DHCP IPv4 new address, but detects it if IPv6 is enabled and restarts the connection properly. My 2 cents.

@JeanFrancois

Please go to this page to apply your request.

https://support.zyxel.eu/hc/en-us/requests/new?ticket_form_id=114093996354

Dear all,

I'm the one posted this:

Be aware that yesterday I opened a ticket providing a lot of evidences showing the fw is not able to manage a new IPv4 under certain circumstancies. I'm really evaluating to return the device to Amazon and post a review because a similar bug is critical also because, if you don't realize no internet access is available, the incoming VoIP calls are not received. So is not just a matter that, soon or late, you discover the device is not working because you are not able to "surf" the internet but also you lose incoming phone calls. I bought a Zyxel thinking to have a very good quality product but now I'm quite disappointed. I really hope the support will be able to post a new fw version fixing this bug, if not I will return the device, in special way now that reading this thread I discovered that many people is suffering the same issue and Zyxel is underevaluating the problem. I'll let you know if the support will contact me providing some feedback/solutions/workarounds.

@BruCom Glad I convinced you we are all facing the same issue shared by both LTE5398 and LTE5388… and most certainly some others (I noticed a few other messages in forums which seem describe a similar unwanted behaviour).

@BruCom @RobTheNetworkGuy Did you also noticed that any existing TCP connection established was still working? This means that the IPv4 stack is still working, pretty strange. I'm out of home for a few more days and cannot test, but I wonder if ICMP would work

Some LTE providers internaly "block" connections after 12 or 24 hours to avoid permanent users. In these situations, users have to disconect and reconnect to fix this. And in the mean time, LTE seems to be established and existing connections are kept (only new TCP is blocked). I wonder if it could be something like this which happens to us. Anyway, the IP monitoring watchdog would detect and fix it easily.

@sysjohn Hum, I think this is not the same issue here: in our case most of the time a configuration change can fix the issue, and a full reboot 100% fixes the issue.

Btw, here is the same issue with NR7101 :

I have reproduced the issue this night, and the last messages I got in log was "daemon.info dnsmasq-dhcp: sendLeaseMessageToESMD" about 15 minutes after IPv4 adress has changed. Again, the existing TCP OpenVPN tunnel was still active and running fine, but I wasn't able to ping any other IPv4 address. I will try to reproduce the bug several times this weekd to export log at each point.