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

[Stephens, A. <all...@wi...>]

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