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 Tran <jasonat...@yahoo.com> wrote: > 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 <cingular.a...@gmail.com> > *To:* j...@ettus.com > *Cc:* Tom Rondeau <trondeau1...@gmail.com>; gnuradio mailing list < > discuss-gnuradio@gnu.org> > *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* <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 > > > -- Alex, *Dreams can come true – just believe.*
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
