socket sends unexpected extra word in UDP packet

[Pierre Fortin]

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... :^)

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   . xÉá... .èØ...E.
0010  00 27 00 00 40 00 40 11  74 b4 c0 a8 01 64 01 02   .'.. at .@. t´À¨.d..
0020  03 04 80 7f 04 d2 00 13  62 96 48 65 6c 6c 6f 20   .....Ò.. b.Hello 
0030  57 6f 72 6c 64                                     World            

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   ........ D.:F....
0010  45 00 ....                           ^^^^^

[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