Tun/Tap Problem while Running tunnel.py while wireshark recognizes

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

On Thu, Jun 6, 2013 at 3:22 PM, Jay Prakash
[email protected] 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

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&trk=hb_tab_pro_top

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

On Tue, Jun 11, 2013 at 1:16 AM, Karan T. [email protected]
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

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

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

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.

Hi,

This works:
http://lists.gnu.org/archive/html/discuss-gnuradio/2012-06/msg00384.html

Best

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs