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
> > (1)     set address to 0.0.0.0
> > (2) set broadcast to 255.255.255.255
> > (3) set netmask to 0.0.0.0
> > (4) set flags to up,broadcast,notrailers,running
> > (1) succeeds, but when it gets to (2) EADDRNOTAVAIL is returned.
> > So whats up?
>
> Linux now stops dhcpcd doing things that aren't really legal but happened
> to work in 2.0. 0.0.0.0 is not a valid IP addresses. The old dhcpcd can
> 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
Bootstrap Protocol


7. Packet Processing

7.1. Client Transmission

Before setting up the packet for the first time, it is a good idea
to clear the entire packet buffer to all zeros; this will place
all fields in their default state. The client then creates a
packet with the following fields.

The IP destination address is set to 255.255.255.255. (the
broadcast address) or to the server's IP address (if known). The
IP source address and 'ciaddr' are set to the client's IP address
if known, else 0.
^^^^^^^^^^^^^^^^^

Just a question.
And the reason I ask it it that I work with this protocol a lot,
and on all platforms so far, it has been nice to be able to trace
problem clients down while they are in the stage of booting where they
have issued the BOOTREQUEST and are awaiting a BOOTREPLY.
You can always tell the state of the client, even remotely, because
he will have whichever interface he is trying to get an address for
at that given moment set to all 0's (IPADDR 0.0.0.0)
( You can actually ping him at this address while he is in this state,
IF you are on the same segment as the client, or you can telnet to
a machine that is on the same segment ) - This saves many admin's the
usually long walk to the client to detect it's state while debugging
bootp/dhcp problems.

Not a lot of people are probably aware of this debugging technique, unless
they specifically have to debug these type of problems, but it does come
in very handy.

It hasn't been a problem in the past, as the clients only remain in this
state until they get an address assignment from a server ( usually a very short
time, unless the bootp server is down, or no servers have
that client listed in /etc/bootptab - in which case he is SOL until
one of the two is corrected - at the server(s).)

My question is this: during this period of time when the client does
not yet know his IPADDR but must ifconfig his interface to be able to
send/recieve bootp packets - what address do you suggest we set the interface
to?
Keep in mind that historically, address "0.0.0.0" has always meant "this machine"
And any client observed in this state, has always been known to be in a state
of having issued a bootrequest, and not having yet recieved a bootreply.

Thank you for your time.
Robert Manning
robertm@teklords.com


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