-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in 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).