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

[Hugo Silva <hugo%barafranca.com@localhost>]

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:
>> 172.16.99.203 > 172.16.99.133: icmp: echo request
>> 15:18:05.216021 f2:0b:a4:63:80:03 00:16:3e:be:ef:03 0800 98:
>> 172.16.99.133 > 172.16.99.203: 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):

em3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:16:3e:be:ef:03
        description: Management interface
        priority: 0
        media: Ethernet autoselect (1000baseT full-duplex)
        status: active
        inet 162.16.99.203 netmask 0xffffff00 broadcast xxx.xxx.xx.255

Machine A (dom0; NetBSD current)

tap100: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        address: f2:0b:a4:3c:ba:02
        media: Ethernet autoselect
        inet 172.16.99.133 netmask 0xffffff00 broadcast 172.16.99.255


bridge3: flags=41<UP,RUNNING>
        Configuration:
                priority 32768 hellotime 2 fwddelay 15 maxage 20
                ipfilter disabled flags 0x0
        Interfaces:
                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:
? (172.16.99.133) 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?

Regards,

Hugo