socket sends unexpected extra word in UDP packet

[Pierre Fortin]

Chris,

Scratch this thread...  the more I dig, the more it looks like RH7.2
contains a buggy ethereal...  all packets (previously hidden by filters)
exhibit this trait...  :^P

Sorry for the intrusion.

Pierre

On 26 May 2002 01:25:52 +0200 Chris Liechti <cliechti at gmx.net> wrote:

> Pierre Fortin <pfortin at pfortin.com> wrote in
> news:20020525181034.42ffddb0.pfortin at pfortin.com: 
> > On 25 May 2002 23:32:42 +0200 Chris Liechti <cliechti at gmx.net> wrote:
> >> Pierre Fortin <pfortin at pfortin.com> wrote in 
> >> news:20020525170124.3b2d7755.pfortin at pfortin.com:
> >> > I created a simple UDP script which does not work with some remote
> >> > hosts...  the only difference I can find is that the packet start
> >> > looks like this:
> >> > 
> >> >   MACdst, MACsrc, 0x0000, 0x0800, 0x45...
> >> >                   ^^^^^^  This is extra.
> >> > 
> >> > Some systems seem to ignore the extra 0x0000; but my customer's
> >> > server doesn't...  At this point, I don't
> >> > know precisely what OS the server is running.
> >> > 
> >> > I can have a fix tested if someone has a patch...  I'm not
> >> > comfortable with the socketmodule.c source; but I'm hunting for the
> >> > bug in the meanwhile...
> >> 
> >> it would help when you could post some small script that shows you
> >> problem. not many people will come up with their own test script but
> >> if you post one many people could verify your results and code and
> >> give you some specific advice (or even guess the unknown OS :-).
> > 
> > Sorry...  I assumed that the problem was a generic bug...  the script
> > sends fine from my Mandrake8.2 system (I'm in NC, USA); but sends the
> > extra 0x0000 from a RedHat7.2 system (in India)...  
> > 
> > Besides, s.sendto() does not give the user access to those parts of
> > the packet; just the target host/port and the data payload...  not an
> > excuse for not including, just my thinking... :^)
> 
> these extra bytes seem to be in the ethernet level. thats a problem of
> the OS and not of python.
> 
> do you capture the frames from india localy there or at your place? when
> 

The user in India runs ethereal while running the script.

> you capture those frames on you local net from outside, then it could be
> 
> your router that causes the problem (as ethernet level info does not
> leave your local network, only IP level and above)

No router involved...  this is trace of packet leaving on local NIC.

> > The following script sends correctly from my system; I'll have it
> > tried in India...
> > 
> > #!/usr/bin/env python
> > import socket
> > s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
> > s.sendto("Hello World",('1.2.3.4',1234))
> > 
> > Sends:
> > 
> > 0000  00 20 78 c9 e1 1a 00 01  02 e8 d8 8d*08 00 45 00
> > 0010  00 27 00 00 40 00 40 11  74 b4 c0 a8 01 64 01 02
> > 0020  03 04 80 7f 04 d2 00 13  62 96 48 65 6c 6c 6f 20
> > 0030  57 6f 72 6c 64                            
> 
> grr, copy&paste does not work in the hex view of ethereal on win32 :-(
> but i get the same (except the MACs of course)

Select with left-mouse, paste with middle-mouse...  oh yeah!  probably no
middle-mouse on W*...  :^)

> > On the RedHat7.2 system, Python 2.2.1 was not included (1.5.2), so it
> > was built from the tarball.  That system gives this on every packet of
> > the production script (won't know the results of the above test script
> > for a day or two...):
> > 
> > 0000  00 04 00 01 00 06 00 02  44 16 3a 46 00 00 08 00
> > 0010  45 00 ....                           ^^^^^
> 
> that should be the type, if its an Ethernet II frame but the 802.3
> Ethernet has a length field there (at least when i interpret this page: 
> 
> http://www.rware.demon.co.uk/ethernet.htm)

Right...  notice the type (0800), IPv4 (4) and length (5) are all shifted
right...

> looks to me as if there were a problem with the ethernet protocol
> version
>
> > [Aside: if you're wondering about the weird dst MAC address, ethereal
> > replaces it with:
> >    Linux cooked capture
> >         Packet type: Sent by us (4)
> >         Link-layer address type: 1
> >         Link-layer address length: 6
> >]

Pierre