Non-varying source port
chelliwell opened this issue · comments
In conjunction with sorting out the problem I had with gettime/PRNG (#17), I was trying to understand how to catch the 'failure' this resulted in. (I think I've fixed it, but was concerned that my thread just sat forever waiting for response from bootstrap server - i.e. maybe something lacking in my error handling).
So I modified 'avs_rand_r()' on Linux , to always return a fixed value, to try to force the same behaviour that I was seeing with my hardware. However this build still worked - I think because although the Msg ID and Token are the same, the UDP source port is changing. But in my platform it always boots to use the same port [52720].
Where is the source port set? Is it generated by the TCP/IP stack? (I'm using lwIP)
In terms of an Anjay 'Issue' - I wonder if there's a hang-up in the state machine(s) if the server doesn't respond: in Wireshark I see the CON from the client, then the ACK 2.04 Changed coming back from the server, but the server does not then send anything else.
The client seems to have no timeout out of this?
If udp_listen_port is not set in anjay_configuration_t, the bind() call on a socket is always performed with the port set to 0. The port number is generated by the TCP/IP stack.
I see - thanks. I guess the 52720 value I'm seeing is being originated in lwIP.
Regarding the 'hang up' scenario above (albeit v. unlikely), is there a way the demo app could timeout of this? Something it could spot and drop out of its state-machine/loop?
Sorry for not responding earlier - I'm closing this issue now that it is over a year old. If you still have this problem, please check with the latest version and open another issue.