socket sends unexpected extra word in UDP packet

[Chris Liechti]

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 
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)

> 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)
 
> 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)

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
>]
> 
> HTH,
> Pierre



-- 
Chris <cliechti at gmx.net>