Tunnel.py destination host unreachable - Temporarily solution, due to too fast reply!

Hello Josh,

I have seen many guys complaining the tunnel.py failed in PING by the
“destination host unreachable”, for both the OFDM and Narrowband.
This problem is caused by crushed ARP reply. I previously use the static
ARP table to work round this problem, but today I did some investigating
and test, and now I believe the too fast ARP reply from the destination
causes that the transmitter can not receive this reply or receive it
with
corrupted packets.

For example, if the usrp A send the ARP request at time T, then usrp B
send
back the ARP reply at time T+delta. If the delta is too small, then A
will
definitely fails to receive it.

The temp solution is as below (tunnel.py in csma_mac.main_loop), just
add
a small delay for B to send back the ARP reply. This solution works
well.

…**

@@ -185,7 +185,10 @@ def main_loop(self):

185185**

         if not payload:

186186**

             self.tb.send_pkt(eof=True)

187187**

             break

188 **

188**

189**

  •        time.sleep(0.009) # delay 9ms before sending out the reply
    

190**

  •        t2 = self.tb.source.u.get_time_now().get_real_secs()
    

191**

  •        print 'reply at time ', t
    

189192**

         if self.verbose:

190193**

             print "Tx: len(payload) = %4d" % (len(payload),)

The root cause for this problem, I guess, should be that the duplex
switching time bwteen the TX and RX at USRP is not small enough. More
details should be about the duplex mechanism of the SBX daughter board.
I
hope there are some other way to solve this problem. For example, I
tried
to specify the TX and RX at different antennas (TX/RX for transmitter,
RX2
for receiver) of the SBX, but unfortunately it seems impossible.

Looking forward to your further comments.

Thanks,

Alex(Changchun) Zhang
Cognitive Radio Institute @ Tennessee Tech Univ.

---------- Forwarded message ----------
From: Alex Z. [email protected]
Date: Mon, Jun 18, 2012 at 4:53 PM
Subject: Re: [Discuss-gnuradio] tunnel.py destination host unreachable
To: Weixian Z. [email protected]
Cc: [email protected], gnuradio mailing list [email protected]

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.

Alex,
Dreams can come true just believe.

Jason,

Thanks for information.
If I am not wrong, I think your problem is from the CSMA threshold. In
the
single link case of my mail, A and B shoule always send packet at
different
time.

In addition, I am using SBX board. The duplex detail is still devil for
me.
:<

On Mon, Jun 18, 2012 at 11:17 PM, Jason T. [email protected]
wrote:

Jason T.
Hello Josh,
send back the ARP reply at time T+delta. If the delta is too small, then A

188 **

         if self.verbose:

to specify the TX and RX at different antennas (TX/RX for transmitter, RX2
From: Alex Z. [email protected]
In the csma_mac.main_loop() of your tunnel.py, add a
The following is the messages of the transmitter after I ping. The
UTx: len(payload) = 302
URx: ok = False len(payload) = 240
Tx: len(payload) = 189
UTx: len(payload) = 90
UTx: len(payload) = 42
UTx: len(payload) = 42
Tx: len(payload) = 42
Tx: len(payload) = 81
CRC check (ok=false). I think some parameters need to be tuned, maybe
On Fri, Jun 15, 2012 at 6:43 PM, Alex Z. [email protected]wrote:
You can try different time intervals.

“Destination Host Unreachable”.
on machine A:
one machine did not rx. Why is that?
located in gnuradio/gr-digital/examples/narrwoband.


Dreams can come true just believe.

Regards,

Weixian Z.


Dreams can come true just believe.


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

Alex,
Dreams can come true just believe.

I had a similar problem way back and found collided packets (corrupted
packets with ok=False). I started digging and found that my
gr_probe_mag_sqrd_X was not returning a high enough magnitude for the
carrier sense to be tripped. This also had to do with an issue I was
having getting the xcvr2450 to tune to the right tx/rx frequencies…

I suggest printing out the result of the magnitude squared to see if
this is the case as well for you guys.

Regards,
Jason T.


From: Alex Z. [email protected]
To: [email protected]
Cc: Tom R. [email protected]; gnuradio mailing list
[email protected]
Sent: Monday, June 18, 2012 9:07 PM
Subject: [Discuss-gnuradio] tunnel.py destination host unreachable -
Temporarily solution, due to too fast reply!

Hello Josh,

I have seen many guys complaining the tunnel.py failed in PING by the
“destination host unreachable”, for both the OFDM and Narrowband.
This problem is caused by crushed ARP reply. I previously use the static
ARP table to work round this problem, but today I did some investigating
and test, and now I believe the too fast ARP reply from the destination
causes that the transmitter can not receive this reply or receive it
with corrupted packets.

For example, if the usrp A send the ARP request at time T, then usrp B
send back the ARP reply at time T+delta. If the delta is too small, then
A will definitely fails to receive it.

The temp solution is as below (tunnel.py in csma_mac.main_loop), just
add a small delay for B to send back the ARP reply. This solution works
well.

… … @@ -185,7 +185,10 @@ def main_loop(self):
185 185 if not payload:
186 186 self.tb.send_pkt(eof=True)
187 187 break
188 -
188 +
189 + time.sleep(0.009) # delay 9ms before sending out the
reply
190 + t2 = self.tb.source.u.get_time_now().get_real_secs()
191 + print 'reply at time ', t
189 192 if self.verbose:
190 193
print “Tx: len(payload) = %4d” % (len(payload),)
The root cause for this problem, I guess, should be that the duplex
switching time bwteen the TX and RX at USRP is not small enough. More
details should be about the duplex mechanism of the SBX daughter board.
I hope there are some other way to solve this problem. For example, I
tried to specify the TX and RX at different antennas (TX/RX for
transmitter, RX2 for receiver) of the SBX, but unfortunately it seems
impossible.

Looking forward to your further comments.

Thanks,

Alex(Changchun) Zhang
Cognitive Radio Institute @ Tennessee Tech Univ.

---------- Forwarded message ----------
From: Alex Z. [email protected]
Date: Mon, Jun 18, 2012 at 4:53 PM
Subject: Re: [Discuss-gnuradio] tunnel.py destination host unreachable
To: Weixian Z. [email protected]
Cc: [email protected], gnuradio mailing list [email protected]

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:

The following is the messages of the transmitter after I ping. The
packages of len(payload)=42 failed CRC check, but other packages
succeed.

URx: ok = False len(payload) = 302
Tx: len(payload) = 404
Rx: ok = False len(payload) = 380
UTx: len(payload) = 350
UTx: len(payload) = 42
URx: ok = False len(payload) = 42
UTx: len(payload) = 42
UTx: len(payload) = 101

You can try different time intervals.

Thanks for responses. The problem that confused me is that when I

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

Regards,Weixian Z.

Alex,
Dreams can come true – just believe.

Alex,
Dreams can come true – just believe.