From: Paolo G. <bla...@ya...> - 2006-08-02 15:04:52
|
"Stephens, Allan" <all...@wi...> ha scritto: > Hi Paolo: > > OK, let me take one more try at explaining what I've observed. > (And my > apologies for making this whole issue more confusing than necessary > ... > I'm pretty inexperienced when it comes to detailing with the > details of > network interface operation.) > > When I used "ethX=daemon", each interface I configured on a UML > guest > forwarded only the traffic that was destined for it to my network > protocol software -- indicating that the uml_switch application was > getting UML to filter things correctly. Does it works corrently even with uml_switch -hub or not? > When I used "ethX=mcast", each interface I configured on a UML > guest > forwarded all packets sent to the associated multicast group to my > network protocol software which I guess operates with raw sockets... >, even though the interfaces were not > configured as "promiscuous". > The latter observation was the source of my original concern, > causing me > to ask "why doesn't UML mark the device as promiscuous if it is > passing > on all packets?". Your subsequent explanations now make me think > that I > should have asked "why isn't UML filtering out the unwanted packets > since the device isn't configured as promiscuous?". > I just repeated my "ethX=mcast" testing to make sure I hadn't done > something stupid, like configure both interfaces with the same MAC > address, but I still see the same result. This leads me to > conclude > that there is a real problem with the way UML is filtering packets > on > "ethX=mcast" interfaces. Admittedly, I can circumvent this problem > being by manually configuring the interfaces as promiscuous, but it > still looks like a bug. > Does this (finally) make sense? Yes, it makes a lot of sense (in fact I'm forwarding this to uml-devel); I have looked at the code but I don't see any really _obvious_ difference. Everything depends on uml_switch -hub result, which I'd like to see. Thanks for your effort meanwhile! Bye Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com |
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 |
From: Jeff D. <jd...@ad...> - 2006-08-03 18:26:33
|
On Thu, Aug 03, 2006 at 09:29:51AM -0700, Stephens, Allan wrote: > 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. Either you or I have a very basic misunderstanding of how these things are supposed to work. You seem to be thinking that when you set an interface promiscuous, it somehow reaches out to the switch and tells it to start sending it everything, and when it is set non-promiscuous, it tells the switch to only send stuff addressed to it. I seem to be thinking that the packets that actually reach the interface is not controlled by its promiscuous setting, and the setting controls whether the packets reach the network stack and are visible to software. Needless to say, I think my thinking is closer to the truth. There is no mechanism that I know of for an interface to communicate its promiscuous setting to a switch. Switches do remember the MAC associated with a port, but that is done by sniffing the packets going by. Jeff |
From: Stephens, A. <all...@wi...> - 2006-08-03 20:09:10
|
Hi Jeff: See comments below. > -----Original Message----- > From: Jeff Dike [mailto:jd...@ad...]=20 > Sent: Thursday, August 03, 2006 2:26 PM > To: Stephens, Allan > Cc: Paolo Giarrusso;=20 > use...@li...;=20 > use...@li... > Subject: Re: [uml-devel] [uml-user] Promiscuous mode interface bug? >=20 > On Thu, Aug 03, 2006 at 09:29:51AM -0700, Stephens, Allan wrote: > > These differences may make sense to people who understand how the=20 > > various transport mechanisms work, but it still leave me with a > > question: why, in the latter two cases, is UML allowing=20 > > non-promiscuous interfaces to receive traffic that wasn't sent to=20 > > them? I can understand that configuring uml_switch as a hub means=20 > > that packets may be forwarded to places they don't need to go, but=20 > > shouldn't these packets still be filtered out somewhere=20 > further down=20 > > the line? As I naive user, I'm not expecting a (simulated)=20 > interface=20 > > to receive traffic that wasn't addressed to it unless it has been=20 > > explicitly configured as promiscuous. >=20 > Either you or I have a very basic misunderstanding of how=20 > these things are supposed to work. That is entirely possible. > You seem to be thinking that when you set an interface=20 > promiscuous, it somehow reaches out to the switch and tells=20 > it to start sending it everything, and when it is set=20 > non-promiscuous, it tells the switch to only send stuff=20 > addressed to it. No, this isn't my thinking at all. (See next point.) > I seem to be thinking that the packets that actually reach=20 > the interface is not controlled by its promiscuous setting,=20 > and the setting controls whether the packets reach the=20 > network stack and are visible to software. I agree with this view completely. > Needless to say, I think my thinking is closer to the truth. =20 > There is no mechanism that I know of for an interface to=20 > communicate its promiscuous setting to a switch. Switches do=20 > remember the MAC associated with a port, but that is done by=20 > sniffing the packets going by. >=20 > Jeff Agreed. Where I think my confusion is arising is in the details of how the filtering controlled by the promiscuous setting is actually done. If a packet with=20 the "wrong" destination address arrives at an interface, who checks to see whether the interface has been configured as promiscuous and passes/discards it accordingly? I have naively assumed that this was handled in hardware on the NIC card in a real system, but is it really done by software? If so, where in the kernel is this done? Again, I would naively assume it was done by the Ethernet driver code that passes packets up to the network stack. What I seem to be observing in my UML testing is that *nobody* is doing this filtering, resulting in unwanted packets being handed to my protocol (which sits directly on top of the Ethernet driver). Is this truly the effect I would see if I had a bunch of PCs connected together using an Ethernet hub? Regards, Al |
From: Jeff D. <jd...@ad...> - 2006-08-03 21:45:14
|
On Thu, Aug 03, 2006 at 01:08:51PM -0700, Stephens, Allan wrote: > Where I think my confusion is arising is in the details of how the > filtering > controlled by the promiscuous setting is actually done. If a packet > with > the "wrong" destination address arrives at an interface, who checks to > see > whether the interface has been configured as promiscuous and > passes/discards it > accordingly? I have naively assumed that this was handled in hardware > on the > NIC card in a real system, but is it really done by software? Ah, a light goes on. I believe that it is done on the card. > What I seem to > be > observing in my UML testing is that *nobody* is doing this filtering, > resulting in > unwanted packets being handed to my protocol (which sits directly on top > of the > Ethernet driver). And since UML doesn't have "cards", it may be that the driver should do the filtering at the bottom layer and it isn't. Jeff |
From: Paolo G. <bla...@ya...> - 2006-08-04 11:09:58
|
Jeff Dike <jd...@ad...> ha scritto: > On Thu, Aug 03, 2006 at 01:08:51PM -0700, Stephens, Allan wrote: > > Where I think my confusion is arising is in the details of how > the > > filtering > > controlled by the promiscuous setting is actually done. If a > packet > > with > > the "wrong" destination address arrives at an interface, who > checks to > > see > > whether the interface has been configured as promiscuous and > > passes/discards it > > accordingly? I have naively assumed that this was handled in > hardware > > on the > > NIC card in a real system, but is it really done by software? > Ah, a light goes on. I believe that it is done on the card. Yes, it is, you can set one (or even more, for special purposes) MAC addresses to accept on a card or configure it as "no hardware filtering done"; I've observed a network driver doing this, and I think set_mac is the hook for this. > > What I seem to > > be > > observing in my UML testing is that *nobody* is doing this > filtering, > > resulting in > > unwanted packets being handed to my protocol (which sits directly > on top > > of the > > Ethernet driver). > > And since UML doesn't have "cards", it may be that the driver > should do the > filtering at the bottom layer and it isn't. I agree too; we may check however if the network stack implements support for such "dumb" cards (probably by setting a flag) to avoid coding it ourselves. Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com |
From: Steven J. <py...@li...> - 2006-08-04 13:01:32
|
On Thu, 3 Aug 2006, Jeff Dike wrote: > On Thu, Aug 03, 2006 at 01:08:51PM -0700, Stephens, Allan wrote: >> Where I think my confusion is arising is in the details of how the >> filtering >> controlled by the promiscuous setting is actually done. If a packet >> with >> the "wrong" destination address arrives at an interface, who checks to >> see >> whether the interface has been configured as promiscuous and >> passes/discards it >> accordingly? I have naively assumed that this was handled in hardware >> on the >> NIC card in a real system, but is it really done by software? > > Ah, a light goes on. I believe that it is done on the card. > >> What I seem to >> be >> observing in my UML testing is that *nobody* is doing this filtering, >> resulting in >> unwanted packets being handed to my protocol (which sits directly on top >> of the >> Ethernet driver). > > And since UML doesn't have "cards", it may be that the driver should do the > filtering at the bottom layer and it isn't. IIRC, most but not all cards will do the filtering in hardware unless they're in promiscuous mode. However if the card is in promiscuous mode or doesn't support filtering, the next step is when eth_type_trans sets the pkt_type of the skb to PACKET_OTHERHOST. I remember there being something odd about the handling of ethernet headers a good while ago. In any event, doing the filtering in the device would help, but won't work when it's promisc (for example if tcpdump is running). G'day, sjames > > Jeff > |
From: Stephens, A. <all...@wi...> - 2006-08-04 15:25:28
|
Hi Jeff/Paolo: Thanks for helping clarify this issue. I'll leave it to the UML development community to decide how and when to modify things to provide the necessary filtering. In the meantime, I'll simply continue to configure my multicast-based interfaces as promiscuous so that my protocol software knows that it has to handle packets that weren't destined for the interface. Regards, Al Stephens Wind River > -----Original Message----- > From: Paolo Giarrusso [mailto:bla...@ya...]=20 > Sent: Friday, August 04, 2006 7:10 AM > To: Jeff Dike; Stephens, Allan > Cc: Paolo Giarrusso;=20 > use...@li...;=20 > use...@li... > Subject: Re: [uml-devel] [uml-user] Promiscuous mode interface bug? >=20 > Jeff Dike <jd...@ad...> ha scritto:=20 >=20 > > On Thu, Aug 03, 2006 at 01:08:51PM -0700, Stephens, Allan wrote: > > > Where I think my confusion is arising is in the details of how > > the > > > filtering > > > controlled by the promiscuous setting is actually done. If a > > packet > > > with > > > the "wrong" destination address arrives at an interface, who > > checks to > > > see > > > whether the interface has been configured as promiscuous and=20 > > > passes/discards it accordingly? I have naively assumed that this=20 > > > was handled in > > hardware > > > on the > > > NIC card in a real system, but is it really done by software? =20 >=20 > > Ah, a light goes on. I believe that it is done on the card. >=20 > Yes, it is, you can set one (or even more, for special=20 > purposes) MAC addresses to accept on a card or configure it=20 > as "no hardware filtering done"; I've observed a network=20 > driver doing this, and I think set_mac is the hook for this. >=20 > > > What I seem to > > > be > > > observing in my UML testing is that *nobody* is doing this > > filtering, > > > resulting in > > > unwanted packets being handed to my protocol (which sits directly > > on top > > > of the > > > Ethernet driver). =20 > >=20 > > And since UML doesn't have "cards", it may be that the=20 > driver should=20 > > do the filtering at the bottom layer and it isn't. >=20 > I agree too; we may check however if the network stack=20 > implements support for such "dumb" cards (probably by setting=20 > a flag) to avoid coding it ourselves. >=20 > Chiacchiera con i tuoi amici in tempo reale!=20 > http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com=20 >=20 |