Forum: GNU Radio Problem with udp-sink/source over a network

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
C15499de74f9ca0604f49a4ee28b2804?d=identicon&s=25 Dev Ramudit (Guest)
on 2007-07-05 22:16
(Received via mailing list)
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!
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2007-07-05 22:41
(Received via mailing list)
Dev Ramudit 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 Corgan
Corgan Enterprises LLC
http://corganenterprises.com
C15499de74f9ca0604f49a4ee28b2804?d=identicon&s=25 Dev Ramudit (Guest)
on 2007-07-06 15:39
(Received via mailing list)
Johnathan Corgan 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.
8cc60441dc67b4e59421ebe95dc63c23?d=identicon&s=25 Tom Rondeau (Guest)
on 2007-07-06 15:52
(Received via mailing list)
Dev Ramudit 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
99cc8dfb87a09ad9853e903cb1fc29d4?d=identicon&s=25 LRK (Guest)
on 2007-07-06 16:54
(Received via mailing list)
On Fri, Jul 06, 2007 at 09:26:25AM -0400, Dev Ramudit 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.:)


--
LRK
gr@ovillatx.sytes.net
C15499de74f9ca0604f49a4ee28b2804?d=identicon&s=25 Dev Ramudit (Guest)
on 2007-07-06 17:01
(Received via mailing list)
Tom Rondeau 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
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
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.
8cc60441dc67b4e59421ebe95dc63c23?d=identicon&s=25 Tom Rondeau (Guest)
on 2007-07-06 19:18
(Received via mailing list)
Dev Ramudit 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
C15499de74f9ca0604f49a4ee28b2804?d=identicon&s=25 Dev Ramudit (Guest)
on 2007-07-06 19:42
(Received via mailing list)
Tom Rondeau 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
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
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!
6d3c49947862f1f7b335aa43cce5a115?d=identicon&s=25 Bart Mermuys (Guest)
on 2007-07-06 22:08
(Received via mailing list)
Hi,

>>>>
>> remotely? If you just mean running the source on one computer and the
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>

>
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 Mermuys
C15499de74f9ca0604f49a4ee28b2804?d=identicon&s=25 Dev Ramudit (Guest)
on 2007-07-09 17:08
(Received via mailing list)
Bart Mermuys wrote:
>>>>> a router or anything)?
>>>>
>>>
>> the same error message. I'm running:
> on host 9.8.7.1:
>
> Bart Mermuys
>>
>
Thanks! That was exactly the problem, it works perfectly now. I
appreciate everyone's help on this matter, sorry for the confusion :)
This topic is locked and can not be replied to.