BSDnet sets wrong broadcast address for DHCP.

[Till Straumann]

Here's a tcpdump of one of my boxes booting up.
Nothing unusual and the IP broadcast address looks fine...

(rtems 4.7.1)

(Ethernet destination: 0xffffffffffff, IP destination 0xffffffff,
IP source 0x00000000)

HTH
-- T.


[root at tillpc guest]# tcpdump -xx ether host 00:01:AF:13:B5:3C
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
11:03:54.098574 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, 
Request from 00:01:af:13:b5:3c, length: 492
        0x0000:  ffff ffff ffff 0001 af13 b53c 0800 4500  ...........<..E.
        0x0010:  0208 0001 0000 4011 78e5 0000 0000 ffff  ...... at .x.......
        0x0020:  ffff 0044 0043 01f4 5b44 0101 0600 ffff  ...D.C..[D......
        0x0030:  ff01 0000 8000 0000 0000 0000 0000 0000  ................
        0x0040:  0000 0000 0000 0001 af13 b53c 0000 0000  ...........<....
        0x0050:  0000 0000 0000 0000 0000 0000 0000 0000  ................
11:03:54.099350 IP tillpc.slac.stanford.edu.bootps > 
255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 356
        0x0000:  0001 af13 b53c 0013 7297 1e45 0800 4510  .....<..r..E..E.
        0x0010:  0180 0000 0000 1011 01b9 864f 2156 ffff  ...........O!V..
        0x0020:  ffff 0043 0044 016c 0970 0201 0600 ffff  ...C.D.l.p......
        0x0030:  ff01 0000 8000 0000 0000 864f 2323 864f  ...........O##.O
        0x0040:  2156 0000 0000 0001 af13 b53c 0000 0000  !V.........<....
        0x0050:  0000 0000 0000 7469 6c6c 7063 0000 0000  ......tillpc....


Arnout Vandecappelle wrote:
>  Hoi all,
>
>  I've encountered some strangeness in my RTEMS code and wonder if it's
> my fault or BSDnet's...
>
>  When I use DHCP, it turns out that the requests are sent out to
> 0.255.255.255 rather than 255.255.255.255...  This happens because
> in_ifinit() doesn't retain the existing broadcast address, but
> overwrites it based on the netmask, and in addition it ignores a netmask
> of 0.0.0.0 and falls back on the class A,B,C categorization.
>
>  As a solution, I made a special case for IP address 0.0.0.0 (see
> attached patch), which solves the problem.
>
>  Unfortunately, I seem to remember that in the past, the DHCP requests
> _were_ sent to 255.255.255.255!  I'm unable to reconstruct that
> situation, however.  Could someone check for me if the stock RTEMS sends
> DHCP requests to the correct address?  If so, the attached patch is
> unnecessary and I should find out what goes wrong in my case...
>
>  Regards,
>  Arnout
>
>   
> ------------------------------------------------------------------------
>
> Index: cpukit/libnetworking/netinet/in.c
> ===================================================================
> --- cpukit/libnetworking/netinet/in.c   (revision 790)
> +++ cpukit/libnetworking/netinet/in.c   (working copy)
> @@ -498,7 +498,14 @@
>                 in_ifscrub(ifp, ia);
>                 ia->ia_ifa.ifa_addr = (struct sockaddr *)&ia->ia_addr;
>         }
> -       if (IN_CLASSA(i))
> +        /* Arnout Vandecappelle 2008-05-22
> +           Special case for 0.0.0.0: this should not be treated as a class A,
> +           but should get netmask 0.0.0.0 as well.  This is required for
> +           BOOTP/DHCP.
> +        */
> +        if (i==0)
> +                ia->ia_netmask = 0;
> +       else if (IN_CLASSA(i))
>                 ia->ia_netmask = IN_CLASSA_NET;
>         else if (IN_CLASSB(i))
>                 ia->ia_netmask = IN_CLASSB_NET;
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>