| > 2. When receiving a connection-Request on a multicast or broadcast
address, no
| > Reset should be generated, to avoid storms of such packets. Instead of
jumping
| > to the `drop' label, the v{4,6}_conn_request functions now return 0.
Below is
| > why in my understanding this is correct:
| >
| DCCP only claims to support unicast so this fix makes sense.. (or
| should we flag we have multicast/broadcast being used? But that's a
| whole separate issue).
As far as I understand it, the behaviour of DCCP is consistent with TCP.
Looking at
net/ipv6/tcp_ipv6.c in tcp_v6_conn_request (comments are not mine):
if (!ipv6_unicast_destination(skb))
goto drop;
/* ... */
drop:
if (req)
reqsk_free(req);
return 0; /* don't send reset */
And in tcp_v4_conn_request:
/* Never answer to SYNs send to broadcast or multicast */
if (((struct rtable *)skb->dst)->rt_flags &
(RTCF_BROADCAST | RTCF_MULTICAST))
goto drop;
/* ... */
drop:
return 0;
I only discovered this after you wrote the reply. Initially, the main problem
fixed by the
patch was that the reset codes got overwritten, and it was something I had
caused in a `tidy-up'
patch where I didn't see that dccp_parse_options generates its own reset codes.
There is still something missing and that is adding the Data 1..3 fields of the
reset packet -
I wonder if this could be done as an array[3] in the DCCP_SKB_CB?
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
