* [Bridge] Man-in-the-middle scenario within vmware - problem
@ 2006-12-10 18:09 Patrick Nagel
2006-12-13 18:14 ` Stephen Hemminger
0 siblings, 1 reply; 3+ messages in thread
From: Patrick Nagel @ 2006-12-10 18:09 UTC (permalink / raw)
To: bridge
[-- Attachment #1: Type: text/plain, Size: 1789 bytes --]
Hi there,
I'm trying to set up a man-in-the-middle scenario within a VMWare Workstation
team, using brctl. What I want is the following:
PC1 eth0 >---LAN-segment-1---< eth0 PCMITM eth1 >---LAN-segment-2---< eth0 PC2
Now I did the following on PCMITM (PC man in the middle):
ifconfig eth0 down
ifconfig eth1 down
brctl addbr lnxbr0
brctl addif lnxbr0 eth0
brctl addif lnxbr0 eth1
ifconfig eth0 0.0.0.0
ifconfig eth1 0.0.0.0
ifconfig lnxbr0 up
All commands exit successfully and I get eth0, eth1 and lnxbr0 listed in
ifconfig.
brctl show says:
bridge name bridge id STP enabled interfaces
lnxbr0 8000.000c296df055 no eth1
eth0
which also seems alright to me.
But now the problem: although PC1 and PC2 are in the same IP subnet (addresses
192.168.222.1 and 192.168.222.2), a ping doesn't pass the bridge. By
starting "ping pc2" on PC1 and "ping pc1" on PC2, I ensure that both machines
are transmitting data frequently, and thus should show up in "brctl
showmacs", but
brctl showmacs lnxbr0 says:
port no mac addr is local? ageing timer
1 00:0c:29:6d:f0:55 yes 0.00
2 00:0c:29:6d:f0:5f yes 0.00
2 00:0c:29:97:e3:a6 no 0.14
So there is one NIC missing - that one of PC1.
Does anyone have an explanation? I don't know what could be wrong in my setup,
I don't even know where to start... Any help is appreciated.
By the way: The LAN segments within VMWare seem to be working. If I give each
NIC on PCMITM an IP address (with no bridge on PCMITM), I can transfer data
from PC1 to PCMITM (and vice versa) and from PC2 to PCMITM (and vice versa).
Patrick.
--
Key ID: 0x86E346D4 http://patrick-nagel.net/key.asc
Fingerprint: 7745 E1BE FA8B FBAD 76AB 2BFC C981 E686 86E3 46D4
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bridge] Man-in-the-middle scenario within vmware - problem
2006-12-10 18:09 [Bridge] Man-in-the-middle scenario within vmware - problem Patrick Nagel
@ 2006-12-13 18:14 ` Stephen Hemminger
2006-12-13 20:26 ` Patrick Nagel
0 siblings, 1 reply; 3+ messages in thread
From: Stephen Hemminger @ 2006-12-13 18:14 UTC (permalink / raw)
To: Patrick Nagel; +Cc: bridge
On Sun, 10 Dec 2006 19:09:27 +0100
Patrick Nagel <mail@patrick-nagel.net> wrote:
> Hi there,
>
> I'm trying to set up a man-in-the-middle scenario within a VMWare Workstation
> team, using brctl. What I want is the following:
>
> PC1 eth0 >---LAN-segment-1---< eth0 PCMITM eth1 >---LAN-segment-2---< eth0 PC2
>
> Now I did the following on PCMITM (PC man in the middle):
>
> ifconfig eth0 down
> ifconfig eth1 down
> brctl addbr lnxbr0
> brctl addif lnxbr0 eth0
> brctl addif lnxbr0 eth1
> ifconfig eth0 0.0.0.0
> ifconfig eth1 0.0.0.0
> ifconfig lnxbr0 up
>
> All commands exit successfully and I get eth0, eth1 and lnxbr0 listed in
> ifconfig.
> brctl show says:
>
> bridge name bridge id STP enabled interfaces
> lnxbr0 8000.000c296df055 no eth1
> eth0
>
> which also seems alright to me.
>
> But now the problem: although PC1 and PC2 are in the same IP subnet (addresses
> 192.168.222.1 and 192.168.222.2), a ping doesn't pass the bridge. By
> starting "ping pc2" on PC1 and "ping pc1" on PC2, I ensure that both machines
> are transmitting data frequently, and thus should show up in "brctl
> showmacs", but
> brctl showmacs lnxbr0 says:
>
> port no mac addr is local? ageing timer
> 1 00:0c:29:6d:f0:55 yes 0.00
> 2 00:0c:29:6d:f0:5f yes 0.00
> 2 00:0c:29:97:e3:a6 no 0.14
>
> So there is one NIC missing - that one of PC1.
>
> Does anyone have an explanation? I don't know what could be wrong in my setup,
> I don't even know where to start... Any help is appreciated.
>
> By the way: The LAN segments within VMWare seem to be working. If I give each
> NIC on PCMITM an IP address (with no bridge on PCMITM), I can transfer data
> from PC1 to PCMITM (and vice versa) and from PC2 to PCMITM (and vice versa).
>
> Patrick.
Did you wait until after the "forwarding delay" expired (30 seconds) or set
turn forwarding delay off?
It may be that the ehternet driver doesn't support promiscious mode
and/or doesn't expect non-local source adresses. You need to see where packets
are being dropped, could be the ethernet driver, or switch with network access
control or inside the bridge.
Also check that the drivers correctly report carrier state.
brctl show lnxbr0
Should show both devices in forwarding atate.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bridge] Man-in-the-middle scenario within vmware - problem
2006-12-13 18:14 ` Stephen Hemminger
@ 2006-12-13 20:26 ` Patrick Nagel
0 siblings, 0 replies; 3+ messages in thread
From: Patrick Nagel @ 2006-12-13 20:26 UTC (permalink / raw)
To: bridge
[-- Attachment #1: Type: text/plain, Size: 5243 bytes --]
Hi Stephen,
thanks for answering!
> Did you wait until after the "forwarding delay" expired (30 seconds) or set
> turn forwarding delay off?
Yes to waiting.
> It may be that the ehternet driver doesn't support promiscious mode
> and/or doesn't expect non-local source adresses. You need to see where
> packets are being dropped, could be the ethernet driver, or switch with
> network access control or inside the bridge.
The driver seems to support promiscious mode, as I get the following from
dmesg after setting up the bridge:
[17179785.256000] Bridge firewalling registered
[17179785.264000] device eth0 entered promiscuous mode
[17179785.264000] audit(1166040131.368:2): dev=eth0 prom=256 old_prom=0
auid=4294967295
[17179785.268000] device eth1 entered promiscuous mode
[17179785.268000] audit(1166040131.372:3): dev=eth1 prom=256 old_prom=0
auid=4294967295
[17179785.272000] eth0: link up
[17179785.280000] eth1: link up
[17179785.284000] lnxbr0: port 2(eth1) entering learning state
[17179785.284000] lnxbr0: port 1(eth0) entering learning state
[17179795.336000] eth1: no IPv6 routers present
[17179795.848000] eth0: no IPv6 routers present
[17179796.040000] lnxbr0: no IPv6 routers present
[17179800.284000] lnxbr0: topology change detected, propagating
[17179800.284000] lnxbr0: port 2(eth1) entering forwarding state
[17179800.284000] lnxbr0: topology change detected, propagating
[17179800.284000] lnxbr0: port 1(eth0) entering forwarding state
Look at those "screenshots":
After some "ping" packets from PC1 to PC2, the statistics look like this:
$ ifconfig eth0 && ifconfig eth1 && ifconfig lnxbr0
eth0 Link encap:Ethernet HWaddr 00:0C:29:6D:F0:55
inet6 addr: fe80::20c:29ff:fe6d:f055/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:48 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2880 (2.8 KiB) TX bytes:468 (468.0 b)
Interrupt:177 Base address:0x1080
eth1 Link encap:Ethernet HWaddr 00:0C:29:6D:F0:5F
inet6 addr: fe80::20c:29ff:fe6d:f05f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:54 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:3348 (3.2 KiB)
Interrupt:185 Base address:0x1400
lnxbr0 Link encap:Ethernet HWaddr 00:0C:29:6D:F0:55
inet6 addr: fe80::20c:29ff:fe6d:f055/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:48 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2208 (2.1 KiB) TX bytes:468 (468.0 b)
So the packets come in on eth0, and they're sent out on eth1, but there is no
answer received from PC2. BUT on PC2, ifconfig says that there were 57
packets in and 57 packets out on eth0.
Now let's do it the other way round:
$ ifconfig eth0 && ifconfig eth1 && ifconfig lnxbr0
eth0 Link encap:Ethernet HWaddr 00:0C:29:6D:F0:55
inet6 addr: fe80::20c:29ff:fe6d:f055/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:48 errors:0 dropped:0 overruns:0 frame:0
TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2880 (2.8 KiB) TX bytes:1548 (1.5 KiB)
Interrupt:177 Base address:0x1080
eth1 Link encap:Ethernet HWaddr 00:0C:29:6D:F0:5F
inet6 addr: fe80::20c:29ff:fe6d:f05f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:18 errors:0 dropped:0 overruns:0 frame:0
TX packets:54 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1080 (1.0 KiB) TX bytes:3348 (3.2 KiB)
Interrupt:185 Base address:0x1400
lnxbr0 Link encap:Ethernet HWaddr 00:0C:29:6D:F0:55
inet6 addr: fe80::20c:29ff:fe6d:f055/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:66 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3036 (2.9 KiB) TX bytes:468 (468.0 b)
And it's the same - the packets come in on eth1, go out on eth0, but the
echoes never make it back through eth0.
So where exactly do they get stuck? I really don't know how to proceed...
> Also check that the drivers correctly report carrier state.
>
> brctl show lnxbr0
... is always like this:
bridge name bridge id STP enabled interfaces
lnxbr0 8000.000c296df055 no eth1
eth0
> Should show both devices in forwarding atate.
Where could I see that?
Thanks for your help!
Patrick.
--
Key ID: 0x86E346D4 http://patrick-nagel.net/key.asc
Fingerprint: 7745 E1BE FA8B FBAD 76AB 2BFC C981 E686 86E3 46D4
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2006-12-13 20:26 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-12-10 18:09 [Bridge] Man-in-the-middle scenario within vmware - problem Patrick Nagel
2006-12-13 18:14 ` Stephen Hemminger
2006-12-13 20:26 ` Patrick Nagel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox