From: Stephens, A. <all...@wi...> - 2006-08-03 16:30:07
|
Hi Paolo: Here are the latest results of my testing of uml_switch. Guest 1 has eth0=3Ddaemon,00:00:00:00:11:00 Guest 2 has eth0=3Ddaemon,00:00:00:00:22:00 and eth1=3Ddaemon,00:00:00:00:22:11 When I do my testing using "uml_switch" (no hub), all interfaces seem to see only the packets that have been sent to their MAC addresses (plus any packets broadcast to FF:FF:FF:FF:FF:FF). When I do my testing using "uml_switch -hub", interface eth0 on Guest 2 sees packets that were destined for eth1 on Guest 2 and for eth0 on Guest 1. Similarly, eth1 on Guest 2 sees packets that were destined for eth0 on Guest 2 and for eth0 on Guest 1. I also retried things with multicast using: Guest 1 has eth0=3Dmcast,00:00:00:00:11:00,,1106 Guest 2 has eth0=3Dmcast,00:00:00:00:22:00,,1106 and eth1=3Dmcast,00:00:00:00:22:11,,1106 In this case, every interface on both guests seems to see all packets -- including the ones that it is sending out itself! So, as far as I can tell, packets sent using "uml_switch" are passed on only to the interfaces that are supposed to receive it, packets sent using "uml_switch -hub" are passed to all interfaces except the sender, and packets sent using multicast are passed to all interfaces (including the sender). These differences may make sense to people who understand how the various transport mechanisms work, but it still leave me with a question: why, in the latter two cases, is UML allowing non-promiscuous interfaces to receive traffic that wasn't sent to them? I can understand that configuring uml_switch as a hub means that packets may be forwarded to places they don't need to go, but shouldn't these packets still be filtered out somewhere further down the line? As I naive user, I'm not expecting a (simulated) interface to receive traffic that wasn't addressed to it unless it has been explicitly configured as promiscuous. Regards, Al > -----Original Message----- > From: Paolo Giarrusso [mailto:bla...@ya...]=20 > Sent: Wednesday, August 02, 2006 11:05 AM > To: Stephens, Allan; use...@li... > Cc: use...@li... > Subject: RE: [uml-user] Promiscuous mode interface bug? >=20 > "Stephens, Allan" <all...@wi...> ha scritto:=20 >=20 > > Hi Paolo: > >=20 > > OK, let me take one more try at explaining what I've observed.=20 > > (And my > > apologies for making this whole issue more confusing than necessary=20 > > ... > > I'm pretty inexperienced when it comes to detailing with=20 > the details=20 > > of network interface operation.) > >=20 > > When I used "ethX=3Ddaemon", each interface I configured on a=20 > UML guest=20 > > forwarded only the traffic that was destined for it to my network=20 > > protocol software -- indicating that the uml_switch application was=20 > > getting UML to filter things correctly. >=20 > Does it works corrently even with uml_switch -hub or not? >=20 > > When I used "ethX=3Dmcast", each interface I configured on a=20 > UML guest=20 > > forwarded all packets sent to the associated multicast group to my=20 > > network protocol software > which I guess operates with raw sockets... > >, even though the interfaces were not > > configured as "promiscuous". >=20 > > The latter observation was the source of my original=20 > concern, causing=20 > > me to ask "why doesn't UML mark the device as promiscuous if it is=20 > > passing on all packets?". Your subsequent explanations now make me=20 > > think that I should have asked "why isn't UML filtering out the=20 > > unwanted packets since the device isn't configured as promiscuous?". >=20 > > I just repeated my "ethX=3Dmcast" testing to make sure I hadn't done = > > something stupid, like configure both interfaces with the same MAC=20 > > address, but I still see the same result. This leads me to=20 > conclude=20 > > that there is a real problem with the way UML is filtering=20 > packets on=20 > > "ethX=3Dmcast" interfaces. Admittedly, I can circumvent this = problem=20 > > being by manually configuring the interfaces as promiscuous, but it=20 > > still looks like a bug. >=20 > > Does this (finally) make sense? >=20 > Yes, it makes a lot of sense (in fact I'm forwarding this to=20 > uml-devel); I have looked at the code but I don't see any=20 > really _obvious_ difference. Everything depends on uml_switch=20 > -hub result, which I'd like to see. >=20 > Thanks for your effort meanwhile! > Bye >=20 > Chiacchiera con i tuoi amici in tempo reale!=20 > http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com=20 >=20 |