-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
gcoap: Do not send responses from multicast addresses #19272
gcoap: Do not send responses from multicast addresses #19272
Conversation
Thanks bors merge |
18257: drivers/wdt: add periph_wdt_auto_start for early watchdog r=benpicco a=benpicco 19272: gcoap: Do not send responses from multicast addresses r=chrysn a=chrysn ### Contribution description Since #18026, CoAP requests to multicast addresses (eg. `ff02::1`) came back from that exact address, which Linux rightfully just drops. The fix uses the existing multicast check from #17978 (thanks `@benpicco` for making me write this as dedicated function, I just had to generalize it removing one struct layer), and foregoes setting the source address when responding to multicasts. ### Testing procedure * Run the gcoap example * Send a CoAP request to a multicast address RIOT listens to, eg. `./aiocoap-client coap://'[ff02::1%tapbr0]'/.well-known/core --non` Before, this got no response (while you see it arrive on wireshark). After, you get a correct response with two lines of note: ``` WARNING:coap:Sending request to multicast via unicast request method Response arrived from different address; base URI is coap://[fe80::3c63:beff:fe85:ca96%tapbr0]/.well-known/core ``` (The former is aiocoap telling us that we're not using the nonexistent multicast API so it's really more of an anycast, the latter is useful factual information). Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com> Co-authored-by: chrysn <chrysn@fsfe.org>
sock_udp_aux_tx_t aux_out = { | ||
.flags = SOCK_AUX_SET_LOCAL, | ||
.local = aux_in.local, | ||
}; | ||
if (_ep_is_multicast(&aux_in.local)) { | ||
aux_out_ptr = NULL; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably I'm too late, but a comment about the semantics of setting this pointer to NULL here would have been nice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, given it takes several indirections before this wins up in a function where one can read the documentation.
Comment added, let's see how mad bors will get at me for throwing logs before its merge train.
96cabee
to
ac3a9cd
Compare
Canceled. |
bors merge |
🕐 Waiting for PR status (GitHub check) to be set, probably by CI. Bors will automatically try to run when all required PR statuses are set. |
GitHub status checks took too long to complete, so bors is giving up. You can adjust bors configuration to have it wait longer if you like. |
bors merge |
Build succeeded: |
Contribution description
Since #18026, CoAP requests to multicast addresses (eg.
ff02::1
) came back from that exact address, which Linux rightfully just drops.The fix uses the existing multicast check from #17978 (thanks @benpicco for making me write this as dedicated function, I just had to generalize it removing one struct layer), and foregoes setting the source address when responding to multicasts.
Testing procedure
./aiocoap-client coap://'[ff02::1%tapbr0]'/.well-known/core --non
Before, this got no response (while you see it arrive on wireshark). After, you get a correct response with two lines of note:
(The former is aiocoap telling us that we're not using the nonexistent multicast API so it's really more of an anycast, the latter is useful factual information).