tcpdump - tun/tap virtual interfaces

[Dambielle Yannick]

Sorry for the mistakes (again)... need to sleep :/
Bellow are the right results with the right ip address...

# route add 10.0.10.1 10.0.10.2

results are :

# route get 10.0.10.1
     route to: 10.0.10.1
 destination: 10.0.10.1
    gateway: 10.0.10.2
    interface: tap0

 # route get 10.0.10.2
     route to: 10.0.10.2
 destination: 10.0.10.2
    interface: tap0

 # ping 10.0.10.1
# tcpdump -i lo0 <-- nothing
# tcpdump -i tap0
 blablabla.... icmp: echo request
 blablabla.... icmp: echo reply

 # ping 10.0.10.2
# tcpdump -i lo0 <-- nothing
# tcpdump -i tap0
 blablabla.... icmp: echo request
 blablabla.... icmp: echo reply


Yannick

----- Original Message ----- 
From: "Dambielle Yannick" <yannick.dambielle at free.fr>
To: "Robert Watson" <rwatson at freebsd.org>; "Giovanni P. Tirloni"
<gpt at tirloni.org>
Cc: <freebsd-net at freebsd.org>
Sent: Monday, September 29, 2003 12:34 AM
Subject: Re: tcpdump - tun/tap virtual interfaces


> Hello,
> Thank you very much for the details. I think I'm starting to understand
the
> subject better.
> Well, I've did all again from the beggining and now I have the same
results
> has you had. It works.
> 10.0.10.1 is routed via lo0, and 10.0.10.2 is routed via tap0.
> Icmp requests and replies could be seen with tcpdump on lo0 for 10.0.10.1,
> but for 10.0.10.2, the request were passing trough tap0 while the replies
> took lo0 (??).
> I don't know, if what I'm going to say is the right method for having both
> replies and requests passing through the same interface, so please, give
me
> a better one.
>
> I did the following trick :
>
> # route add 10.0.10.1 10.0.10.2
>
> and the result is :
>
> # route get 10.0.10.1
>     route to: 10.0.10.1
> destination: 10.0.0.1
>    gateway: 10.0.0.1
>    interface: tap0
>
> # route get 10.0.10.2
>     route to: 10.0.10.2
> destination: 10.0.0.2
>    interface: tap0
>
> # ping 10.0.0.1
> # tcpdump -i lo0 <-- nothing
> # tcpdump -i tap0
> blablabla.... icmp: echo request
> blablabla.... icmp: echo reply
>
> # ping 10.0.0.2
> # tcpdump -i lo0 <-- nothing
> # tcpdump -i tap0
> blablabla.... icmp: echo request
> blablabla.... icmp: echo reply
>
> Now I can go back to my jails and my little project :)
>
> Yannick
>
> ----- Original Message ----- 
> From: "Robert Watson" <rwatson at freebsd.org>
> To: "Giovanni P. Tirloni" <gpt at tirloni.org>
> Cc: <freebsd-net at freebsd.org>
> Sent: Sunday, September 28, 2003 8:05 PM
> Subject: Re: tcpdump - tun/tap virtual interfaces
>
>
> >
> > On Sun, 28 Sep 2003, Giovanni P. Tirloni wrote:
> >
> > > * Robert Watson (rwatson at freebsd.org) wrote:
> > >
> > > > Do you see anything when you ping the broadcast address or other
> foreign
> > > > address of the tap interface?  Packets delivered to local IP
addresses
> > > > generally don't go out an interface.
> > >
> > >  About Ethernet frames not going out to the wire and being sent to the
> > >  loopback..
> > >
> > >  The check seems to happen at line 291 in if_ethersubr.c and then it
> > >  uses the if_simloop() function to copy the packet to the loopback
> > >  interface. Is that right?
> > >
> > >  The rcvif interface is set to the hardware device, how is this used
in
> > >  this case? What kind of checks are done to the rcvif usually?
> > >
> > >  I haven't received my copy of Steven's Volume 2 yet so if it's
> > >  explained there (as I hope) I will sit in my corner and wait to for
it
> > >  patiently :)
> >
> > Ethernet loopback does occur, and BPF will pick those up.  However, the
> > loopback you're seeing is actually happening at the IP layer, as a
result
> > of routing rather than link layer behavior:
> >
> > 10                 link#6             UC          1        0   tap0
> > 10.0.10.1          00:bd:18:a1:11:00  UHLW        0       26    lo0
> >
> > Local IP addresses have their packets routed to them over lo0, so the
> > packets being looked for can be found by doing tcpdump on lo0:
> >
> > test1# tcpdump -eni lo0 &
> > [2] 511
> > tcpdump: listening on lo0
> > test1# Sep 28 14:03:07 test1 kernel: lo0: promiscuous mode enabled
> >
> > test1# ping -c 1 10.0.10.1
> > PING 10.0.10.1 (10.0.10.1): 56 data bytes
> > 64 bytes from 10.0.10.1: icmp_seq=0 ttl=64 time=0.073 ms
> >
> > --- 10.0.10.1 ping statistics ---
> > 1 packets transmitted, 1 packets received, 0% packet loss
> > round-trip min/avg/max/stddev = 0.073/0.073/0.073/0.000 ms
> > test1# 14:03:12.713690 AF 2 84: 10.0.10.1 > 10.0.10.1: icmp: echo
request
> > 14:03:12.713724 AF 2 84: 10.0.10.1 > 10.0.10.1: icmp: echo reply
> >
> > Route command output appended below.
> >
> > Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
> > robert at fledge.watson.org      Network Associates Laboratories
> >
> > route get 10.0.10.1
> >    route to: 10.0.10.1
> > destination: 10.0.10.1
> >   interface: lo0
> >       flags: <UP,HOST,DONE,LLINFO,WASCLONED,LOCAL>
> >  recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu
> > expire
> >        0         0         0         0         0         0      1500
> > 0
> > test1# route get 10.0.10.2
> >    route to: 10.0.10.2
> > destination: 10.0.0.0
> >        mask: 255.0.0.0
> >   interface: tap0
> >       flags: <UP,DONE,CLONING>
> >  recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu
> > expire
> >        0         0         0         0         0         0      1500
> > -100
> >
> >
> > _______________________________________________
> > freebsd-net at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
> >
>
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>