Re: Hostile wireless in 9.3

davidca@writeme.com wrote:
> Maybe its because I upgraded from 9.0, if not then wireless users
who have
> a built in interface, use DHCP, and also have a built in wired
ethernet
> which many do can find one or the other non-functional. In my case
it was
> the wireless. Much mucking around later I found that unless I
modified the
> ifcfg* files in /etc/sysconfig/network to set:
> DHCLIENT_PRIMARY_DEVICE='yes'
> then only the first configured device would set 'global' items using
dhcp
> like the default routem gateway, and nameservers even if that device
was
> not connected. Setting the variable forces both interfaces to set
the
> 'global' environment. The commentary in the template implies that
this is
> an potentially undefined case if both interfaces are live. This may
be
> true, but I would argue that it is the expected behavior because
otherwise
> you have traded potentially bad behavior when both are live for one
or the
> other simply not working. Seems to me this could potentiallly bite
a lot
> of people.

It may "bite" people. But at the same time it does educate people
that
ONLY ONE interface can have the default gateway at any given time.

My solution... I wrote a small wrapper script with icons for my wife's

desktop so she can activate either interface (while shutting down theother). So when she's plugged in at the docking station, she can
enable her wired interface (for speed) rather than randomly getting
one or the other as the "primary" interface.

Another solution is to make a TON of assumptions via polling. You
could
try to hit all interfaces and make sure the first one that it active
gets to own the default gateway via its dhcp client process. I
believe
this is essentially how Windows operates... but who knows, it may
just give preference to one of the interface types... for example,
if your wireless becomes live, maybe it just lets it have the defaultgateway.... dunno.

> davidca@writeme.com wrote:
> > Maybe its because I upgraded from 9.0, if not then wireless users
who have
> > a built in interface, use DHCP, and also have a built in wired
ethernet
> > which many do can find one or the other non-functional. In my
case it was
> > the wireless. Much mucking around later I found that unless I
modified the
> > ifcfg* files in /etc/sysconfig/network to set:
> > DHCLIENT_PRIMARY_DEVICE='yes'
> > then only the first configured device would set 'global' items
using dhcp
> > like the default routem gateway, and nameservers even if that
device was
> > not connected. Setting the variable forces both interfaces to set
the
> > 'global' environment. The commentary in the template implies that
this is
> > an potentially undefined case if both interfaces are live. This
may be
> > true, but I would argue that it is the expected behavior because
otherwise
> > you have traded potentially bad behavior when both are live for
one or the
> > other simply not working. Seems to me this could potentiallly
bite a lot
> > of people.
>
> It may "bite" people. But at the same time it does educate people
that
> ONLY ONE interface can have the default gateway at any given time.
>
I'm not a big fan of being 'educated' by the system not working and aneophyte wouldn't stand a chance and would most likely walk away in
disgust. One of the reasons for DHCP in the first place is so you
wouldn't
have to configure this stuff.
>
> Another solution is to make a TON of assumptions via polling. You
could
> try to hit all interfaces and make sure the first one that it active

> gets to own the default gateway via its dhcp client process. I
believe
> this is essentially how Windows operates... but who knows, it may
> just give preference to one of the interface types... for example,
> if your wireless becomes live, maybe it just lets it have the
default
> gateway.... dunno.
Quite frankly I don't see the ton of assumptions. It polls all the
devices
now in their configuration order and having the first one that gets
dhcp
access 'win' and lock resolv.conf seems more reasonable than only the
first
one can set 'global' settings (which isn't indicated in any fashion by
YAST
by the way). If you want the wired connection to have priority then
have
it first on the configuration list Personally, I don't see any
circumstance where #1 always wins is better than the first one that
actually can get DHCP info wins.

Dave

davidca@writeme.com wrote:
>>davidca@writeme.com wrote:
>>>Maybe its because I upgraded from 9.0, if not then wireless users
who have
>>>a built in interface, use DHCP, and also have a built in wired
ethernet
>>>which many do can find one or the other non-functional. In my case
it was
>>>the wireless. Much mucking around later I found that unless I
modified the
>>>ifcfg* files in /etc/sysconfig/network to set:
>>>DHCLIENT_PRIMARY_DEVICE='yes'
>>>then only the first configured device would set 'global' items
using dhcp
>>>like the default routem gateway, and nameservers even if that
device was
>>>not connected. Setting the variable forces both interfaces to set
the
>>>'global' environment. The commentary in the template implies that
this is
>>>an potentially undefined case if both interfaces are live. This
may be
>>>true, but I would argue that it is the expected behavior because
otherwise
>>>you have traded potentially bad behavior when both are live for one
or the
>>>other simply not working. Seems to me this could potentiallly bite
a lot
>>>of people.
>>It may "bite" people. But at the same time it does educate people
that
>>ONLY ONE interface can have the default gateway at any given time.
>>
> I'm not a big fan of being 'educated' by the system not working and
a
> neophyte wouldn't stand a chance and would most likely walk away in> disgust. One of the reasons for DHCP in the first place is so you
wouldn't
> have to configure this stuff.

DHCP assumes ONE interface.

>>Another solution is to make a TON of assumptions via polling. You
could
>>try to hit all interfaces and make sure the first one that it active

>>gets to own the default gateway via its dhcp client process. I
believe
>>this is essentially how Windows operates... but who knows, it may
>>just give preference to one of the interface types... for example,
>>if your wireless becomes live, maybe it just lets it have the
default
>>gateway.... dunno.
> Quite frankly I don't see the ton of assumptions. It polls all the
devices
> now in their configuration order and having the first one that gets
dhcp
> access 'win' and lock resolv.conf seems more reasonable than only
the first
> one can set 'global' settings (which isn't indicated in any fashion
by YAST
> by the way). If you want the wired connection to have priority then
have
> it first on the configuration list Personally, I don't see any
> circumstance where #1 always wins is better than the first one that> actually can get DHCP info wins.

Due to the nature of hotplug, you can't be assured of the order
of configuration. First device on one boot will not necessarily be
the first device on subsequent boots.

Default behavior (as you pointed out) is to give the first interface
preference... but since you can't guarantee order...

This has been the biggest issue for me since I migrated my work
laptopn
from XP to SUSE. I move from wired to wireless environments frequently
and
find it a hassle to have to deactivate one card in order to get
connectivity from the other. This is a big minus for SUSE on mobile
systems. I'll try some of the ideas presented here but I am not moving
any
nontech laptops in my company for a long time.


> davidca@writeme.com wrote:
> >>davidca@writeme.com wrote:
> >>>Maybe its because I upgraded from 9.0, if not then wireless users
who have
> >>>a built in interface, use DHCP, and also have a built in wired
ethernet
> >>>which many do can find one or the other non-functional. In my
case it was
> >>>the wireless. Much mucking around later I found that unless I
modified the
> >>>ifcfg* files in /etc/sysconfig/network to set:
> >>>DHCLIENT_PRIMARY_DEVICE='yes'
> >>>then only the first configured device would set 'global' items
using dhcp
> >>>like the default routem gateway, and nameservers even if that
device was
> >>>not connected. Setting the variable forces both interfaces to
set the
> >>>'global' environment. The commentary in the template implies
that this is
> >>>an potentially undefined case if both interfaces are live. This
may be
> >>>true, but I would argue that it is the expected behavior because
otherwise
> >>>you have traded potentially bad behavior when both are live for
one or the
> >>>other simply not working. Seems to me this could potentiallly
bite a lot
> >>>of people.
> >>It may "bite" people. But at the same time it does educate people
that
> >>ONLY ONE interface can have the default gateway at any given time.

> >>
> > I'm not a big fan of being 'educated' by the system not working
and a
> > neophyte wouldn't stand a chance and would most likely walk away
in
> > disgust. One of the reasons for DHCP in the first place is so you
wouldn't
> > have to configure this stuff.
>
> DHCP assumes ONE interface.
>
> >>Another solution is to make a TON of assumptions via polling. You
could
> >>try to hit all interfaces and make sure the first one that it
active
> >>gets to own the default gateway via its dhcp client process. I
believe
> >>this is essentially how Windows operates... but who knows, it may> >>just give preference to one of the interface types... for example,

> >>if your wireless becomes live, maybe it just lets it have the
default
> >>gateway.... dunno.
> > Quite frankly I don't see the ton of assumptions. It polls all
the devices
> > now in their configuration order and having the first one that
gets dhcp
> > access 'win' and lock resolv.conf seems more reasonable than only
the first
> > one can set 'global' settings (which isn't indicated in any
fashion by YAST
> > by the way). If you want the wired connection to have priority
then have
> > it first on the configuration list Personally, I don't see any
> > circumstance where #1 always wins is better than the first one
that
> > actually can get DHCP info wins.
>
> Due to the nature of hotplug, you can't be assured of the order
> of configuration. First device on one boot will not necessarily be> the first device on subsequent boots.
>
> Default behavior (as you pointed out) is to give the first interface

> preference... but since you can't guarantee order...