On Wednesday 2012-02-15 10:00, Darren Willis wrote:
>
>For checking the validity of a DHCP packet, there's not really very
>much that can be done without parsing the DHCPv6 options. I've added a
>length check to make sure the outgoing message has at least a message
>type and transaction ID, and the timeout setting-code implicitly
>checks that the message has a known DHCPv6 message type.
Seems sufficient indeed.
>It would be possible to capture outgoing messages' transaction IDs and
>require that incoming advertise/reply responses match it, but I'm not
>sure that's really going to be a big help (the clients are surely
>doing this already).
Certainly would be on my wishlist if such an extension does not look
too ugly.
>> Thirdly, your module does not seem to make any attempt (yet) to handle
>> the DHCP v6 RECONFIGURE message.
>
>Right. I'm not sure of a good way to handle this; I suppose I could
>check initial ADVERTISE messages for the 'accept reconfigure' option,
>and allow the source of that advertise to have access to port 546.
>There's no time limit on reconfigure messages,[...]
Irk. I would suggest doing like the ICMPv6 tracker does,
marking it unconditionally as INVALID to indicate that the
implementation chose to not track RECONFIGURE on purpose.
>+static int dhcpv6_help(struct sk_buff *skb,
>+ unsigned int protoff,
>+ struct nf_conn *ct,
>+ enum ip_conntrack_info ctinfo)
>+{
>...
>+ unsigned char *type = 0;
= NULL.
>+static struct nf_conntrack_helper helper __read_mostly = {
>+ .name = "dhcpv6",
>+ .tuple.src.l3num = AF_INET6,
This should be NFPROTO_IPV6 actually.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
