aiocoap icon indicating copy to clipboard operation
aiocoap copied to clipboard

Changing request Source port

Open eyalr99 opened this issue 6 years ago • 3 comments

Hi @chrysn I am using aiocoap and need the ability to configure the source port of outgoing requests. Is it possible? Thank you

eyalr99 avatar May 21 '19 21:05 eyalr99

Partially; you can create your context as a server context and bind it to a particular port, then all your UDP communication will happen from there (provided you're on a platform supported by the udp6 backend, which is primarily Linux).

To better understand the question: What would you use that for? Picking a port that's compressible in 6LoWPAN? (Then the above should suffice). Sending non-traditional responses? (That'd need additional support from aiocoap, probably).

chrysn avatar May 22 '19 06:05 chrysn

Thanks for the reply, the problem is that I am communicating with a remote coap server which I can't control. I'm creating a coap client to communicate with the server but I need to control the source port of the coap packets coming out of my client. I am coupled to windows. To summarize I am creating a coap client and I need to be able to change its source port.

eyalr99 avatar May 22 '19 08:05 eyalr99

Windows makes things trickier here, because Windows does not support the required IPV6_RECVPKTINFO socket flag that would set the source port on unbound sockets, and for bound sockets there is no error information backchannel at all (IPV6_RECVERR; without that, we'd be sending blindly). (At least not the same way as it does on regular Posix systems, see https://bugs.python.org/issue36217)

I see three ways out of this:

  • Get https://bugs.python.org/issue36217 solved (hard but clean)
  • Try running not the Windows Python but Python on WSL (that seems to have a full network stack from what I've heard recently); the udp6 transport could just work there and you can start your client with a server context bound to the right port.
  • Add some workaround that'd using a simpleserver transport as a bad client

I'd rather not do the last as it's messy and adds code that only serves to work around very exotic servers; could you tell me a little about the server in question to evaluate whether it'd warrant such a thing?

At any rate, could you try the WSL version?

chrysn avatar May 22 '19 08:05 chrysn