Bad BSD socket behavior - possibly triggered by unexpected mobile-terminated TCP FIN?

RE: Bad BSD socket behavior - possibly triggered by unexpected mobile-terminated TCP FIN?

jbrzozoski — Thu, 19 Dec 2019 17:19:00 GMT

Unable to recreate this to get a modem trace yet.

The modem is now sending a RST packet instead of locking up at step 6, like I would expect.

Something was definitely different the other day. I'm now trying to remember what other testing I had been doing leading up to the failures, in case one of those tests was somehow a prerequisite for the failure.

I'm still trying...

RE: Bad BSD socket behavior - possibly triggered by unexpected mobile-terminated TCP FIN?

Didrik Rokhaug — Thu, 19 Dec 2019 11:59:56 GMT

According to our modem team, the modem uses a random TCP source port for when a socket bind is not used.

Other than that, we will need a modem trace in order to debug further.

RE: Bad BSD socket behavior - possibly triggered by unexpected mobile-terminated TCP FIN?

jbrzozoski — Wed, 18 Dec 2019 15:45:42 GMT

MFW 1.1.0 ... BSDLIB 0.5.1

RE: Bad BSD socket behavior - possibly triggered by unexpected mobile-terminated TCP FIN?

Didrik Rokhaug — Wed, 18 Dec 2019 15:44:36 GMT

Hi, and thanks for the detailed report.

I have forwarded it to our modem team and will keep you updated about any progress.

What modem firmware and bsdlib versions do you use?

Best regards,

Didrik

RE: Bad BSD socket behavior - possibly triggered by unexpected mobile-terminated TCP FIN?

jbrzozoski — Tue, 17 Dec 2019 18:46:25 GMT

As a quick hack, I tried binding the socket to a changing port number after opening it in mqtt_transport_xxx.c. The lockup seems to be gone now.

I'd still like some confirmation from someone with visibility into the modem firmware whether my theory is plausible.

If this does look like the issue, I'd argue that a quick fix would be for the modem firmware to use a changing source port if the application doesn't specifically bind one. If the current system uses an incrementing port number, maybe just seed it from the RTC on bootup? It doesn't need to be random, just not the same on every reboot.

Additionally, some more effort should be made to not fail if an invalid FIN for an ip/port we actually have open shows up, but I understand that might be harder to distinguish. Maybe if the ACK sequence from the server is way out of line you could ignore it?