Date: Mon, 29 Sep 2003 00:57:39 +0200 From: "Dambielle Yannick" <yannick.dambielle@free.fr> To: "Dambielle Yannick" <yannick.dambielle@free.fr>, "Robert Watson" <rwatson@freebsd.org>, "Giovanni P. Tirloni" <gpt@tirloni.org> Cc: freebsd-net@freebsd.org Subject: Re: tcpdump - tun/tap virtual interfaces Message-ID: <006c01c38613$eaa728f0$3fc64352@shibuya> References: <Pine.NEB.3.96L.1030928140046.20493G-100000@fledge.watson.org> <006201c38610$a8a0b910$3fc64352@shibuya>
next in thread | previous in thread | raw e-mail | index | archive | help
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@free.fr>
To: "Robert Watson" <rwatson@freebsd.org>; "Giovanni P. Tirloni"
<gpt@tirloni.org>
Cc: <freebsd-net@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@freebsd.org>
> To: "Giovanni P. Tirloni" <gpt@tirloni.org>
> Cc: <freebsd-net@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@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@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@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
> >
>
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?006c01c38613$eaa728f0$3fc64352>