lkml.org 
[lkml]   [1997]   [Dec]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: 2.1.75 breaks dhcpcd
Date
From
> > > do bad things if something else sends packets to 0.0.0.0 (if you've ever
> > > seen mixed dhcp and old old sun boxes with 0.0.0.0 as broadcast on a lan
> > > you'd get the picture)
> > >
> > > Alan
> >
> > And what of RFC 951 ?
> > RFC 951 September 1985
>
> It says you may transmit as 0.0.0.0 for those special cases but nowhere
> does it say you should respond to normal traffic on that address. Thats
> what dhcpcd causes in its current mode of operation.
>
> DHCPD needs to use SOCK_PACKET. Now that we have the BPF filter on
> SOCK_PACKET this can be done very cleanly

But that's the very reason bootp has been worked on so carefully over the
last ten years, - ( I'm speaking of all Unix platforms )
If you deicde to go RAW, then you take too much away from admin's who are
trying to troubleshoot a situation, and I'll give you a real-world
scenario:

Bootp client on segment#1 configures the appropriate interface to 0.0.0.0 and
issues BOOTREQUEST, which then is supposed to get picked-up by the bootp relay
agent on a misconfigured router and forwarded to bootp server on segment#2,
but it does not, it gets ignored,
because the router arrived onsite, and was carelessly installed by others (TM)
with the bootp relay function disabled (factory default for most routers).

Now, the server recieves no request, and thus the client recieves no reply.
How does the average admin (without a $14,000.00 Network General sniffer)
go about deciding if the client EVER ISSUED the request to begin with?
( And no, he does not control the router -although maybe he should, but
that's another issue )
But if he can get some type of positive feedback that that client has
AT LEAST configured his interface appropriately for a bootp request,
(ping it from another machine on the same segment, then observe the MAC
address that comes back) he will know that :
A: - at least the NIC in the client is functional.
B: - the IP stack in the client is also functional enough to talk ICMP
C: - the wiring from the client to his local segment is not the problem.
(remember, he just telnetted from the server's segment over to the
client's segment, then pinged the client)

Now, this net admin can confidently deduce that the problem is with the
router between segments 1 and 2.

And he has not had to leave his chair, either.

Tell me how I am going to know (without using the sniffer, or any other
machine in promiscous mode) if your client has gone far enough through the
bootup process to initiate a bootrequest?
( Without walking over to it's console )

I know you have ways around this, and it may be cleaner to code this raw,
but if admins lose some functionality because of it, then the thought should
be looked at very carefully, before you decide to implement.


Thanks again,
Robert Manning
robertm@teklords.com





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