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 Zhang <cingular.a...@gmail.com>
Date: Mon, Jun 18, 2012 at 4:53 PM
Subject: Re: [Discuss-gnuradio] tunnel.py destination host unreachable
To: Weixian Zhou <idea...@gmail.com>
Cc: j...@ettus.com, gnuradio mailing list <discuss-gnuradio@gnu.org>
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 <idea...@gmail.com> 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 <idea...@gmail.com> 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 <idea...@gmail.com> 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 <cingular.a...@gmail.com>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 <cingular.a...@gmail.com>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
>>>>> <cingular.a...@gmail.com>wrote:
>>>>>
>>>>>> Something like discarded.
>>>>>>
>>>>>>
>>>>>> On Fri, Jun 15, 2012 at 11:59 AM, Weixian Zhou <idea...@gmail.com>wrote:
>>>>>>
>>>>>>> What do you mean by "it may be consumed"?
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jun 15, 2012 at 12:44 PM, Alex Zhang <
>>>>>>> cingular.a...@gmail.com> 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
>>>>>>>> <idea...@gmail.com>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 <
>>>>>>>>> cingular.a...@gmail.com> 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 <idea...@gmail.com
>>>>>>>>>> > 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 <
>>>>>>>>>>> cingular.a...@gmail.com> 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 <
>>>>>>>>>>>> idea...@gmail.com> 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
>>>>>>>>>>>>> Discuss-gnuradio@gnu.org
>>>>>>>>>>>>> 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
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
