Peter Memishian wrote:
>...
> 3. (Please sit down for this one.) Have ip_input() itself recognize
> that it's received one of the special IP unicast DHCP packets, and
> have it rewrite the packet to have the IP broadcast address in the
> slow path. To do this in a manner that doesn't massively interfere
> with forwarding performance (e.g., since the packet isn't for us, we
> need to decide whether to forward it or rewrite to be for us), it
> seems like we'd need an SIOCSLIFDHCPINIT ioctl that the client would
> use to enable this behavior when necessary on an interface[2] (which
> would e.g. set ill->ill_dhcp_init), and then we'd have to add one
> additional check to the fastpath stanza in ip_input() -- e.g.:
>
> if (!is_system_labeled() &&
> !ipst->ips_ip_cgtp_filter && ipp_action_count == 0 &&
> opt_len == 0 && ipha->ipha_protocol != IPPROTO_RSVP &&
> !ll_multicast && !CLASSD(dst) && !ill->ill_dhcp_init) {
> ^^^^^^^^^^^^^^^^^^^
>
> Unfortunately, even this single check will impact general networking
> performance especially for small packets, which I know is something
> we're already working hard to improve -- so this seems bad too.
>
>
What are the other implications for ip_input()?
For example, what needs to change in order for the packet to
be accepted based on a destination address that doesn't apply
to the current system?
More specifically, do the changes you are proposing also
cause the system to accept packets that aren't DHCP replies?
Which begats an architectural question of why should there
be a special purpose hack in ip_input() for DHCP and not a
better solution that has some other level of generality?
Darren
