|
From: | Alex Zhang |
Subject: | Re: [Discuss-gnuradio] tunnel.py destination host unreachable - Temporarily solution, due to too fast reply! |
Date: | Mon, 18 Jun 2012 23:37:45 -0500 |
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 break188 -188 +189 + time.sleep(0.009) # delay 9ms before sending out the reply190 + t2 = self.tb.source.u.get_time_now().get_real_secs()191 + print 'reply at time ', t189 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) ZhangCognitive 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.AlexOn 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) = 101Tx: len(payload) = 90Tx: len(payload) = 54UTx: len(payload) = 220UTx: len(payload) = 326URx: ok = False len(payload) = 326Tx: len(payload) = 81UTx: len(payload) = 326UTx: len(payload) = 326UTx: len(payload) = 302URx: ok = False len(payload) = 302Tx: len(payload) = 78UTx: len(payload) = 220URx: ok = False len(payload) = 220Tx: len(payload) = 81UTx: len(payload) = 302URx: ok = False len(payload) = 302Tx: len(payload) = 70UTx: len(payload) = 110UTx: len(payload) = 240URx: ok = False len(payload) = 240Tx: len(payload) = 404Tx: len(payload) = 201UTx: len(payload) = 101UTx: len(payload) = 404Tx: len(payload) = 201Tx: len(payload) = 54UTx: len(payload) = 404Tx: len(payload) = 201Tx: len(payload) = 114UTx: len(payload) = 380Tx: len(payload) = 189Rx: ok = False len(payload) = 380UTx: len(payload) = 240UTx: len(payload) = 101UTx: len(payload) = 318UTx: len(payload) = 81UTx: len(payload) = 380Tx: len(payload) = 189Rx: ok = False len(payload) = 380URx: ok = False len(payload) = 189Tx: len(payload) = 302UTx: len(payload) = 90UTx: len(payload) = 350UTx: len(payload) = 101UTx: len(payload) = 380Tx: len(payload) = 189Rx: ok = False len(payload) = 380UTx: len(payload) = 70UTx: len(payload) = 81UTx: len(payload) = 101UTx: len(payload) = 70UTx: len(payload) = 42UTx: len(payload) = 42UTx: len(payload) = 42URx: ok = True len(payload) = 81Tx: len(payload) = 42UTx: len(payload) = 42URx: ok = True len(payload) = 101Tx: len(payload) = 42UTx: len(payload) = 81UTx: len(payload) = 42URx: ok = False len(payload) = 42Tx: len(payload) = 101UTx: len(payload) = 42URx: ok = False len(payload) = 42Tx: len(payload) = 42URx: ok = False len(payload) = 42Tx: len(payload) = 42URx: ok = False len(payload) = 42Tx: len(payload) = 42URx: ok = False len(payload) = 42Tx: len(payload) = 42UTx: len(payload) = 42URx: ok = False len(payload) = 42Tx: len(payload) = 42UTx: len(payload) = 42UTx: len(payload) = 42URx: ok = False len(payload) = 42Tx: len(payload) = 42UTx: len(payload) = 42UTx: len(payload) = 42UTx: len(payload) = 42URx: ok = False len(payload) = 42Tx: len(payload) = 42URx: ok = False len(payload) = 42Tx: len(payload) = 81UTx: len(payload) = 101URx: ok = True len(payload) = 81Rx: 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 Ion machine A:sudo ./tunnel.py --tx-freq=2.51G --rx-freq=2.515G -c 50 -r 0.5Mthensudo ifconfig gr0 192.168.200.1on machine B:sudo ./tunnel.py --tx-freq=2.515G --rx-freq=2.51G -c 50 -r 0.5Mthensudo ifconfig gr0 192.168.200.2I 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
[Prev in Thread] | Current Thread | [Next in Thread] |