[lkml]   [1998]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: DHCPD v1.3 needs testing (fwd)
In article <> you wrote:
: >Dhcpcd must generate ethernet frames itself

: And Token-Ring frames, and whatever frametypes you might
: imagine using DHCP with ? I'm sorry, but I don't understand
: why a DHCP client needs to know about all sorts of underlying
: network frames,

(AF_PACKET, SOCK_DGRAM) does NOT depend on link layer details.

Really, it was supposed that client should open two sockets
(AF_PACKET, SOCK_DGRAM) and bootp udp.
When an address is acquired and checked for validity,
it is assigned to interface, packet socket is unbound and
background communication goes via udp.

: when there is a perfectly capable network
: stack that already has all of the necessary code.

This stack has no code to work in IP promiscuous mode.

2.0 had some bits of it, but it had "small" :-) drawback.
It killed all the IP, when at least one interface
was not configured.

Now we have a chance to write true dhcpd/bootpd,
which is able to work on multihomed host or router.

Alexey Kuznetsov

 \ /
  Last update: 2005-03-22 13:41    [W:0.029 / U:6.464 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site