Forum: GNU Radio Tun/Tap Problem while Running tunnel.py while wireshark recognizes

2253f229de2a90490d242cd781878d37?d=identicon&s=25 Jay Prakash (Guest)
on 2013-06-06 21:24
(Received via mailing list)
We are working on establishing a tunnel for MAC protocol design using
tunnel.py given as example in GNU Radio but are unable to receive ping
reply from the other node.

We created tun/tap interface using ./tunnel.py -f 990M and ipconfig
192.168.200.1 on Machine A connected to N210 series of USRP.
and ./tunnel.py -f 990M and ifconfig 192.168.200.2 on machine B.

1. Now on pinging machine B from A we can see ping packets being sent to
B
by A using wireshark, but there is no reply on node A.

2. We went into details and saw there were ARQ requests from B
repetitively.
I manually added the mac address to update the table.
Now ARQ request ceased to exist but still there were no replies on A.


3. Since we knew the Packaging details of ICMP we read the packets being
received by B and found the exact source address of A from the frame. It
means message have been successfully decoded by the destination and it
knows whom to reply for the ping but still I don't find any reception
confirmation on source side.

What may be the possible problems?USRP antenna gain?Packets collision?

In short we are unable to use tunnely.py  and are seeking for possible
causes.

Jay Prakash
Senior Undergraduate
C539637020fd56193dd6daec746c4a84?d=identicon&s=25 Tom Rondeau (Guest)
on 2013-06-10 15:44
(Received via mailing list)
On Thu, Jun 6, 2013 at 3:22 PM, Jay Prakash
<jay.prakash.ece09@itbhu.ac.in> wrote:
>
>
> What may be the possible problems?USRP antenna gain?Packets collision?
>
> In short we are unable to use tunnely.py  and are seeking for possible
> causes.
>
> Jay Prakash
> Senior Undergraduate

You could be having gain issues. Test this using the standard
uhd_siggen and uhd_fft programs to understand what settings give you
the best gain.

Also, try using different frequencies for transmit and receive (use
the -h on the command line to figure out how to do this).

Tom
2253f229de2a90490d242cd781878d37?d=identicon&s=25 Jay Prakash (Guest)
on 2013-06-10 16:32
(Received via mailing list)
Yes I have tested using different frequency.No help.

And while debugging I figured out that PHY layer receives the packet
from
transmitter sent as ping ICMP packets and decodes the sender's address.
After that it writes to the tun/tap. But tun/tap reply is unavailable.
Ie there is some problem in tun/tap and PHY layer interface.

How to figure this out?


Jay Prakash
Senior Undergraduate
Electronics Engineering
IIT (BHU)
VARANASI

+91-9559475258
http://about.me/jay.prakash/
http://www.linkedin.com/profile/view?id=91120191&t...
080e3a7c076624fe71d3e868d496552e?d=identicon&s=25 Karan T. (karan_t)
on 2013-06-11 07:17
(Received via mailing list)
Hi Jay and Tom,
                        we too are having similar issues in
communicating
between two USRP's using tunnel.py. we fiddled a lot with the gain
values,
changed frequencies, modified delay variables in the code but found that
even though there is pretty good full duplex communication of packets
between the USRP's, the ping command is not giving a  good output. we
tried
and received a minimum ping packet loss of 60%. we couldn't get better
than
that with all the modifications we tried. we thought that the ping is
not
receiving the icmp back in time so it is showing as a false packet
because
the usrp packets reception on both ends is fine.

Any suggestions will be very helpful. Thank You.


On Mon, Jun 10, 2013 at 8:00 PM, Jay Prakash
C539637020fd56193dd6daec746c4a84?d=identicon&s=25 Tom Rondeau (Guest)
on 2013-06-11 15:33
(Received via mailing list)
On Tue, Jun 11, 2013 at 1:16 AM, Karan Talasila <karan.t86@gmail.com>
wrote:
>
> Any suggestions will be very helpful. Thank You.

I was hoping that what I said to Jay would have been a bit of a help
to get him going. But go back in this list a few months to read my
post about not using tunnel.py. There are a number of problems with it
at this point. Fundamentally, the CSMA decision is made too far away
from the antenna to be of any real value. Also, there is no FEC, so
any wrong bit in a frame means you lose that entire frame.

You'll be better served building your application of using GNU Radio
blocks to transmit data.

Tom
858d92a2065de150eae9d55dd81d1dbd?d=identicon&s=25 Frank Smith (frank_smith)
on 2014-01-08 10:24
Karan T. wrote in post #1111989:
> Hi Jay and Tom,
>                         we too are having similar issues in
> communicating
> between two USRP's using tunnel.py. we fiddled a lot with the gain
> values,
> changed frequencies, modified delay variables in the code but found that
> even though there is pretty good full duplex communication of packets
> between the USRP's, the ping command is not giving a  good output. we
> tried
> and received a minimum ping packet loss of 60%. we couldn't get better
> than
> that with all the modifications we tried. we thought that the ping is
> not
> receiving the icmp back in time so it is showing as a false packet
> because
> the usrp packets reception on both ends is fine.
>
> Any suggestions will be very helpful. Thank You.
>
>
> On Mon, Jun 10, 2013 at 8:00 PM, Jay Prakash

hi there
I am trying to build a polling system but failed to setup the reliable
communication link between two nodes.the problem is that when A send a
packet to B,it cannot receive a reply,so how did you do that?any
suggestions will be appreciated.
A0810aff8d8c0540f3c1c47e790f8eeb?d=identicon&s=25 Jeremy C. (jeremy_c)
on 2014-01-09 09:38
Hello,

I got tunnel.py working okay years ago using USRP1. I could run ping and
other stuff through the tunnel without problems.

Now I seem to have the same problems you do with USRP N210. I suspect it
might have something to do with IP tunnelling through the LAN connection
causing confusion.

Are you people using the USRP2 / N series as well? If so, it would
support the hypothesis. In that case, how would we fix this?

Best,
Jeremy
A0810aff8d8c0540f3c1c47e790f8eeb?d=identicon&s=25 Jeremy C. (jeremy_c)
on 2014-01-09 09:42
For what it's worth, one thing we noticed was that gr0 gets assigned a
virtual physical address which ARP uses in signalling. Would this cause
a problem?

Jeremy
A0810aff8d8c0540f3c1c47e790f8eeb?d=identicon&s=25 Jeremy C. (jeremy_c)
on 2014-01-09 10:26
This topic is locked and can not be replied to.