[ECOS] Re: Unable to get IP address using do_bootp (found a bug in do_bootp!)

[agyhoo <agyhoo at yahoo dot com>]

Andrew,

Here are the dumps:

tcpdump -i eth1 port 67 or port 68
tcpdump: listening on eth1

<<<<<WITHOUT BROADCAST FLAG SET>>>>>
13:34:23.526904 0.0.0.0.bootpc > 255.255.255.255.bootps: 
[|bootp]
13:34:23.527458 192.168.0.2.bootps > 192.168.0.11.bootpc: 
Y:192.168.0.11 S:192.168.0.2 [|bootp] [tos 0x10]

<<<<<WITH BROADCAST FLAG SET>>>>
13:35:35.451533 0.0.0.0.bootpc > 255.255.255.255.bootps: 
flags:0x8000 [|bootp]
13:35:35.452004 192.168.0.2.bootps >
255.255.255.255.bootpc:  flags:0x8000 Y:192.168.0.11
S:192.168.0.2 [|bootp] [tos 0x10]


Note I am using Red Hat 9.0's dhcpd. T

As you can see from the trace, dhcpd responds with a
unicast
pkt when the broadcast bit is NOT set. However, this pkt
is not received in the do_bootp fn. When the broadcast
bit IS set, the dhcpd response is sent to 255.255.255.255
and the do_bootp fn. is able to get the response.

The reason I came to the conclusion I did was based on the
man page for dhcpd.conf. Here is the relevant section :

       The always-broadcast statement

          always-broadcast flag;

          The  DHCP and BOOTP protocols both require DHCP
and BOOTP clients to
          set the broadcast bit in  the  flags  field  of 
the  BOOTP  message
          header.   Unfortunately, some DHCP and BOOTP
clients do not do this,
          and therefore may not receive responses from the
DHCP server.    The
          DHCP server can be made to always broadcast its
responses to clients
          by setting this flag to ?on? for the relevant
scope; relevant scopes
          would be inside a conditional statement, as a
parameter for a class,
          or as a parameter for a host declaration.   To
avoid creating excess
          broadcast  traffic  on  your network, we
recommend that you restrict
          the use of this option to as few clients as
possible.   For example,
          the  Microsoft DHCP client is known not to have
this problem, as are
          the OpenTransport and ISC DHCP clients.

So I can get bootp to work in 2 ways:
1. set the broadcast flag in the ecos do_bootp fn.
2. set the always-broadcast flag to on in the dhcpd.conf
file.

Note that the do_dhcp fn. does set the same broadcast bit.



--- Andrew Lunn <andrew@lunn.ch> wrote:
> On Mon, Mar 29, 2004 at 07:31:48AM -0800, agyhoo wrote:
> > While trying to debug why I was not able to get an IP
> > address using do_bootp, I discovered that the do_bootp
> > routine does NOT set the broadcast flag in the flags
> > field of the bootp protocol header. This is required
> > per the BOOTP protocol.
> 
> Hold on a minute.....RFC1532 says:
> 
> 3.1.1 The BROADCAST flag
> 
>    Normally, BOOTP servers and relay agents attempt to
> deliver BOOTREPLY
>    messages directly to a client using unicast delivery. 
> The IP
>    destination address (in the IP header) is set to the
> BOOTP 'yiaddr'
>    address and the link-layer destination address is set
> to the BOOTP
>    unable to receive such unicast IP datagrams until they
> know their own
>    IP address (thus we have a "chicken and egg" issue). 
> Often, however,
>    they can receive broadcast IP datagrams (those with a
> valid IP
>    broadcast address as the IP destination and the
> link-layer broadcast
>    address as the link-layer destination).
> 
>    If a client falls into this category, it SHOULD set
> (to 1) the
>    newly-defined BROADCAST flag in the 'flags' field of
> BOOTREPLY
>    messages it generates.  This will provide a hint to
> BOOTP servers and
>    relay agents that they should attempt to broadcast
> their BOOTREPLY
>    messages to the client.
> 
>    If a client does not have this limitation (i.e., it is
> perfectly able
>    to receive unicast BOOTREPLY messages), it SHOULD NOT
> set the
>    BROADCAST flag (i.e., it SHOULD clear the BROADCAST
> flag to 0).
> 
>       DISCUSSION:
> 
>          This addition to the protocol is a workaround
> for old host
>          implementations.  Such implementations SHOULD be
> modified so
>          that they may receive unicast BOOTREPLY
> messages, thus making
>          use of this workaround unnecessary.  In general,
> the use of
>          this mechanism is discouraged.
> 
> So we should first work out if the network stack really
> needs it or if
> the BOOTP server is doing something wrong. This code has
> been around
> for many years so why has somebody else not found the
> problem....
> 
> Please show us a tcpdump trace of the bootp exchange
> before and after
> your patch.
> 
>      Andrew


__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss