sys/net/gnrc/tcp: fix gnrc_tcp_open() netif handling#20977
sys/net/gnrc/tcp: fix gnrc_tcp_open() netif handling#20977maribu merged 1 commit intoRIOT-OS:masterfrom
Conversation
|
|
||
| /* We did not fine the netif, so rather than wasting more resources | ||
| * before timing out without sending anything, return an error */ | ||
| if (tcb->ll_iface == SOCK_ADDR_ANY_NETIF) { |
There was a problem hiding this comment.
| if (tcb->ll_iface == SOCK_ADDR_ANY_NETIF) { | |
| if (ipv6_addr_is_link_local(tcb->peer_addr) && tcb->ll_iface == SOCK_ADDR_ANY_NETIF) { |
There was a problem hiding this comment.
I think for link local, we don't even need to check if only one netif is available: Any interface will be equally valid then, so we could always just take the first netif for link local addresses and unspecified netif.
There was a problem hiding this comment.
No, always chosing the first interface when no interface is specified is way too surprising/confusing.
Just return an error if you'd need to make a choice, like gnrc_udp does.
There was a problem hiding this comment.
I cannot find where UDP does this. Do you know where the code lives? If that is implemented already, I could split this out info a common function and reuse this. That way, we can ensure that TCP and UDP will behave consistently in this regard.
There was a problem hiding this comment.
OK, I just free coded this for now.
68acbd0 to
a0de15a
Compare
874311e to
f36469a
Compare
gnrc_tcp_open() previously would eventually fail with a timeout without sending any data when no netif was specified and a link-local target address was used. This fixes the behavior: - If there is only one netif, we just pick that - If there are multiple netifs, fail directly with `-EINVAL` rather than sending out nothing and waiting for a timeout. Co-authored-by: benpicco <[email protected]>
f36469a to
e714707
Compare
|
Thx ❤️ |
Contribution description
gnrc_tcp_open() previously would eventually fail with a timeout without sending any data when no netif was specified and a link-local target address was used. This fixes the behavior:
-EINVALrather than sending out nothing and waiting for a timeout.Testing procedure
In one terminal run:
In a second (while keeping the TCP server from the first terminal running) run:
Issues/PRs references
None