This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


agyhoo said:
> 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.
>

There must be something else wrong with your target.  I (and
many others) use DHCPD on RH 9 without ever resorting to either
of the steps you outline above.

My quess is that your ethernet is not being setup with the proper
ESA (MAC address).  When you do a BOOTP (or DHCP) request, you tell
the server what your ESA is.  When it replies, it sends the reply
to exactly that node.  If what your hardware is expecting and what
the DHCP server sends (ESA addresses!) don't match, then your target
won't see the response.

If you to set this bit, and your target sees the reply, can you then
use the node, e.g. TFTP load something?  Have you verified that the
network stack functions after it manages to get an address?

>
>
> --- 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
>
>




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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]