On Jul 12, 2011, at 11:23 AM, Matthew Cini Sarreo wrote: > Thanks for your reply. Where can I find documentation about this? (Or would > it be possible for you to direct me at the proper sources?) At http://fxr.watson.org/fxr/source/netinet/ip_input.c#L464 the length field is converted to host byte order. I have not looked at the Linux sources.
I figured it out when writing an SCTP test tool which uses raw socket IO and support Solaris, Linux, FreeBSD and Mac OS X. Best regards Michael > > Thanks & Regards > Matt > > On 11 July 2011 18:01, Michael Tüxen <michael.tue...@lurchi.franken.de> wrote: > On Jul 11, 2011, at 5:26 PM, Matthew Cini Sarreo wrote: > > > Hello all; > > > > I have recently encountered a problem when using raw sockets on FreeBSD 8 > > (8.0-RELEASE) when using ESP raw sockets. > > > > I have created a raw esp socket using: > > socket(AF_INET, SOCK_RAW, 50); > > which works fine. However, when there is a packet on the socket, recvfrom() > > returns a packet where the length bytes in the IP header are incorrect; they > > are swapped (MSB is placed in the LSB and vice-versa) > > > > tcpdump shows the following: > > > > tcpdump: listening on le0, link-type EN10MB (Ethernet), capture size 96 > > bytes > > 15:00:53.993810 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ESP > > (50), length 120) > > 10.0.251.228 > 10.0.252.231: ESP(spi=0xa0534f17,seq=0x3), length 100 > > 0x0000: 4500 0078 0000 4000 4032 2d88 0a00 fbe4 > > 0x0010: 0a00 fce7 a053 4f17 0000 0003 6885 8abd > > 0x0020: 2222 5ded 44dc 842f 3081 8fa3 bde4 2265 > > 0x0030: 7438 2bf4 049c 664b 7dc4 44ef 1f6f 5e7d > > 0x0040: b8c1 482f 8c3b f488 a19a 3d9a d5fe ed9d > > 0x0050: b1c2 > > > > > > However, recvfrom() returns the following buffer: > > 4500 6400 0000 0040 4032 2D88 0A00 FBE4 > > 0A00 FCE7 A053 4F17 0000 0003 6885 8ABD > > 2222 5DED 44DC 842F 3081 8FA3 BDE4 2265 > > 7438 2BF4 049C 664B 7DC4 44EF 1F6F 5E7D > > B8C1 482F 8C3B F488 A19A 3D9A D5FE ED9D > > B1C2 > > > > As it is easy to see, the length is not correct (bytes 2 and 3 are 0x6400 > > instead of 0x0064) and it does not correspond to the value returned by > > recvfrom(). > > > > Is this a known issue? Am I missing some options for raw sockets that are > > required for FreeBSD? I have attempted this on a socket to a TUN interface > > (not with an ESP socket) and the buffer had the proper length; it seems to > > only happen with ESP. This code runs fine on multiple Linux distributions > > and on Windows; it was only noticed with FreeBSD. Could it be that there is > > some other ESP application running and interfering (I have not installed > > any; don't know if there are by default and I'm quite new to any of the > > BSDs)? > I think Linux provides the tot_len field in network byte order whereas > FreeBSD provides it in host byte order. At least they expect it that way > when using a send call. > > So you must take care of this in the source code of the application by > using an #ifdef... > > Best regards > Michael > > > > Any help would be much appreciated. > > Matt > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > > > > _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"