(I won't forward more stuff unless asked to)
--- Begin Message ---
Michael Richardson wrote:
>
>
>>>>>>>"Simon" == Simon Kelley <[EMAIL PROTECTED]> writes:
>
> Simon> The alternative if LPF which is adopted by most clients,
> Simon> (udhcpc, dhcpcd, diamond) is AF_PACKET sockets. A packet
> Simon> socket gives you complete IP packets, with IP header. The
> Simon> best solution seems to be to use a packet socket until bound,
> Simon> and then switch to an AF_INET socket.
>
> Why use two mechanism if the first will do?
>
> I'll answer my question a bit --- because something else might come
> along and cause the LPF or AF_PACKET socket to become unuseable. For
> instance, anyone who decides to IPsec encrypt their wireless winds up
> having to make dhcp exceptions for the renewals.
Another reason: you either have to use a packet-filter on the AF_PACKET
socket (which gets you back to needing the packet filter in the kernel,
and is arguably ugly) or your DHCP client gets every IP packet the host
ever receives. Better, once established, to close the packet socket and
have the client sleep except when a packet arrives on port 67.
>
> Simon> No-one else has every achieved this, as far as know.
>
> Simon> If you find a way, I'd be very interested.
>
> I think it's a kernel bug. I think that a way ought to be created to
> make this work.
>
OK, let's try and enumerate what we're asking for here:
Client first.
To make the client work, we need to be able to receive broadcasts sent
to 255.255.255.255 even on an interface which doesn't have an IP
address. We need to be able to send UDP packets from an interface which
doesn't have an IP address, and the source address of those packets
needs to set to 0.0.0.0 (That's conventional, I'm not sure it's a MUST)
These packets have to be able to be broadcast and have destination
address 255.255.255.255
Actually, I'm not sure the send part doesn't work. What happens if one
uses sendmsg and IP_PKTINFO to force the source address to 0.0.0.0?
allowing that to work shouldn't be a big deal.
For both send and receive, we'd like SO_BINDTODEVICE to work. This is
not essential, since the interface can be specified for send and receive
using the ipi_ifindex field of the pktinfo struct. Having it would make
one-daemon-to-one-interface easier to do.
Now the server.
This is easier, we need to be able to do is send to host which can't
reply to ARP requests, but for which we know the MAC address and the
interface by which it is reachable. The ARP-injection trick needs to be
investigated for this, it looks promising. We also need to be able to
send broadcasts with the destination address set as 255.255.255.255, not
the net broadcast. I have feeling that that used to be problematic, but
may not be now. If that works, and ARP-injection works, there's no
kernel fixes needed for the server.
Anybody have anything to add to the shopping list?
Cheers,
Simon.
--- End Message ---
