Tunnel.py destination host unreachable

GNU Radio
1

I was testing with tunnel.py and following the instructions in README
located in gnuradio/gr-digital/examples/narrwoband.
I found that when I input* ifconfig gr0 192.168.200.1* on machine A, and
input* ifconfig gr0 192.168.200.2* on machine B at the same time, both
machines showed Tx and Rx packages.
But when I* ping 192.168.200.2* from machine A ( or ping
192.168.200.1from machine B respectively), one window of machine A
only showed Tx
packages and another window showed “Destination Host Unreachable”.
Machine
B showed both Rx/Tx packages.
It means that machine B can successfully received packages from machine
A
but A failed to receive replied packages from machine B. It confused me
that the packages tx/rx were succeed before the ping. Anyone has idea?

2

Most likely you did not set the freq and gain properly. Unstable
physical
layer communications cause the ARP routing failure.
Please use different frequencies for tx and rx.

On Thu, Jun 14, 2012 at 1:51 PM, Weixian Z. [email protected] wrote:

that the packages tx/rx were succeed before the ping. Anyone has idea?
Discuss-gnuradio Info Page

–

Alex,
Dreams can come true just believe.

3

I did the test by myself, and the most of the time ARP queries
failed… I
met this problem when I do the OFDM link test, but that is because the
physical layer is not robust. But for this narrow band (GMSK)
modulation, I
am not sure what the problem is.

May Josh knows… :slight_smile:

On Fri, Jun 15, 2012 at 3:05 PM, Alex Z. [email protected]
wrote:

Did you see RX False at the receiver for the ARP reply? If that is not

then
On Thu, Jun 14, 2012 at 4:38 PM, Alex Z. [email protected]wrote:

A, and input* ifconfig gr0 192.168.200.2* on machine B at the same

–
Dreams can come true just believe.

Regards,

–

Alex,
Dreams can come true just believe.

4

Weixian,

Could you please try the ping command like this (if you are working on
linux):

sudo ping 192.168.200.2 -i 0.01

-i 0.01 means the time interval between pings is 0.01 second. And tell
me
what happened.
You can try different time intervals.

On Fri, Jun 15, 2012 at 5:37 PM, Alex Z. [email protected]
wrote:

Something like discarded.

seen, it could be due to some reason causing the ARP reply is not sent out

Do you check the ARP reply is sent out or not?

sudo ifconfig gr0 192.168.200.1

wrote:

A, and input* ifconfig gr0 192.168.200.2* on machine B at the

–
Dreams can come true just believe.

Regards,

–

Alex,
Dreams can come true just believe.

–

Alex,
Dreams can come true just believe.

5

Weixian,

Here is a temp solution, not sure it works or not:

In the csma_mac.main_loop() of your tunnel.py, add a
time_sleep(fixed_delay) right after the payload is read from the OS. You
can set fixed_delay as 0.01 to 0.1 and test the result.

And also, please set the CSMA threshold carefully to avoid
possible collision.

Alex

On Mon, Jun 18, 2012 at 10:10 AM, Weixian Z. [email protected]
wrote:

UTx: len(payload) = 326
UTx: len(payload) = 240
UTx: len(payload) = 380
Tx: len(payload) = 302
UTx: len(payload) = 42
Tx: len(payload) = 101
URx: ok = False len(payload) = 42
URx: ok = False len(payload) = 42

packages of len(payload)=42 from the receiver, but the the packages failed

me what happened.

May Josh knows… :slight_smile:

On Fri, Jun 15, 2012 at 10:49 AM, Weixian Z. [email protected]wrote:

[email protected]> wrote:

I found that when I input* ifconfig gr0 192.168.200.1* on

Alex,

–
Dreams can come true just believe.

Regards,

–
Regards,
Weixian Z.

–

Alex,
Dreams can come true just believe.

6

It works!
Thanks.