[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:
>> 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
> What are the ifconfig outputs on the "machines" in question ?
Machine B (OpenBSD):
em3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
description: Management interface
media: Ethernet autoselect (1000baseT full-duplex)
inet 22.214.171.124 netmask 0xffffff00 broadcast xxx.xxx.xx.255
Machine A (dom0; NetBSD current)
tap100: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
media: Ethernet autoselect
inet 172.16.99.133 netmask 0xffffff00 broadcast 172.16.99.255
priority 32768 hellotime 2 fwddelay 15 maxage 20
ipfilter disabled flags 0x0
port 18 priority 128
port 14 priority 128
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 ?
> 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?
Main Index |
Thread Index |