Re: [Discuss-gnuradio] tunnel.py destination host unreachable - Temporarily solution, due to too fast reply!

[Jason Tran]

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 Zhang <address@hidden>
To: address@hidden
Cc: Tom Rondeau <address@hidden>; gnuradio mailing list <address@hidden>
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 Zhang <address@hidden>
Date: Mon, Jun 18, 2012 at 4:53 PM
Subject: Re: [Discuss-gnuradio] tunnel.py destination host unreachable
To: Weixian Zhou <address@hidden>
Cc: address@hidden, gnuradio mailing list <address@hidden>


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 Zhou <address@hidden> 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 = True  len(payload) =  101

Tx: len(payload) =   90

Tx: len(payload) =   54

UTx: len(payload) =  220

UTx: len(payload) =  326

URx: ok = False  len(payload) =  326

Tx: len(payload) =   81

UTx: len(payload) =  326

UTx: len(payload) =  326

UTx: len(payload) =  302

URx: ok = False  len(payload) =  302

Tx: len(payload) =   78

UTx: len(payload) =  220

URx: ok = False  len(payload) =  220

Tx: len(payload) =   81

UTx: len(payload) =  302

URx: ok = False  len(payload) =  302

Tx: len(payload) =   70

UTx: len(payload) =  110

UTx: len(payload) =  240

URx: ok = False  len(payload) =  240

Tx: len(payload) =  404

Tx: len(payload) =  201

UTx: len(payload) =  101

UTx: len(payload) =  404

Tx: len(payload) =  201

Tx: len(payload) =   54

UTx: len(payload) =  404

Tx: len(payload) =  201

Tx: len(payload) =  114

UTx: len(payload) =  380

Tx: len(payload) =  189

Rx: ok = False  len(payload) =  380

UTx: len(payload) =  240

UTx: len(payload) =  101

UTx: len(payload) =  318

UTx: len(payload) =   81

UTx: len(payload) =  380

Tx: len(payload) =  189

Rx: ok = False  len(payload) =  380

URx: ok = False  len(payload) =  189

Tx: len(payload) =  302

UTx: len(payload) =   90

UTx: len(payload) =  350

UTx: len(payload) =  101

UTx: len(payload) =  380

Tx: len(payload) =  189

Rx: ok = False  len(payload) =  380

UTx: len(payload) =   70

UTx: len(payload) =   81

UTx: len(payload) =  101

UTx: len(payload) =   70

UTx: len(payload) =   42

UTx: len(payload) =   42

UTx: len(payload) =   42

URx: ok = True  len(payload) =   81

Tx: len(payload) =   42

UTx: len(payload) =   42

URx: ok = True  len(payload) =  101

Tx: len(payload) =   42

UTx: len(payload) =   81

UTx: len(payload) =   42

URx: ok = False  len(payload) =   42

Tx: len(payload) =  101

UTx: len(payload) =   42

URx: ok = False  len(payload) =   42

Tx: len(payload) =   42

URx: ok = False  len(payload) =   42

Tx: len(payload) =   42

URx: ok = False  len(payload) =   42

Tx: len(payload) =   42

URx: ok = False  len(payload) =   42

Tx: len(payload) =   42

UTx: len(payload) =   42

URx: ok = False  len(payload) =   42

Tx: len(payload) =   42

UTx: len(payload) =   42

UTx: len(payload) =   42

URx: ok = False  len(payload) =   42

Tx: len(payload) =   42

UTx: len(payload) =   42

UTx: len(payload) =   42

UTx: len(payload) =   42

URx: ok = False  len(payload) =   42

Tx: len(payload) =   42

URx: ok = False  len(payload) =   42

Tx: len(payload) =   81

UTx: len(payload) =  101

URx: ok = True  len(payload) =   81

Rx: ok = True  len(payload) =  101

On Mon, Jun 18, 2012 at 11:01 AM, Weixian Zhou <address@hidden> wrote:

Hi Alex,

After tried many times I found that the transmitter actually received packages of len(payload)=42 from the receiver, but the the packages failed CRC check (ok=false). I think some parameters need to be tuned, maybe bitrate?

On Mon, Jun 18, 2012 at 10:21 AM, Weixian Zhou <address@hidden> wrote:

Hi Alex,

I tried it. The problem is the same. The transmitter only showed tx message of len(payload) = 42, and the receiver showed both tx/rx messages of len(payload) = 42.

On Fri, Jun 15, 2012 at 6:43 PM, Alex Zhang <address@hidden> wrote:

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 Zhang <address@hidden> wrote:

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... :)

On Fri, Jun 15, 2012 at 3:05 PM, Alex Zhang <address@hidden> wrote:

Something like discarded.

On Fri, Jun 15, 2012 at 11:59 AM, Weixian Zhou <address@hidden> wrote:

What do you mean by "it may be consumed"?

On Fri, Jun 15, 2012 at 12:44 PM, Alex Zhang <address@hidden> wrote:

Did you see RX False at the receiver for the ARP reply? If that is not seen, it could be due to some reason causing the ARP reply is not sent out at all. Although you see the log for the TX packet in the CSMA mainloop, but it may be consumed before or when  it goes to the transmitting path...

On Fri, Jun 15, 2012 at 10:49 AM, Weixian Zhou <address@hidden> wrote:

Yes, the ARP is replied. But another machine did not received and showed "Destination Host Unreachable".

On Fri, Jun 15, 2012 at 11:19 AM, Alex Zhang <address@hidden> wrote:

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

I am not sure if there are some flow control issues for the networking. 

On Fri, Jun 15, 2012 at 10:02 AM, Weixian Zhou <address@hidden> wrote:

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

on machine A:

sudo ./tunnel.py --tx-freq=2.51G --rx-freq=2.515G -c 50 -r 0.5M 

then 

sudo ifconfig gr0 192.168.200.1

on machine B:

sudo ./tunnel.py --tx-freq=2.515G --rx-freq=2.51G -c 50 -r 0.5M 

then 

sudo ifconfig gr0 192.168.200.2

I can see packages tx/rx succeed on both machines. But the ping failed and one machine did not rx. Why is that?

On Thu, Jun 14, 2012 at 4:38 PM, Alex Zhang <address@hidden> wrote:

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 Zhou <address@hidden> wrote:

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.1 from 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?

--

Regards,

Weixian Zhou

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

--

Alex,

Dreams can come true – just believe.

--

Regards,

Weixian Zhou

--

Alex,

Dreams can come true – just believe.

--

Regards,

Weixian Zhou

--

Alex,

Dreams can come true – just believe.

--

Regards,

Weixian Zhou

--

Alex,

Dreams can come true – just believe.

--

Alex,

Dreams can come true – just believe.

--

Alex,

Dreams can come true – just believe.

--

Regards,

Weixian Zhou

--

Regards,

Weixian Zhou

--

Regards,

Weixian Zhou

--

Alex,

Dreams can come true – just believe.

--

Alex,

Dreams can come true – just believe.

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio