Network Connect Error

#1

Hiya,

I’m using the le_data API to request a connection to the network.

After the first cellular network disconnection after a reboot, every time I try a reconnect, I always get the following sequence of errors:

Dec 17 07:36:16 swi-mdm9x28-wp user.info Legato:  INFO | reService[25722]/reComponent T=main | api_network.c _OpenTcpSocket() 690 | Broker: test.server.com Port: 1234
Dec 17 07:36:17 swi-mdm9x28-wp user.info Legato:  INFO | modemDaemon[936]/modemDaemon T=main | le_mrc.c NetworkRejectIndHandler() 1170 | Network Reject Ind Handler called with RAT.8, mcc. and mnc.
Dec 17 07:36:17 swi-mdm9x28-wp user.err Legato: =ERR= | modemDaemon[936]/le_pa T=unknown | pa_mrc_qmi.c EventReportHandler() 1337 | Network Registration failed error code 10
Dec 17 07:36:21 swi-mdm9x28-wp user.warn Legato: -WRN- | reService[25722]/reComponent T=main | api_network.c _OpenTcpSocket() 695 | getaddrinfo: [-3]Temporary failure in name resolution

What does

Network Registration failed error code 10

indicate?

There is definitely something wrong - cm data shows that the network is connected (DNS servers and so on are displayed), but the module is having trouble resolving names.

Platform: WP7702/R9.1/Legato 18.05.1

ciao, Dave

#2

We have seen that when having established an connection, you sometimes manually have to setup a default route. Try using the cm data to see what the GW address is supposed to be and then use the command

route add default gw gw-ip

to set the default route to use the new interface. This makes us able to resolv names (however, we also manually (or using our legato app) populate the nameservers file in /etc).

#3

Hi @andcor,

Ta. I can see what you’re saying and it makes sense.

But … it’s not much good when you’re trying to build a reliable, headless system to put out in the field! The whole idea of using the Legato le_data API is to make all this sort of stuff transparent to the app that requires cellular data connection.

The other issue with manually populating resolv.conf is I’ve seen that it’s sometimes not re-read when it changes by other applications even through they’re not sandboxed (I believe this is a feature of the way that Legato uses chroot jails for security and isolation).

ciao, Dave

#4

I have solved it by adding the route command to an external command legato app in C. I know it is somewhat of a workaround, but we are in a hurry and therefore we will have to add workarounds for the issues we come across instead of waiting for the issue to be adressed in the framework itself.

Modem gets into a state where it thinks it's connected but isn't
#5

Hi,

yes the DCS should take of managing the default route along with DNS entries, so it’s really not the expected behavior for that to be needed from another legato app.

@davidc, could please provide some more logs for the issue? Since the DCS should set the default route, I’m thinking that either that code is not triggered, or it can’t get the gateway to set from the modem, and I think logs would highlight that.

Note that we are actively working on making the DCS more reliable and a refactoring is going on. Some content is already in 18.10.3 but it will be completed in version 19.xx with xx > 02 (not sure if >= or >).

#6

Hi @CoRfr,

I can’t remember what I was working on when I tripped over this. If you tell me what logs (and how to fish them out) I’ll try and revisit and see if I can find anything else.

ciao, Dave

#7

Please check whether it’s really a matter of needing the manually added default route, or a matter of needing to wait for a while after boot-up before traffic can successfully flow through. Or even something else which the manual route addition just creates a way to overcome.