From: Stephens, A. <all...@wi...> - 2006-07-31 17:30:19
|
Hi Paolo: I tried configuring the Ethernet interfaces as "promiscuous" and this did indeed provide a workaround for the issue I raised. The root cause of my problems seems to have been a lack of understanding on my part as to what I was really asking UML to do for me; your explanation has helped clear things up significantly. It appears that I was using interfaces of the form "ethX=3Dmcast" expecting them to behave like ones of the form "ethX=3Ddaemon" used with "uml_switch -hub". I've now reconfigured things to use the latter type of interface, and things are working as I expected. Thanks so much for your help! Regards, Al Stephens Wind River > -----Original Message----- > From: Blaisorblade [mailto:bla...@ya...]=20 > Sent: Saturday, July 29, 2006 4:20 AM > To: use...@li... > Cc: Stephens, Allan > Subject: Re: [uml-user] Promiscuous mode interface bug? >=20 > On Wednesday 26 July 2006 16:34, Stephens, Allan wrote: > > Hi there: > > > > I've been running UML using Linux 2.6.17 (guest) and 2.6.12=20 > (host) and=20 > > configured a guest with a pair of Ethernet multicast interfaces as=20 > > shown below. (Note that I didn't configure any IP=20 > addresses, as I'm=20 > > not trying to use them to carry IP traffic.) > > > > uml_mconsole <session> config eth1=3Dmcast,00:00:00:00:01:01=20 > > uml_mconsole <session> config eth2=3Dmcast,00:00:00:00:02:02 > > > > When a second guest transmitted traffic using a destination=20 > address of=20 > > 00:00:00:00:01:01, the message showed up on both interfaces (as=20 > > expected). However, the kernel protocol handled incoming=20 > messages did=20 > > not recognize and discard the unwanted copy that showed up at "eth2" > > because the associated "struct net_device" object did not have the=20 > > "promiscuity" field set to indicate that the interface=20 > might receive=20 > > traffic other than its own. >=20 > That's a slightly wrong interpretation of the flag (it=20 > actually means that the interface should accept others'=20 > packets; whether it may receive them or not is indicated by=20 > the BROADCAST/POINTTOPOINT flag in ifconfig output). >=20 > It's also a slightly complex way to check it: >=20 > ifconfig eth2 |grep PROMISC would be simpler. > and ifconfig eth2 promisc would enable it. >=20 > > It seems to me that any UML interface configured to use multicast=20 > > should cause the promiscuity field of the associated=20 > net_device to be=20 > > set -- but maybe I'm missing something here. Is the scenario I=20 > > encountered really a bug? >=20 > No, it's a feature; I understand your point of view and what=20 > you say makes sense from that, but you're looking from an=20 > unusual point of view (and you went very fast up the=20 > knowledge hill so it's not a problem, you must be a smart guy). >=20 > You're more or less claiming that if you have a hub-based=20 > Ethernet LAN (multicast networking has the same properties,=20 > it's a broadcast LAN implemented over multicast IP) all PCs=20 > should auto-configure their interfaces to work in promiscuos mode. >=20 > That's wrong, as promiscuos mode only makes sense in=20 > hub-based networks and reduces overhead. >=20 > You can still configure your interface to work in promiscuos=20 > mode as said above. >=20 > All this said, if when trying what I suggested you see=20 > unexpected behaviour, it _may_ be a bug (especially in UML=20 > network support and/or UML multicast transport). > -- > Inform me of my mistakes, so I can keep imitating Homer=20 > Simpson's "Doh!". > Paolo Giarrusso, aka Blaisorblade > http://www.user-mode-linux.org/~blaisorblade > Chiacchiera con i tuoi amici in tempo reale!=20 > http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com=20 >=20 >=20 |
From: Stephens, A. <all...@wi...> - 2006-08-01 17:41:29
|
Hi Paolo: Apparently I was unclear in my last email. I was not trying to claim that "uml_switch -hub" was delivering promiscuously when "ifconfig promisc" was not set, but rather that it was (correctly) delivering non-promiscuously -- meaning I didn't have to trick my protocol software into filtering out the unwanted packets using the "ifconfig promisc" approach that was required with "ethX=3Dmcast". In short, I think everything is now working as it should. But if I see anything else that looks strange I'll be sure to mention it! Regards, Al Stephens Wind River > -----Original Message----- > From: Paolo Giarrusso [mailto:bla...@ya...]=20 > Sent: Tuesday, August 01, 2006 12:56 PM > To: Stephens, Allan; use...@li... > Subject: RE: [uml-user] Promiscuous mode interface bug? >=20 > "Stephens, Allan" <all...@wi...> ha scritto:=20 >=20 > > Hi Paolo: > >=20 > > I tried configuring the Ethernet interfaces as=20 > "promiscuous" and this=20 > > did indeed provide a workaround for the issue I raised. The root=20 > > cause of my problems seems to have been a lack of=20 > understanding on my=20 > > part as to what I was really asking UML to do for me; your=20 > explanation=20 > > has helped clear things up significantly. It appears that=20 > I was using=20 > > interfaces of the form "ethX=3Dmcast" expecting them to=20 > behave like ones=20 > > of the form "ethX=3Ddaemon" used with "uml_switch -hub". >=20 > I.e. when you use "uml_switch -hub" even without "ifconfig promisc" > all packets arrive as if the interface were in promiscuos mode? > Compliments, if this is true you have found a bug! I'll=20 > verify this ASAP - it could be born from the fact that=20 > uml_switch is normally a switch so maybe the code coping with=20 > it thinks there's no need to filter MAC destination address.=20 > I'll verify this (if I don't forget). >=20 > > I've now > > reconfigured things to use the latter type of interface, and things=20 > > are working as I expected. > >=20 > > Thanks so much for your help! > >=20 > > Regards, > > Al Stephens > > Wind River > >=20 > > > -----Original Message----- > > > From: Blaisorblade [mailto:bla...@ya...] > > > Sent: Saturday, July 29, 2006 4:20 AM > > > To: use...@li... > > > Cc: Stephens, Allan > > > Subject: Re: [uml-user] Promiscuous mode interface bug? > > >=20 > > > On Wednesday 26 July 2006 16:34, Stephens, Allan wrote: > > > > Hi there: > > > > > > > > I've been running UML using Linux 2.6.17 (guest) and 2.6.12 > > > (host) and > > > > configured a guest with a pair of Ethernet multicast interfaces > > as > > > > shown below. (Note that I didn't configure any IP > > > addresses, as I'm > > > > not trying to use them to carry IP traffic.) > > > > > > > > uml_mconsole <session> config eth1=3Dmcast,00:00:00:00:01:01=20 > > > > uml_mconsole <session> config eth2=3Dmcast,00:00:00:00:02:02 > > > > > > > > When a second guest transmitted traffic using a destination > > > address of > > > > 00:00:00:00:01:01, the message showed up on both interfaces (as > >=20 > > > > expected). However, the kernel protocol handled incoming > > > messages did > > > > not recognize and discard the unwanted copy that showed up at > > "eth2" > > > > because the associated "struct net_device" object did not have > > the > > > > "promiscuity" field set to indicate that the interface > > > might receive > > > > traffic other than its own. > > >=20 > > > That's a slightly wrong interpretation of the flag (it actually=20 > > > means that the interface should accept others' > > > packets; whether it may receive them or not is indicated by the=20 > > > BROADCAST/POINTTOPOINT flag in ifconfig output). > > >=20 > > > It's also a slightly complex way to check it: > > >=20 > > > ifconfig eth2 |grep PROMISC would be simpler. > > > and ifconfig eth2 promisc would enable it. > > >=20 > > > > It seems to me that any UML interface configured to use > > multicast > > > > should cause the promiscuity field of the associated > > > net_device to be > > > > set -- but maybe I'm missing something here. Is the scenario I > >=20 > > > > encountered really a bug? > > >=20 > > > No, it's a feature; I understand your point of view and=20 > what you say=20 > > > makes sense from that, but you're looking from an unusual=20 > point of=20 > > > view (and you went very fast up the knowledge hill so it's not a=20 > > > problem, you must be a smart guy). > > >=20 > > > You're more or less claiming that if you have a hub-based=20 > Ethernet=20 > > > LAN (multicast networking has the same properties, it's a=20 > broadcast=20 > > > LAN implemented over multicast IP) all PCs should auto-configure=20 > > > their interfaces to work in promiscuos > > mode. > > >=20 > > > That's wrong, as promiscuos mode only makes sense in hub-based=20 > > > networks and reduces overhead. > > >=20 > > > You can still configure your interface to work in=20 > promiscuos mode as=20 > > > said above. > > >=20 > > > All this said, if when trying what I suggested you see unexpected=20 > > > behaviour, it _may_ be a bug (especially in UML network support=20 > > > and/or UML multicast transport). > > > -- > > > Inform me of my mistakes, so I can keep imitating Homer Simpson's=20 > > > "Doh!". > > > Paolo Giarrusso, aka Blaisorblade > > > http://www.user-mode-linux.org/~blaisorblade > > > Chiacchiera con i tuoi amici in tempo reale!=20 > > > http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com > > >=20 > > >=20 > >=20 >=20 >=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: Blaisorblade <bla...@ya...> - 2006-08-01 18:38:09
|
On Tuesday 01 August 2006 19:41, Stephens, Allan wrote: > Hi Paolo: > > Apparently I was unclear in my last email. I was not trying to claim > that "uml_switch -hub" was delivering promiscuously when "ifconfig > promisc" was not set, This makes sense... > but rather that it was (correctly) delivering > non-promiscuously uml_switch is broadcasting, the uml driver is doing the filtering (so the network stack doesn't see unwanted stuff). > -- meaning I didn't have to trick my protocol software > into filtering out the unwanted packets using the "ifconfig promisc" > approach that was required with "ethX=mcast". This part of your mail doesn't make sense _to me_, you're either missing or adding some negations. If things are correct eth0=anything gives the same result: non-promiscous by default and promiscous only if you ask (with "ifconfig promisc" or by default by packet sniffers); the only difference is that some trasports are "broadcast" (like Ethernet with hubs) and others not (like Ethernet with switches, even if technically this is still referred to as a broadcast LAN since you can do broadcast). Sorry, didn't you complain that promiscous mode wasn't auto-enabled by "eth0=mcast"? Ok, you expected that your software had to cope with this situation and not coping with it is better, but there's still somebody not playing within the rules. Maybe it's all ok, but could you rewrite the above paragraph to make it clearer for me? You've flipped some sentences... since "promiscuos" means "the interface accepts every packet" and non-promiscous means "the driver or the hardware only accepts packet with the right destination MAC". > In short, I think everything is now working as it should. But if I see > anything else that looks strange I'll be sure to mention it! > Regards, > Al Stephens > Wind River -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade 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-02 14:27:11
|
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=3Ddaemon", 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. When I used "ethX=3Dmcast", each interface I configured on a UML guest forwarded all packets sent to the associated multicast group to my network protocol software, 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=3Dmcast" 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=3Dmcast" 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? Regards, Al > -----Original Message----- > From: Blaisorblade [mailto:bla...@ya...]=20 > Sent: Tuesday, August 01, 2006 2:37 PM > To: Stephens, Allan > Cc: use...@li... > Subject: Re: [uml-user] Promiscuous mode interface bug? >=20 > On Tuesday 01 August 2006 19:41, Stephens, Allan wrote: > > Hi Paolo: > > > > Apparently I was unclear in my last email. I was not=20 > trying to claim=20 > > that "uml_switch -hub" was delivering promiscuously when "ifconfig=20 > > promisc" was not set, >=20 > This makes sense... >=20 > > but rather that it was (correctly) delivering non-promiscuously >=20 > uml_switch is broadcasting, the uml driver is doing the=20 > filtering (so the network stack doesn't see unwanted stuff). >=20 >=20 > > -- meaning I didn't have to trick my protocol software=20 > > into filtering out the unwanted packets using the "ifconfig promisc" > > approach that was required with "ethX=3Dmcast". > This part of your mail doesn't make sense _to me_, you're=20 > either missing or=20 > adding some negations. >=20 > If things are correct eth0=3Danything gives the same result:=20 > non-promiscous by=20 > default and promiscous only if you ask (with "ifconfig=20 > promisc" or by default=20 > by packet sniffers); the only difference is that some trasports=20 > are "broadcast" (like Ethernet with hubs) and others not=20 > (like Ethernet with=20 > switches, even if technically this is still referred to as a=20 > broadcast LAN=20 > since you can do broadcast). >=20 > Sorry, didn't you complain that promiscous mode wasn't auto-enabled=20 > by "eth0=3Dmcast"? Ok, you expected that your software had to=20 > cope with this=20 > situation and not coping with it is better, but there's still=20 > somebody not=20 > playing within the rules. >=20 > Maybe it's all ok, but could you rewrite the above paragraph=20 > to make it=20 > clearer for me? You've flipped some sentences... since "promiscuos"=20 > means "the interface accepts every packet" and non-promiscous=20 > means "the=20 > driver or the hardware only accepts packet with the right=20 > destination MAC". >=20 > > In short, I think everything is now working as it should. =20 > But if I see > > anything else that looks strange I'll be sure to mention it! >=20 > > Regards, > > Al Stephens > > Wind River >=20 > --=20 > Inform me of my mistakes, so I can keep imitating Homer=20 > Simpson's "Doh!". > Paolo Giarrusso, aka Blaisorblade > http://www.user-mode-linux.org/~blaisorblade > Chiacchiera con i tuoi amici in tempo reale!=20 > http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com=20 >=20 >=20 |
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: Jeff D. <jd...@ad...> - 2006-08-02 16:16:11
|
On Wed, Aug 02, 2006 at 07:27:00AM -0700, Stephens, Allan wrote: > 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, even though the interfaces were not > configured as "promiscuous". Are you talking about the multicast group on the host that's used as the network interconnect? If so, this is a property of the interconnect, akin to plugging yourself into a hub and observing that you see everyone's traffic, not just your own. Jeff |
From: Stephens, A. <all...@wi...> - 2006-08-03 16:30:06
|
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:08
|
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:13
|
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:33
|
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 |
From: Paolo G. <bla...@ya...> - 2006-08-01 16:56:47
|
"Stephens, Allan" <all...@wi...> ha scritto: > Hi Paolo: > > I tried configuring the Ethernet interfaces as "promiscuous" and > this > did indeed provide a workaround for the issue I raised. The root > cause > of my problems seems to have been a lack of understanding on my > part as > to what I was really asking UML to do for me; your explanation has > helped clear things up significantly. It appears that I was using > interfaces of the form "ethX=mcast" expecting them to behave like > ones > of the form "ethX=daemon" used with "uml_switch -hub". I.e. when you use "uml_switch -hub" even without "ifconfig promisc" all packets arrive as if the interface were in promiscuos mode? Compliments, if this is true you have found a bug! I'll verify this ASAP - it could be born from the fact that uml_switch is normally a switch so maybe the code coping with it thinks there's no need to filter MAC destination address. I'll verify this (if I don't forget). > I've now > reconfigured things to use the latter type of interface, and things > are > working as I expected. > > Thanks so much for your help! > > Regards, > Al Stephens > Wind River > > > -----Original Message----- > > From: Blaisorblade [mailto:bla...@ya...] > > Sent: Saturday, July 29, 2006 4:20 AM > > To: use...@li... > > Cc: Stephens, Allan > > Subject: Re: [uml-user] Promiscuous mode interface bug? > > > > On Wednesday 26 July 2006 16:34, Stephens, Allan wrote: > > > Hi there: > > > > > > I've been running UML using Linux 2.6.17 (guest) and 2.6.12 > > (host) and > > > configured a guest with a pair of Ethernet multicast interfaces > as > > > shown below. (Note that I didn't configure any IP > > addresses, as I'm > > > not trying to use them to carry IP traffic.) > > > > > > uml_mconsole <session> config eth1=mcast,00:00:00:00:01:01 > > > uml_mconsole <session> config eth2=mcast,00:00:00:00:02:02 > > > > > > When a second guest transmitted traffic using a destination > > address of > > > 00:00:00:00:01:01, the message showed up on both interfaces (as > > > > expected). However, the kernel protocol handled incoming > > messages did > > > not recognize and discard the unwanted copy that showed up at > "eth2" > > > because the associated "struct net_device" object did not have > the > > > "promiscuity" field set to indicate that the interface > > might receive > > > traffic other than its own. > > > > That's a slightly wrong interpretation of the flag (it > > actually means that the interface should accept others' > > packets; whether it may receive them or not is indicated by > > the BROADCAST/POINTTOPOINT flag in ifconfig output). > > > > It's also a slightly complex way to check it: > > > > ifconfig eth2 |grep PROMISC would be simpler. > > and ifconfig eth2 promisc would enable it. > > > > > It seems to me that any UML interface configured to use > multicast > > > should cause the promiscuity field of the associated > > net_device to be > > > set -- but maybe I'm missing something here. Is the scenario I > > > > encountered really a bug? > > > > No, it's a feature; I understand your point of view and what > > you say makes sense from that, but you're looking from an > > unusual point of view (and you went very fast up the > > knowledge hill so it's not a problem, you must be a smart guy). > > > > You're more or less claiming that if you have a hub-based > > Ethernet LAN (multicast networking has the same properties, > > it's a broadcast LAN implemented over multicast IP) all PCs > > should auto-configure their interfaces to work in promiscuos > mode. > > > > That's wrong, as promiscuos mode only makes sense in > > hub-based networks and reduces overhead. > > > > You can still configure your interface to work in promiscuos > > mode as said above. > > > > All this said, if when trying what I suggested you see > > unexpected behaviour, it _may_ be a bug (especially in UML > > network support and/or UML multicast transport). > > -- > > Inform me of my mistakes, so I can keep imitating Homer > > Simpson's "Doh!". > > Paolo Giarrusso, aka Blaisorblade > > http://www.user-mode-linux.org/~blaisorblade > > Chiacchiera con i tuoi amici in tempo reale! > > http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com > > > > > Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com |