This is the mail archive of the ecos-discuss@sourceware.org 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: BOOTP problem


Ð ÐÐÐ, 11/02/2008 Ð 09:43 -0800, Jay Foster ÐÐÑÐÑ:
> I added the CYGOPT_NET_FREEBSD_STACK_ACCEPT_UNICAST CDL option a while back,
> and I am the author of the associated description.  I also use both DHCP and
> BOOTP and found that BOOTP wasn't working.  I tracked it down to the in the
> Free BSD network stack code that the BOOTP_COMPAT conditional needed to be
> turned on to allow BOOTP to work.  I added the
> CYGOPT_NET_FREEBSD_STACK_ACCEPT_UNICAST simply as a means for eCos
> developers to define the Free BSD stack BOOTP_COMPAT conditional if they
> needed to use BOOTP.
> 
> The BOOTP_COMPAT is a Free BSD network stack option, so why it's there would
> need to be answered by the BSD folks.  I suspect that it was put in because
> most applications use only DHCP, and the ability to accept a unicast network
> packet when the interface address isn't set may have been considered a
> security issue.  The BSD maintainers probably added the BOOTP_COMPAT
> conditional to permit users to re-anable this functionality to allow BOOTP
> to work.  (THIS IS SPECULATION).
> 
> The link between wanting to use BOOTP and needing to enable the
> CYGOPT_NET_FREEBSD_STACK_ACCEPT_UNICAST option is not obvious and weak at
> best. 

eCos BOOTP doesn't work without this option. What is not obvious?

Any developer who would like to use BOOTP will get not working program
firstly. And later (when he has wasted his time) he'll have found
CYGOPT_NET_FREEBSD_STACK_ACCEPT_UNICAST option. Excellent!

RFC 951 - Bootstrap Protocol:

      2. If the client does not yet know its IP address (ciaddr zero),
      then the client cannot respond to ARPs sent by the transmitter of
      the bootreply. There are two options:

         a. If the transmitter has the necessary kernel or driver hooks
         to 'manually' construct an ARP address cache entry, then it can
         fill in an entry using the 'chaddr' and 'yiaddr' fields.  Of
         course, this entry should have a timeout on it, just like any
         other entry made by the normal ARP code itself.  The
         transmitter of the bootreply can then simply send the bootreply
         to the client's IP address.  UNIX (4.2 BSD) has this
         capability.
         ^^^^^^^^^^^^^^^^^^^^^^^^^^
         eCos receives bootreply only if ACCEPT_UNICAST is enabled

         b. If the transmitter lacks these kernel hooks, it can simply
         send the bootreply to the IP broadcast address on the
         appropriate interface.  This is only one additional broadcast
         over the previous case.
         ^^^^^^^^^^^^^^^^^^^^^^^^^^
         receives in any case

> How best to impart this association/information isn't obvious to me
> (some additional CDL configury, documentation, just search the eCos-discuss
> archives, just search the source code (as I did)).  If you do search the
> eCos source for "BOOTP" or "bootp" you will find the
> CYGOPT_NET_FREEBSD_STACK_ACCEPT_UNICAST option.

grep -r -i bootp ./ | wc -l
656

best regards
Alexey



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