Re: [uml-devel] [uml-user] Promiscuous mode interface bug?

Re: [uml-devel] [uml-user] Promiscuous mode interface bug?

[Paolo Giarrusso]

"Stephens, Allan" <allan.stephens@windriver.com> 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 

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [uml-user] Promiscuous mode interface bug?

[Stephens, Allan]

Hi Paolo:

Here are the latest results of my testing of uml_switch.

Guest 1 has eth0=daemon,00:00:00:00:11:00
Guest 2 has eth0=daemon,00:00:00:00:22:00 and
eth1=daemon,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=mcast,00:00:00:00:11:00,,1106
Guest 2 has eth0=mcast,00:00:00:00:22:00,,1106 and
eth1=mcast,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:blaisorblade@yahoo.it] 
> Sent: Wednesday, August 02, 2006 11:05 AM
> To: Stephens, Allan; user-mode-linux-devel@lists.sourceforge.net
> Cc: user-mode-linux-user@lists.sourceforge.net
> Subject: RE: [uml-user] Promiscuous mode interface bug?
> 
> "Stephens, Allan" <allan.stephens@windriver.com> 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 
> 

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [uml-user] Promiscuous mode interface bug?

[Jeff Dike]

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

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [uml-user] Promiscuous mode interface bug?

[Stephens, Allan]

Hi Jeff:

See comments below.

> -----Original Message-----
> From: Jeff Dike [mailto:jdike@addtoit.com] 
> Sent: Thursday, August 03, 2006 2:26 PM
> To: Stephens, Allan
> Cc: Paolo Giarrusso; 
> user-mode-linux-devel@lists.sourceforge.net; 
> user-mode-linux-user@lists.sourceforge.net
> Subject: Re: [uml-devel] [uml-user] Promiscuous mode interface bug?
> 
> 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.

That is entirely possible.

> 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.

No, this isn't my thinking at all.  (See next point.)

> 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.

I agree with this view completely.

> 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

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 
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

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [uml-user] Promiscuous mode interface bug?

[Jeff Dike]

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

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [uml-user] Promiscuous mode interface bug?

[Paolo Giarrusso]

Jeff Dike <jdike@addtoit.com> 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 

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [uml-user] Promiscuous mode interface bug?

[Steven James]

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
>

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [uml-user] Promiscuous mode interface bug?

[Stephens, Allan]

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:blaisorblade@yahoo.it] 
> Sent: Friday, August 04, 2006 7:10 AM
> To: Jeff Dike; Stephens, Allan
> Cc: Paolo Giarrusso; 
> user-mode-linux-devel@lists.sourceforge.net; 
> user-mode-linux-user@lists.sourceforge.net
> Subject: Re: [uml-devel] [uml-user] Promiscuous mode interface bug?
> 
> Jeff Dike <jdike@addtoit.com> 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 
> 

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel