Messages in this thread | | | Subject | Re: 2.1.75 breaks dhcpcd | Date | Thu, 25 Dec 1997 11:25:04 -0600 | From | root <> |
| |
> > (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
| |