From: Tuan (Johnny) Ta <ta.tu...@gmail.com>
To: Marcus D. Leech <mle...@ripnet.com>; david.barto...@yahoo.com
Cc: discuss-gnuradio@gnu.org
Sent: Monday, October 31, 2011 6:01 PM
Subject: Re: [Discuss-gnuradio] USRP2 / Tunnel.py packet reflection issue
I have been running into problems using tunnel.py as well so instead of
creating a new post I thought I'll just continue this thread.
My setting:
USRP2
XCVR2450
Ubuntu 10.04 (32bit)
The problem I have is that after running tunnel, whenever I do ping, my system
gets stuck on the ARP exchange. Say A wants to ping B. A broadcasts an ARP
packet to find the MAC address of B's IP. B gets the ARP request, immediately
sends an ARP response back to A with its MAC. However, in my system, A never
gets the ARP reply.
I seriously can't think of a reason for this. I can guess a possible cause is
that B sends the ARP reply too quickly that A doesn't have enough time to go
from transmit mode to receive mode (XCVR2450 is a half-duplex daughterboard).
But I don't know how to verify this hypothesis.
Can anyone help me?
Thank you,
Johnny
On Thu, Oct 20, 2011 at 11:24 AM, Marcus D. Leech <mle...@ripnet.com> wrote:
On 20/10/2011 10:25 AM, David Barton wrote:
>
>>I have been troubleshooting an issue with possible packet relflections and
>>cannot figure out the cause. I am running tunnel.py on two USRP2s that are
>>cabled together with a 20dB attenuator between them. The settings I am using
>>on both sides for tunnel.py are:
>>
>>Tx Gain: 15 dB
>>Rx Gain: 10 dB
>>Carrier Threshold: -80
>>Rx Tunnel Freq: 400 MHz
>>Modulation: GMSK
>>Bit Rate: 1Mb/sec
>>
>>When I use VLC to stream a video from computer A to computer B over the USRP
>>link it works ok but there are alot of reflected packs being recorded by
>>computer A. The same thing happens when I try to stream from computer A to
>>computer B. This also occurs when I use iperf to test the link. Strangely,
>>though there are NO reflected packets when I ping between the computers.
>>
>>Below is a paste of some of the output from computer A. I put in a timestamp
>>on the left of when events occur. I also put in an explicit statement to
>>print out when tunnel is backing off and for how long. I added sequence
>>number to make it blatantly obvious that the computer is receiving its own
>>packet. Any packet with a sequence number beginning originates from computer
>>A. If the packet originated from computer B it shows up at RX_packet=none. As
>>it shows computer A is receiving its own packets!
>>[ 63.61 ] Tx: seq_no = 100054 | len(payload) = 1448
>>[ 63.61 ] Tx: seq_no = 100055 | len(payload) = 186
>>[ 63.61 ] Tx: seq_no = 100056 | len(payload) = 1310
>>[ 63.61 ] Tx: seq_no = 100057 | len(payload) = 1448
>>[ 63.61 ] Tx: seq_no = 100058 | len(payload) = 1021
>>[ 63.61 ] Backing off for 0.001 sec
>>[ 63.62 ] Backing off for 0.002 sec
>>[ 63.62 ] Backing off for 0.004 sec
>>[ 63.63 ] Backing off for 0.008 sec
>>[ 63.64 ] Backing off for 0.016 sec
>>[ 63.64 ] Rx: ok = True | seq_no = 100054 | len(payload) = 1448
>>[ 63.66 ] Backing off for 0.032 sec
>>[ 63.64 ] Rx: ok = True | seq_no = 100055 | len(payload) = 186
>>[ 63.66 ] Rx: ok = True | seq_no = 100056 | len(payload) = 1310
>>[ 63.66 ] Rx: ok = True | seq_no = 100057 | len(payload) = 1448
>>[ 63.67 ] Backing off for 0.064 sec
>>[ 63.67 ] Rx: ok = True | seq_no = 100058 | len(payload) = 1021
>>[ 63.72 ] Tx: seq_no = 100059 | len(payload) = 1448
>>[ 63.72 ] Tx: seq_no = 100060 | len(payload) = 70
>>[ 63.72 ] Tx: seq_no = 100061 | len(payload) = 1448
>>[ 63.72 ] Tx: seq_no = 100062 | len(payload) = 150
>>[ 63.72 ] Tx: seq_no = 100063 | len(payload) = 1448
>>[ 63.72 ] Tx: seq_no = 100064 | len(payload) = 248
>>[ 63.72 ] Backing off for 0.001 sec
>>[ 63.72 ] Backing off for 0.002 sec
>>[ 63.73 ] Backing off for 0.004 sec
>>[ 63.74 ] Backing off for 0.008 sec
>>[ 63.75 ] Backing off for 0.016 sec
>>[ 63.74 ] Rx: ok = True | seq_no = 100060 | len(payload) = 70
>>[ 63.75 ] Rx: ok = True | seq_no = 100061 | len(payload) = 1448
>>[ 63.76 ] Backing off for 0.032 sec
>>[ 63.75 ] Rx: ok = True | seq_no = 100062 | len(payload) = 150
>>[ 63.76 ] Rx: ok = True | seq_no = 100063 | len(payload) = 1448
>>[ 63.76 ] Rx: ok = True | seq_no = 100064 | len(payload) = 248
>>[ 63.78 ] Tx: seq_no = 100065 | len(payload) = 1448
>>[ 63.78 ] Tx: seq_no = 100066 | len(payload) = 566
>>[ 63.78 ] Tx: seq_no = 100067 | len(payload) = 1448
>>[ 63.78 ] Tx: seq_no = 100068 | len(payload) = 987
>>[ 63.78 ] Backing off for 0.001 sec
>>[ 63.79 ] Backing off for 0.002 sec
>>[ 63.79 ] Backing off for 0.004 sec
>>[ 63.79 ] Backing off for 0.008 sec
>>[ 63.8 ] Backing off for 0.016 sec
>>[ 63.8 ] Rx: ok = True | seq_no = 100066 | len(payload) = 566
>>[ 63.82 ] Backing off for 0.032 sec
>>[ 63.82 ] Rx: ok = True | seq_no = 100067 | len(payload) = 1448
>>[ 63.82 ] Rx: ok = True | seq_no = 100068 | len(payload) = 987
>>[ 63.84 ] Tx: seq_no = 100069 | len(payload) = 1448
>>[ 63.84 ] Tx: seq_no = 100070 | len(payload) = 1448
>>[ 63.84 ] Tx: seq_no = 100071 | len(payload) = 1448
>>[ 63.84 ] Tx: seq_no = 100072 | len(payload) = 321
>>[ 63.84 ] Tx: seq_no = 100073 | len(payload) = 1448
>>[ 63.84 ] Tx: seq_no = 100074 | len(payload) = 855
>>[ 63.84 ] Backing off for 0.001 sec
>>[ 63.84 ] Backing off for 0.002 sec
>>[ 63.85 ] Backing off for 0.004 sec
>>[ 63.85 ] Backing off for 0.008 sec
>>[ 63.86 ] Backing off for 0.016 sec
>>[ 63.87 ] Backing off for 0.032 sec
>>[ 63.86 ] Rx: ok = True | seq_no = 100070 | len(payload) = 1448
>>[ 63.89 ] Rx: ok = True | seq_no = 100071 | len(payload) = 1448
>>[ 63.89 ] Rx: ok = True | seq_no = 100072 | len(payload) = 321
>>[ 63.89 ] Rx: ok = True | seq_no = 100073 | len(payload) = 1448
>>[ 63.9 ] Backing off for 0.064 sec
>>[ 63.9 ] Rx: ok = True | seq_no = 100074 | len(payload) = 855
>>
>>
>> Does anyone have any idea why this could be occurring? I thought maybe it
>>would be a physical reflection but dont understand why ping packets would not
>>be reflected in that case.
>>
>>Thanks,
>>Dave
>There's generally only about 45dB of isolation available between TX and RX, so
>if you're running in full-duplex, your receiver will see its
> own transmissions.
>
>
>
>
>Marcus,
>
>
>I do not believe I am running in full duplex mode. I am only using one antenna
>and have not set any options to full duplex. On a side note how would I change
>to full duplex if desired?
>
>
>So, if I am running in half duplex any ideas why I would be seeing these
>"reflections" with the WBX daughter card? It is very problematic because it
>could cause the transmitter to back off the link for a reflected packet.
>
>Thanks,
>Dave
>
>_______________________________________________
>Discuss-gnuradio mailing list
>Discuss-gnuradio@gnu.org
>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
