Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: tcpdump on tap100: no packets shown, even though they arrive/get replied to

On 08/24/11 16:55, Robert Swindells wrote:
> Hugo Silva wrote:
>> Just noticed this;
>> 15:18:05.215970 00:16:3e:be:ef:03 f2:0b:a4:63:80:03 0800 98:
>> > icmp: echo request
>> 15:18:05.216021 f2:0b:a4:63:80:03 00:16:3e:be:ef:03 0800 98:
>> > icmp: echo reply
>> That's on machine B.
>> On machine A (the one replying to the ping), # tcpdump -peni tap100
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>> listening on tap100, link-type EN10MB (Ethernet), capture size 65535 bytes
>> machine A is a 5.99.55 kernel+world built  Tue Aug 23 12:05:48 UTC 2011,
>> tap100 is on bridge3 which is passed as an interface to machine B (a Xen
>> domU).
> What are the ifconfig outputs on the "machines" in question ?

Machine B (OpenBSD):

        lladdr 00:16:3e:be:ef:03
        description: Management interface
        priority: 0
        media: Ethernet autoselect (1000baseT full-duplex)
        status: active
        inet netmask 0xffffff00 broadcast

Machine A (dom0; NetBSD current)

        address: f2:0b:a4:3c:ba:02
        media: Ethernet autoselect
        inet netmask 0xffffff00 broadcast

bridge3: flags=41<UP,RUNNING>
                priority 32768 hellotime 2 fwddelay 15 maxage 20
                ipfilter disabled flags 0x0
                tap3 flags=3<LEARNING,DISCOVER>
                        port 18 priority 128
                xvif1i3 flags=3<LEARNING,DISCOVER>
                        port 14 priority 128
                tap100 flags=3<LEARNING,DISCOVER>
                        port 5 priority 128
        Address cache (max cache: 100, timeout: 1200):
                00:16:3e:be:ef:03 tap3 385 flags=0<>

>> Shouldn't the ping reply appear on tap100 @ the host ?
> Nope.
> You *really* don't want to send any packets that use the ethernet
> address of the tap device itself, they will not get bridged to
> anywhere that a socket is listening.

On OpenBSD, I see @ the arp cache table:
? ( at f2:0b:a4:3c:ba:02 on em3

And I'm logged in on machine A, through the IP assigned on tap100 there
(which is bridged via bridge3).

It works as expected, it's just that I can't see any packets to tap100,
and tcpdump doesn't work on bridges (it seems).

I may be missing something obvious, but if tcpdump on a bridge doesn't
work and tcpdump tap100 comes in clear, even though I have a TCP
connection established/active to the IP assigned on it, how should one
go on about troubleshooting connectivity (this is what brought me to ask
the question; in the mean time I've solved the problem, was missing a
static route, but tcpdump on tap100 still shows nothing) issues?

In this particular case, the packets don't really come from any "real"
interface - thus the most I could do was, from machine B, confirming
that the packets were leaving the system. No way to actually confirm
they were coming in to machine A (hence tcpdump tap100)

Am I making sense?



Home | Main Index | Thread Index | Old Index