#39 Linux receives phantom packets of zero length

[Frank Bannon]

When reading UDP packets on Linux, every other packet read is bogus with length zero. Confirmed using the demo udpcat.tcl
TCL app on Windows reports incoming packets correctly. Tested Linux platforms report first packet with correct length, then when subsequent packets arrive, each is preceded by a phantom packet of length zero.
Test case sent three UDP packets to network. Wireshark reported three packets with data. Windows app of udpcat.tcl reported three packets. Linux app of udpcat.tcl reported five packets, two of which are length zero.
Confirmed with tcludp-1.0.8 on Red Hat Enterprise Linux 4 with TCL 8.4.7, UDP package compiled from 1.0.8 source code.
Confirmed with tcludp-1.0.8 and 1.0.9 on Red Hat Enterprise Linux 5 with TCL 8.4.17, UDP package compiled from 1.0.8 and 1.0.9 source code.

[Huub Eikens]

I am unable to reproduce this problem. Proposal is to close this ticket.

[Holger Jakobs]

I get an endless row of phantom packets of 0 bytes when using tclkit 8.6.3 with tcludp 1.0.9, but none when using ordinary Tcl installation with tcludp 1.0.10 - both on Ubuntu 14.10.

[pcc]

hello,

I confirm the problem with tcludp1.0.8 and tcl8.6.3 and tcl8.6.4

It seems related to the modifications made to the handling of eof in recent version of tcl (see http://code.activestate.com/lists/tcl-core/14249/ )

to test the problem I generate a UDP stream, for example with netcat :

while true; do echo azertyuiop; sleep 1; done | nc -u 127.0.0.1 4444

and try to read it with a script :

package require udp

set sock [ udp_open 4444 ]
fconfigure $sock -buffering none -translation binary

proc readSock sock { set data [ read $sock ]; puts "[string length $data] : $data" }

fileevent $sock readable [ list readSock $sock ]

I tested different versions of tcl interpreter :
tcl 8.5, tcl 8.3 : all is well, I get the expected data :

11 : azertyuiop

tcl 8.6.3 : as Holger said, I can only read empty lines :

0 :

I noticed that eof $sock returns 1, and that if I use gets instead of read, it works.

So the problems really seems to be related to read

If instead of using a fileevent, I directly call my readSock procedure, I get the same result (no data)

tcl 8.6.4, : the difference with tcl 8.6.3 is that if I do not use a fileevent, using readSock directly, I can collect data from the udp socket with read.
So going from 8.6.3 to 8.6.4 is an improvement.

But If I attach readSock to a fileevent, no read is triggered.

Again, using gets gives to expected result.

So it seems the problem may not be in the TCL UDP extension, but it makes it unusable with recent version of tcl.