ESP Raw Socket: Returned IP packet incorrect

Michael Tüxen Michael.Tuexen at lurchi.franken.de
Tue Jul 12 10:25:42 UTC 2011


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.Tuexen at 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 at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
> >
> 
> 



More information about the freebsd-net mailing list