[bug found] Re: byte swapped udp length in diskless bootp request ?

From: Luigi Rizzo <rizzo_at_icir.org>
Date: Fri, 1 Dec 2006 10:08:21 -0800
On Thu, Nov 30, 2006 at 10:55:37AM -0800, Luigi Rizzo wrote:
> i was just trying to diskless-boot a -current kernel,
> and when it was time for the kernel to acquire the address
> i was getting the usual
> 
> 	DHCP/BOOTP timeout for server 255.255.255.255
> 
> Usually it is because of lack of connectivity, but
> a bit of inspection on the server showed (as you can see
> below) that the UDP len field is byte-swapped - the 05bc
> in the packet is in little-endian format, causing the
> server to reject it.

[ actually, it is the IP len that is byte-swapped ]

> I am trying to follow the code in sys/nfsclient/bootp_subr.c
> (which should send the packet) but it seemd to call sosend()
> (at line 755) to generate the packet, so it looks really strange
> that the bug is in such a central place... any ideas ?

as a followup:

    Downgrading sys/kern/uipc_socket.c to version 1.284 make HEAD
    work again with in-kernel bootp..

i managed to locate the bug in the following commit:

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/uipc_socket.c.diff?r1=1.284&r2=1.285

  Revision 1.285  Thu Nov 2 17:45:28 2006 UTC (4 weeks ago) by andre
  Branch: MAIN
  Changes since 1.284: +29 -1 lines
  Diff to previous 1.284 (colored)

  Use the improved m_uiotombuf() function instead of home grown sosend_copyin()
  to do the userland to kernel copying in sosend_generic() and sosend_dgram().

  sosend_copyin() is retained for ZERO_COPY_SOCKETS which are not yet supported
  by m_uiotombuf().

I don't know exactly where the problem is, but the bug i found is triggered
by in-kernel sockets (such as the one used by the internal bootp client)
so maybe this was a case not tested by andre.

I am unclear on where is the actual bug. hopefully something simple...

	cheers
	luigi


> If that matters, the kernel is cross-compiled on a 6.2-RC1
> box using a relatively fresh source tree.
> 
> 	cheers
> 	luigi
> 
> TCPDUMP OUTPUT ON THE SERVER SIDE:
> 
> r1# tcpdump -nli em0 -s 0 -veX port 67
> tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 65535 bytes
> 19:37:30.633525 00:40:f4:34:ad:09 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 1502: truncated-ip - 46645 bytes missing! (tos 0x0, ttl   1, id 83, offset 0, flags [none], proto: UDP (17), length: 48133, bad cksum 5bc (->fd95)!) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:40:f4:34:ad:09, length: 48105, xid:0xffff0001, secs:400, flags: [Broadcast]
>           Client Ethernet Address: 00:40:f4:34:ad:09
>           Vendor-rfc1048:
>             MSZ:1460
>             VC:"FreeBSD:i386:7.0-CURRENT"
>             DHCP:DISCOVER
>         0x0000:  4500 bc05 0053 0000 0111 05bc 0000 0000  E....S..........
>         0x0010:  ffff ffff 0044 0043 05bc 0000 0101 0600  .....D.C........
>         0x0020:  ffff 0001 0190 8000 0000 0000 0000 0000  ................
>         0x0030:  0000 0000 0000 0000 0040 f434 ad09 0000  ........._at_.4....
> 
> 		... and so on. The rest of the packet has all
> 		the good data up to
> 
>         0x05a0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
>         0x05b0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
>         0x05c0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
> 
> ----------------------------------------------------------
Received on Fri Dec 01 2006 - 17:08:27 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:03 UTC