netcat-traditional stops listening after one packet in UDP broadcast mode

Bug #1079950 reported by Mark Roduner
24
This bug affects 5 people
Affects Status Importance Assigned to Milestone
netcat (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

I had planned on using netcat as a UDP broadcast listener / server, for audio distribution, and in testing I found this neat little gem.

The UDP server below works, tested with wireshark (on both local, and remote machines):
<code>
nc -u -b 192.168.0.255 9999 < /dev/random
</code>

However, the UDP receiver quits listening after one packet
<code>
nc -l -u -b -q -1 -p 9999
</code>

Example output as follows (using stdin rather than random for clarity)
Server:
<code>
$ nc -u -b 192.168.0.255 9999< /dev/stdin
test packet 1
test packet two
^C
</code>

Client(s):
<code>
$ nc -l -u -b -q -1 -p 9999
test packet 1
</code>
and then nothing else is received.

(edit: forgot to add the ports)

description: updated
Revision history for this message
Charles Lohr (charles-cnlohr) wrote :

This is totally biting me, too. I can't figure out how to get it to receive! One packet and it dies.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in netcat (Ubuntu):
status: New → Confirmed
Revision history for this message
flux242 (flux242) wrote :

listen to the udp broadcasts on a specific port:
nc -klu port_number

Revision history for this message
Bernd Porr (berndporr) wrote :

I'm having exactly the same problem. I'm transmitting data with my program attys_scope. It's using QT for the UDP transmit and under Windows it works. Under Linux it won't. I've tried the nc -klu and it also just gives one line back. However the same problem arises when I use a python program which reads from the UDP socket. Under Windows it works. Under Linux it doesn't. So it might be something deeper in the kernel.

Python script which works under Windows but not under Linux:
# socket connection to attys_scope
s = socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
listen_addr = ("",65000)
s.bind(listen_addr)
f = s.makefile()

# init the amplitudes
amplitudes = np.zeros(2)

# for the thread below
doRun = True

# read data from the udp socket into two variables
# note you need to have at least two analoge channels on
# this just overwrites the amplitudes as fast as possible
# for an oscilloscope plot we need a proper ringbuffer here!
def readSocket():
    global amplitudes
    while doRun:
        # check if data is available
        data = f.readline()
        values = np.array(data.split(','),dtype=np.float32)
        values = np.fabs(values)
        amplitudes = values[9:11]

bp1@bp1-Precision-WorkStation-T5400:~/sandbox/attys_scope/python$ nc -klu 65000
491.859985,-30.928297,7.316680,-2.791639,0.000013,-0.000020,0.000015,0.247545,0.001498,-0.000834,0.001498

QT program which transmits the datagrams (inspired by the QT examples which won't require a bind):

void ScopeWindow::startUDP(int port)
{
 udpSocket = new QUdpSocket(this);
 udpPort = port;
 _RPT1(0, "UDP transmit on port %d\n",port);
}

void ScopeWindow::stopUDP()
{
 delete udpSocket;
 udpSocket = NULL;
}

void ScopeWindow::writeUDP() {
 if (!udpSocket) return;
 char tmp[256];
 sprintf(tmp, "%f", ((float)nsamples) / ((float)attysComm[0]->getSamplingRateInHz()));
 for (int n = 0; n < nAttysDevices; n++) {
  int nFiltered = 0;
  for (int i = 0; i < channels_in_use; i++) {
   if (attys_scope->channel[n][i]->isActive()) {
    nFiltered++;
   }
   float phy = unfiltDAQData[n][i];
   sprintf(tmp+strlen(tmp), ",%f", phy);
  }
  for (int i = 0; i < nFiltered; i++) {
   float phy = filtDAQData[n][i];
   sprintf(tmp+strlen(tmp), ",%f", phy);
  }
 }
 sprintf(tmp+strlen(tmp), "\n");
 if (udpSocket) {
  if (udpStatus > -1) {
   udpStatus = udpSocket->writeDatagram(tmp, strlen(tmp), QHostAddress::Broadcast, udpPort);
   //_RPT1(0, "%s", tmp);
  }
 }
}

This script works find under Windows. I use s similar programs as nc under Windows and there everything is fine.

Kernel issue?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.