Ok, that definitely makes sense if there is no error correction is
implemented.
We are now trying to establish an TCP/IP connection between both USRP2s
with the tunnel.py script.
Unfortunately, it says “Destination Host unreachable” when pinging the
other USRP. We should have set up the tunnel correct as some packets
are received and transmitted after having configured the IP address.
The pinged USRPs is indicating the received icmp packet but there is
still no confirmed ping-request though.
Do you have an idea why the pinging is not working after having
established the tunnel.py connection?
On 01/31/2012 02:48 PM, Florian Schlembach wrote:
Short answer; dont do that. Yes, this particular USRP is a network
device, but that is completely unrelated to the purpose of tunnel.py.
You probably have to play with routing tables to make this work…
Do you have an idea why the pinging is not working after having
established the tunnel.py connection?
Try pinging a service that is running on the remote virtual interface on
host PC0 from the local virtual interface on host PC1.
_josh
device, but that is completely unrelated to the purpose of tunnel.py.
You probably have to play with routing tables to make this work…
Why is that unrelated to the purpose of tunnel.py? Shouldnt a simple
ping request be a basic application of using this TUN/TAP application?
Anyway, we have now set up the routing table correctly by using TUN
instead of TAP.
As we are transmitting the ping from one of the USRPs, we are also
receiving them at the RX-USRP which is answering with a ping reply:
RX-USRP:
TIMEOUT
Rx: ok = True len(payload) = 84
Tx: len(payload) = 84
send now!
UTIMEOUT
Observing the IP dataflow via Wireshark (at RX-USRP) confirms that.
However, we are NOT receiving this ping reply and the transmitting USRP.
It seems, like it cannot transmit and receive simultaneously. Exactky
the same happens if we swap the role of transmitting and receiving
USRPs.
Anybody has an idea how we could overcome this problem? Basically, we
want to measure the latency of a “real” application.
device, but that is completely unrelated to the purpose of tunnel.py.
You probably have to play with routing tables to make this work…
Why is that unrelated to the purpose of tunnel.py? Shouldnt a simple
ping request be a basic application of using this TUN/TAP application?
Anyway, we have now set up the routing table correctly by using TUN
instead of TAP.
As we are transmitting the ping from one of the USRPs, we are also
receiving them at the RX-USRP which is answering with a ping reply:
RX-USRP:
TIMEOUT
Rx: ok = True len(payload) = 84
Tx: len(payload) = 84
send now!
UTIMEOUT
Observing the IP dataflow via Wireshark (at RX-USRP) confirms that.
However, we are NOT receiving this ping reply and the transmitting USRP.
It seems, like it cannot transmit and receive simultaneously. Exactky
the same happens if we swap the role of transmitting and receiving
USRPs.
Anybody has an idea how we could overcome this problem? Basically, we
want to measure the latency of a “real” application.
The XCVR2450 hardware is incapable of full-duplex operation. It cannot
transmit and receive at the same time.
Yes, you are right but consider we are transmitting ping requests just
for a very short moment (since they are also containing only 84 bytes)
with a frequency of 1 Hz. Hence, we are occupying the channel only for a
very short-termed moment.
We have right now in this moment found out or at least got a clue why it
isn’t running.
We have inserted a sleep of roughly 50ms before the
self.tb.txpath.send_pkt(payload) in order to give the RX/TX switching
some time. The packet is now sent back and the ping request indicates a
delay of 56ms (including the sleeping delay of 50ms).
Does anybody has a clue why the RX/TX switching is not established fast
enough? Is there some code missing what dictates the UHD interface to
switch? In another application using UHD natively we are not
experiencing such a strange behavior.
The XCVR2450 hardware is incapable of full-duplex operation. It
cannot transmit and receive at the same time.
On Wed, 01 Feb 2012
18:05:53 +0100, Florian Schlembach wrote:
We are now trying to
establish an TCP/IP connection between both USRP2s with the tunnel.py
script. Unfortunately, it says “Destination Host unreachable” when
pinging the other USRP. We should have set up the tunnel correct as some
packets are received and transmitted after having configured the IP
address. The pinged USRPs is indicating the received icmp packet but
there is still no confirmed ping-request though.
Short answer; dont
do that. Yes, this particular USRP is a network device, but that is
completely unrelated to the purpose of tunnel.py. You probably have to
play with routing tables to make this work…
Why is that unrelated to
the purpose of tunnel.py? Shouldnt a simple ping request be a basic
application of using this TUN/TAP application? Anyway, we have now set
up the routing table correctly by using TUN instead of TAP. As we are
transmitting the ping from one of the USRPs, we are also receiving them
at the RX-USRP which is answering with a ping reply: RX-USRP: - TIMEOUT
Rx: ok = True len(payload) = 84 Tx: len(payload) = 84 send now! UTIMEOUT
- Observing the IP dataflow via Wireshark (at RX-USRP) confirms that.
However, we are NOT receiving this ping reply and the transmitting USRP.
It seems, like it cannot transmit and receive simultaneously. Exactky
the same happens if we swap the role of transmitting and receiving
USRPs. Anybody has an idea how we could overcome this problem?
Basically, we want to measure the latency of a “real” application.