Problem with udp-sink/source over a network

Hello all,

I've been working with the udp-sink and source blocks to try and get

a usrp working from a remote location. Everything I’ve tried seems to be
working fine when I test on a local machine, but I’m getting an odd
error once I move to a remote test. I used the vector_source.py and
vector_sink.py as examples for what I have so far, and going back to
them it seems like they don’t work for me remotely either. I get the
following error when attempting to connect my own application and
vector_source.py to a remote computer:

socket connect: Invalid argument
terminate called after throwing an instance of ‘std::runtime_error’
what(): can’t connect to socket
Aborted

I can’t for the life of me figure out what the invalid argument going to
connect() might be. I’ve attempted to use gdb as per the recommendations
in “How to Write a Block”, but after attaching to the process gdb is
unable to figure out where it is, and stepping through the code doesn’t
work at all. If anyone could try running vector_source/sink.py on remote
systems, I would greatly appreciate any help getting this working.
Thanks!

Dev R. wrote:

socket connect: Invalid argument
terminate called after throwing an instance of ‘std::runtime_error’
what(): can’t connect to socket
Aborted

You must have the remote listener already running before running the
sender script.


Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com

Dev R. wrote:

You must have the remote listener already running before running the
error to the connect() call is being thrown. If anyone has any other
suggestions, please let me know.

What port are you trying to use? Have you tried to run your scripts
between machines on the same network (that is, same subnet; not through
a router or anything)?

Tom

Johnathan C. wrote:

sender script.

I’ve got the remote listener running (I’ve tested this over the course
of 4-5 hours, with every configuration I can think of). Nmapping the
computers shows that the port is being opened when I run the listener,
running the source application locally also works fine, but remotely I
always receive the above error. I’ve tried all combinations of
“localhost” and the public IP that I can think of, with no luck. I’m
going to try to write out everything in C++ and figure out why the error
to the connect() call is being thrown. If anyone has any other
suggestions, please let me know.

On Fri, Jul 06, 2007 at 09:26:25AM -0400, Dev R. wrote:

going to try to write out everything in C++ and figure out why the error
to the connect() call is being thrown. If anyone has any other
suggestions, please let me know.

I have a program which runs tcp/ip over the network but I have to run
the sender before the receiver. The sender is in python and hangs on
the open. The receiver is in C and when it opens the socket, the python
program proceeds.

When the receiving program closes, the python errors off.

I suspect the udp does this the same way but I haven’t converted to udp.

I have done this on the same machine, between machines over ethernet,
and even over the internet via an SSH tunnel. This is low-speed, 19200
bytes/sec max so I don’t know about higher speeds.

I also have a case where the sender hangs on one socket until the
receiver
opens it, then goes to hang on the second one until it opens. This
version
reads audio from two radios on a stereo sound card, feeds each thru two
types of filters, then bit recovery, and level slicers. The C program
then
allows me to work on the four bit streams. A script re-cycles the python
program whenever the C program closes.

Not real exciting stuff but amazing that an ol dawg can get it to
work.:slight_smile:


LRK
[email protected]

Tom R. wrote:

what(): can’t connect to socket
computers shows that the port is being opened when I run the listener,
a router or anything)?

Tom


Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

I’ve generally tested with the 65500 port that the scripts have, but
I’ve also changed this to 13421 (and a couple of others) with the same
problem. I’ve tested on machines in the same network and subnet, which
are all able to see each other and connect to other ports through other
applications. Has anyone else tried running the vector_source.py and
vector_sink.py scripts remotely? Just want to clarify if this is an
issue with my setup.

Dev R. wrote:

other applications. Has anyone else tried running the vector_source.py
and vector_sink.py scripts remotely? Just want to clarify if this is
an issue with my setup

I’m not sure what you mean when you say you’re running the scripts
remotely? If you just mean running the source on one computer and the
sink on another, then yes, I tested them out on my network. I had two
computers taking with static IPs on a GigE switch. I’ve not tried to go
through a router or gateway, though I don’t see why that wouldn’t work
(sans firewalls, proxy’s, etc.).

Tom

Tom R. wrote:

I’ve generally tested with the 65500 port that the scripts have, but
sink on another, then yes, I tested them out on my network. I had two
[email protected]
Discuss-gnuradio Info Page

Thanks for the response Tom, that’s exactly what I was looking for. I
have the same setup (no routers or NAT-ing involved). Running
vector_sink on either and running vector_source on the other gives the
same error message. I’m running:

on host 9.8.7.1:
./vector_source.py --dst-name=9.8.7.2

on host 9.8.7.2:
./vector_sink.py --src-name=9.8.7.2

I’ve tried reversing which host connects to the other, changing ports
with the --src-port option, running the scripts in different orders,
etc. I’m running debian on one host and fedora on the other, and I’ve
disabled the firewall on both machines. Going to keep trying to figure
it out, thanks for all the responses so far!

Hi,

remotely? If you just mean running the source on one computer and the
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

Have you tried the following ?

on host 9.8.7.1:
./vector_source.py --dst-name=9.8.7.2 --src-name=9.8.7.1

on host 9.8.7.2:
./vector_sink.py --src-name=9.8.7.2

vector_source uses udp_sink, which explicitly binds before calling
connect
which requires you to pass the correct source IP, which I believe must
be
the IP of the NIC that’s going to be used to reach the destination
address,
though 0.0.0.0 may work too, but not the default “localhost”.

I’ve tried reversing which host connects to the other, changing ports with
the --src-port option, running the scripts in different orders,

Technically UDP doesn’t connect. vector_source which uses udp_sink
sends
data, while vector_sink uses udp_source which receives data. There is
no
real connection being made. The connect and bind calls only associate
local
and remote endpoints with the socket for use in subsequent recv or send
calls.

Greetings
Bart M.

Bart M. wrote:

a router or anything)?

the same error message. I’m running:
on host 9.8.7.1:

Bart M.

Thanks! That was exactly the problem, it works perfectly now. I
appreciate everyone’s help on this matter, sorry for the confusion :slight_smile: