Hi all,
I've now managed to get the Linux ip stack talking to a 3rd party ip
stack via ethertap, but there's a few problems I'm not sure about:
1) My packet exchange code (that talks to tap0 and the other stack)
uses the tap device in a blocking mode so that when it does a read, it
will wait until a packet arrives before continuing. This means that if
the next packet is originated by the other stack, it won't reach tap0
until tap0 first sends a packet. Can the ethertap device be put in
non-blocking mode like can be done with stdin and stdout? Is there
some other way I should achieve this?
2) As a consequence of the blocking problem, responses from the 3rd
party stack are always one packet behind - ie. The 3rd party stack
takes (atleast) two arp-who-has packets to respond, & then another two
to respond to ICMP echo requests etc. This is because the looking for
packets from the other stack is done in a non-blocking manner - if
there's no immediate response from the other stack after sending one
to it, control is back to the blocked read of the tap device again. Is
this not a common problem with programs that do a blocking read on
tap0? I've seen references to source that seem to do this.
3) Even with the delayed reception of the ARP-who-has request, the
Linux stack still accepts it and adds the new data to its arp cache.
The following ICMP echo request from a ping isn't so forgiving - &
seems to not accept the echo-reply at all - presumably because the
response is now (atleast) one request behind. I have several questions
about this:
3a) I'm running a packet sniffer (ethereal) on tap0, & it shows all
the packets exchanged between the two stacks. Why then does the ping
program not report even bad responses? It reports 0 returned packets.
Using pings "-v" switch to show other ICMP packets shows nothing
either. Does this sound correct? How else can I find out why ping is
rejecting (or not seeing) the packets? I couldn't see anything in RFC
1812 to suggest a reason for this.
3b) Can I assume that as the packet sniffer is seeing the
echo-responses (they have reasonable format, which is decoded
properly), that ping is receiving them also? The ethernet and ip
addresses are correct. Ifconfig also reports that that number of
packets has been received by tap0, and that none were dropped, or
otherwise.
Thanks, sTu.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:23 EST