1:39 p.m.
I've just completed an install of a rawhide snapshot, approximately one week
old. I was not able to configure the network during the install, so I'm doing
it now. Unusually, the wireless network has set up without a problem but the
wired connection is failing to set. The 'OK' remains greyed out.
Is it necessary to give a MAC address during setup? I confess I don't know
how to get it until I have a connection.
I want to use static IP on the wired connection. Is that not possible at this
stage?
I can fall back to dhcp for the present, if that's the case.
Anne
3:22 p.m.
On Mon, Nov 10, 2008 at 07:39:17PM +0000, Anne Wilson wrote:
I've just completed an install of a rawhide snapshot,
approximately one week
old. I was not able to configure the network during the install, so I'm doing
it now. Unusually, the wireless network has set up without a problem but the
wired connection is failing to set. The 'OK' remains greyed out.
Do not let NetworkManager to handle your static connections. It
will mess up badly. OTOH it is quite possible that you run into
that bug: https://bugzilla.redhat.com/show_bug.cgi?id=459017
Is it necessary to give a MAC address during setup?
No.
I confess I don't know
how to get it until I have a connection.
'ip link' will show that but you should not care.
Michal
4:05 p.m.
On Monday 10 November 2008 21:22:55 Michal Jaegermann wrote:
On Mon, Nov 10, 2008 at 07:39:17PM +0000, Anne Wilson wrote:
> I've just completed an install of a rawhide snapshot, approximately one
> week old. I was not able to configure the network during the install, so
> I'm doing it now. Unusually, the wireless network has set up without a
> problem but the wired connection is failing to set. The 'OK' remains
> greyed out.
Do not let NetworkManager to handle your static connections. It
will mess up badly. OTOH it is quite possible that you run into
that bug: https://bugzilla.redhat.com/show_bug.cgi?id=459017
It's very odd. System-config-nework shows all the correct settings for static
IP, but 'Activate' has no effect
> Is it necessary to give a MAC address during setup?
No.
> I confess I don't know
> how to get it until I have a connection.
'ip link' will show that but you should not care.
OK, thanks
Anne
5:23 p.m.
On Mon, Nov 10, 2008 at 10:05:25PM +0000, Anne Wilson wrote:
On Monday 10 November 2008 21:22:55 Michal Jaegermann wrote:
>
> Do not let NetworkManager to handle your static connections. It
> will mess up badly. OTOH it is quite possible that you run into
> that bug: https://bugzilla.redhat.com/show_bug.cgi?id=459017
>
It's very odd. System-config-nework shows all the correct settings for static
IP, but 'Activate' has no effect
Did you look at the quoted bug? It says "confusing". Basically it
initially appears that NM is _not_ handling a given device but this
is not true. If that is the case then 'Activate' has no effect and
if you are in an NM territory then then it is how it should be.
Michal
9:43 p.m.
2008/11/11 Anne Wilson <cannewilson(a)googlemail.com>
On Monday 10 November 2008 21:22:55 Michal Jaegermann wrote:
> On Mon, Nov 10, 2008 at 07:39:17PM +0000, Anne Wilson wrote:
> > I've just completed an install of a rawhide snapshot, approximately one
> > week old. I was not able to configure the network during the install,
so
> > I'm doing it now. Unusually, the wireless network has set up without a
> > problem but the wired connection is failing to set. The 'OK' remains
> > greyed out.
>
> Do not let NetworkManager to handle your static connections. It
> will mess up badly. OTOH it is quite possible that you run into
> that bug: https://bugzilla.redhat.com/show_bug.cgi?id=459017
>
It's very odd. System-config-nework shows all the correct settings for
static
IP, but 'Activate' has no effect
is the NetworkManager service stopped?
is the network service running?
> > Is it necessary to give a MAC address during setup?
>
> No.
>
> > I confess I don't know
> > how to get it until I have a connection.
>
> 'ip link' will show that but you should not care.
>
OK, thanks
Anne
--
fedora-test-list mailing list
fedora-test-list(a)redhat.com
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
--
Linux counter #213090
1:40 a.m.
On Tuesday 11 November 2008 03:43:40 cornel panceac wrote:
is the NetworkManager service stopped?
is the network service running?
Networking is the one aspect of Fedora that always confuses me. It seems to
me that on a laptop I want/need NetworkManager to work with wifi wherever I am
working. OTOH, at home I would generally want to work with wired. Can you
please spell out for me which services I should be using?
Thanks
Anne
1:53 a.m.
On Tuesday 11 November 2008 07:40:14 Anne Wilson wrote:
On Tuesday 11 November 2008 03:43:40 cornel panceac wrote:
> is the NetworkManager service stopped?
> is the network service running?
Networking is the one aspect of Fedora that always confuses me. It seems
to me that on a laptop I want/need NetworkManager to work with wifi
wherever I am working. OTOH, at home I would generally want to work with
wired. Can you please spell out for me which services I should be using?
Just to confuse me even more :-) booting up this morning brought me the
dialogue to enter my WPA key, which was refused three times before appearing
to be accepted. However, on completion, the taskbar icon showed that I have a
wired connection, so I ran ifconfig.
To my surprise I saw no eth0, but eth1 has what is clearly a dhcp address
(although it says there were ~48 million packets dropped!) so that looks as
though the wireless connection is working and the wired connection not
working.
Could you also please remind me which file I need to edit to disable IPV6?
Thanks
Anne
2:43 a.m.
On Tuesday 11 November 2008 07:53:40 Anne Wilson wrote:
Could you also please remind me which file I need to edit to disable IPV6?
/etc/sysconfig/network
NETWORKING_IPV6=no
For a wired connection run the network service and disable the NetworkManager
service.
Regards,
Tony
Thanks
Anne
11 a.m.
On Tue, 2008-11-11 at 08:43 +0000, Tony Molloy wrote:
For a wired connection run the network service and disable the
NetworkManager
service.
This is just bad advice. Unless you need ipv6, or need advanced
networking features such as bridges, or are setting up a headless system
with static networking, NetworkManager is fine for both wireless and
wired. NetworkManager can have system wide connections configured that
will be brought up at boot time, both dhcp or static.
For the OPs laptop case, NM is even better as you can go from one
location where you're using wireless to another location, plug in a wire
and NetworkManager will automatically attempt to get an address from
that wire and allow you to use the wired network.
There are very few reasons and less each release to revert to the
'network' service.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
11:49 a.m.
On Tue, Nov 11, 2008 at 12:36:27PM -0500, Steve Thompson wrote:
On Tue, 11 Nov 2008, Jesse Keating wrote:
>There are very few reasons and less each release to revert to the
>'network' service.
So NetworkManager now knows how to set the hostname properly?
You mean like https://bugzilla.redhat.com/show_bug.cgi?id=441453
At least a status of that is still ASSIGNED. And the next question
would be what about if you need to mount some NFS supplied directories
while booting (and similar network services).
Michal
11:53 a.m.
On Tue, 2008-11-11 at 10:49 -0700, Michal Jaegermann wrote:
On Tue, Nov 11, 2008 at 12:36:27PM -0500, Steve Thompson wrote:
> On Tue, 11 Nov 2008, Jesse Keating wrote:
>
> >There are very few reasons and less each release to revert to the
> >'network' service.
>
> So NetworkManager now knows how to set the hostname properly?
You mean like https://bugzilla.redhat.com/show_bug.cgi?id=441453
At least a status of that is still ASSIGNED. And the next question
would be what about if you need to mount some NFS supplied directories
while booting (and similar network services).
... such as autofs w/ yp/nismaps ;)
Ralf
2:18 p.m.
On Tue, 2008-11-11 at 12:36 -0500, Steve Thompson wrote:
So NetworkManager now knows how to set the hostname properly?
Now that all depends on your definition of properly. There are cases
where changing the hostname of a running system will break other running
software. It's not a perfect world, neither option is that great.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
2:45 p.m.
On Tue, Nov 11, 2008 at 12:18:02PM -0800, Jesse Keating wrote:
On Tue, 2008-11-11 at 12:36 -0500, Steve Thompson wrote:
> So NetworkManager now knows how to set the hostname properly?
Now that all depends on your definition of properly. There are cases
where changing the hostname of a running system will break other running
software. It's not a perfect world, neither option is that great.
Service 'network' for years was adjusting machine names only when
it was 'localhost' or 'localhost.localdomain' and this was done only
when an interface was going up for the first time after a boot. So
it is doable and in many situations it is important that you are not
get stuck with 'localhost' while assigning a "fixed name" to a
machine is not feasible or desirable.
Michal
4:18 p.m.
On Tue, 11 Nov 2008, Jesse Keating wrote:
On Tue, 2008-11-11 at 12:36 -0500, Steve Thompson wrote:
> So NetworkManager now knows how to set the hostname properly?
Now that all depends on your definition of properly. There are cases
where changing the hostname of a running system will break other running
software. It's not a perfect world, neither option is that great.
Point taken. However, I have been setting hostnames via DHCP for years
(both Fedora and CentOS on over 300 machines), and have never had anything
break because of it (not one single breakage of any kind). I've also tried
NM a few times (maybe 10 times) and have never had it work "properly" even
once. When deploying a large number of equivalent machines (more than
two), it is simply not acceptable for there to be a need for the system
image to contain the hostname _anywhere_, as seems to be currently
required by NM.
Steve
4:43 p.m.
On Tue, 2008-11-11 at 17:18 -0500, Steve Thompson wrote:
Point taken. However, I have been setting hostnames via DHCP for
years
(both Fedora and CentOS on over 300 machines), and have never had anything
break because of it (not one single breakage of any kind).
While on the other hand, I would constantly have X break, no new windows
could launch, audio break, not able to re-connect to the daemon, so on
and so forth. It's an imperfect system.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
10:11 p.m.
On Tue, Nov 11, 2008 at 4:43 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
On Tue, 2008-11-11 at 17:18 -0500, Steve Thompson wrote:
> Point taken. However, I have been setting hostnames via DHCP for years
> (both Fedora and CentOS on over 300 machines), and have never had anything
> break because of it (not one single breakage of any kind).
While on the other hand, I would constantly have X break, no new windows
could launch, audio break, not able to re-connect to the daemon,
Maybe, on a running system, where a DHCP renew happens to change the
hostname for some unearthly reason. In other words, not a likely use
case.
I love NetworkMangler. Really, I do. What? :-)
jerry
--
There's plenty of youth in America - it's time we find the "fountain of
smart".
11:57 p.m.
On Tue, 2008-11-11 at 22:11 -0600, Jerry Amundson wrote:
Maybe, on a running system, where a DHCP renew happens to change the
hostname for some unearthly reason.
Like when moving from the coffee shop to the house to the office to the
train?
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
12:10 p.m.
On Tue, Nov 11, 2008 at 09:57:59PM -0800, Jesse Keating wrote:
On Tue, 2008-11-11 at 22:11 -0600, Jerry Amundson wrote:
>
> Maybe, on a running system, where a DHCP renew happens to change the
> hostname for some unearthly reason.
Like when moving from the coffee shop to the house to the office to the
train?
And how that is supposed to happen without a reboot if renames occur
only if a name was 'localhost' or 'locahost.localdomain' and only
the first time an interface was going up after a reboot? That person
who implemented that for 'network' service had some clue.
If you rebooted then all your objections are an undiluted garbage.
Michal
12:26 p.m.
On Wed, 2008-11-12 at 11:10 -0700, Michal Jaegermann wrote:
And how that is supposed to happen without a reboot if renames occur
only if a name was 'localhost' or 'locahost.localdomain' and only
the first time an interface was going up after a reboot? That person
who implemented that for 'network' service had some clue.
If you rebooted then all your objections are an undiluted garbage.
The problem was that your initial hostname would get set to something
like dhcp49.homelan.blah and it would resolve out to 192.168.10.49 or
some such. Then you'd to go a coffee shop and you'd have a problem.
Either your hostname would have to change, or the hosts entry for what
it resolved to would have to change, because your address is changing.
And if that previous address is still resolvable via dns (think vpn
access back to the home) you're now overriding dns which is wrong.
The work around I had was to set hostname up once, resolve it to
127.0.0.1 and call it a day. Nothing would ever fiddle with my hostname
nor it's resolution and I could hop networks with ease.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
1 p.m.
On Wed, Nov 12, 2008 at 10:26:44AM -0800, Jesse Keating wrote:
On Wed, 2008-11-12 at 11:10 -0700, Michal Jaegermann wrote:
> And how that is supposed to happen without a reboot if renames occur
> only if a name was 'localhost' or 'locahost.localdomain' and only
> the first time an interface was going up after a reboot?
The problem was that your initial hostname would get set to something
like dhcp49.homelan.blah and it would resolve out to 192.168.10.49 or
some such.
OK. Let's say.
Then you'd to go a coffee shop and you'd have a problem.
And that problem is? How this is different if you would always set
a name of that machine to jesse.keating.box? Nowhere says that what
is returned by 'hostname' needs really be the same what a name
resolution will return. Moreover machines very often have multiple
names, even with a single network interface, although 'hostname'
will show the only one.
Either your hostname would have to change, or the hosts entry for
what
it resolved to would have to change, because your address is changing.
Your name to the outside world, are returned by a name resolution,
will change. That is true. That does not mean that your machine
has to be known as localhost.localdomain.
By your arguments it appears that you imagine that a machine with
multiple network interfaces is an instant disaster. Surprise!
There are many like that around.
And if that previous address is still resolvable via dns (think vpn
access back to the home) you're now overriding dns which is wrong.
You do not have "that previous address" now. You kept a displayed
name. This is how it works with currently existing laptops for
years and years. If you called it jesse.keating.box then this is
how it will look from a prompt does not matter where you will go
with it.
The work around I had was to set hostname up once, resolve it to
127.0.0.1 and call it a day.
You are missing the point. This is not an issue for a laptop or
if you have two boxes around. That is a great headache if you are
launching few hundreds clients on a network and they are not going
anywhere, because they are part of a big lab or nodes in a cluster,
and all report that they are called 'localhost.localdomain'. And
no - pre-assigning fixed names is not feasible or desirable. If you
do not want to see a name of your machine to "float" then you just
assign one to it from the very beginning. It is that simple.
Michal
1:12 p.m.
On Wed, 2008-11-12 at 12:00 -0700, Michal Jaegermann wrote:
And that problem is? How this is different if you would always set
a name of that machine to jesse.keating.box? Nowhere says that what
is returned by 'hostname' needs really be the same what a name
resolution will return. Moreover machines very often have multiple
names, even with a single network interface, although 'hostname'
will show the only one.
The problem is that various pieces of software would bind to what was
returned by 'hostname', or to the IP address that was resolved out of
querying the hostname. And when either the hostname changes, or the
result of querying the hostname changes, those pieces of software broke.
> Either your hostname would have to change, or the hosts entry for what
> it resolved to would have to change, because your address is changing.
Your name to the outside world, are returned by a name resolution,
will change. That is true. That does not mean that your machine
has to be known as localhost.localdomain.
Nobody said it has to be known as that. You're free to name your
machine whatever you want. Automatically naming it (and changing it)
based on DHCP returns isn't exactly the "right" thing to do all the
time.
By your arguments it appears that you imagine that a machine with
multiple network interfaces is an instant disaster. Surprise!
There are many like that around.
Not at all. My arguments are that when you set and change your hostname
to reflect whatever dhcp results of the moment you're getting (which is
what has happened with the good ole "network" service) things can and do
break. It's not a good scenario to be in.
> And if that previous address is still resolvable via dns (think vpn
> access back to the home) you're now overriding dns which is wrong.
You do not have "that previous address" now. You kept a displayed
name. This is how it works with currently existing laptops for
years and years. If you called it jesse.keating.box then this is
how it will look from a prompt does not matter where you will go
with it.
> The work around I had was to set hostname up once, resolve it to
> 127.0.0.1 and call it a day.
You are missing the point. This is not an issue for a laptop or
if you have two boxes around. That is a great headache if you are
launching few hundreds clients on a network and they are not going
anywhere, because they are part of a big lab or nodes in a cluster,
and all report that they are called 'localhost.localdomain'. And
no - pre-assigning fixed names is not feasible or desirable. If you
do not want to see a name of your machine to "float" then you just
assign one to it from the very beginning. It is that simple.
In a lab such as that, it is quite trivial to use %pre to determine an
appropriate automatic hostname to use and set it within the kickstart
with %include.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
1:26 p.m.
On Wed, Nov 12, 2008 at 11:12:35AM -0800, Jesse Keating wrote:
My arguments are that when you set and change your hostname
to reflect whatever dhcp results of the moment
Somebody has serious problems with a reading comprehension.
I stressed many times that "dhcp results of the moment" is not
on the table here.
In a lab such as that, it is quite trivial to use %pre to determine
an
appropriate automatic hostname to use and set it within the kickstart
with %include.
No comment!
Michal
11:43 a.m.
On Tue, Nov 11, 2008 at 09:00:50AM -0800, Jesse Keating wrote:
There are very few reasons and less each release to revert to the
'network' service.
Apart from such details like
https://bugzilla.redhat.com/show_bug.cgi?id=464417
That admittedly was closed on "2008-10-03 18:35:51 EDT" - roughly
a week ago. I did not have yet a chance to try that it really works
as advertised in all circumstances. If that is really fixed, and
will not reapper, then it would be great.
I believe that those heavily burned by NM in the past are still shy.
Michal
1:02 p.m.
On Tuesday 11 November 2008 17:00:50 Jesse Keating wrote:
On Tue, 2008-11-11 at 08:43 +0000, Tony Molloy wrote:
> For a wired connection run the network service and disable the
> NetworkManager
> service.
This is just bad advice. Unless you need ipv6, or need advanced
networking features such as bridges, or are setting up a headless system
with static networking, NetworkManager is fine for both wireless and
wired. NetworkManager can have system wide connections configured that
will be brought up at boot time, both dhcp or static.
For the OPs laptop case, NM is even better as you can go from one
location where you're using wireless to another location, plug in a wire
and NetworkManager will automatically attempt to get an address from
that wire and allow you to use the wired network.
There are very few reasons and less each release to revert to the
'network' service.
Jesse, system-config-network worries me. The hardware tab tells me that my
wired connection, Realtek 8101E, is eth1, but the devices tab says that it is
eth0. I see there is a network script for ifcfg-eth0, but not eth1, so I
guess that's the correct (as well as logical) one.
Unless you have some ideas on something that I can manually edit to deal with
this, I guess I need to file a bug.
Anne
2:20 p.m.
On Tue, 2008-11-11 at 19:02 +0000, Anne Wilson wrote:
Jesse, system-config-network worries me. The hardware tab tells me
that my
wired connection, Realtek 8101E, is eth1, but the devices tab says that it is
eth0. I see there is a network script for ifcfg-eth0, but not eth1, so I
guess that's the correct (as well as logical) one.
Unless you have some ideas on something that I can manually edit to deal with
this, I guess I need to file a bug.
Forgive me, but what is the desired outcome of your configuration?
Hopefully you can achieve that without having to invoke
system-config-network.
System-config-network is (mostly) for dealing with the old "network"
service. NetworkManager has it's own config integrated to the applet
that will allow you do to things such as setup (multiple) static
configurations for your wired or wireless interfaces and choose between
them on the fly using the applet, as well as have one system config that
is applied at boot time (not after login, at boot time).
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
2:52 p.m.
On Tuesday 11 November 2008 20:20:48 Jesse Keating wrote:
On Tue, 2008-11-11 at 19:02 +0000, Anne Wilson wrote:
> Jesse, system-config-network worries me. The hardware tab tells me that
> my wired connection, Realtek 8101E, is eth1, but the devices tab says
> that it is eth0. I see there is a network script for ifcfg-eth0, but not
> eth1, so I guess that's the correct (as well as logical) one.
>
> Unless you have some ideas on something that I can manually edit to deal
> with this, I guess I need to file a bug.
Forgive me, but what is the desired outcome of your configuration?
Hopefully you can achieve that without having to invoke
system-config-network.
System-config-network is (mostly) for dealing with the old "network"
service. NetworkManager has it's own config integrated to the applet
that will allow you do to things such as setup (multiple) static
configurations for your wired or wireless interfaces and choose between
them on the fly using the applet, as well as have one system config that
is applied at boot time (not after login, at boot time).
Jesse, I don't care which route we go - NM is fine if we can persuade it to
work.
All I want is a fixed address when on my home LAN - and I'll accept reserved
IP from my router's dhcp if that's easiest - and straight dhcp for the wifi,
since that will be used at various locations.
Since trying to get the cabled connection working properly (and it's working
now, but not on my chosen IP address) I have lost the wifi altogether, so if
you can advise me how to start from scratch that would probably be best.
Anne
4:47 p.m.
On Tue, 2008-11-11 at 20:52 +0000, Anne Wilson wrote:
Jesse, I don't care which route we go - NM is fine if we can
persuade it to
work.
All I want is a fixed address when on my home LAN - and I'll accept reserved
IP from my router's dhcp if that's easiest - and straight dhcp for the wifi,
since that will be used at various locations.
Since trying to get the cabled connection working properly (and it's working
now, but not on my chosen IP address) I have lost the wifi altogether, so if
you can advise me how to start from scratch that would probably be best.
Well, I'd re-edit your ifcfg-eth* files and set them all back to
NM_CONTROLLED=yes. Also, I'd question why you have an eth1 file, and
perhaps remove it, if all you have is a wired and wireless. Make sure
the eth0 file still matches the right MAC address etc..
Then in NetworkManager you can right click the panel and edit
connections. There you should be able to define a configuration for
System eth0 complete with static addressing. This in theory should
allow it to come up at boot time with this static address and be fine.
As to why your wireless went away, that's a different matter. Might be
worth booting a Live image and seeing if it makes any difference by
having fresh configurations in place.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
8:41 p.m.
Jesse Keating <jkeating(a)redhat.com> wrote:
On Tue, 2008-11-11 at 20:52 +0000, Anne Wilson wrote:
> Jesse, I don't care which route we go - NM is fine if we can
persuade
> it to work.
> All I want is a fixed address when on my home LAN - and I'll
accept
> reserved IP from my router's dhcp if that's easiest - and straight dhcp
> for the wifi, since that will be used at various locations.
> Since trying to get the cabled connection working properly (and
it's
> working now, but not on my chosen IP address) I have lost the wifi
> altogether, so if you can advise me how to start from scratch that
> would probably be best.
Similar to my needs. I've got a fixed wired address (static, _no_ DHCP) at
work, and use WiFi elsewhere.
Well, I'd re-edit your ifcfg-eth* files and set them all back to
NM_CONTROLLED=yes.
No such files here (just ifcfg-lo).
Also, I'd question why you have an eth1 file,
and
perhaps remove it, if all you have is a wired and wireless. Make sure
the eth0 file still matches the right MAC address etc..
Then in NetworkManager you can right click the panel and edit
connections. There you should be able to define a configuration for
System eth0 complete with static addressing. This in theory should
allow it to come up at boot time with this static address and be fine.
No, it doesn't. The static configuration gets lost each time.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
11:56 p.m.
On Tue, 2008-11-11 at 23:41 -0300, Horst H. von Brand wrote:
> Then in NetworkManager you can right click the panel and edit
> connections. There you should be able to define a configuration for
> System eth0 complete with static addressing. This in theory should
> allow it to come up at boot time with this static address and be fine.
No, it doesn't. The static configuration gets lost each time.
Yah that sounds like a bug. I'll run through this scenario on rawhide
tomorrow and verify that it's working as expected.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
4:24 a.m.
On Tuesday 11 November 2008 22:47:53 Jesse Keating wrote:
On Tue, 2008-11-11 at 20:52 +0000, Anne Wilson wrote:
> Jesse, I don't care which route we go - NM is fine if we can persuade it
> to work.
>
> All I want is a fixed address when on my home LAN - and I'll accept
> reserved IP from my router's dhcp if that's easiest - and straight dhcp
> for the wifi, since that will be used at various locations.
>
> Since trying to get the cabled connection working properly (and it's
> working now, but not on my chosen IP address) I have lost the wifi
> altogether, so if you can advise me how to start from scratch that would
> probably be best.
Well, I'd re-edit your ifcfg-eth* files and set them all back to
NM_CONTROLLED=yes.
Done.
Also, I'd question why you have an eth1 file, and
perhaps remove it, if all you have is a wired and wireless.
There is no such file. It's just that system-config-network referred to eth1
- which is one of the things I found confusing. Also ifconfig refers to eth1
- although it is picking up the address. However, since that address is set
both in NM and on the router's dhcp I don't know which is prevailing.
Make sure
the eth0 file still matches the right MAC address etc..
No MAC address is set. Unless there's an advantage, I'll think about that
later.
Then in NetworkManager you can right click the panel and edit
connections. There you should be able to define a configuration for
System eth0 complete with static addressing. This in theory should
allow it to come up at boot time with this static address and be fine.
As to why your wireless went away, that's a different matter.
Might be
worth booting a Live image and seeing if it makes any difference by
having fresh configurations in place.
That at least is solved - it seems I had accidentally moved a physical switch,
whose existence I had completely forgotten.
However, I can't connect to the wireless. I believe I read of something
similar in one of the bug reports, though this morning I've failed to find the
right one.
First it offers me the chance to connect to hidden networks. I give it the
ESSID, set it to WPA and give it the passphrase. It whirs for a while, then a
dialogue box opens asking me to give a WEP key. I'll continue searching for
the bug report and hope that it gives me a workaround
Anne
11:59 a.m.
On Wed, Nov 12, 2008 at 10:24:21AM +0000, Anne Wilson wrote:
However, since that address is set
both in NM and on the router's dhcp I don't know which is prevailing.
You should not reserve an address for an interface on your DHCP
server and at the same time attempt to give it a specific address.
It will get one anyway but in a DHCP lease. Maybe this is causing
an appearance of this "ghost" eth1 interface which you are talking
about?
In any case if an interface is configured to use DHCP then any
specific address assignments in its configuration file are ignored
(or at least they should be).
OTOH I recall that on some occassion NetworkMangler crashed on me
and later it was so entangled in its own junk that it could not find
a way out. That will be that bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=413281
See in particular comments #10 and #11 how I eventually forced it to
find correct interfaces as otherwise NM was terminally lost. I have
no idea if this still applies. In case that it does then reopen the
bug.
Michal
1 p.m.
On Wednesday 12 November 2008 17:59:17 Michal Jaegermann wrote:
On Wed, Nov 12, 2008 at 10:24:21AM +0000, Anne Wilson wrote:
> However, since that address is set
> both in NM and on the router's dhcp I don't know which is prevailing.
You should not reserve an address for an interface on your DHCP
server and at the same time attempt to give it a specific address.
It will get one anyway but in a DHCP lease. Maybe this is causing
an appearance of this "ghost" eth1 interface which you are talking
about?
In any case if an interface is configured to use DHCP then any
specific address assignments in its configuration file are ignored
(or at least they should be).
OTOH I recall that on some occassion NetworkMangler crashed on me
and later it was so entangled in its own junk that it could not find
a way out. That will be that bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=413281
See in particular comments #10 and #11 how I eventually forced it to
find correct interfaces as otherwise NM was terminally lost. I have
no idea if this still applies. In case that it does then reopen the
bug.
Progress, of a sort. Following your lead I renamed ~/.gconf then created a
new connection. It now tells me that I am connected to myESSID at 0%, and of
course I have no internet connection on it. That sounds to me as though it
has found the signal and latched on to it, but failed to pass my key.
What the !!!! According to the info panel it has an IP address of 10.42.45.1 -
when the rest of the lan is 192.168.0.x. Where the heck did that come from?
Anne
1:10 p.m.
On Wed, Nov 12, 2008 at 07:00:38PM +0000, Anne Wilson wrote:
> That will be that bug report:
> https://bugzilla.redhat.com/show_bug.cgi?id=413281
> See in particular comments #10 and #11 how I eventually forced it to
> find correct interfaces as otherwise NM was terminally lost.
>
Progress, of a sort. Following your lead I renamed ~/.gconf
That sounds somewhat excessive. In ~/.gconf you possibly have quite
a bit of other information and not only NM connections. I have
thrown away only NM specific parts and restarted.
What the !!!!
According to the info panel it has an IP address of 10.42.45.1 -
when the rest of the lan is 192.168.0.x. Where the heck did that come from?
Are you connecting to an access point of your neighbour? With all
SSIDs around straight from factory that is not unthinkable. :-) If
not how you configured your router?
Michal
1:56 p.m.
On Wednesday 12 November 2008 19:10:32 Michal Jaegermann wrote:
On Wed, Nov 12, 2008 at 07:00:38PM +0000, Anne Wilson wrote:
> > That will be that bug report:
> > https://bugzilla.redhat.com/show_bug.cgi?id=413281
> > See in particular comments #10 and #11 how I eventually forced it to
> > find correct interfaces as otherwise NM was terminally lost.
>
> Progress, of a sort. Following your lead I renamed ~/.gconf
That sounds somewhat excessive. In ~/.gconf you possibly have quite
a bit of other information and not only NM connections. I have
thrown away only NM specific parts and restarted.
By renaming I can get back anything that is needed.
> What the !!!!
> According to the info panel it has an IP address of 10.42.45.1 -
> when the rest of the lan is 192.168.0.x. Where the heck did that come
> from?
Are you connecting to an access point of your neighbour? With all
SSIDs around straight from factory that is not unthinkable. :-) If
not how you configured your router?
No, I don't see that at all. I gave it the ESSID and passphrase for my
router. I don't see how that could possibly pick up my neighbour's
connection. The info popup definitely named my ESSID.
I've had it for tonight. Maybe one of us will have a brainwave overnight.
Anne
1:10 p.m.
Somehow my reply got split into two messages, so here is the other half
On Wednesday 12 November 2008 17:59:17 Michal Jaegermann wrote:
On Wed, Nov 12, 2008 at 10:24:21AM +0000, Anne Wilson wrote:
> However, since that address is set
> both in NM and on the router's dhcp I don't know which is prevailing.
You should not reserve an address for an interface on your DHCP
server and at the same time attempt to give it a specific address.
It will get one anyway but in a DHCP lease. Maybe this is causing
an appearance of this "ghost" eth1 interface which you are talking
about?
I doubt it, because it was so before I reserved an address on the router.
Today I found in dmesg that
udev: renamed network interface eth0 to eth1.
I didn't see anything that amounted to a reason for that.
In any case if an interface is configured to use DHCP then any
specific address assignments in its configuration file are ignored
(or at least they should be).
The wired interface is set to static, and appears to be working fine now.
It's the wireless that is using dhcp (or would be, if I could connect) and
it's for that interface that I've reserved an address.
OTOH I recall that on some occassion NetworkMangler crashed on me
and later it was so entangled in its own junk that it could not find
a way out. That will be that bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=413281
See in particular comments #10 and #11 how I eventually forced it to
find correct interfaces as otherwise NM was terminally lost. I have
no idea if this still applies. In case that it does then reopen the
bug.
Michal
Anne
1:20 p.m.
On Wed, Nov 12, 2008 at 07:10:05PM +0000, Anne Wilson wrote:
Today I found in dmesg that
udev: renamed network interface eth0 to eth1.
I didn't see anything that amounted to a reason for that.
One possibility I can think of that something claims "eth0" name for
an interface with a different MAC that you have and a rename is done
to avoid a conflict.
What that can be and how you got into that state I have no idea.
See, for example, 'man ifrename' how this can be done. You happen
to have something in /etc/iftab? Or maybe somewhere else?
Michal
2 p.m.
On Wednesday 12 November 2008 19:20:29 Michal Jaegermann wrote:
On Wed, Nov 12, 2008 at 07:10:05PM +0000, Anne Wilson wrote:
> Today I found in dmesg that
>
> udev: renamed network interface eth0 to eth1.
>
> I didn't see anything that amounted to a reason for that.
One possibility I can think of that something claims "eth0" name for
an interface with a different MAC that you have and a rename is done
to avoid a conflict.
Can't see how that could be.
What that can be and how you got into that state I have no idea.
See, for example, 'man ifrename' how this can be done. You happen
to have something in /etc/iftab? Or maybe somewhere else?
I've never heard of /etc/iftab. There's nothing strange about my setup,
and
this laptop, sitting next to the one in question, is connected by wireless,
currently as 192.168.0.2 - so the right subnet addresses are being handed out.
It's a total mystery as to where it's getting the other address from.
Anne
4:27 a.m.
On Tuesday 11 November 2008 22:47:53 Jesse Keating wrote:
On Tue, 2008-11-11 at 20:52 +0000, Anne Wilson wrote:
> Jesse, I don't care which route we go - NM is fine if we can persuade it
> to work.
>
> All I want is a fixed address when on my home LAN - and I'll accept
> reserved IP from my router's dhcp if that's easiest - and straight dhcp
> for the wifi, since that will be used at various locations.
>
> Since trying to get the cabled connection working properly (and it's
> working now, but not on my chosen IP address) I have lost the wifi
> altogether, so if you can advise me how to start from scratch that would
> probably be best.
Well, I'd re-edit your ifcfg-eth* files and set them all back to
NM_CONTROLLED=yes. Also, I'd question why you have an eth1 file, and
perhaps remove it, if all you have is a wired and wireless. Make sure
the eth0 file still matches the right MAC address etc..
Then in NetworkManager you can right click the panel and edit
connections. There you should be able to define a configuration for
System eth0 complete with static addressing. This in theory should
allow it to come up at boot time with this static address and be fine.
As to why your wireless went away, that's a different matter. Might be
worth booting a Live image and seeing if it makes any difference by
having fresh configurations in place.
Referring back to the eth0/eth1 question, running 'service network status'
gives
Configured devices:
l0 eth0 wlan0
Currently active devices:
lo eth1 wmaster0 wlan0
Thos wmaster0 is something I've not met before.
Anne
6:22 a.m.
On Wednesday 12 November 2008 10:27:12 Anne Wilson wrote:
Referring back to the eth0/eth1 question, running 'service
network status'
gives
Configured devices:
l0 eth0 wlan0
Currently active devices:
lo eth1 wmaster0 wlan0
Thos wmaster0 is something I've not met before.
I get
--------------------------------------------------
[tim@mary GroupRepresentations]$ service network status
Configured devices:
lo eth0 eth1 pan0
Currently active devices:
lo eth0 eth1
--------------------------------------------------
I've no idea who or what pan0 is.
On the general topic of the thread,
I have never had any problem anywhere in making an ethernet connection,
whereas I have had endless problems getting a WiFi connection.
Admittedly NM has been getting better (very slowly) as far as I am concerned -
I find it really annoying when people say NM works perfectly
instead of "NM works perfectly for ME on MY machine with MY WiFi card".
As for "It just works" that makes me want to scream.
In fact on one machine with an Orinoco Classic Gold card
NM actually works much better under F-10 than F-9.
But the fact remains that NM is unforgivably badly documented,
and the vast amount of NM data that fills my /var/log/messages
is almost completely useless as far as I am concerned.
What does "(eth1): device state change: 7 -> 8" mean?
Especially as NM then says
"Activation (eth1) Stage 5 of 5 (IP Configure Commit) complete".
10:53 a.m.
On Wed, 2008-11-12 at 12:22 +0000, Timothy Murphy wrote:
[tim@mary GroupRepresentations]$ service network status
Configured devices:
lo eth0 eth1 pan0
Currently active devices:
lo eth0 eth1
--------------------------------------------------
I've no idea who or what pan0 is.
I had that happen before as well but I have since reinstalled and it
wasn't created this time. Never did figure out why pan0 was there
though.
Anyway, if it helps, gonna post my ifcfg-eth0 file as it works fine with
NM and nothing special really cept it's a static IP.
[mike@scrappy ~]$ more /etc/sysconfig/network-scripts/ifcfg-eth0
# nVidia Corporation MCP61 Ethernet
DEVICE=eth0
BOOTPROTO=none
BROADCAST=192.168.1.255
DNS1=192.168.1.4
GATEWAY=192.168.1.1
HWADDR=00:1b:fc:5e:53:18
IPADDR=192.168.1.3
NETMASK=255.255.255.0
ONBOOT=yes
SEARCH="miketc.net"
TYPE=Ethernet
USERCTL=no
IPV6INIT=no
NM_CONTROLLED=yes
--
Mike Chambers
Fedora Project - Ambassador, Bug Zapper, Tester, User, etc..
mikec302(a)fedoraproject.org
5:48 p.m.
On Wednesday 12 November 2008 04:53:18 pm Mike Chambers wrote:
Anyway, if it helps, gonna post my ifcfg-eth0 file as it works fine
with
NM and nothing special really cept it's a static IP.
IIRC, it used to be said that NM didn't read
/etc/sysconfig/network-scripts/ifcfg-* .
In my case if NM does read these files
it doesn't seem to take much notice of what it reads,
as I have specified the ESSID of the AP I want to link to,
but NM seems to ignore this.
It really would be useful if one knew which files NM looks at.
It's really not good enough to say that this is not needed
because "NM just works".
--
Timothy Murphy
e-mail: gayleard /at/ eircom.net
tel: +353-86-2336090, +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
6:21 p.m.
Timothy Murphy wrote:
On Wednesday 12 November 2008 04:53:18 pm Mike Chambers wrote:
> Anyway, if it helps, gonna post my ifcfg-eth0 file as it works fine with
> NM and nothing special really cept it's a static IP.
IIRC, it used to be said that NM didn't read
/etc/sysconfig/network-scripts/ifcfg-* .
In my case if NM does read these files
it doesn't seem to take much notice of what it reads,
as I have specified the ESSID of the AP I want to link to,
but NM seems to ignore this.
It really would be useful if one knew which files NM looks at.
It's really not good enough to say that this is not needed
because "NM just works".
I agree. While I applaud the concept behind NM, its execution is very,
very flawed. It can't be used on systems that use network-based
authentication because of the chicken-and-egg problem it causes (you
need a desktop for it to start and you can't log in to get a desktop
because the network is down due to NM not running).
Other drawbacks: the utter and complete lack of documentation; the
inability to (consistently) control its behavior via config files
(including its ignoring of existing directives in files it claims to
read); its apparent random selection of nearby wireless access points;
occasional ignoring of existing keyring entries; its inability to be
started prior to a user logging in--and then only if the system is
in GUI mode; the list goes on.
I like the idea. It's just nowhere ready for prime time in anything
but the absolute simplest of network environments with GUI-based
systems. I realize that Fedora is where things like this get the bugs
shaken out, but NM has been a problem child for quite a while (F8, F9
and now F10). Anaconda should at least ask you if you want NM as the
default network environment when upgrading or installing (it certainly
shouldn't run roughshod over an existing network environment). On top
of that and given its, uhm, "maturity", you'd think there'd at least be
a bloody man page for it!
That's just my opinion. I could be wrong.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer ricks(a)nerd.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- "Men occasionally stumble over the truth, but most of them pick" -
- themselves up and hurry off as if nothing had happened." -
- -- Winston Churchill -
----------------------------------------------------------------------
6:37 p.m.
On Wed, 2008-11-12 at 16:21 -0800, Rick Stevens wrote:
I agree. While I applaud the concept behind NM, its execution is
very,
very flawed. It can't be used on systems that use network-based
authentication because of the chicken-and-egg problem it causes (you
need a desktop for it to start and you can't log in to get a desktop
because the network is down due to NM not running).
Blatantly wrong. NetworkManager service starts well before the desktop
login, and will bring up any "system" configured connections.
Other drawbacks: the utter and complete lack of documentation;
$ rpm -qd NetworkManager
/usr/share/doc/NetworkManager-0.7.0/AUTHORS
/usr/share/doc/NetworkManager-0.7.0/CONTRIBUTING
/usr/share/doc/NetworkManager-0.7.0/COPYING
/usr/share/doc/NetworkManager-0.7.0/ChangeLog
/usr/share/doc/NetworkManager-0.7.0/NEWS
/usr/share/doc/NetworkManager-0.7.0/README
/usr/share/doc/NetworkManager-0.7.0/TODO
/usr/share/man/man1/nm-tool.1.gz
/usr/share/man/man8/NetworkManager.8.gz
the
inability to (consistently) control its behavior via config files
(including its ignoring of existing directives in files it claims to
read);
Do you have specific bugs filed for specific cases where it's ignoring
things it's supposed to be reading?
its apparent random selection of nearby wireless access points;
Again, bugs? AFAIKT it doesn't pick any until /you/ pick one to join,
and then it'll re-join that one if it notices it's available and you're
not connected to anything else at the time.
occasional ignoring of existing keyring entries;
Bugs filed?
its inability to be
started prior to a user logging in--and then only if the system is
in GUI mode; the list goes on.
Again, very very wrong.
I like the idea. It's just nowhere ready for prime time in anything
but the absolute simplest of network environments with GUI-based
systems. I realize that Fedora is where things like this get the bugs
shaken out, but NM has been a problem child for quite a while (F8, F9
and now F10). Anaconda should at least ask you if you want NM as the
default network environment when upgrading or installing (it certainly
shouldn't run roughshod over an existing network environment). On top
of that and given its, uhm, "maturity", you'd think there'd at least
be
a bloody man page for it!
See the rpm output from above.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
9:30 p.m.
On Wed, Nov 12, 2008 at 7:37 PM, shmuel siegel
<fedora(a)shmuelhome.mine.nu> wrote:
Jesse Keating wrote:
> NetworkManager service starts well before the desktop
> login, and will bring up any "system" configured connections.
I seemed to have missed some documentation. Is there a way to attach to my
WPA encrypted wireless without logging in first?
ding-ding-ding. Yep, file that under
just-becuase-Windows-does-this-does-not-mean-we-have-to!
Forget that remote ssh access you thought you'd have to the laptop at
home with the latest changes you brilliantly coded at home last night.
jerry
--
There's plenty of youth in America - it's time we find the "fountain of
smart".
4:33 a.m.
On Thu, Nov 13, 2008 at 03:37:08AM +0200, shmuel siegel wrote:
Jesse Keating wrote:
> ....
> NetworkManager service starts well before the desktop
> login, and will bring up any "system" configured connections.
>
>
I seemed to have missed some documentation. Is there a way to attach to
my WPA encrypted wireless without logging in first?
No. Moreover, patches to current initscripts to cater for at least one
common scenario are being rejected because they're "not generic enough".
So instead of having it working in some cases (I'd argue: most), we have
it not working at all.
Regards,
R.
--
Dominik 'Rathann' Mierzejewski <rathann*at*icm.edu.pl> | LAN Staff
Interdisciplinary Centre for Mathematical and Computational Modelling
Warsaw University | http://www.icm.edu.pl | tel. +48 (22) 5540810
11:51 a.m.
On Thu, 2008-11-13 at 03:37 +0200, shmuel siegel wrote:
I seemed to have missed some documentation. Is there a way to attach
to
my WPA encrypted wireless without logging in first?
This is one place that is in need of documentation.
Yes, you can, it's not super friendly to do it, but then again neither
was the old way of doing this.
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00900....
This is actually a pretty good thread that touches on a lot of what is
likely interesting to those on this thread, NetworkManager and more
"server" mode of operation than desktop.
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00863.... starts
talking about NetworkManager about there. A goodly amount of FUD is thrown around and
then Dan Williams answers a lot of questions clearing the air.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
1:23 p.m.
On Thu, Nov 13, 2008 at 09:51:03AM -0800, Jesse Keating wrote:
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00863....
starts talking about NetworkManager about there. A goodly amount
of FUD is thrown around and then Dan Williams answers a lot of
questions clearing the air.
And what that FUD will be? This detail that NM was fixed rather
recently to handle static connections and not everybody is yet aware
of this? NM was screwing here a big time so I am not surprised that
there is no big rush to try again.
I looked through all this thread and it follows from it that NM,
after a really long wait, slowly becomes a tool which has some
chance to be usable beyond a basic "one user - one computer - one
network connection (and maybe some wifi on the top)" situation
although clearly it is still not there; but obviously much closer
than it used to be.
OTOH Dan Williams also says there: "I tend to think there will be a
place for manual network configuration for a long time (no matter
what jeremy says :), because there are some situations that are just
too borderline to support in the short term, or are sufficiently
borderline that the maintenance cost of adding the feature outweighs
the benefit of the feature in the first place. There's always a
tradeoff to feature addition". So, luckily, he is not such gung ho
as Jesse. :-)
Michal
1:36 p.m.
On Thu, Nov 13, 2008 at 12:23:27PM -0700, Michal Jaegermann wrote:
On Thu, Nov 13, 2008 at 09:51:03AM -0800, Jesse Keating wrote:
>
> https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00863....
> starts talking about NetworkManager about there. A goodly amount
> of FUD is thrown around and then Dan Williams answers a lot of
> questions clearing the air.
And what that FUD will be? This detail that NM was fixed rather
recently to handle static connections and not everybody is yet aware
of this? NM was screwing here a big time so I am not surprised that
there is no big rush to try again.
Given the definition of "FUD" as "Fear, Uncertainty, Doubt",
that's
what arises when there is little to no documentation. BTW, NM was
fixed for F9 to support multiple simultaneous active connections and
static configurations.
I looked through all this thread and it follows from it that NM,
after a really long wait, slowly becomes a tool which has some
chance to be usable beyond a basic "one user - one computer - one
network connection (and maybe some wifi on the top)" situation
although clearly it is still not there; but obviously much closer
than it used to be.
OTOH Dan Williams also says there: "I tend to think there will be a
place for manual network configuration for a long time (no matter
what jeremy says :), because there are some situations that are just
too borderline to support in the short term, or are sufficiently
borderline that the maintenance cost of adding the feature outweighs
the benefit of the feature in the first place. There's always a
tradeoff to feature addition". So, luckily, he is not such gung ho
as Jesse. :-)
I think the biggest problem we have now is missing documentation. If
only things would be documented as they were developed, rather than
long after or never.
2:46 p.m.
On Thu, 2008-11-13 at 14:36 -0500, Chuck Anderson wrote:
I think the biggest problem we have now is missing documentation. If
only things would be documented as they were developed, rather than
long after or never.
If only people would volunteer to help with documenting the software,
instead of demanding that documentation show up, instead of bugs being
fixed.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
4 p.m.
Jesse Keating wrote:
On Thu, 2008-11-13 at 14:36 -0500, Chuck Anderson wrote:
> I think the biggest problem we have now is missing documentation. If
> only things would be documented as they were developed, rather than
> long after or never.
If only people would volunteer to help with documenting the software,
instead of demanding that documentation show up, instead of bugs being
fixed.
Since I'm the one that really whined about the lack of documentation,
I'm willing to help where I can. However (and I suspect this may be the
case with many potential volunteers), the only way one can document
adequately is to know how it's supposed to work.
Obviously I'm on the outside looking in, so I haven't seen a statement
of work, requirements document, functional spec or anything that would
preclude a foray into the source to dig that information out. I am a
qualified C/C++ programmer and can probably tunnel my way through the
source, but many probably can't and rather depend on the developer to
provide documentation.
I've been through the items in /usr/share/doc/NetworkManager-xxx and
while the README explains (in general terms) what it's supposed to do,
it says very little about HOW it does it (which files it scans, what the
various options in the files might mean and so on).
If you would like, I will try to take on the documentation task. My
time is limited (as I'm sure yours is) and this would definitely be a
sideline thing for me, but I'm willing to "put my money where my whining
is". I can try to do a decent man page and possibly an illustrative
texinfo tree.
Please feel free to contact me off-list.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer ricks(a)nerd.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- If at first you don't succeed, quit. No sense being a damned fool! -
----------------------------------------------------------------------
4:56 p.m.
On Thu, 2008-11-13 at 14:46, Jesse Keating wrote:
If only people would volunteer to help with documenting the
software,
instead of demanding that documentation show up, instead of bugs being
fixed.
That really isn't fair. It's a chicken and the egg problem in that the
only way someone outside could write documentation is if someone inside
gives them some rudimentary documentation first. After all, by your
reasoning anyone skilled enough to read the source should be adding
features and fixing bugs so apparently that route to knowledge is out.
Outside help can clean up documentation, enhance documentation, take
manpage level documentation and write detailed howtos for mortal users
to follow. If they have some help from the developers they can even
update documentation to track changes. Waiting for someone to appear
and present documentation from scratch for a system that nobody outside
the development team has knowledge of is asking for a miracle.
--
John M. http://www.beau.org/~jmorris This post is 100% M$Free!
Geekcode 3.1:GCS C+++ UL++++$ P++ L+++ W++ w--- Y++ b++ 5+++ R tv- e* r
5:22 p.m.
On Thu, 2008-11-13 at 16:56 -0600, John Morris wrote:
That really isn't fair. It's a chicken and the egg problem
in that the
only way someone outside could write documentation is if someone inside
gives them some rudimentary documentation first. After all, by your
reasoning anyone skilled enough to read the source should be adding
features and fixing bugs so apparently that route to knowledge is out.
Outside help can clean up documentation, enhance documentation, take
manpage level documentation and write detailed howtos for mortal users
to follow. If they have some help from the developers they can even
update documentation to track changes. Waiting for someone to appear
and present documentation from scratch for a system that nobody outside
the development team has knowledge of is asking for a miracle.
Outside people can create lists of things they'd like to see documented,
create questions for the developer to answer, prepare shells of
documentation that need details filled in, and talk with the developer
to get that information. That would go a lot farther to having good
documentation than lamenting the fact that none exists and doing nothing
about it.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
10:28 p.m.
On Thu, Nov 13, 2008 at 5:22 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
On Thu, 2008-11-13 at 16:56 -0600, John Morris wrote:
> That really isn't fair. It's a chicken and the egg problem in that the
> only way someone outside could write documentation is if someone inside
> gives them some rudimentary documentation first. After all, by your
> reasoning anyone skilled enough to read the source should be adding
> features and fixing bugs so apparently that route to knowledge is out.
>
> Outside help can clean up documentation, enhance documentation, take
> manpage level documentation and write detailed howtos for mortal users
> to follow. If they have some help from the developers they can even
> update documentation to track changes. Waiting for someone to appear
> and present documentation from scratch for a system that nobody outside
> the development team has knowledge of is asking for a miracle.
Outside people can create lists of things they'd like to see documented,
create questions for the developer to answer, prepare shells of
documentation that need details filled in, and talk with the developer
to get that information. That would go a lot farther to having good
documentation than lamenting the fact that none exists and doing nothing
about it.
I propose that this 82 message thread covers those items.
Yet, the insiders are telling everyone else that all is right in nm world.
Whatever. For the record, I see the potential, and it's good, but
thus far this thread is the voice of the masses falling of deaf ears,
and that's bad.
jerry
--
There's plenty of youth in America - it's time we find the "fountain of
smart".
11:31 p.m.
On Thu, 2008-11-13 at 22:28 -0600, Jerry Amundson wrote:
I propose that this 82 message thread covers those items.
Yet, the insiders are telling everyone else that all is right in nm world.
Whatever. For the record, I see the potential, and it's good, but
thus far this thread is the voice of the masses falling of deaf ears,
and that's bad.
Can you give me actual examples of where I said everything was all
right? Can you give me examples where the valid complaints of the users
are falling on my deaf ears? Can you give me examples of where I'm not
being helpful to those trying to use NetworkManager, or providing
information to those who have stopped using it due to past experiences?
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
12:14 a.m.
On Thu, Nov 13, 2008 at 11:31 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
On Thu, 2008-11-13 at 22:28 -0600, Jerry Amundson wrote:
> I propose that this 82 message thread covers those items.
> Yet, the insiders are telling everyone else that all is right in nm world.
>
> Whatever. For the record, I see the potential, and it's good, but
> thus far this thread is the voice of the masses falling of deaf ears,
> and that's bad.
Can you give me actual examples of where I said everything was all
right? Can you give me examples where the valid complaints of the users
are falling on my deaf ears? Can you give me examples of where I'm not
being helpful to those trying to use NetworkManager, or providing
information to those who have stopped using it due to past experiences?
Gladly. Hope you take criticism well. I know I have to in my job...
On Tue, Nov 11, 2008 at 11:00 AM, Jesse Keating <jkeating(a)redhat.com> wrote:
On Tue, 2008-11-11 at 08:43 +0000, Tony Molloy wrote:
> For a wired connection run the network service and disable the
> NetworkManager
> service.
This is just bad advice.
When, in fact, this is exactly what has been needed at times for a
functional network, states plainly, "I'm not listening".
On Tue, Nov 11, 2008 at 2:18 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
On Tue, 2008-11-11 at 12:36 -0500, Steve Thompson wrote:
> So NetworkManager now knows how to set the hostname properly?
Now that all depends on your definition of properly. There are cases
where changing the hostname of a running system will break other running
software. It's not a perfect world, neither option is that great.
That's not helpful. Change the f(*&ing hostname if that's what we've
asked it to do.
On Tue, Nov 11, 2008 at 2:20 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
On Tue, 2008-11-11 at 19:02 +0000, Anne Wilson wrote:
> Jesse, system-config-network worries me. The hardware tab tells me that my
> wired connection, Realtek 8101E, is eth1, but the devices tab says that it is
> eth0. I see there is a network script for ifcfg-eth0, but not eth1, so I
> guess that's the correct (as well as logical) one.
>
> Unless you have some ideas on something that I can manually edit to deal with
> this, I guess I need to file a bug.
Forgive me, but what is the desired outcome of your configuration?
Hopefully you can achieve that without having to invoke
system-config-network.
In other words, everything is OK here in nm world. You must be trying
some bizarre corner case you silly goose.
On Tue, Nov 11, 2008 at 4:43 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
On Tue, 2008-11-11 at 17:18 -0500, Steve Thompson wrote:
> Point taken. However, I have been setting hostnames via DHCP for years
> (both Fedora and CentOS on over 300 machines), and have never had anything
> break because of it (not one single breakage of any kind).
While on the other hand, I would constantly have X break, no new windows
could launch, audio break, not able to re-connect to the daemon, so on
and so forth. It's an imperfect system.
In other words, we didn't design it for that, so we don't expect it to
work, you're doing something wrong.
On Tue, Nov 11, 2008 at 4:47 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
On Tue, 2008-11-11 at 20:52 +0000, Anne Wilson wrote:
> Jesse, I don't care which route we go - NM is fine if we can persuade it to
> work.
>
> All I want is a fixed address when on my home LAN - and I'll accept reserved
> IP from my router's dhcp if that's easiest - and straight dhcp for the wifi,
> since that will be used at various locations.
>
> Since trying to get the cabled connection working properly (and it's working
> now, but not on my chosen IP address) I have lost the wifi altogether, so if
> you can advise me how to start from scratch that would probably be best.
Well, I'd re-edit your ifcfg-eth* files and set them all back to
NM_CONTROLLED=yes. Also, I'd question why you have an eth1 file, and
You're not questioning, you're implying - implying that the user has
done something wrong, when, in all likelihood. it's just THE WAY NM
HAS SET IT UP.
On Tue, Nov 11, 2008 at 11:56 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
On Tue, 2008-11-11 at 23:41 -0300, Horst H. von Brand wrote:
>
> > Then in NetworkManager you can right click the panel and edit
> > connections. There you should be able to define a configuration for
> > System eth0 complete with static addressing. This in theory should
> > allow it to come up at boot time with this static address and be fine.
>
> No, it doesn't. The static configuration gets lost each time.
Yah that sounds like a bug. I'll run through this scenario on rawhide
tomorrow and verify that it's working as expected.
Did you? Does it? bz number?
I was wrong - this thread is closer to 100 messages than 82.
I've been involved in open source projects long enough not to expect
insiders to admit they're wrong, but I should think you would at least
be open minded.
jerry
--
There's plenty of youth in America - it's time we find the "fountain of
smart".
1:11 a.m.
On Friday 14 November 2008 06:14:31 Jerry Amundson wrote:
> Well, I'd re-edit your ifcfg-eth* files and set them all
back to
> NM_CONTROLLED=yes. Also, I'd question why you have an eth1 file, and
You're not questioning, you're implying - implying that the user has
done something wrong, when, in all likelihood. it's just THE WAY NM
HAS SET IT UP.
<quote>
dmesg:
udev: renamed network interface eth0 to eth1.
</quote>
No reason visible
Anne
11:42 a.m.
Anne Wilson (cannewilson(a)googlemail.com) said:
<quote>
dmesg:
udev: renamed network interface eth0 to eth1.
</quote>
No reason visible
This is udev, renaming the device based on configuration
in /etc/udev/rules.d/70-persistent-net.rules (written by
anaconda, and updated by udev on device add), or from
the HWADDR field in /etc/sysconfig/network-scripts/ifcfg-XXX
(written by anaconda, or system-config-network, or the user
by hand.)
Bill
1:01 p.m.
On Friday 14 November 2008 17:42:40 Bill Nottingham wrote:
Anne Wilson (cannewilson(a)googlemail.com) said:
> <quote>
> dmesg:
> udev: renamed network interface eth0 to eth1.
> </quote>
>
> No reason visible
This is udev, renaming the device based on configuration
in /etc/udev/rules.d/70-persistent-net.rules (written by
anaconda, and updated by udev on device add), or from
the HWADDR field in /etc/sysconfig/network-scripts/ifcfg-XXX
(written by anaconda, or system-config-network, or the user
by hand.)
But why?
Anne
1:05 p.m.
Anne Wilson (cannewilson(a)googlemail.com) said:
> > <quote>
> > dmesg:
> > udev: renamed network interface eth0 to eth1.
> > </quote>
> >
> > No reason visible
>
> This is udev, renaming the device based on configuration
> in /etc/udev/rules.d/70-persistent-net.rules (written by
> anaconda, and updated by udev on device add), or from
> the HWADDR field in /etc/sysconfig/network-scripts/ifcfg-XXX
> (written by anaconda, or system-config-network, or the user
> by hand.)
But why?
Because modules are loaded in parallel on boot, so interfaces
can come up named different things on each boot depending on
delays, etc. udev is renaming them based on the configuration
in the system so that the devices remain the same from boot
to boot.
Bill
2:27 p.m.
On Friday 14 November 2008 19:05:51 Bill Nottingham wrote:
Anne Wilson (cannewilson(a)googlemail.com) said:
> > > <quote>
> > > dmesg:
> > > udev: renamed network interface eth0 to eth1.
> > > </quote>
> > >
> > > No reason visible
> >
> > This is udev, renaming the device based on configuration
> > in /etc/udev/rules.d/70-persistent-net.rules (written by
> > anaconda, and updated by udev on device add), or from
> > the HWADDR field in /etc/sysconfig/network-scripts/ifcfg-XXX
> > (written by anaconda, or system-config-network, or the user
> > by hand.)
>
> But why?
Because modules are loaded in parallel on boot, so interfaces
can come up named different things on each boot depending on
delays, etc. udev is renaming them based on the configuration
in the system so that the devices remain the same from boot
to boot.
Bill, I've used wireless on other systems for quite a long time, and I've
never come across such a situation.
Anne
2:33 p.m.
Anne Wilson (cannewilson(a)googlemail.com) said:
> > But why?
>
> Because modules are loaded in parallel on boot, so interfaces
> can come up named different things on each boot depending on
> delays, etc. udev is renaming them based on the configuration
> in the system so that the devices remain the same from boot
> to boot.
Bill, I've used wireless on other systems for quite a long time, and I've
never come across such a situation.
Not sure what to say, other than maybe 'you're lucky'? In any
case, it's a generally harmless message that should not affect
functionality - it's just ensuring the device names are consistent
between reboots.
Bill
11:17 a.m.
On Fri, 2008-11-14 at 00:14 -0600, Jerry Amundson wrote:
On Thu, Nov 13, 2008 at 11:31 PM, Jesse Keating
<jkeating(a)redhat.com> wrote:
> On Thu, 2008-11-13 at 22:28 -0600, Jerry Amundson wrote:
>> I propose that this 82 message thread covers those items.
>> Yet, the insiders are telling everyone else that all is right in nm world.
>>
>> Whatever. For the record, I see the potential, and it's good, but
>> thus far this thread is the voice of the masses falling of deaf ears,
>> and that's bad.
>
> Can you give me actual examples of where I said everything was all
> right? Can you give me examples where the valid complaints of the users
> are falling on my deaf ears? Can you give me examples of where I'm not
> being helpful to those trying to use NetworkManager, or providing
> information to those who have stopped using it due to past experiences?
Gladly. Hope you take criticism well. I know I have to in my job...
On Tue, Nov 11, 2008 at 11:00 AM, Jesse Keating <jkeating(a)redhat.com> wrote:
> On Tue, 2008-11-11 at 08:43 +0000, Tony Molloy wrote:
>> For a wired connection run the network service and disable the
>> NetworkManager
>> service.
>
> This is just bad advice.
When, in fact, this is exactly what has been needed at times for a
functional network, states plainly, "I'm not listening".
Not so. The original poster just needed one static wired interface, and
one wireless dynamic interface. This type of situation is very easy to
accomplish with NetworkManager, and over time would be easier to manage
rather than the Network service, particularly because the wireless
interface was involved.
On Tue, Nov 11, 2008 at 2:18 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
> On Tue, 2008-11-11 at 12:36 -0500, Steve Thompson wrote:
>> So NetworkManager now knows how to set the hostname properly?
>
> Now that all depends on your definition of properly. There are cases
> where changing the hostname of a running system will break other running
> software. It's not a perfect world, neither option is that great.
That's not helpful. Change the f(*&ing hostname if that's what we've
asked it to do.
It's not helpful to point out that the desired action you want actually
has in the past and may still break certain scenarios? You can't accept
that just because it works in your use case that it doesn't work in
every use case? I also said it's not a good situation, and what likely
needs to happen is some (god I hate this) extra box to twiddle if you
want to keep your hostname changing depending on what dns says for you.
That way for those that it works they can check it, but for those that
it doesn't, it's really really non-obvious why things just start
failing. It took a lot of deep thinking to realize that changing the
hostname on a running session had dire results.
On Tue, Nov 11, 2008 at 2:20 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
> On Tue, 2008-11-11 at 19:02 +0000, Anne Wilson wrote:
>> Jesse, system-config-network worries me. The hardware tab tells me that my
>> wired connection, Realtek 8101E, is eth1, but the devices tab says that it is
>> eth0. I see there is a network script for ifcfg-eth0, but not eth1, so I
>> guess that's the correct (as well as logical) one.
>>
>> Unless you have some ideas on something that I can manually edit to deal with
>> this, I guess I need to file a bug.
>
> Forgive me, but what is the desired outcome of your configuration?
> Hopefully you can achieve that without having to invoke
> system-config-network.
In other words, everything is OK here in nm world. You must be trying
some bizarre corner case you silly goose.
That's really some odd reading there. I was simply asking the original
poster to re-outline what they wished to accomplish. I hoped that
NetworkManager would cover it, and indeed NetworkManager is supposed to
cover her desired configuration. I was completely willing to admit that
if if she needed something that wasn't possible with NetworkManager that
she shouldn't use it. I really think you're reading my words with a
very odd slant and with as much vindictive as you can possibly muster.
On Tue, Nov 11, 2008 at 4:43 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
> On Tue, 2008-11-11 at 17:18 -0500, Steve Thompson wrote:
>> Point taken. However, I have been setting hostnames via DHCP for years
>> (both Fedora and CentOS on over 300 machines), and have never had anything
>> break because of it (not one single breakage of any kind).
>
> While on the other hand, I would constantly have X break, no new windows
> could launch, audio break, not able to re-connect to the daemon, so on
> and so forth. It's an imperfect system.
In other words, we didn't design it for that, so we don't expect it to
work, you're doing something wrong.
Again you're putting words in my mouth. I was explaining what broke
when hostnames changed. I also said it's an imperfect system in that
the underlying software just wasn't ready to accept that kind of dynamic
changes. Should it be fixed? Sure. Is it fixed already? I don't
know, but it certainly wasn't a priority of the upstreams involved.
Their fix was "don't do that".
On Tue, Nov 11, 2008 at 4:47 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
> On Tue, 2008-11-11 at 20:52 +0000, Anne Wilson wrote:
>> Jesse, I don't care which route we go - NM is fine if we can persuade it to
>> work.
>>
>> All I want is a fixed address when on my home LAN - and I'll accept
reserved
>> IP from my router's dhcp if that's easiest - and straight dhcp for the
wifi,
>> since that will be used at various locations.
>>
>> Since trying to get the cabled connection working properly (and it's
working
>> now, but not on my chosen IP address) I have lost the wifi altogether, so if
>> you can advise me how to start from scratch that would probably be best.
>
> Well, I'd re-edit your ifcfg-eth* files and set them all back to
> NM_CONTROLLED=yes. Also, I'd question why you have an eth1 file, and
You're not questioning, you're implying - implying that the user has
done something wrong, when, in all likelihood. it's just THE WAY NM
HAS SET IT UP.
Again, reading way more into my words than ever intended.
On Tue, Nov 11, 2008 at 11:56 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
> On Tue, 2008-11-11 at 23:41 -0300, Horst H. von Brand wrote:
>>
>> > Then in NetworkManager you can right click the panel and edit
>> > connections. There you should be able to define a configuration for
>> > System eth0 complete with static addressing. This in theory should
>> > allow it to come up at boot time with this static address and be fine.
>>
>> No, it doesn't. The static configuration gets lost each time.
>
> Yah that sounds like a bug. I'll run through this scenario on rawhide
> tomorrow and verify that it's working as expected.
Did you? Does it? bz number?
I did attempt it. I ran into one bug while trying to make the setting
apply to the system and I filed the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471308
I still need to complete the tests, but I got caught up in a minor
emergency related to the release of F10. I'll report more results today
(provided no other fires crop up).
I was wrong - this thread is closer to 100 messages than 82.
I've been involved in open source projects long enough not to expect
insiders to admit they're wrong, but I should think you would at least
be open minded.
I honestly think you're reading what I say in the worst possible way.
That's one of the follies of email, you can't detect tone or attitude,
so it's easy to misinterpret. I am deeply sorry if what I said came
across as the way you seem to have read it. It was not my intention.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
11:35 a.m.
Jerry Amundson (jamundso(a)gmail.com) said:
> Well, I'd re-edit your ifcfg-eth* files and set them all
back to
> NM_CONTROLLED=yes. Also, I'd question why you have an eth1 file, and
You're not questioning, you're implying - implying that the user has
done something wrong, when, in all likelihood. it's just THE WAY NM
HAS SET IT UP.
NM_CONTROLLED is written by system-config-network, in response to
user configuration.
Frankly, I do not understand why it was implemented in the first place,
as configuring a system such that you'd try and have both services
running simultaneously managing different sets of devices is crazy.
Bill
5:47 p.m.
John Morris wrote:
On Thu, 2008-11-13 at 14:46, Jesse Keating wrote:
> If only people would volunteer to help with documenting the software,
> instead of demanding that documentation show up, instead of bugs being
> fixed.
That really isn't fair. It's a chicken and the egg problem in that the
only way someone outside could write documentation is if someone inside
gives them some rudimentary documentation first.
That's not the case. I have written from scratch documentation for
projects where none or almost nothing existed before. You just need to
know the questions, users usually ask and then interact with the
developers to try and answer them. Over a few revisions and reviews, you
can get it right without having to know much if anything to get started.
Admittedly, for something like NetworkManager, it would be a significant
amount of time but if there is a real need, someone should step up and
do it.
Rahul
10:49 p.m.
On Thu, Nov 13, 2008 at 5:47 PM, Rahul Sundaram
<sundaram(a)fedoraproject.org> wrote:
John Morris wrote:
>
> On Thu, 2008-11-13 at 14:46, Jesse Keating wrote:
>
>> If only people would volunteer to help with documenting the software,
>> instead of demanding that documentation show up, instead of bugs being
>> fixed.
>
> That really isn't fair. It's a chicken and the egg problem in that the
> only way someone outside could write documentation is if someone inside
> gives them some rudimentary documentation first.
That's not the case. I have written from scratch documentation for projects
where none or almost nothing existed before. You just need to know the
questions, users usually ask and then interact with the developers to try
and answer them. Over a few revisions and reviews, you can get it right
without having to know much if anything to get started.
Admittedly, for something like NetworkManager, it would be a significant
amount of time but if there is a real need, someone should step up and do
it.
So, what you meant is that *is* the case.
There was a real need, and (some of) the documentation should have
been built in parallel with the development of the feature.
NetworkMangler is an example of how the Fedora user base was abused.
Throw the burden of the QA and documentation cycle out to the rest of
us in the name of open source an creative content.
For the time spent calling my co-worker 1000 miles away to run "ifup
eth0", and for the time it cost us figuring out that's just the way
Fedora 9 networking is, you're welcome.
jerry
--
There's plenty of youth in America - it's time we find the "fountain of
smart".
2:43 p.m.
On Thu, 2008-11-13 at 12:23 -0700, Michal Jaegermann wrote:
OTOH Dan Williams also says there: "I tend to think there will
be a
place for manual network configuration for a long time (no matter
what jeremy says :), because there are some situations that are just
too borderline to support in the short term, or are sufficiently
borderline that the maintenance cost of adding the feature outweighs
the benefit of the feature in the first place. There's always a
tradeoff to feature addition". So, luckily, he is not such gung ho
as Jesse. :-)
It's not about being "Gung ho", it's about NetworkManager being much
more suitable for the default system. The cases where you need the
network service are fewer and fewer.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:50 p.m.
On Thu, Nov 13, 2008 at 12:43:39PM -0800, Jesse Keating wrote:
It's not about being "Gung ho", it's about NetworkManager being much
more suitable for the default system. The cases where you need the
network service are fewer and fewer.
That is that "it works for me and few of my friends hence it has to
be fine for everybody" attitude which so often bugs me in an
observed desktop development. You keep forgetting that even if some
small percentage of systems gets broken in absolute numbers this is
getting huge pretty quickly.
As you can observe on this list, and in this thread in particular,
people who have a hard time (with networking in particular) are more
that just a few and here a sample is rather limited. "More suitable
for the default" does not really mean very much.
Michal
5:23 p.m.
On Thu, 2008-11-13 at 14:50 -0700, Michal Jaegermann wrote:
As you can observe on this list, and in this thread in particular,
people who have a hard time (with networking in particular) are more
that just a few and here a sample is rather limited. "More suitable
for the default" does not really mean very much.
*shrug* it's about target audience. Can you honestly tell me that the
pre-network manager world was better for dealing with wireless networks,
roaming from one location to another, typical laptop usage?
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
6:04 p.m.
On Thu, 13 Nov 2008, Jesse Keating wrote:
*shrug* it's about target audience. Can you honestly tell me
that the
pre-network manager world was better for dealing with wireless networks,
roaming from one location to another, typical laptop usage?
No, the pre-network manager world was not better for those systems. So for
those systems it is perhaps an advance. But that doesn't justify breaking
it for the other 90+% (or, in my case, 100%). I don't use Fedora for most
of my boxes (they are CentOS): what scares me is that this is going to
show up in Redhat/CentOS one of these days, and then I'm in a whole world
of hurt. If I'm starting the first hard-wired DHCP interface after boot on
a system that hasn't declared a hostname, NM *has* to be able to set the
hostname.
Steve
6:10 p.m.
On Thu, 2008-11-13 at 19:04 -0500, Steve Thompson wrote:
No, the pre-network manager world was not better for those systems. So for
those systems it is perhaps an advance. But that doesn't justify breaking
it for the other 90+% (or, in my case, 100%). I don't use Fedora for most
of my boxes (they are CentOS): what scares me is that this is going to
show up in Redhat/CentOS one of these days, and then I'm in a whole world
of hurt. If I'm starting the first hard-wired DHCP interface after boot on
a system that hasn't declared a hostname, NM *has* to be able to set the
hostname.
For the cases where you need to do advanced configuration, and
NetworkManager can't handle it, you can turn it off and use the old
network service. It's a lot easier for the class of folks that need
this to do it, than for the class of folks who need easy to use casual
networking to work easily for them to switch off 'network' and turn on
'NetworkManager'.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
5:11 a.m.
Jesse Keating wrote:
On Thu, 2008-11-13 at 19:04 -0500, Steve Thompson wrote:
> No, the pre-network manager world was not better for those systems. So for
> those systems it is perhaps an advance. But that doesn't justify breaking
> it for the other 90+% (or, in my case, 100%). I don't use Fedora for most
> of my boxes (they are CentOS): what scares me is that this is going to
> show up in Redhat/CentOS one of these days, and then I'm in a whole world
> of hurt. If I'm starting the first hard-wired DHCP interface after boot on
> a system that hasn't declared a hostname, NM *has* to be able to set the
> hostname.
For the cases where you need to do advanced configuration, and
NetworkManager can't handle it, you can turn it off and use the old
network service. It's a lot easier for the class of folks that need
this to do it, than for the class of folks who need easy to use casual
networking to work easily for them to switch off 'network' and turn on
'NetworkManager'.
Jesse,
I realize very well that OSS is to be used under term "AS IS". So I know
I have no right to complain about what is offered. And be sure I am very
greatfull about everything that fedora offers. And that is what we have
to thank the developers for. So THANKS.
But on the other end I use RedHat since the Redhat 3.x days, about more
then 10 years ago. What strikes me is that a product, how promising it
is/can be, becomes the default without it functioning 99.9% right. With
a 10 year history of 100% functioning network in RedHat, being
confronted with none functioning network after a installation process,
does not make me very happy.
The solution of correcting an installation by hand instead of anaconda
supporting this, is not a reward for 10 year of using and advocating a
product. My first and most important reason for using RH in favor of MS
was the better possibility to tell my computer what to do, instead of my
computer telling me what to do, as is very normal in the MS world. At
the moment I see NM as a product that tells me what to do, so it brings
me back to the MS world. And I don't like that.
I was very supprised to see the deactivation of IPv6 functionality in
anaconda simply because NM did not yet support it. As I mostly use
fedora as a server solution, IPv6 is more interesting to me and
historically has more right to be in anaconda than NM is. So I would
have been more happy if the implementation of NM would have been halted
until support for IPv6 was realized or at least NM would not have been
made the default.
This way, in order to gain new users in the graphical market section,
you frighten of your old "customers". To me this does not seem to be a
good idea.
At the moment I would advocate for a user choice NM/network-service at
least until the moment that NM will be able to perform all the tasks
network service does/did with the same level of quality and without the
need to post configure. In fact I would be happy to always have the
clear choice between configuring parameters myself and letting my
computer decide what it thinks is best.
So far my contribution to the community, but developers I don't ask to
stop developing!
Koos.
10:57 a.m.
On Fri, 2008-11-14 at 12:11 +0100, A.J. Werkman wrote:
At the moment I would advocate for a user choice NM/network-service at
least until the moment that NM will be able to perform all the tasks
network service does/did with the same level of quality and without the
need to post configure. In fact I would be happy to always have the
clear choice between configuring parameters myself and letting my
computer decide what it thinks is best.
Asking users questions like this is just silly. They're not going to
understand the difference enough to make an informed decision, and if
they did, they'd be informed enough to do the very very simple steps to
disable NetworkManager in favor of the legacy network service. It takes
very few lines in a kickstart %post to do it.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:26 p.m.
Jesse Keating schreef:
On Fri, 2008-11-14 at 12:11 +0100, A.J. Werkman wrote:
> At the moment I would advocate for a user choice NM/network-service at
> least until the moment that NM will be able to perform all the tasks
> network service does/did with the same level of quality and without the
> need to post configure. In fact I would be happy to always have the
> clear choice between configuring parameters myself and letting my
> computer decide what it thinks is best.
Asking users questions like this is just silly. They're not going to
understand the difference enough to make an informed decision, and if
What do you mean by "this".
Do you mean a question in anaconda to select NM Yes or no. In that case
I would say you have "the default choice" as a solution for people who
do not know what they are doing. And please do not victimise the knowing
by treating them as the unknowing.
Or do you mean my question asking for an opinion about this matter. In
that case be carefull not to call users dumb.
they did, they'd be informed enough to do the very very simple
steps to
disable NetworkManager in favor of the legacy network service. It takes
very few lines in a kickstart %post to do it.
This is a non argument because in this respect you could strip a lot of
code from anaconda because it can all be handled in the %post section.
The plus of anaconda handling this is that users wil not have bother
coding it themselfs. And I do not consider the choice between network
and NM that extreem that it is justifiable to have users put it in %post.
Koos
4:02 p.m.
On Fri, 2008-11-14 at 22:26 +0100, A.J. Werkman wrote:
What do you mean by "this".
Do you mean a question in anaconda to select NM Yes or no. In that case
I would say you have "the default choice" as a solution for people who
do not know what they are doing. And please do not victimise the knowing
by treating them as the unknowing.
Or do you mean my question asking for an opinion about this matter. In
that case be carefull not to call users dumb.
I meant the "Do you want to use NetworkManager or network?" question.
> they did, they'd be informed enough to do the very very simple steps to
> disable NetworkManager in favor of the legacy network service. It takes
> very few lines in a kickstart %post to do it.
This is a non argument because in this respect you could strip a lot of
code from anaconda because it can all be handled in the %post section.
The plus of anaconda handling this is that users wil not have bother
coding it themselfs. And I do not consider the choice between network
and NM that extreem that it is justifiable to have users put it in %post.
If you haven't noticed, the trend over the last few releases has been to
move as much out of anaconda as possible. It does ask a heck of a lot
less now, mostly just things necessary to complete the installation, not
a whole lot of questions about how the system should work after it has
been installed.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
4:47 p.m.
On Fri, 14 Nov 2008 14:02:17 -0800
Jesse Keating <jkeating(a)redhat.com> wrote:
I meant the "Do you want to use NetworkManager or network?"
question.
That's not the right question. The right question is something like:
Does this computer connect to many different networks (like a laptop
with wi-fi), or does it just always use the same network connection?
7:12 a.m.
On Thu, 13 Nov 2008, Jesse Keating wrote:
For the cases where you need to do advanced configuration, and
NetworkManager can't handle it, you can turn it off and use the old
network service. It's a lot easier for the class of folks that need
this to do it, than for the class of folks who need easy to use casual
networking to work easily for them to switch off 'network' and turn on
'NetworkManager'.
A problem is that for the very simplest of configurations (a system with
one single hardwired interface that doesn't roam), NM does not work. At
all. I have a humble collection of about 30 Fedora machines in my
business; four of them are F9 and the rest are earlier versions. I have no
Linux laptops at all; nearly all of the several hundred boxes that I have
managed are of this simple configuration. NM does not work in this
situation; the hostname never gets set. On the F9 systems, turning off
NetworkManager and turning on network also does not work; the hostname is
supplied by the DHCP server, but the hostname on the box gets set to the
formatted IP address (eg '192.168.1.201'). If I have a small army of
machines to configure, I need to have every image be installed via PXE and
be identical, with no hostname/DNS configured on any box; I could do this
with F6/F7/F8, but not F9. I am certainly willing to listen to any advice
to help get this working, as I don't appear to be able to do it. I have to
log in to every box after installation and set the hostname; doing it in a
%post section should not be necessary. And I'm not sure that I like the
sound of "the *old* network service". What happens when that goes away?
Steve
8:03 a.m.
On Friday 14 November 2008 13:12:52 Steve Thompson wrote:
A problem is that for the very simplest of configurations (a system
with
one single hardwired interface that doesn't roam), NM does not work. At
all. I have a humble collection of about 30 Fedora machines in my
business; four of them are F9 and the rest are earlier versions. I have no
Linux laptops at all; nearly all of the several hundred boxes that I have
managed are of this simple configuration. NM does not work in this
situation; the hostname never gets set.
I've probably misunderstood completely,
but doesn't it get the hostname from /etc/sysconfig/network ?
8:23 a.m.
Timothy Murphy wrote:
On Friday 14 November 2008 13:12:52 Steve Thompson wrote:
> A problem is that for the very simplest of configurations (a system with
> one single hardwired interface that doesn't roam), NM does not work. At
> all. I have a humble collection of about 30 Fedora machines in my
> business; four of them are F9 and the rest are earlier versions. I have no
> Linux laptops at all; nearly all of the several hundred boxes that I have
> managed are of this simple configuration. NM does not work in this
> situation; the hostname never gets set.
I've probably misunderstood completely,
but doesn't it get the hostname from /etc/sysconfig/network ?
Yes but at install time anaconda fills this using NM. This means you can
get it right with a manual post install configuration.
And anyhow since F9 anaconda starts NM service by default. So to use
network service again you always have to manually alter the anaconda result.
Koos.
8:29 a.m.
On Fri, 14 Nov 2008, Timothy Murphy wrote:
On Friday 14 November 2008 13:12:52 Steve Thompson wrote:
> A problem is that for the very simplest of configurations (a system with
> one single hardwired interface that doesn't roam), NM does not work. At
> all. I have a humble collection of about 30 Fedora machines in my
> business; four of them are F9 and the rest are earlier versions. I have no
> Linux laptops at all; nearly all of the several hundred boxes that I have
> managed are of this simple configuration. NM does not work in this
> situation; the hostname never gets set.
I've probably misunderstood completely,
but doesn't it get the hostname from /etc/sysconfig/network ?
Yes, it does, if the hostname is set there. But the point is that it is
not acceptable to have to set it there. If I am configuring a whole bunch
of similar machines, I want /etc/sysconfig/network to be identical on all
of them. Imagine the situation where I am installing a set of virtual
machines: I build it once, and then clone the image. If the image contains
any information that identifies the machine, it's now wrong for all of the
clones.
Steve
10:18 a.m.
On Fri, Nov 14, 2008 at 02:03:54PM +0000, Timothy Murphy wrote:
On Friday 14 November 2008 13:12:52 Steve Thompson wrote:
> NM does not work in this
> situation; the hostname never gets set.
I've probably misunderstood completely,
but doesn't it get the hostname from /etc/sysconfig/network ?
To an extent. In /etc/rc.d/rc.sysinit there is the following code:
if [ "$HOSTNAME" = "localhost" -o "$HOSTNAME" =
"localhost.localdomain" ]; then
<some conditions checked and variables set>
....
eval $(ipcalc -h $ipaddr 2>/dev/null)
hostname ${HOSTNAME}
fi
So if you did not already set that earlier from values in
/etc/sysconfig/network then all that really comes to what, and when,
'ipcalc -h $ipaddr' is doing for a calculated value of $ipaddr.
This picture is a bit more involved than that but this is the main
point. With the current NM you need either to "hardwire" a machine
name in /etc/sysconfig/network or you will end up as
localhost.localdomain.
It sounds like Steve Thompson supplied names in DHCP leases and this
stopped to work. I really cannot tell why without a detailed
investigation. OTOH if you are able to resolve addresses to names,
through /etc/hosts or a local DNS server or whatever then, AFAICT,
with 'network' service this still works in F9 and the current
rawhide.
Michal
11:06 a.m.
On Fri, 2008-11-14 at 08:12 -0500, Steve Thompson wrote:
A problem is that for the very simplest of configurations (a system
with
one single hardwired interface that doesn't roam), NM does not work. At
all.
Where is the bug report for this so that we can see the details of what
you're trying to do, where NetworkManager is failing, and what we can do
to fix this in the future?
I have a humble collection of about 30 Fedora machines in my
business; four of them are F9 and the rest are earlier versions. I have no
Linux laptops at all; nearly all of the several hundred boxes that I have
managed are of this simple configuration. NM does not work in this
situation; the hostname never gets set. On the F9 systems, turning off
NetworkManager and turning on network also does not work; the hostname is
supplied by the DHCP server, but the hostname on the box gets set to the
formatted IP address (eg '192.168.1.201').
Wait, so you turn off NetworkManager and the legacy network service
still doesn't work for you? That doesn't sound like a NetworkManager
situation then, that sounds like something different. Is there a bug
against this configuration as well?
If I have a small army of
machines to configure, I need to have every image be installed via PXE and
be identical, with no hostname/DNS configured on any box; I could do this
with F6/F7/F8, but not F9. I am certainly willing to listen to any advice
to help get this working, as I don't appear to be able to do it. I have to
log in to every box after installation and set the hostname; doing it in a
%post section should not be necessary. And I'm not sure that I like the
sound of "the *old* network service". What happens when that goes away?
Currently there are no plans to remove the legacy network service. Such
plans would be met with such wailing and gnashing of teeth (:
Honestly though it sounds like something else unrelated to
NetworkManager has regressed with F9 and I'd like to see that get fixed.
Please do file bugs with the details of what you're trying to do and
what you're seeing so that we can address it. cc me on the bugs if you
like.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
8:26 a.m.
On Friday 14 November 2008 00:10:19 Jesse Keating wrote:
For the cases where you need to do advanced configuration, and
NetworkManager can't handle it, you can turn it off and use the old
network service. It's a lot easier for the class of folks that need
this to do it, than for the class of folks who need easy to use casual
networking to work easily for them to switch off 'network' and turn on
'NetworkManager'.
In my experience the network service does not, and never did,
work properly (with WiFi).
To start with, it was more or less incompatible with system-config-network.
NM has its faults - many of them - but by comparison with the network service
it is utopia.
I would never advise anyone I like to use the network service.
9:23 a.m.
On Fri, Nov 14, 2008 at 02:26:14PM +0000, Timothy Murphy wrote:
On Friday 14 November 2008 00:10:19 Jesse Keating wrote:
> For the cases where you need to do advanced configuration, and
> NetworkManager can't handle it, you can turn it off and use the old
> network service. It's a lot easier for the class of folks that need
> this to do it, than for the class of folks who need easy to use casual
> networking to work easily for them to switch off 'network' and turn on
> 'NetworkManager'.
In my experience the network service does not, and never did,
work properly (with WiFi).
It used to, and still does, work with plain WEP connections.
For wpa_supplicant-managed it needs to be patched, but still works just
fine.
To start with, it was more or less incompatible with
system-config-network.
NM has its faults - many of them - but by comparison with the network service
it is utopia.
I would never advise anyone I like to use the network service.
I would never advise anyone I like to use NetworkManager.
Regards,
R.
--
Dominik 'Rathann' Mierzejewski <rathann*at*icm.edu.pl> | LAN Staff
Interdisciplinary Centre for Mathematical and Computational Modelling
Warsaw University | http://www.icm.edu.pl | tel. +48 (22) 5540810
6:29 p.m.
Steve Thompson wrote:
On Thu, 13 Nov 2008, Jesse Keating wrote:
> *shrug* it's about target audience. Can you honestly tell me that the
> pre-network manager world was better for dealing with wireless networks,
> roaming from one location to another, typical laptop usage?
No, the pre-network manager world was not better for those systems. So
for those systems it is perhaps an advance. But that doesn't justify
breaking it for the other 90+% (or, in my case, 100%).
That seems dubious. You think NetworkManager "broke" things (or at
least made network configuration more difficult) for 90+% of systems?
Perhaps if you count each pc in a 1000-pc server farm separately, but
even in those cases I'm surprised NetworkManager would "break" things.
I'm very happy with NetworkManager. It has made networking much easier
for me, and I suspect the vast majority of Fedora users (not to mention
Ubuntu and other distros). Supporting vpnc and ad hoc networks in F10
are nice improvements on top of quite solid wired/wireless support.
(I haven't tested ad hoc networks, but I do use vpnc, and while running
vpnc by hand wasn't difficult, it's nice to have it in NetworkManager.)
(It would be nice to have as solid modem support - once in a blue moon
I need to use dial-up, but getting laptop modems working is so
daunting that I just share a connection from my husband's Windows
machine. Even most external USB modems are useless WinModems.)
(I wish the display support, not to mention suspend/hibernate,
were as solid - but we're getting there.)
Thanks to everyone working on this!
--
--Per Bothner
per(a)bothner.com http://per.bothner.com/
7:16 a.m.
On Thu, 13 Nov 2008, Per Bothner wrote:
Steve Thompson wrote:
> No, the pre-network manager world was not better for those systems. So for
> those systems it is perhaps an advance. But that doesn't justify breaking
> it for the other 90+% (or, in my case, 100%).
That seems dubious.
Hardly.
You think NetworkManager "broke" things (or at least made
network
configuration more difficult) for 90+% of systems?
Yes. As I said, in my case, NM broke 100% of the machines that I tried it
on.
Perhaps if you count each pc in a 1000-pc server farm separately,
but
even in those cases I'm surprised NetworkManager would "break" things.
If I have to log in to every single frigging box and fix the configuration
after I install, then I definitely count every one.
I'm very happy with NetworkManager.
I'm not.
It has made networking much easier for me,
Good.
and I suspect the vast majority of Fedora users (not to mention
Ubuntu
and other distros).
That seems dubious.
Steve
1:14 a.m.
On Thursday 13 November 2008 23:23:19 Jesse Keating wrote:
On Thu, 2008-11-13 at 14:50 -0700, Michal Jaegermann wrote:
> As you can observe on this list, and in this thread in particular,
> people who have a hard time (with networking in particular) are more
> that just a few and here a sample is rather limited. "More suitable
> for the default" does not really mean very much.
*shrug* it's about target audience. Can you honestly tell me that the
pre-network manager world was better for dealing with wireless networks,
roaming from one location to another, typical laptop usage?
I have used Mandriva (2009 at present), Xandros and Linpus Lite on roaming
laptops, and every one of them manages wireless networks without a problem.
Anne
6:53 a.m.
Anne Wilson wrote:
I have used Mandriva (2009 at present), Xandros and Linpus Lite on
roaming
laptops, and every one of them manages wireless networks without a
problem.
To be honest, NM works better for me under Fedora-10 than Fedora-9
on a Thinkpad T43.
But occasionally it does not work, and then I find the messages I read
in /var/log/messages completely unintelligible and unhelpful.
I've simply found as a matter of experiment
that I have to re-boot the machine, and then it will probably work,
with probability 0.8 .
But I don't think computing should be a matter of
experiment and probability.
What I would like is a message along the following lines:
"We connected to the AP, but your DHCP request was rejected", or
"We are unable to initialize your WiFi card".
Something, in other words, that might help me to correct the problem.
Incidentally, Anne mentioned Xandros.
I'm really embarrassed that my grand-daughter's EeePC 4G
(ie the cheapest of the cheap) running Xandros
connects faultlessly to WiFi wherever she is.
I wonder what WiFi program that uses?
(She is in Australia at the moment, so I cannot examine the machine.)
7:38 a.m.
On Friday 14 November 2008 12:53:06 Timothy Murphy wrote:
Anne Wilson wrote:
> I have used Mandriva (2009 at present), Xandros and Linpus Lite on
> roaming laptops, and every one of them manages wireless networks without
> a problem.
To be honest, NM works better for me under Fedora-10 than Fedora-9
on a Thinkpad T43.
But occasionally it does not work, and then I find the messages I read
in /var/log/messages completely unintelligible and unhelpful.
I've simply found as a matter of experiment
that I have to re-boot the machine, and then it will probably work,
with probability 0.8 .
But I don't think computing should be a matter of
experiment and probability.
What I would like is a message along the following lines:
"We connected to the AP, but your DHCP request was rejected", or
"We are unable to initialize your WiFi card".
Something, in other words, that might help me to correct the problem.
Incidentally, Anne mentioned Xandros.
I'm really embarrassed that my grand-daughter's EeePC 4G
(ie the cheapest of the cheap) running Xandros
connects faultlessly to WiFi wherever she is.
I wonder what WiFi program that uses?
(She is in Australia at the moment, so I cannot examine the machine.)
Mine is the original 701, and yes, it's wireless performance is impressive.
It uses wpa_supplicant.
Anne
9:14 a.m.
On Fri, Nov 14, 2008 at 01:38:19PM +0000, Anne Wilson wrote:
On Friday 14 November 2008 12:53:06 Timothy Murphy wrote:
> Anne Wilson wrote:
> > I have used Mandriva (2009 at present), Xandros and Linpus Lite on
> > roaming laptops, and every one of them manages wireless networks without
> > a problem.
>
> To be honest, NM works better for me under Fedora-10 than Fedora-9
> on a Thinkpad T43.
>
> But occasionally it does not work, and then I find the messages I read
> in /var/log/messages completely unintelligible and unhelpful.
> I've simply found as a matter of experiment
> that I have to re-boot the machine, and then it will probably work,
> with probability 0.8 .
>
> But I don't think computing should be a matter of
> experiment and probability.
>
> What I would like is a message along the following lines:
> "We connected to the AP, but your DHCP request was rejected", or
> "We are unable to initialize your WiFi card".
>
> Something, in other words, that might help me to correct the problem.
>
> Incidentally, Anne mentioned Xandros.
> I'm really embarrassed that my grand-daughter's EeePC 4G
> (ie the cheapest of the cheap) running Xandros
> connects faultlessly to WiFi wherever she is.
> I wonder what WiFi program that uses?
> (She is in Australia at the moment, so I cannot examine the machine.)
Mine is the original 701, and yes, it's wireless performance is impressive.
It uses wpa_supplicant.
FWIW, using plain wpa_supplicant works for me just fine on a 901, and with
a little patching of the /etc/sysconfig/network-scripts/ifup-wireless,
I can even use the usual ifup/ifdown commands with my wifi interface.
Regards,
R.
--
Dominik 'Rathann' Mierzejewski <rathann*at*icm.edu.pl> | LAN Staff
Interdisciplinary Centre for Mathematical and Computational Modelling
Warsaw University | http://www.icm.edu.pl | tel. +48 (22) 5540810
9:40 a.m.
On Friday 14 November 2008 15:14:52 Dominik 'Rathann' Mierzejewski wrote:
FWIW, using plain wpa_supplicant works for me just fine on a 901, and
with
a little patching of the /etc/sysconfig/network-scripts/ifup-wireless,
I can even use the usual ifup/ifdown commands with my wifi interface.
How exactly did you patch the file?
I take it 901 means EeePC-901.
Are you running Fedora on it?
If so, which version?
7:16 a.m.
On Fri, Nov 14, 2008 at 03:40:17PM +0000, Timothy Murphy wrote:
On Friday 14 November 2008 15:14:52 Dominik 'Rathann'
Mierzejewski wrote:
> FWIW, using plain wpa_supplicant works for me just fine on a 901, and with
> a little patching of the /etc/sysconfig/network-scripts/ifup-wireless,
> I can even use the usual ifup/ifdown commands with my wifi interface.
How exactly did you patch the file?
Patch attached.
I take it 901 means EeePC-901.
Yes.
Are you running Fedora on it?
Yes.
If so, which version?
F-10.
Regards,
R.
--
Dominik 'Rathann' Mierzejewski <rathann*at*icm.edu.pl> | LAN Staff
Interdisciplinary Centre for Mathematical and Computational Modelling
Warsaw University | http://www.icm.edu.pl | tel. +48 (22) 5540810
11:20 a.m.
On Fri, 2008-11-14 at 12:53 +0000, Timothy Murphy wrote:
Incidentally, Anne mentioned Xandros.
I'm really embarrassed that my grand-daughter's EeePC 4G
(ie the cheapest of the cheap) running Xandros
connects faultlessly to WiFi wherever she is.
I wonder what WiFi program that uses?
(She is in Australia at the moment, so I cannot examine the machine.)
It would be interesting to know. It's also important to remember that
when trying to get wireless connected, it's not just NetworkManager
involved. It's NetworkManager, often wpa-supplicant if you're using
that auth, the firmware for the device, and the kernel driver. If any
of those pieces go wrong, the connection can fail, but usually only
NetworkManager gets the blame (because that's what user's see).
Depending on the hardware, some distros ship a ripped windows driver for
them, or ship firmware that Fedora is just not able to, so it can appear
that other distros work better when in fact they do, but it's because
they are doing things that Fedora is not legally able to do.
I'm not claiming that this is the case with Anne or your grand-daughter,
I'm just saying that it's something to consider when doing comparisons.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
4:05 p.m.
On Fri, Nov 14, 2008 at 09:20:22AM -0800, Jesse Keating wrote:
On Fri, 2008-11-14 at 12:53 +0000, Timothy Murphy wrote:
> Incidentally, Anne mentioned Xandros.
> I'm really embarrassed that my grand-daughter's EeePC 4G
> (ie the cheapest of the cheap) running Xandros
> connects faultlessly to WiFi wherever she is.
> I wonder what WiFi program that uses?
> (She is in Australia at the moment, so I cannot examine the machine.)
It would be interesting to know.
I'm almost certain, but not 100 %, that the early EEE PC used
ndiswrapper. Up to the 901, they used the AR5007EG and it took the
MadWfi folks, well, FreeBSD's Sam Leffler, mostly, to get a driver
going.
64 bit support was only added last Summer, IIRC.
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
Buffy: Oh, look at my poor neck... all bare and tender and
exposed. All that blood, just pumping away.
Giles: Oh, please.
Spike: Giles, make her stop!
Giles: If those two don't kill each other, I might lend a hand.
4:24 p.m.
On Fri, 2008-11-14 at 17:05 -0500, Scott Robbins wrote:
I'm almost certain, but not 100 %, that the early EEE PC used
ndiswrapper. Up to the 901, they used the AR5007EG and it took the
MadWfi folks, well, FreeBSD's Sam Leffler, mostly, to get a driver
going.
64 bit support was only added last Summer, IIRC.
Yeah, that seems more a function of the driver being used, and less the
software on top to manage it.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:34 a.m.
On Friday 14 November 2008 22:05:07 Scott Robbins wrote:
On Fri, Nov 14, 2008 at 09:20:22AM -0800, Jesse Keating wrote:
> On Fri, 2008-11-14 at 12:53 +0000, Timothy Murphy wrote:
> > Incidentally, Anne mentioned Xandros.
> > I'm really embarrassed that my grand-daughter's EeePC 4G
> > (ie the cheapest of the cheap) running Xandros
> > connects faultlessly to WiFi wherever she is.
> > I wonder what WiFi program that uses?
> > (She is in Australia at the moment, so I cannot examine the machine.)
>
> It would be interesting to know.
I'm almost certain, but not 100 %, that the early EEE PC used
ndiswrapper. Up to the 901, they used the AR5007EG and it took the
MadWfi folks, well, FreeBSD's Sam Leffler, mostly, to get a driver
going.
That would seem likely, since the kernel on my 701 is 2.6.21-4-eeepc. Would
you expect madwifi to show up in a 'locate', because it doesn't?
Anne
.
4:52 a.m.
On Sat, Nov 15, 2008 at 09:34:21AM +0000, Anne Wilson wrote:
<from Scott (me)>
> I'm almost certain, but not 100 %, that the early EEE PC
used
> ndiswrapper. Up to the 901, they used the AR5007EG and it took the
> MadWfi folks, well, FreeBSD's Sam Leffler, mostly, to get a driver
> going.
That would seem likely, since the kernel on my 701 is 2.6.21-4-eeepc.
Would
you expect madwifi to show up in a 'locate', because it doesn't?
You can try lsmod |grep ath and see if ath_pci shows up. It might be
MadWifi or Madwifi, etc.
(also worth trying locate ndiswrapper).
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
Buffy: Will, wait. I'm really sorry.
Willow: Buff, I'm storming off. It doesn't really work if you come
with me.
6:07 a.m.
On Saturday 15 November 2008 10:52:04 Scott Robbins wrote:
On Sat, Nov 15, 2008 at 09:34:21AM +0000, Anne Wilson wrote:
<from Scott (me)>
> > I'm almost certain, but not 100 %, that the early EEE PC used
> > ndiswrapper. Up to the 901, they used the AR5007EG and it took the
> > MadWfi folks, well, FreeBSD's Sam Leffler, mostly, to get a driver
> > going.
>
> That would seem likely, since the kernel on my 701 is 2.6.21-4-eeepc.
> Would you expect madwifi to show up in a 'locate', because it doesn't?
You can try lsmod |grep ath and see if ath_pci shows up. It might be
MadWifi or Madwifi, etc.
ath_pci 74084 0
ath_rate_atheros 24768 1 ath_pci
wlan 144280 4 wlan_scan_sta,ath_pci,ath_rate_atheros
ath_dfs 25476 1 ath_pci
ath_hal 139968 3 ath_pci,ath_rate_atheros
(also worth trying locate ndiswrapper).
I'd already tried that without a result.
Anne
7:29 a.m.
On Sat, Nov 15, 2008 at 12:07:43PM +0000, Anne Wilson wrote:
On Saturday 15 November 2008 10:52:04 Scott Robbins wrote:
>
> You can try lsmod |grep ath and see if ath_pci shows up. It
might be
> MadWifi or Madwifi, etc.
>
ath_pci 74084 0
ath_rate_atheros 24768 1 ath_pci
wlan 144280 4 wlan_scan_sta,ath_pci,ath_rate_atheros
ath_dfs 25476 1 ath_pci
ath_hal 139968 3 ath_pci,ath_rate_atheros
That indicates that MadWifi is there somewhere.
If it's a pre-configured system though, IIRC, Linpus didn't show a trace
of Madwifi, they just had their custom built kernel with the driver in
there. I never investigated how they did it.
(I could easily be wrong though. I no longer have a Linpus install to
check.)
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
Giles: It's a trick. They get inside my head, make me see
things I want.
Xander: Then why would they make you see me?
Giles: You're right. Let's go.
8:49 a.m.
On Saturday 15 November 2008 13:29:33 Scott Robbins wrote:
> > You can try lsmod |grep ath and see if ath_pci shows up.
It might be
> > MadWifi or Madwifi, etc.
>
> ath_pci 74084 0
> ath_rate_atheros 24768 1 ath_pci
> wlan 144280 4 wlan_scan_sta,ath_pci,ath_rate_atheros
> ath_dfs 25476 1 ath_pci
> ath_hal 139968 3 ath_pci,ath_rate_atheros
That indicates that MadWifi is there somewhere.
What is "That"?
9:19 a.m.
On Saturday 15 November 2008 13:29:33 Scott Robbins wrote:
On Sat, Nov 15, 2008 at 12:07:43PM +0000, Anne Wilson wrote:
> On Saturday 15 November 2008 10:52:04 Scott Robbins wrote:
> > You can try lsmod |grep ath and see if ath_pci shows up. It might be
> > MadWifi or Madwifi, etc.
>
> ath_pci 74084 0
> ath_rate_atheros 24768 1 ath_pci
> wlan 144280 4 wlan_scan_sta,ath_pci,ath_rate_atheros
> ath_dfs 25476 1 ath_pci
> ath_hal 139968 3 ath_pci,ath_rate_atheros
That indicates that MadWifi is there somewhere.
If it's a pre-configured system though, IIRC, Linpus didn't show a trace
of Madwifi, they just had their custom built kernel with the driver in
there. I never investigated how they did it.
(I could easily be wrong though. I no longer have a Linpus install to
check.)
Fair enough - except that it's Xandros on the EeePC :-)
Anne
10:44 a.m.
On Sat, Nov 15, 2008 at 03:19:55PM +0000, Anne Wilson wrote:
On Saturday 15 November 2008 13:29:33 Scott Robbins wrote:
>
> That indicates that MadWifi is there somewhere.
>
> If it's a pre-configured system though, IIRC, Linpus didn't show a trace
> of Madwifi, they just had their custom built kernel with the driver in
> there. I never investigated how they did it.
>
> (I could easily be wrong though. I no longer have a Linpus install to
> check.)
>
Fair enough - except that it's Xandros on the EeePC :-)
Sorry, my mental shorthand. I did remember that it was an EEE and my
full (thought, though not written) statement was, Linpus didn't blah
blah, and perhaps Xandros doesn't either.
I was (admittedly quite obscurely) speaking of preconfigured systems in
general.
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
Anya: I swear, I am just trying to find my necklace.
Willow: Well, did you try looking inside the sofa in hell?
11:21 a.m.
On Fri, 2008-11-14 at 12:53 +0000, Timothy Murphy wrote:
What I would like is a message along the following lines:
"We connected to the AP, but your DHCP request was rejected", or
"We are unable to initialize your WiFi card".
This is a good suggestion, and it could even be possible for nm-applet
or the kde variant to display this with a notification popup. You
should file this as a RFE against NetworkManager.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
5:32 a.m.
On Wed, 2008-11-12 at 16:37 -0800, Jesse Keating wrote:
On Wed, 2008-11-12 at 16:21 -0800, Rick Stevens wrote:
> Other drawbacks: the utter and complete lack of documentation;
$ rpm -qd NetworkManager
/usr/share/doc/NetworkManager-0.7.0/AUTHORS
/usr/share/doc/NetworkManager-0.7.0/CONTRIBUTING
/usr/share/doc/NetworkManager-0.7.0/COPYING
/usr/share/doc/NetworkManager-0.7.0/ChangeLog
/usr/share/doc/NetworkManager-0.7.0/NEWS
/usr/share/doc/NetworkManager-0.7.0/README
/usr/share/doc/NetworkManager-0.7.0/TODO
/usr/share/man/man1/nm-tool.1.gz
/usr/share/man/man8/NetworkManager.8.gz
That is none.
6:27 a.m.
On Thursday 13 November 2008 11:32:48 Ralf Corsepius wrote:
On Wed, 2008-11-12 at 16:37 -0800, Jesse Keating wrote:
> On Wed, 2008-11-12 at 16:21 -0800, Rick Stevens wrote:
> > Other drawbacks: the utter and complete lack of documentation;
>
> $ rpm -qd NetworkManager
> /usr/share/doc/NetworkManager-0.7.0/AUTHORS
> /usr/share/doc/NetworkManager-0.7.0/CONTRIBUTING
> /usr/share/doc/NetworkManager-0.7.0/COPYING
> /usr/share/doc/NetworkManager-0.7.0/ChangeLog
> /usr/share/doc/NetworkManager-0.7.0/NEWS
> /usr/share/doc/NetworkManager-0.7.0/README
> /usr/share/doc/NetworkManager-0.7.0/TODO
> /usr/share/man/man1/nm-tool.1.gz
> /usr/share/man/man8/NetworkManager.8.gz
That is none.
I don't know if this was intended as a response
to my complaint about the lack of NM documentation,
but if so (1) the man pages mentioned are completely useless,
consisting of a bare statement that the applications exist,
(2) I don't consider a list of AUTHORS etc to be documentation.
The only item in the above list that could be considered documentation
is README, which in my view is completely inadequate,
eg it does not explain what the various "states" (1 to 9)
listed in /var/log/messages actually are,
or what the 5 "steps" that NM apparently goes through correspond to.
It doesn't say what files NM looks at,
or how one can modify NM's behaviour.
8:49 a.m.
Timothy Murphy wrote, On 11/13/2008 07:27 AM:
On Thursday 13 November 2008 11:32:48 Ralf Corsepius wrote:
> On Wed, 2008-11-12 at 16:37 -0800, Jesse Keating wrote:
>> On Wed, 2008-11-12 at 16:21 -0800, Rick Stevens wrote:
>>> Other drawbacks: the utter and complete lack of documentation;
>> $ rpm -qd NetworkManager
>> /usr/share/doc/NetworkManager-0.7.0/AUTHORS
>> /usr/share/doc/NetworkManager-0.7.0/CONTRIBUTING
>> /usr/share/doc/NetworkManager-0.7.0/COPYING
>> /usr/share/doc/NetworkManager-0.7.0/ChangeLog
>> /usr/share/doc/NetworkManager-0.7.0/NEWS
>> /usr/share/doc/NetworkManager-0.7.0/README
>> /usr/share/doc/NetworkManager-0.7.0/TODO
>> /usr/share/man/man1/nm-tool.1.gz
>> /usr/share/man/man8/NetworkManager.8.gz
> That is none.
I don't know if this was intended as a response
to my complaint about the lack of NM documentation,
but if so (1) the man pages mentioned are completely useless,
consisting of a bare statement that the applications exist,
(2) I don't consider a list of AUTHORS etc to be documentation.
The only item in the above list that could be considered documentation
is README, which in my view is completely inadequate,
eg it does not explain what the various "states" (1 to 9)
listed in /var/log/messages actually are,
or what the 5 "steps" that NM apparently goes through correspond to.
It doesn't say what files NM looks at,
or how one can modify NM's behaviour.
Tim,
Could you please expand[1] your comments above a (very) little more inside of
a bug report against NM documentation.
From _MY_ perspective what Jesse and some of the others are dancing around
or have outright indicated, is:
from the NM developers perspective, If there are no BZ entries for these
problems, then the problems DO NOT EXIST. :)
And even if they disagree with the BZ entry, it is easer to keep poking them
and others with even a closed REFUSETOACK_WONTFIX bug number that others can
reference. It even would even have the benefit of getting in writing (or at
least selection box clicking) the developers opinions.
[1] or even just put what you have above in BZ so that others feeling the pain
can pile on.
I have done the fall back to network, so I have avoided the pain and thus
don't have anything I could add to the BZ, but I know my day is coming soon.
Thanks.
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
9:09 a.m.
On Thursday 13 November 2008 14:49:10 Todd Denniston wrote:
I have done the fall back to network, so I have avoided the pain and
thus
don't have anything I could add to the BZ, but I know my day is coming
soon.
It may come to that for me. I've been fighting this for two days now, and
have given it a lot of time, so I may be asking your advice for dropping back.
I do have a working ifcfg-eth1 on this laptop (my wireless connection) so I
know what needs to be in the file.
Anne
11:53 a.m.
On Thu, 2008-11-13 at 15:09 +0000, Anne Wilson wrote:
It may come to that for me. I've been fighting this for two days now, and
have given it a lot of time, so I may be asking your advice for dropping back.
I do have a working ifcfg-eth1 on this laptop (my wireless connection) so I
know what needs to be in the file.
Anne, I would suggest booting a live image and attempting your config
from there. This will give you a fresh start at both the config files,
and the gconf entries, so that your attempts aren't sullied by any
previous tweakings. Once you've either gotten it to work on the Live
image, or still fail, you can either transfer that knowledge to your
existing install, or be in a better position to file a bug that can be
reproduced.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
12:57 p.m.
On Thursday 13 November 2008 17:53:10 Jesse Keating wrote:
On Thu, 2008-11-13 at 15:09 +0000, Anne Wilson wrote:
> It may come to that for me. I've been fighting this for two days now,
> and have given it a lot of time, so I may be asking your advice for
> dropping back. I do have a working ifcfg-eth1 on this laptop (my wireless
> connection) so I know what needs to be in the file.
Anne, I would suggest booting a live image and attempting your config
from there. This will give you a fresh start at both the config files,
and the gconf entries, so that your attempts aren't sullied by any
previous tweakings. Once you've either gotten it to work on the Live
image, or still fail, you can either transfer that knowledge to your
existing install, or be in a better position to file a bug that can be
reproduced.
Any fedora live image? I assume that there isn't one yet for the current
rawhide. I'm concerned that a live image that isn't *very* up-to-date won't
have a kernel with the ath5k driver in it.
Anne
1:07 p.m.
On Thu, 2008-11-13 at 18:57 +0000, Anne Wilson wrote:
Any fedora live image? I assume that there isn't one yet for the
current
rawhide. I'm concerned that a live image that isn't *very* up-to-date won't
have a kernel with the ath5k driver in it.
The Fedora 10 Preview live image would suffice.
http://fedoraproject.org/get-prerelease
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
1:14 p.m.
On Thursday 13 November 2008 19:07:46 Jesse Keating wrote:
On Thu, 2008-11-13 at 18:57 +0000, Anne Wilson wrote:
> Any fedora live image? I assume that there isn't one yet for the current
> rawhide. I'm concerned that a live image that isn't *very* up-to-date
> won't have a kernel with the ath5k driver in it.
The Fedora 10 Preview live image would suffice.
http://fedoraproject.org/get-prerelease
OK - I hadn't expected there to be a preview live image yet. It's
downloading, and I'll have a go with it in the morning.
Anne
6:24 p.m.
On Thu, Nov 13, 2008 at 06:57:37PM +0000, Anne Wilson wrote:
On Thursday 13 November 2008 17:53:10 Jesse Keating wrote:
> This will give you a fresh start at both the config files,
> and the gconf entries, so that your attempts aren't sullied by any
> previous tweakings. Once you've either gotten it to work on the Live
> image, or still fail, you can either transfer that knowledge to your
> existing install, or be in a better position to file a bug that can be
> reproduced.
Any fedora live image? I assume that there isn't one yet for the current
rawhide. I'm concerned that a live image that isn't *very* up-to-date won't
have a kernel with the ath5k driver in it.
There are various spins--see my other post, the drivers were there, but
it wouldn't connect to a WPA network.
However, even with the early Fedora rawhide, despite this issue with the
live CDs, the ath5k has been working rather well, at least for me.
Perhaps because I'm pure of heart?
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
Spike: Willow, tell 'em what I did.
Willow: You said you were gonna kill me, then Buffy.
Spike: Yes, bad, but let's skip that part and get to
the part where I couldn't bite you.
1:17 a.m.
On Friday 14 November 2008 00:24:37 Scott Robbins wrote:
However, even with the early Fedora rawhide, despite this issue with
the
live CDs, the ath5k has been working rather well, at least for me.
That's a comfort at least. There is some hope, then.
Perhaps because I'm pure of heart?
LOL - I was before NM drove me to distraction
Anne
6:11 a.m.
On Fri, Nov 14, 2008 at 07:17:43AM +0000, Anne Wilson wrote:
On Friday 14 November 2008 00:24:37 Scott Robbins wrote:
> ... the ath5k has been working rather well, at least for me.
>
That's a comfort at least. There is some hope, then.
> Perhaps because I'm pure of heart?
LOL - I was before NM drove me to distraction
Ah, but Mandriva works for you and not me, so perhaps you're still
pure of heart. :)
(Actually, judging from the Aspire One forums, it seems to work for most
people. I didn't try that hard with it.)
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
Willow: So, how did it go?
Xander: On a scale from one to ten? It sucked.
6:36 a.m.
On Friday 14 November 2008 12:11:15 Scott Robbins wrote:
On Fri, Nov 14, 2008 at 07:17:43AM +0000, Anne Wilson wrote:
> On Friday 14 November 2008 00:24:37 Scott Robbins wrote:
> > ... the ath5k has been working rather well, at least for me.
>
> That's a comfort at least. There is some hope, then.
>
> > Perhaps because I'm pure of heart?
>
> LOL - I was before NM drove me to distraction
Ah, but Mandriva works for you and not me, so perhaps you're still
pure of heart. :)
(Actually, judging from the Aspire One forums, it seems to work for most
people. I didn't try that hard with it.)
Familiarity helps. I've used Fedora since the end of FC5, but I've used
Mandriva since Mandrake 8.0 - much longer and more intensively. It's been my
main workstation distro since 8.1.
Anne
6:05 a.m.
On Thursday 13 November 2008 17:53:10 Jesse Keating wrote:
On Thu, 2008-11-13 at 15:09 +0000, Anne Wilson wrote:
> It may come to that for me. I've been fighting this for two days now,
> and have given it a lot of time, so I may be asking your advice for
> dropping back. I do have a working ifcfg-eth1 on this laptop (my wireless
> connection) so I know what needs to be in the file.
Anne, I would suggest booting a live image and attempting your config
from there. This will give you a fresh start at both the config files,
and the gconf entries, so that your attempts aren't sullied by any
previous tweakings. Once you've either gotten it to work on the Live
image, or still fail, you can either transfer that knowledge to your
existing install, or be in a better position to file a bug that can be
reproduced.
OK - I've got the livecd up. This is not helped by the fact that it's a gnome
desktop, so I have to search for unfamiliar tools. However, attempting to
connect with NM has brought some interesting info.
1. There is no list whatsoever of available wireless networks.
2. De-selecting the radio button for Auto eth0 (not eth1, mind!) results in a
whirring, then the same connection being restored.
3. Attempting to connect to "Hidden Wireless" results, as on my own system,
with a request for a WEP key, despite the fact that it has already been given
the WPA key.
4. As on my own system, when the WEP key is requested there is no option in
the drop-down list to change it to WPA.
IOW, exactly like on my own system, it plain doesn't work.
What now?
Anne
8:28 a.m.
On Fri, Nov 14, 2008 at 12:05:16PM +0000, Anne Wilson wrote:
OK - I've got the livecd up. This is not helped by the fact that
it's a gnome
desktop, so I have to search for unfamiliar tools. However, attempting to
connect with NM has brought some interesting info.
1. There is no list whatsoever of available wireless networks.
2. De-selecting the radio button for Auto eth0 (not eth1, mind!) results in a
whirring, then the same connection being restored.
3. Attempting to connect to "Hidden Wireless" results, as on my own system,
with a request for a WEP key, despite the fact that it has already been given
the WPA key.
4. As on my own system, when the WEP key is requested there is no option in
the drop-down list to change it to WPA.
IOW, exactly like on my own system, it plain doesn't work.
What now?
This *sounds* like an old bug I ran into where the nm-applet (the
graphical icon with the pull down menu) got out of sync with what the
underlying system (NetworkManager itself) had for the wireless network
list.
Can you run "nm-tool" in a terminal window, then run "iwlist scanning"
as well (I think the latter needs to be run as root)? That may
provide a clue as to what is being misdetected. The two should agree
on the list of APs found, their encryption modes, etc.
9:15 a.m.
On Friday 14 November 2008 14:28:27 Chuck Anderson
wrote:
Can you run "nm-tool" in a terminal window, then run
"iwlist scanning"
as well (I think the latter needs to be run as root)?
That
may
provide a clue as to what is being misdetected. The
two
should agree
on the list of APs found, their encryption modes, etc.
nm-tool
NetworkManager Tool
State: connected
- Device: eth1
----------------------------------------------------------------
Type: Wired
Driver: r8169
State: connected
Default: yes
HW Address: 00:1E:68:BD:EF:73
Capabilities:
Supported: yes
Carrier Detect: yes
Speed: 100 Mb/s
Wired Settings
IPv4 Settings:
Address: 192.168.0.92
Prefix: 24 (255.255.255.0)
Gateway: 192.168.0.1
DNS: 192.168.0.1
- Device: wlan0
----------------------------------------------------------------
Type: 802.11 WiFi
Driver: ath5k_pci
State: disconnected
Default: no
HW Address: 00:22:33:44:55:66
Capabilities:
Supported: yes
Wireless Settings
WEP Encryption: yes
WPA Encryption: yes
WPA2 Encryption: yes
Wireless Access Points
[root@AAO ~]# iwlist scanning
lo Interface doesn't support scanning.
wmaster0 Interface doesn't support scanning.
wlan0 No scan results
eth1 Interface doesn't support scanning.
pan0 Interface doesn't support scanning.
*MAC address obscured.
Anne
10:24 a.m.
On Friday 14 November 2008 15:33:20 Chuck Anderson
wrote:
On Fri, Nov 14, 2008 at 03:15:40PM +0000, Anne
Wilson wrote:
> [root@AAO ~]# iwlist scanning
>
> wlan0 No scan results
Either the card isn't "up" or something else is wrong.
Can you try
these in this order:
ifconfig wlan0 up
ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr
00:22:33:44:55:66
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
frame:0
TX packets:0 errors:0 dropped:0 overruns:0
carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
I did read somewhere that a MTU of 1400 is better.
iwconfig wlan0
wlan0 IEEE 802.11bg ESSID:""
Mode:Managed Frequency:2.412
GHz Access
Point: Not-Associated
Tx-Power=27 dBm
Retry min limit:7 RTS thr:off Fragment thr=2352
B
Encryption key:off
Power Management:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid
frag:0
Tx excessive retries:0 Invalid misc:0 Missed
beacon:0
Now that's a report I haven't seen before. It appears that
neither my ESSID or key are being read from the file that
surely must be created when NM configures the
connection.
iwlist scanning
As before - No scan results.
Wow - some progress, if only small. In view of what
appears above I renamed ifcfg-wlan0 and created a new
one. I immediately got a popup saying that I am now
connected to myESSID. BUT, the icon shows a very weak
signal, and ifconfig shows that it has the address
10.42.44.1, while my network is a 192.168.0.x LAN.
This is the situation I reached a couple of days ago, and
I'm comopletely foxed by it.
Running iwconfig wlan0 again I now get
wlan0 IEEE 802.11bg ESSID:"myESSID"
Mode:Ad-Hoc Frequency:2.412 GHz Cell:
36:8F:3A:45:3F:BC
Tx-Power=27 dBm
Retry min limit:7 RTS thr:off Fragment thr=2352
B
Power Management:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid
frag:0
Tx excessive retries:0 Invalid misc:0 Missed
beacon:0
I tried changing the setup from ad-hoc to Infrastructure,
but that breaks things - I can no longer connect.
FWIW, my router does not list this netbook as a
connected device.
Anne
11 a.m.
On Fri, Nov 14, 2008 at 04:24:47PM +0000, Anne Wilson wrote:
On Friday 14 November 2008 15:33:20 Chuck Anderson
Now that's a report I haven't seen before. It appears that
neither my ESSID or key are being read from the file that
surely must be created when NM configures the
connection.
iwconfig is a low-level tool--it just shows or manually configures
what is in the kernel driver for the wireless card. It doesn't
integrate with the configuration files or wpa_supplicant or
NetworkManager at all.
> iwlist scanning
As before - No scan results.
Try repeating "iwlist scanning" a few times in a row--sometimes it
takes a few tries for results to appear.
But, this seems like a kernel driver issue then, nothing to do with
wpa_supplicant or NetworkManager. To be sure, could you temporarily
turn those off, reboot, and repeat those steps above?
chkconfig --level 2345 NetworkManager off
(wpa_supplicant should always be off by default anyway, but in case:
chkconfig --level 2345 wpa_supplicant off
don't turn it back on again after testing since it is launched
automatically as needed by NM)
After testing, you can turn NetworkManager back on:
chkconfig --level 2345 NetworkManager on
This will help by eliminating NetworkManager or wpa_supplicant as the
cause of "no scan results".
Remeber to try "iwlist scanning" a few times in a row.
Wow - some progress, if only small. In view of what
appears above I renamed ifcfg-wlan0 and created a new
one. I immediately got a popup saying that I am now
connected to myESSID. BUT, the icon shows a very weak
signal, and ifconfig shows that it has the address
10.42.44.1, while my network is a 192.168.0.x LAN.
Strange.
This is the situation I reached a couple of days ago, and
I'm comopletely foxed by it.
Running iwconfig wlan0 again I now get
wlan0 IEEE 802.11bg ESSID:"myESSID"
Mode:Ad-Hoc Frequency:2.412 GHz Cell:
36:8F:3A:45:3F:BC
Tx-Power=27 dBm
Retry min limit:7 RTS thr:off Fragment thr=2352
B
Power Management:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid
frag:0
Tx excessive retries:0 Invalid misc:0 Missed
beacon:0
I tried changing the setup from ad-hoc to Infrastructure,
but that breaks things - I can no longer connect.
ad-hoc should only be for computer-to-computer connections, not
computer-to-accesspoint.
FWIW, my router does not list this netbook as a
connected device.
I'm guessing that you really didn't connect anywhere--you just created
a new ad-hoc connection so that other computers could have connected
to you on an ad-hoc basis.
Beyond the debugging of "scanning" above, you could ignore scanning
and try to manually connect to a specific network. With
NetworkManager disabled:
iwconfig wlan0 essid myESSID
iwconfig wlan0 mode Managed
ifconfig wlan0 up
Now check a few times to see if it eventually associates to the AP:
iwconfig wlan0
Eventually, you should see it say "associated". If that happens, you
could try to get an IP address configured by manually starting the
dhcp client:
dhclient wlan0
If you can repeatably connect fine using this method, then there is
probably a problem with the kernel driver scanning for networks.
NetworkManager won't work well if scanning doesn't work.
Some SELinux notes:
The above tests might work best with SELinux in permissive mode.
If you run in permissive mode for a while, your system may no longer
have correct file labels. After testing in permissive mode, when you
are ready to switch back to enforcing mode, it is a good idea to:
touch /.autorelabel
reboot
To fix the labels on the entire system.
11:28 a.m.
On Friday 14 November 2008 17:00:49 Chuck Anderson
wrote:
I have already changed to permissive mode.
> touch /.autorelabel
> reboot
> To fix the labels on the entire system.
OK - I'll try to remember that :-)
Anne
Try repeating "iwlist scanning" a few times in a row--
sometimes it
takes a few tries for results to appear.
No joy.
But, this seems like a kernel driver issue then, nothing
to do
with
wpa_supplicant or NetworkManager. To be sure, could
you
temporarily
turn those off, reboot, and repeat those steps above?
chkconfig --level 2345 NetworkManager off
(wpa_supplicant should always be off by default
anyway, but in case:
chkconfig --level 2345 wpa_supplicant off
don't turn it back on again after testing since it is
launched
automatically as needed by NM)
After testing, you can turn NetworkManager back on:
chkconfig --level 2345 NetworkManager on
This will help by eliminating NetworkManager or
wpa_supplicant as the
cause of "no scan results".
Remeber to try "iwlist scanning" a few times in a row.
Again, none of this made any difference.
> Wow - some progress, if only small. In view of what
> appears above I renamed ifcfg-wlan0 and created a
new
> one. I immediately got a popup saying that I am
now
> connected to myESSID. BUT, the icon shows a very
weak
> signal, and ifconfig shows that it has the address
> 10.42.44.1, while my network is a 192.168.0.x LAN.
Strange.
> This is the situation I reached a couple of days ago,
and
> I'm comopletely foxed by it.
> Running iwconfig wlan0 again I now get
> wlan0 IEEE 802.11bg ESSID:"myESSID"
> Mode:Ad-Hoc Frequency:2.412 GHz Cell:
> 36:8F:3A:45:3F:BC
> Tx-Power=27 dBm
> Retry min limit:7 RTS thr:off Fragment
thr=2352
> B
> Power Management:off
> Link Quality:0 Signal level:0 Noise level:0
> Rx invalid nwid:0 Rx invalid crypt:0 Rx
invalid
> frag:0
> Tx excessive retries:0 Invalid misc:0 Missed
> beacon:0
> I tried changing the setup from ad-hoc to
Infrastructure,
> but that breaks things - I can no longer connect.
ad-hoc should only be for computer-to-computer
connections, not
computer-to-accesspoint.
That's why I tried to change it - without success.
> FWIW, my router does not list this netbook as a
> connected device.
I'm guessing that you really didn't connect anywhere--
you just created
a new ad-hoc connection so that other computers
could have
connected
to you on an ad-hoc basis.
Beyond the debugging of "scanning" above, you could
ignore scanning
and try to manually connect to a specific network.
With
NetworkManager disabled:
iwconfig wlan0 essid myESSID
iwconfig wlan0 mode Managed
ifconfig wlan0 up
Now check a few times to see if it eventually associates
to the AP:
iwconfig wlan0
Eventually, you should see it say "associated".
I can't get an association. At the end of all this I get
wlan0 IEEE 802.11bg ESSID:"myESSID"
Mode:Managed Frequency:2.412 GHz Access
Point: Not-Associated
Tx-Power=27 dBm
Retry min limit:7 RTS thr:off Fragment thr=2352
B
Encryption key:off
Power Management:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid
frag:0
Tx excessive retries:0 Invalid misc:0 Missed
beacon:0
If that happens, you
could try to get an IP address configured by manually
starting the
dhcp client:
dhclient wlan0
Although I hadn't got an association, I tried it anyway. It
said dhclient was already running, and exited.
If you can repeatably connect fine using this method,
then there is
probably a problem with the kernel driver scanning for
networks.
NetworkManager won't work well if scanning doesn't
work.
Some SELinux notes:
The above tests might work best with SELinux in
permissive mode.
If you run in permissive mode for a while, your system
may no
longer
have correct file labels. After testing in permissive
mode,
when you
are ready to switch back to enforcing mode, it is a
good idea
to:
9:37 a.m.
On Friday 14 November 2008 15:15:40 Anne Wilson wrote:
[root@AAO ~]# iwlist scanning
lo Interface doesn't support scanning.
wmaster0 Interface doesn't support scanning.
wlan0 No scan results
eth1 Interface doesn't support scanning.
pan0 Interface doesn't support scanning.
*MAC address obscured.
My impression is that "iwlist scan" hasn't been giving anything sensible
for quite a long time (long before F-10).
Now I try it, and I find it is working fine ...
----------------------------------------------
[tim@mary ~]$ sudo iwlist scan
lo Interface doesn't support scanning.
eth0 Interface doesn't support scanning.
irda0 Interface doesn't support scanning.
eth1 Scan completed :
Cell 01 - Address: 00:16:B6:DA:56:B4
ESSID:"dd-wrt"
Mode:Master
Frequency:2.437 GHz (Channel 6)
Signal level:-74 dBm Noise level:-97 dBm
Encryption key:on
Extra: Last beacon: 135ms ago
pan0 Interface doesn't support scanning.
----------------------------------------------
Computing is truly an experimental science.
11:27 a.m.
On Fri, 2008-11-14 at 12:05 +0000, Anne Wilson wrote:
OK - I've got the livecd up. This is not helped by the fact that it's a gnome
desktop, so I have to search for unfamiliar tools. However, attempting to
connect with NM has brought some interesting info.
1. There is no list whatsoever of available wireless networks.
Do you expect that there are other wireless access points in the area?
Have you seen them with another system? Just not showing any available
doesn't mean that something is broken, it could just mean that there are
no non-hidden access points within range of your card.
If you do know that there are some available, then I do suspect that
there are deeper card/firmware issues at play here, not failings of
NetworkManager.
2. De-selecting the radio button for Auto eth0 (not eth1, mind!) results in a
whirring, then the same connection being restored.
It's not a de-selection, you've triggered it to re-associate that
connection, in the case of your wired connection to re-dhcp. I don't
believe that currently there is a good way to disable a wired connection
through the UI.
3. Attempting to connect to "Hidden Wireless" results, as on my own system,
with a request for a WEP key, despite the fact that it has already been given
the WPA key.
When did you give the WPA key? Are you saying that you gave it once
when setting up the connection, it spun for a while, and then prompted
you again for the key? This failure mode is typical when it cannot
associate with the access point. We don't get good information as to
why we couldn't associate (it doesn't say "bad password!") so we just
assume that the password was wrong and allow you to try it again.
4. As on my own system, when the WEP key is requested there is no option in
the drop-down list to change it to WPA.
That's because with WPA the access point can actually tell you that it
requires WPA. If you're not getting this, and your access point is
setup for WPA, I would suspect that your card is never actually able to
communicate with the access point, which could be a firmware/kernel
thing.
IOW, exactly like on my own system, it plain doesn't work.
Thank you for trying, as I stated, I think the evidence in this trail
points more toward a kernel/firmware issue than a connection software
issue. It would be good to file a bug against kernel and include the
log messages related to your attempts to connect.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
12:49 p.m.
On Friday 14 November 2008 17:27:52 Jesse Keating wrote:
On Fri, 2008-11-14 at 12:05 +0000, Anne Wilson wrote:
> OK - I've got the livecd up. This is not helped by the fact that it's a
> gnome desktop, so I have to search for unfamiliar tools. However,
> attempting to connect with NM has brought some interesting info.
>
> 1. There is no list whatsoever of available wireless networks.
Do you expect that there are other wireless access points in the area?
Have you seen them with another system? Just not showing any available
doesn't mean that something is broken, it could just mean that there are
no non-hidden access points within range of your card.
There is one next door that is constantly on, and should show as a weak
signal. There are a couple of others that show up sporadically. I would
expect at least my own and next door's to be listed.
If you do know that there are some available, then I do suspect that
there are deeper card/firmware issues at play here, not failings of
NetworkManager.
Chuck's guidance seems to be leading us to that conclusion, too.
> 2. De-selecting the radio button for Auto eth0 (not eth1, mind!)
results
> in a whirring, then the same connection being restored.
It's not a de-selection, you've triggered it to re-associate that
connection, in the case of your wired connection to re-dhcp. I don't
believe that currently there is a good way to disable a wired connection
through the UI.
OK - fair enough.
> 3. Attempting to connect to "Hidden Wireless" results,
as on my own
> system, with a request for a WEP key, despite the fact that it has
> already been given the WPA key.
When did you give the WPA key? Are you saying that you gave it once
when setting up the connection, it spun for a while, and then prompted
you again for the key? This failure mode is typical when it cannot
associate with the access point. We don't get good information as to
why we couldn't associate (it doesn't say "bad password!") so we just
assume that the password was wrong and allow you to try it again.
But it doesn't allow me to try again. It asks for WEP keys. There are four
options, all WEP, whereas the main dialogue offers the same four plus two WPA
ones.
> 4. As on my own system, when the WEP key is requested there is
no option
> in the drop-down list to change it to WPA.
That's because with WPA the access point can actually tell you that it
requires WPA. If you're not getting this, and your access point is
setup for WPA, I would suspect that your card is never actually able to
communicate with the access point, which could be a firmware/kernel
thing.
The fact that wireless worked, however briefly, when I first installed F10
makes me think that the card is not at fault. However, I am tending towards
believing that it is a kernel issue.
> IOW, exactly like on my own system, it plain doesn't work.
Thank you for trying, as I stated, I think the evidence in this trail
points more toward a kernel/firmware issue than a connection software
issue. It would be good to file a bug against kernel and include the
log messages related to your attempts to connect.
I'll see whether I can put together a suitable report out of all this :-)
Anne
1:05 p.m.
On Fri, 2008-11-14 at 18:49 +0000, Anne Wilson wrote:
But it doesn't allow me to try again. It asks for WEP keys.
There are four
options, all WEP, whereas the main dialogue offers the same four plus two WPA
ones.
Hrm, that may itself be a different bug. I'll check with the NM author.
> > 4. As on my own system, when the WEP key is requested there
is no option
> > in the drop-down list to change it to WPA.
>
> That's because with WPA the access point can actually tell you that it
> requires WPA. If you're not getting this, and your access point is
> setup for WPA, I would suspect that your card is never actually able to
> communicate with the access point, which could be a firmware/kernel
> thing.
>
The fact that wireless worked, however briefly, when I first installed F10
makes me think that the card is not at fault. However, I am tending towards
believing that it is a kernel issue.
Well, card firmware is most often loaded from the operating system onto
the volatile memory on the card, so it could in fact be a firmware
issue.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
6:11 a.m.
On Friday 14 November 2008 19:05:00 Jesse Keating wrote:
On Fri, 2008-11-14 at 18:49 +0000, Anne Wilson wrote:
> But it doesn't allow me to try again. It asks for WEP keys. There are
> four options, all WEP, whereas the main dialogue offers the same four
> plus two WPA ones.
Hrm, that may itself be a different bug. I'll check with the NM author.
Did you get any info on this? I need to know whether to raise a separate bug
report for this.
Also, the renaming by udev of eth0 to eth1, when it doesn't happen with the
Live CD. Is that also a separate bug?
I'm working now on getting a summary report for the main bug report.
Anne
10:07 a.m.
On Mon, Nov 17, 2008 at 12:11:36PM +0000, Anne Wilson wrote:
Also, the renaming by udev of eth0 to eth1, when it doesn't happen with the
Live CD. Is that also a separate bug?
That, I am guessing, is not really a bug. Probably something wrote,
and why I do not know, at some moment a rule which requires such
rename into /etc/udev/rules.d/70-persistent-net.rules. Just to be
sure of that name grep for udev/write_net_rules in files from
/etc/udev/rules.d/. You can edit found file or throw it away (just
rename it for a start not to have a suffix '.rules') and it should
be regenerated on the next boot. Only make sure that something else
does not bring that interface up as eth1.
A generation of that rule in question may be a bug, or maybe not;
depending on why it was created in the first place. A general idea
is not to allow udev to rename your network interfaces on every
boot. Especially important if you have many interfaces with
different drivers.
Michal
10:35 a.m.
On Monday 17 November 2008 16:07:37 Michal Jaegermann wrote:
On Mon, Nov 17, 2008 at 12:11:36PM +0000, Anne Wilson wrote:
> Also, the renaming by udev of eth0 to eth1, when it doesn't happen with
> the Live CD. Is that also a separate bug?
That, I am guessing, is not really a bug. Probably something wrote,
and why I do not know, at some moment a rule which requires such
rename into /etc/udev/rules.d/70-persistent-net.rules. Just to be
sure of that name grep for udev/write_net_rules in files from
/etc/udev/rules.d/.
Curiouser and curiouser. 70-persistent-net.rules clearly says that it is
eth0!
You can edit found file or throw it away (just
rename it for a start not to have a suffix '.rules') and it should
be regenerated on the next boot. Only make sure that something else
does not bring that interface up as eth1.
A generation of that rule in question may be a bug, or maybe not;
depending on why it was created in the first place. A general idea
is not to allow udev to rename your network interfaces on every
boot. Especially important if you have many interfaces with
different drivers.
While I have the file, is there any advantage/disadvantage of changing the
ATTR{address} lines to show the genuine MAC addresses, rather than
00:00:00:00:00:00?
Anne
10:39 a.m.
Anne Wilson (cannewilson(a)googlemail.com) said:
While I have the file, is there any advantage/disadvantage of
changing the
ATTR{address} lines to show the genuine MAC addresses, rather than
00:00:00:00:00:00?
00:00:00:00:00:00 is unlikely to actually match anything, unless that's
what the device looks like before it loads any firmware.
Bill
11:44 a.m.
On Monday 17 November 2008 16:39:02 Bill Nottingham wrote:
Anne Wilson (cannewilson(a)googlemail.com) said:
> While I have the file, is there any advantage/disadvantage of changing
> the ATTR{address} lines to show the genuine MAC addresses, rather than
> 00:00:00:00:00:00?
00:00:00:00:00:00 is unlikely to actually match anything, unless that's
what the device looks like before it loads any firmware.
OK, I've edited that. I realise now that there is a section of the file that
I hadn't noticed before. I wonder if this is the cause of the problem.
Originally eth0 had 00:00:00:00:00:00, then there is the section
# PCI device 0x10ec:0x8136 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:1e:68:bd:ef:73", ATTR{type}=="1",
KERNEL=="eth*",
NAME="eth1"
Presumably this means that it has discovered the MAC address and is not aware
that it belongs to the Realtek device defined above it.
I'm going to try commenting out that section now that I've put the MAC address
in, and see whether I then get connected on eth0.
Yes - I'm now connected to Auto eth0! So that's one mystery cleared up. I
wonder why it didn't detect the MAC in the first place? Maybe that's
connected to the fact that wired didn't work just at first. Pure speculation,
of course.
Anne
11:25 a.m.
On Mon, Nov 17, 2008 at 04:35:43PM +0000, Anne Wilson wrote:
On Monday 17 November 2008 16:07:37 Michal Jaegermann wrote:
> Probably something wrote,
> and why I do not know, at some moment a rule which requires such
> rename into /etc/udev/rules.d/70-persistent-net.rules.
Curiouser and curiouser. 70-persistent-net.rules clearly says that it is
eth0!
> You can edit found file or throw it away
While I have the file, is there any advantage/disadvantage of changing the
ATTR{address} lines to show the genuine MAC addresses, rather than
00:00:00:00:00:00?
This should be the genuine MAC addresses as this identifies the
interface in question.
My guess would be that you started with a buggy driver which was
unable to find MAC and that is why you ended with 00:00:00:00:00:00.
Now udev gets "no, this does not match the card here so eth0 is
taken and the next one free needs to be used" and you end up with
eth1.
Maybe udev should take 00:00:00:00:00:00 as a "wild card" which
would match any MAC? Only that should be processed only after all
present "real MACs" were taken care of.
Again - I only _think that is a probable scenario_ but I do not know
that for sure.
Michal
10:23 p.m.
On Mon, 2008-11-17 at 12:11 +0000, Anne Wilson wrote:
Did you get any info on this? I need to know whether to raise a
separate bug
report for this.
The author thought it might be a bug, so it'd be worth filing it.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
10 a.m.
On Tuesday 18 November 2008 04:23:37 Jesse Keating wrote:
On Mon, 2008-11-17 at 12:11 +0000, Anne Wilson wrote:
> Did you get any info on this? I need to know whether to raise a
> separate bug
> report for this.
The author thought it might be a bug, so it'd be worth filing it.
Bug #472248
Anne
10:55 a.m.
On Wed, 2008-11-12 at 12:22 +0000, Timothy Murphy wrote:
O
[tim@mary GroupRepresentations]$ service network status
Configured devices:
lo eth0 eth1 pan0
Currently active devices:
lo eth0 eth1
--------------------------------------------------
I've no idea who or what pan0 is.
pan0 is/is for bluetooth apps/programs/access.
--
Mike Chambers
Fedora Project - Ambassador, Bug Zapper, Tester, User, etc..
mikec302(a)fedoraproject.org
4:56 a.m.
Another, related question. Bug #469097 talks about a drop-down list of
available connections. Where is this list? I can't see it.
Checking the wireless connection configuration screen I see that every time I
try to connect by entering the details into a box it begins a new connection
definition! Consequently I can have multiple instances of the same ESSID
connection defined. Clearing all but the first makes no difference.
Anne
10:52 a.m.
On Wed, 2008-11-12 at 10:56 +0000, Anne Wilson wrote:
Another, related question. Bug #469097 talks about a drop-down list
of
available connections. Where is this list? I can't see it.
It's when you click on the NetworkManager applet in your task bar.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
1:02 p.m.
On Wednesday 12 November 2008 16:52:56 Jesse Keating wrote:
On Wed, 2008-11-12 at 10:56 +0000, Anne Wilson wrote:
> Another, related question. Bug #469097 talks about a drop-down list
> of
> available connections. Where is this list? I can't see it.
It's when you click on the NetworkManager applet in your task bar.
It wasn't there, Jesse. Since I followed Michal Jaegermann's latest
suggestion I can now see my connection there. However, please read my reply
to him, as this opens up a whole new can of worms.
Anne
1:25 p.m.
On Tuesday 11 November 2008 17:00:50 Jesse Keating wrote:
On Tue, 2008-11-11 at 08:43 +0000, Tony Molloy wrote:
> For a wired connection run the network service and disable the
> NetworkManager
> service.
This is just bad advice. Unless you need ipv6, or need advanced
networking features such as bridges, or are setting up a headless system
with static networking, NetworkManager is fine for both wireless and
wired. NetworkManager can have system wide connections configured that
will be brought up at boot time, both dhcp or static.
For the OPs laptop case, NM is even better as you can go from one
location where you're using wireless to another location, plug in a wire
and NetworkManager will automatically attempt to get an address from
that wire and allow you to use the wired network.
There are very few reasons and less each release to revert to the
'network' service.
Just realised - NM sees it as Auto eth1 - presumably the source of the problem
in my last message. I'm guessing that this means I have two network services
running and fighting it out. Maybe what I need now is some authoritative
advice on dealing with this. Here's what I've tried so far -
Stopped network service. Configured eth0 in NM applet - except that it still
says Auto eth1.
Rebooted - ifconfig tells me that I have eth1, but it is still on a dhcp
address, not the static one I defined in the NM applet.
Restarting network service says that eth0 is not present. How do I get it to
use the NM settings?
I see no sign of the wireless one at all now - it seems to have totally
disappeared.
Anne
1:36 p.m.
On Tue, 2008-11-11 at 19:25 +0000, Anne Wilson wrote:
Just realised - NM sees it as Auto eth1 - presumably the source of
the problem
in my last message. I'm guessing that this means I have two network services
running and fighting it out. Maybe what I need now is some authoritative
advice on dealing with this. Here's what I've tried so far -
Stopped network service. Configured eth0 in NM applet - except that it still
says Auto eth1.
Rebooted - ifconfig tells me that I have eth1, but it is still on a dhcp
address, not the static one I defined in the NM applet.
Restarting network service says that eth0 is not present. How do I get it to
use the NM settings?
I see no sign of the wireless one at all now - it seems to have totally
disappeared.
Look at /etc/sysconfig/network-scripts/ifcfg-eth0 file and see if
nm_controlled=yes is there, and if it has your dns/search type info, if
it gets dhcp or static, etc.. maybe post if need to. That file sort of
is main control between network device/the service/NM.
--
Mike Chambers
Fedora Project - Ambassador, Bug Zapper, Tester, User, etc..
mikec302(a)fedoraproject.org
1:48 p.m.
On Tuesday 11 November 2008 19:36:19 Mike Chambers wrote:
On Tue, 2008-11-11 at 19:25 +0000, Anne Wilson wrote:
> Just realised - NM sees it as Auto eth1 - presumably the source of the
> problem in my last message. I'm guessing that this means I have two
> network services running and fighting it out. Maybe what I need now is
> some authoritative advice on dealing with this. Here's what I've tried
> so far -
>
> Stopped network service. Configured eth0 in NM applet - except that it
> still says Auto eth1.
>
> Rebooted - ifconfig tells me that I have eth1, but it is still on a dhcp
> address, not the static one I defined in the NM applet.
>
> Restarting network service says that eth0 is not present. How do I get
> it to use the NM settings?
>
> I see no sign of the wireless one at all now - it seems to have totally
> disappeared.
Look at /etc/sysconfig/network-scripts/ifcfg-eth0 file and see if
nm_controlled=yes is there, and if it has your dns/search type info, if
it gets dhcp or static, etc.. maybe post if need to. That file sort of
is main control between network device/the service/NM.
ifcfg-eth0
#Realtek Semiconductor Co., Ltd. RTL8101E PCI Express Fast Ethernet Controller
DEVICE=eth0
BOOTPROTO=static
DNS1=212.23.3.100 GATEWAY=192.168.0.1
HWADDR=00:00:00:00:00:00
IPADDR=192.168.0.93
NETMASK=255.255.255.0
ONBOOT=yes
SEARCH="lydgate.lan"
NM_CONTROLLED=yes
(I have tried both yes and no on that last line)
Anne
1:29 p.m.
On Tue, Nov 11, 2008 at 07:48:25PM +0000, Anne Wilson wrote:
>
ifcfg-eth0
#Realtek Semiconductor Co., Ltd. RTL8101E PCI Express Fast Ethernet Controller
DEVICE=eth0
BOOTPROTO=static
DNS1=212.23.3.100 GATEWAY=192.168.0.1
HWADDR=00:00:00:00:00:00
^^^^^^^^^^^^^
Why that? Surely not right unless your hardware is broken.
You will likely fare better with HWADDR line removed.
Michal
6:09 a.m.
On Wed, 2008-11-12 at 12:29 -0700, Michal Jaegermann wrote:
On Tue, Nov 11, 2008 at 07:48:25PM +0000, Anne Wilson wrote:
> >
> ifcfg-eth0
>
> #Realtek Semiconductor Co., Ltd. RTL8101E PCI Express Fast Ethernet Controller
> DEVICE=eth0
> BOOTPROTO=static
> DNS1=212.23.3.100 GATEWAY=192.168.0.1
> HWADDR=00:00:00:00:00:00
^^^^^^^^^^^^^
Why that? Surely not right unless your hardware is broken.
You will likely fare better with HWADDR line removed.
I would guess on a side-effect of
https://bugzilla.redhat.com/show_bug.cgi?id=468360
or
https://bugzilla.redhat.com/show_bug.cgi?id=460747
Ralf
9:44 a.m.
On Thursday 13 November 2008 12:09:24 Ralf Corsepius wrote:
On Wed, 2008-11-12 at 12:29 -0700, Michal Jaegermann wrote:
> On Tue, Nov 11, 2008 at 07:48:25PM +0000, Anne Wilson wrote:
> > ifcfg-eth0
> >
> > #Realtek Semiconductor Co., Ltd. RTL8101E PCI Express Fast Ethernet
> > Controller DEVICE=eth0
> > BOOTPROTO=static
> > DNS1=212.23.3.100 GATEWAY=192.168.0.1
> > HWADDR=00:00:00:00:00:00
>
> ^^^^^^^^^^^^^
> Why that? Surely not right unless your hardware is broken.
>
> You will likely fare better with HWADDR line removed.
I would guess on a side-effect of
https://bugzilla.redhat.com/show_bug.cgi?id=468360
or
https://bugzilla.redhat.com/show_bug.cgi?id=460747
Or both. Both seem relevant to me. I have three kernels installed, so I
tried each, with the following results:
2.6.27.3-34 no wired or wireless connection
2.6.27.4-79 Wired connection ok, but WPA connection asks for WEP key
2.6.27.5-94 ditto
I guess that explains why my wired connection suddenly started working, but it
gets me no nearer with wireless, and a netbook loses its point without
wireless.
I know that the netbook uses a realtek wireless, but I can't remember where I
found the model. I did write everything down before wiping Linpus, but I'm
afraid I put it into the proverbial "safe place". I need to find that info
before I can add to the bug report.
Anne
10:28 a.m.
On Thu, Nov 13, 2008 at 03:44:26PM +0000, Anne Wilson wrote:
I know that the netbook uses a realtek wireless, but I can't remember where I
found the model.
'lspci -v' should give you all information about PCI devices it can
find although 'lspci -tv' output would be likely more useful on the
first blush. You can be also quite a bit more selective and/or
demanding. 'man lspci' for a lot of information.
I did write everything down before wiping Linpus, but I'm
afraid I put it into the proverbial "safe place".
Linux is rather good about finding such details so "safe places",
especially when they tend to go out-of-sync, are not that needed.
'dmesg' likely tells also all you need to know (and quite a bit
more).
Michal
12:25 p.m.
On Thursday 13 November 2008 16:28:36 Michal Jaegermann wrote:
On Thu, Nov 13, 2008 at 03:44:26PM +0000, Anne Wilson wrote:
> I know that the netbook uses a realtek wireless, but I can't remember
> where I found the model.
'lspci -v' should give you all information about PCI devices it can
find although 'lspci -tv' output would be likely more useful on the
first blush. You can be also quite a bit more selective and/or
demanding. 'man lspci' for a lot of information.
> I did write everything down before wiping Linpus, but I'm
> afraid I put it into the proverbial "safe place".
Linux is rather good about finding such details so "safe places",
especially when they tend to go out-of-sync, are not that needed.
'dmesg' likely tells also all you need to know (and quite a bit
more).
Thanks, Michal. I was mistaken. The wired connection is realtek and the
wireless is Atheros AR242x. I'll have to read the bug report again to see
whether it really is the same, although the symptoms sounded very similar.
Anne
12:34 p.m.
On Thu, 2008-11-13 at 18:25 +0000, Anne Wilson wrote:
Thanks, Michal. I was mistaken. The wired connection is realtek and
the
wireless is Atheros AR242x. I'll have to read the bug report again to see
whether it really is the same, although the symptoms sounded very similar.
By chance maybe Atheros wireless might have bugs or have you had this
running before? I had problems with realtek wireless before and was a
real hassle (especially when the driver was real flaky on top of that)
to get it going with NM. Had to manually get it going with network
service and such.
I would do as Jesse stated, and get the live-cd and use it and see if
doing it from scratch works and then compare files/settings to get the
installed working. Or to file bugs if it still doesn't?
--
Mike Chambers
Fedora Project - Ambassador, Bug Zapper, Tester, User, etc..
mikec302(a)fedoraproject.org
12:59 p.m.
On Thursday 13 November 2008 18:34:01 Mike Chambers wrote:
By chance maybe Atheros wireless might have bugs or have you had
this
running before?
When I first installed the rawhide snapshot, the wireless was working
perfectly, but the wired connection wasn't. The next kernel seems to have
been the critical point, when the wired connection started to work, but the
wireless wouldn't - and it never has since.
Anne
6:21 p.m.
On Thu, Nov 13, 2008 at 12:34:01PM -0600, Mike Chambers wrote:
I would do as Jesse stated, and get the live-cd and use it and see if
doing it from scratch works and then compare files/settings to get the
installed working. Or to file bugs if it still doesn't?
Just a note on this, both myself and one other fellow, on the Apsire
one, which is what I believe Anne is using, found that for some reason,
the LiveCD wouldn't connect properly (with NM or without) to a WPA2
network. An install and quick update fixed the issue--also, this was at
least a month ago, so if there's a newer kernel in the current live CD,
the results might be different.
In the very early 2.6.27 kernels, the ath5k was giving some people
(though not me) problems.
Ubuntu still has it blacklisted by default, I believe. (Judging from
Aspire One forums.)
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
Xander: The band, yeah. They're great. They march.
Willow: Like an army. Except with music, instead of bullets, and
usually no one dies.
6:10 a.m.
On Friday 14 November 2008 00:21:48 Scott Robbins wrote:
On Thu, Nov 13, 2008 at 12:34:01PM -0600, Mike Chambers wrote:
> I would do as Jesse stated, and get the live-cd and use it and see if
> doing it from scratch works and then compare files/settings to get the
> installed working. Or to file bugs if it still doesn't?
I found everything exactly as on my own setup. It accepts my WPA key then
requests a WEP key.
Just a note on this, both myself and one other fellow, on the Apsire
one, which is what I believe Anne is using, found that for some reason,
the LiveCD wouldn't connect properly (with NM or without) to a WPA2
network. An install and quick update fixed the issue--also, this was at
least a month ago, so if there's a newer kernel in the current live CD,
the results might be different.
Yes, this may be a kernel issue, because wireless worked when I installed out
of the box, but the cabled connection didn't. It may be that I have to go
back to the original kernel and manage without cabled altogether for the
present. That could be one solution. I will alter the number of kernels kept
(I can't remember, off-hand where that is, but I'm sure I'll find it).
Is there any way to make an older kernel the default boot?
Anne
In the very early 2.6.27 kernels, the ath5k was giving some people
(though not me) problems.
Ubuntu still has it blacklisted by default, I believe. (Judging from
Aspire One forums.)
6:24 a.m.
On Fri, Nov 14, 2008 at 12:10:40PM +0000, Anne Wilson wrote:
> Is there any way to make an older kernel the default
boot?
Yes, there's a line in /boot/grub/menu.lst towards the top. Usually it
reads Default=0 (or something similar--writing this from a BSD machine
so can't check the exact syntax.)
0 is the first entry, 1, the second, etc.
Just change the default to read 1 if you want to boot the older kernel,
which should be the second in the list of possible entries.
Assuming (which I'm only doing because you mentioned Linpus) that it's
the Aspire One, it's odd that wired isn't working. The only
distribution that gave me trouble with wired out of the box was CentOS,
due to an older version of the kernel driver. (There were workarounds,
detailed in my article on the CentOS wiki.)
Hrrm, I don't think I've tried wired and NM with it though.
Also, just for what it's worth (I don't know about NM) the 2.6.27
kernels typically refer to that card as wlan0 while the earlier kernels
that use the MadWifi driver will call it ath0.
I've only had my wireless automatically set as eth1 with Intel 2100
(although it's probably true for the 2200 as well) card. Again, this
is leaving NM out of the equation though, coming from the BSDs I'm just
more comfortable doing it by hand.
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
Angel: I've been around death before. A lot. I've lost
people. I've killed people...
Cordelia: And you are dead.
>
Yes, this may be a kernel issue, because wireless worked when I installed out
of the box, but the cabled connection didn't. It may be that I have to go
back to the original kernel and manage without cabled altogether for the
present. That could be one solution. I will alter the number of kernels kept
(I can't remember, off-hand where that is, but I'm sure I'll find it).
6:34 a.m.
On Friday 14 November 2008 12:24:06 Scott Robbins wrote:
On Fri, Nov 14, 2008 at 12:10:40PM +0000, Anne Wilson wrote:
> Yes, this may be a kernel issue, because wireless worked when I installed
> out of the box, but the cabled connection didn't. It may be that I have
> to go back to the original kernel and manage without cabled altogether
> for the present. That could be one solution. I will alter the number of
> kernels kept (I can't remember, off-hand where that is, but I'm sure
I'll
> find it).
>
>
>
> Is there any way to make an older kernel the default boot?
Yes, there's a line in /boot/grub/menu.lst towards the top. Usually it
reads Default=0 (or something similar--writing this from a BSD machine
so can't check the exact syntax.)
0 is the first entry, 1, the second, etc.
Just change the default to read 1 if you want to boot the older kernel,
which should be the second in the list of possible entries.
OK, thanks. That's what I needed to know. It used to be so in lilo :-)
If I get no further today I'll try that for a day or two, just buying time,
really. I have exactly two weeks to get a working distro, fedora or not. And
oddly enough I do have a life out side this :-)
Assuming (which I'm only doing because you mentioned Linpus) that
it's
the Aspire One, it's odd that wired isn't working.
It wasn't with that one kernel (from snapshot 3, I think it was). The next
kernel install got the wired working - and stopped the wireless working. It's
never worked since.
The only
distribution that gave me trouble with wired out of the box was CentOS,
due to an older version of the kernel driver. (There were workarounds,
detailed in my article on the CentOS wiki.)
Hrrm, I don't think I've tried wired and NM with it though.
Also, just for what it's worth (I don't know about NM) the 2.6.27
kernels typically refer to that card as wlan0 while the earlier kernels
that use the MadWifi driver will call it ath0.
Yes, I realise that.
I've only had my wireless automatically set as eth1 with Intel
2100
(although it's probably true for the 2200 as well) card. Again, this
is leaving NM out of the equation though, coming from the BSDs I'm just
more comfortable doing it by hand.
This laptop has Intel 2200, and yes, it's eth1.
Anne
6:35 a.m.
<Snip>
....
</Snip>
Yes, this may be a kernel issue, because wireless worked when I
installed out
of the box, but the cabled connection didn't. It may be that I have to go
back to the original kernel and manage without cabled altogether for the
present. That could be one solution. I will alter the number of kernels kept
(I can't remember, off-hand where that is, but I'm sure I'll find it).
Is there any way to make an older kernel the default boot?
Just change the "default=0" line in /etc/grub.conf
Counts from the top entry being the 0 for example..
default=0
timeout=0
chaintimeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
Title Fedora <kernel version X>
root (hd0,0)
kernel # first to boot as in this is 0
Title Fedora <kernel version Y>
root (hd0,0)
kernel # second to boot change the default=0 to default=1 to boot
this one by default
Title Fedora <kernel version Z>
root (hd0,0)
kernel # Third to boot change the default=0 to default=2 to boot
this one by default
And so fourth..
JBG
6:43 a.m.
On Friday 14 November 2008 12:35:37 Jóhann B. Guðmundsson wrote:
<Snip>
....
</Snip>
> Yes, this may be a kernel issue, because wireless worked when I installed
> out of the box, but the cabled connection didn't. It may be that I have
> to go back to the original kernel and manage without cabled altogether
> for the present. That could be one solution. I will alter the number of
> kernels kept (I can't remember, off-hand where that is, but I'm sure
I'll
> find it).
>
> Is there any way to make an older kernel the default boot?
Just change the "default=0" line in /etc/grub.conf
Counts from the top entry being the 0 for example..
default=0
timeout=0
chaintimeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
Title Fedora <kernel version X>
root (hd0,0)
kernel # first to boot as in this is 0
Title Fedora <kernel version Y>
root (hd0,0)
kernel # second to boot change the default=0 to default=1 to boot
this one by default
Title Fedora <kernel version Z>
root (hd0,0)
kernel # Third to boot change the default=0 to default=2 to boot
this one by default
Thanks Johann
Anne
7:51 a.m.
Anne Wilson wrote:
On Friday 14 November 2008 12:35:37 Jóhann B. Guðmundsson wrote:
> <Snip>
> ....
> </Snip>
>
>
>> Yes, this may be a kernel issue, because wireless worked when I installed
>> out of the box, but the cabled connection didn't. It may be that I have
>> to go back to the original kernel and manage without cabled altogether
>> for the present. That could be one solution. I will alter the number of
>> kernels kept (I can't remember, off-hand where that is, but I'm sure
I'll
>> find it).
>>
>> Is there any way to make an older kernel the default boot?
>>
> Just change the "default=0" line in /etc/grub.conf
>
> Counts from the top entry being the 0 for example..
>
> default=0
> timeout=0
> chaintimeout=5
> splashimage=(hd0,0)/grub/splash.xpm.gz
> hiddenmenu
>
> Title Fedora <kernel version X>
> root (hd0,0)
> kernel # first to boot as in this is 0
>
> Title Fedora <kernel version Y>
> root (hd0,0)
> kernel # second to boot change the default=0 to default=1 to boot
> this one by default
>
> Title Fedora <kernel version Z>
> root (hd0,0)
> kernel # Third to boot change the default=0 to default=2 to boot
> this one by default
>
>
Thanks Johann
Anne
Anne could you test kernel 2.6.27. 4-79
and see if it works..
( http://koji.fedoraproject.org/koji/buildinfo?buildID=68527 )
Then test with 2.6.27.4-100 and see it if breaks..
( http://koji.fedoraproject.org/koji/buildinfo?buildID=69310 )
Wondering if -83 and or -85 are breaking this..
JBG
9:05 a.m.
On Friday 14 November 2008 13:51:34 Jóhann B. Guðmundsson wrote:
Anne could you test kernel 2.6.27. 4-79
and see if it works..
( http://koji.fedoraproject.org/koji/buildinfo?buildID=68527 )
I already had that kernel and had checked it.
Then test with 2.6.27.4-100 and see it if breaks..
( http://koji.fedoraproject.org/koji/buildinfo?buildID=69310 )
So I installed this one and checked it.
Wondering if -83 and or -85 are breaking this..
Results:
2.6.27.3-34 no wired or wireless connection
2.6.27.4-79 Wired connection ok, but WPA connection asks for WEP key
2.6.27.5-94 ditto
2.6.27.5-100 ditto
(Just realised that you said 4-100 and I have 5-100 - is that what you
intended?)
Note that when the WPA connection fails it brings up a dialogue box asking for
the WEP key. Unlike the first dialogue, this is restricted to 4 WEP entries -
there is no option to enter a WPA key.
Maybe I've already lost the kernel that was installed by the snapshot. That,
presumably, was prior to 2.6.27.3-34 - and wireless did work, but wired didn't
when I first installed.
HTH
Anne
Anne
9:11 a.m.
On Friday 14 November 2008 15:05:10 Anne Wilson wrote:
On Friday 14 November 2008 13:51:34 Jóhann B. Guðmundsson wrote:
> Anne could you test kernel 2.6.27. 4-79
> and see if it works..
> ( http://koji.fedoraproject.org/koji/buildinfo?buildID=68527 )
I already had that kernel and had checked it.
> Then test with 2.6.27.4-100 and see it if breaks..
> ( http://koji.fedoraproject.org/koji/buildinfo?buildID=69310 )
So I installed this one and checked it.
> Wondering if -83 and or -85 are breaking this..
Results:
2.6.27.3-34 no wired or wireless connection
2.6.27.4-79 Wired connection ok, but WPA connection asks for WEP key
2.6.27.5-94 ditto
2.6.27.5-100 ditto
(Just realised that you said 4-100 and I have 5-100 - is that what you
intended?)
Note that when the WPA connection fails it brings up a dialogue box asking
for the WEP key. Unlike the first dialogue, this is restricted to 4 WEP
entries - there is no option to enter a WPA key.
Maybe I've already lost the kernel that was installed by the snapshot.
That, presumably, was prior to 2.6.27.3-34 - and wireless did work, but
wired didn't when I first installed.
I've just seen that I have kernel-firmware.noarch 2.6.27.5-101.fc10.
Shouldn't that match the kernel?
Anne
9:36 a.m.
On Fri, Nov 14, 2008 at 03:11:26PM +0000, Anne Wilson wrote:
On Friday 14 November 2008 15:05:10 Anne Wilson wrote:
> On Friday 14 November 2008 13:51:34 Jóhann B. Guðmundsson wrote:
> > Anne could you test kernel 2.6.27. 4-79
> > and see if it works..
> > ( http://koji.fedoraproject.org/koji/buildinfo?buildID=68527 )
>
> I already had that kernel and had checked it.
>
> > Then test with 2.6.27.4-100 and see it if breaks..
> > ( http://koji.fedoraproject.org/koji/buildinfo?buildID=69310 )
>
> So I installed this one and checked it.
>
> > Wondering if -83 and or -85 are breaking this..
>
> Results:
>
> 2.6.27.3-34 no wired or wireless connection
> 2.6.27.4-79 Wired connection ok, but WPA connection asks for WEP key
> 2.6.27.5-94 ditto
> 2.6.27.5-100 ditto
>
> (Just realised that you said 4-100 and I have 5-100 - is that what you
> intended?)
>
> Note that when the WPA connection fails it brings up a dialogue box asking
> for the WEP key. Unlike the first dialogue, this is restricted to 4 WEP
> entries - there is no option to enter a WPA key.
>
> Maybe I've already lost the kernel that was installed by the snapshot.
> That, presumably, was prior to 2.6.27.3-34 - and wireless did work, but
> wired didn't when I first installed.
>
I've just seen that I have kernel-firmware.noarch 2.6.27.5-101.fc10.
Shouldn't that match the kernel?
It should be >= the kernel you have.
The condition I'm trying to have you capture with the "iwlist
scanning" and "nm-tool" output is the one where you get a dialog box
asking for a WEP key.
10:26 a.m.
On Friday 14 November 2008 15:36:20 Chuck Anderson wrote:
On Fri, Nov 14, 2008 at 03:11:26PM +0000, Anne Wilson wrote:
>
> I've just seen that I have kernel-firmware.noarch 2.6.27.5-101.fc10.
> Shouldn't that match the kernel?
It should be >= the kernel you have.
OK - that's fine, then.
The condition I'm trying to have you capture with the
"iwlist
scanning" and "nm-tool" output is the one where you get a dialog box
asking for a WEP key.
By now this thread is so long and convulated that it's hard to follow.
Another post is already on its way that may give you more clues.
Anne
7:16 a.m.
--- On Fri, 11/14/08, Anne Wilson <cannewilson(a)googlemail.com> wrote:
From: Anne Wilson <cannewilson(a)googlemail.com>
Subject: Re: Problem setting up wired networking
To: "For testers of Fedora Core development releases"
<fedora-test-list(a)redhat.com>
Date: Friday, November 14, 2008, 4:10 AM
On Friday 14 November 2008 00:21:48 Scott Robbins wrote:
> On Thu, Nov 13, 2008 at 12:34:01PM -0600, Mike
Chambers wrote:
> > I would do as Jesse stated, and get the live-cd
and use it and see if
> > doing it from scratch works and then compare
files/settings to get the
> > installed working. Or to file bugs if it still
doesn't?
>
I found everything exactly as on my own setup. It accepts
my WPA key then
requests a WEP key.
> Just a note on this, both myself and one other fellow,
on the Apsire
> one, which is what I believe Anne is using, found that
for some reason,
> the LiveCD wouldn't connect properly (with NM or
without) to a WPA2
> network. An install and quick update fixed the
issue--also, this was at
> least a month ago, so if there's a newer kernel in
the current live CD,
> the results might be different.
>
Yes, this may be a kernel issue, because wireless worked
when I installed out
of the box, but the cabled connection didn't. It may
be that I have to go
back to the original kernel and manage without cabled
altogether for the
present. That could be one solution. I will alter the
number of kernels kept
(I can't remember, off-hand where that is, but I'm
sure I'll find it).
[root@localhost ~]# cat /etc/yum.conf
[main]
cachedir=/var/cache/yum
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
metadata_expire=1800
installonly_limit=4 <==== Here change the limit default is 3 :)
# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d
[root@localhost ~]#
installonly_limit=4 change this one and you are in business :)
Is there any way to make an older kernel the default boot?
Change the default in
/boot/grub/grub.conf to a kernel that was working :)
default=0 is the first kernel, 1 is the second and so forth. Change default=X where is
the line of the kernel that you want to boot
[root@localhost ~]# cat /boot/grub/grub.conf
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,1)
# kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00 rhgb quiet
# initrd /initrd-version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,1)/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.27.5-101.fc10.i686)
root (hd0,1)
kernel /vmlinuz-2.6.27.5-101.fc10.i686 ro root=/dev/VolGroup00/LogVol00
initrd /initrd-2.6.27.5-101.fc10.i686.img
title Fedora (2.6.26.6-79.fc9.i686)
root (hd0,1)
kernel /vmlinuz-2.6.26.6-79.fc9.i686 ro root=/dev/VolGroup00/LogVol00
initrd /initrd-2.6.26.6-79.fc9.i686.img
title Fedora (2.6.26.3-29.fc9.i686)
root (hd0,1)
kernel /vmlinuz-2.6.26.3-29.fc9.i686 ro root=/dev/VolGroup00/LogVol00
initrd /initrd-2.6.26.3-29.fc9.i686.img
title Fedora (2.6.25.14-108.fc9.i686)
root (hd0,1)
kernel /vmlinuz-2.6.25.14-108.fc9.i686 ro root=/dev/VolGroup00/LogVol00
initrd /initrd-2.6.25.14-108.fc9.i686.img
Anne
> In the very early 2.6.27 kernels, the ath5k was giving
some people
> (though not me) problems.
> Ubuntu still has it blacklisted by default, I believe.
(Judging from
> Aspire One forums.)
>
>
--
fedora-test-list mailing list
fedora-test-list(a)redhat.com
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
HTH,
Antonio
7:41 a.m.
On Friday 14 November 2008 13:16:17 Antonio Olivares wrote:
> Yes, this may be a kernel issue, because wireless worked
> when I installed out
> of the box, but the cabled connection didn't. It may
> be that I have to go
> back to the original kernel and manage without cabled
> altogether for the
> present. That could be one solution. I will alter the
> number of kernels kept
> (I can't remember, off-hand where that is, but I'm
> sure I'll find it).
[root@localhost ~]# cat /etc/yum.conf
[main]
cachedir=/var/cache/yum
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
metadata_expire=1800
installonly_limit=4 <==== Here change the limit default is 3 :)
# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d
[root@localhost ~]#
installonly_limit=4 change this one and you are in business :)
OK, thanks. I can always remove some of them later by reducing the number.
Anne
9:32 a.m.
On Friday 14 November 2008 00:21:48 Scott Robbins wrote:
On Thu, Nov 13, 2008 at 12:34:01PM -0600, Mike Chambers wrote:
> I would do as Jesse stated, and get the live-cd and use it and see if
> doing it from scratch works and then compare files/settings to get the
> installed working. Or to file bugs if it still doesn't?
Just a note on this, both myself and one other fellow, on the Apsire
one, which is what I believe Anne is using, found that for some reason,
the LiveCD wouldn't connect properly (with NM or without) to a WPA2
network. An install and quick update fixed the issue--also, this was at
least a month ago, so if there's a newer kernel in the current live CD,
the results might be different.
I meant to ask, at the time, what you meant by "An install and quick update
fixed the issue"
Anne
10:14 a.m.
On Mon, Nov 17, 2008 at 03:32:30PM +0000, Anne Wilson wrote:
On Friday 14 November 2008 00:21:48 Scott Robbins wrote:
> Just a note on this, both myself and one other fellow, on the
Apsire
> one, which is what I believe Anne is using, found that for some reason,
> the LiveCD wouldn't connect properly (with NM or without) to a WPA2
> network. An install and quick update fixed the issue--also, this was at
> least a month ago, so if there's a newer kernel in the current live CD,
> the results might be different.
>
I meant to ask, at the time, what you meant by "An install and quick update
fixed the issue"
I'm sorry, mental shorthand as usual.
That is, we tried the liveCD. We then installed from the liveCD and ran
(using the wired ethernet, which worked for us) yum update.
When that was done, the newer kernel (and possibly other updated
programs) enabled us to use our wireless cards.
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
Cordelia: Buffy, these men are rich, and I am not being
shallow. Think of all the
poor people I could help with all my money.
10:33 a.m.
On Monday 17 November 2008 16:14:28 Scott Robbins wrote:
On Mon, Nov 17, 2008 at 03:32:30PM +0000, Anne Wilson wrote:
> On Friday 14 November 2008 00:21:48 Scott Robbins wrote:
> > Just a note on this, both myself and one other fellow, on the Apsire
> > one, which is what I believe Anne is using, found that for some reason,
> > the LiveCD wouldn't connect properly (with NM or without) to a WPA2
> > network. An install and quick update fixed the issue--also, this was
> > at least a month ago, so if there's a newer kernel in the current live
> > CD, the results might be different.
>
> I meant to ask, at the time, what you meant by "An install and quick
> update fixed the issue"
I'm sorry, mental shorthand as usual.
That is, we tried the liveCD. We then installed from the liveCD and ran
(using the wired ethernet, which worked for us) yum update.
When that was done, the newer kernel (and possibly other updated
programs) enabled us to use our wireless cards.
Hmm - I was clutching at straws, but I guess that your situation was quite
different from mine, then. Thanks for answering
Anne
6:08 p.m.
On Thu, Nov 13, 2008 at 06:25:56PM +0000, Anne Wilson wrote:
On Thursday 13 November 2008 16:28:36 Michal Jaegermann wrote:
Thanks, Michal. I was mistaken. The wired connection is realtek and
the
wireless is Atheros AR242x. I'll have to read the bug report again to see
whether it really is the same, although the symptoms sounded very similar.
See my earlier post. That one is fairly trivial now and your Linpus
settings wouldn't have helped you. (Different kernel, different way of
doing it.)
If you want to do it manually, I have a page that has a link to an
excellent howto at
http://home.roadrunner.com/~computertaijutsu/rhwireless.html
Look for the link to the tutorial by the gentleman named Mike.
There's a great deal on the page about your card as well, but it's
almost all unnecessary with the 2.6.27 kernel, which supports it with
the ath5k module.
Note that the page has nothing to do with NM, it's just about
configuring the card through various command line tools and files.
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
Angel: Acathla turned to stone, as demons sometimes do, and
was buried
where neither man nor demon would want to look...unless, of course,
they're
putting up low-rent housing.
5:07 a.m.
On Friday 14 November 2008 00:08:00 Scott Robbins wrote:
On Thu, Nov 13, 2008 at 06:25:56PM +0000, Anne Wilson wrote:
> On Thursday 13 November 2008 16:28:36 Michal Jaegermann wrote:
>
>
> Thanks, Michal. I was mistaken. The wired connection is realtek and the
> wireless is Atheros AR242x. I'll have to read the bug report again to
> see whether it really is the same, although the symptoms sounded very
> similar.
See my earlier post. That one is fairly trivial now and your Linpus
settings wouldn't have helped you. (Different kernel, different way of
doing it.)
If you want to do it manually, I have a page that has a link to an
excellent howto at
http://home.roadrunner.com/~computertaijutsu/rhwireless.html
Look for the link to the tutorial by the gentleman named Mike.
There's a great deal on the page about your card as well, but it's
almost all unnecessary with the 2.6.27 kernel, which supports it with
the ath5k module.
Note that the page has nothing to do with NM, it's just about
configuring the card through various command line tools and files.
I'm reaching the end of my patience. I've struggled with this all week.
Now,
trying to connect with wpa_supplicant I get selinux denials. It tells me to
run a restorecon - which doesn't work. I'll turn it to permissive for now and
see if I can get any further. If I don't get anywhere today I'm bailing out.
There's a limit to how much time I can give this, when I know I can get other
distros working.
Anne
2:12 p.m.
I read your howto good work!
On Fri, Nov 14, 2008 at 6:07 AM, Anne Wilson <cannewilson(a)googlemail.com>wrote:
On Friday 14 November 2008 00:08:00 Scott Robbins wrote:
> On Thu, Nov 13, 2008 at 06:25:56PM +0000, Anne Wilson wrote:
> > On Thursday 13 November 2008 16:28:36 Michal Jaegermann wrote:
> >
> >
> > Thanks, Michal. I was mistaken. The wired connection is realtek and
the
> > wireless is Atheros AR242x. I'll have to read the bug report again to
> > see whether it really is the same, although the symptoms sounded very
> > similar.
>
> See my earlier post. That one is fairly trivial now and your Linpus
> settings wouldn't have helped you. (Different kernel, different way of
> doing it.)
>
> If you want to do it manually, I have a page that has a link to an
> excellent howto at
>
http://home.roadrunner.com/~computertaijutsu/rhwireless.html<http://ho...
>
> Look for the link to the tutorial by the gentleman named Mike.
>
>
> There's a great deal on the page about your card as well, but it's
> almost all unnecessary with the 2.6.27 kernel, which supports it with
> the ath5k module.
>
> Note that the page has nothing to do with NM, it's just about
> configuring the card through various command line tools and files.
>
>
I'm reaching the end of my patience. I've struggled with this all week.
Now,
trying to connect with wpa_supplicant I get selinux denials. It tells me
to
run a restorecon - which doesn't work. I'll turn it to permissive for now
and
see if I can get any further. If I don't get anywhere today I'm bailing
out.
There's a limit to how much time I can give this, when I know I can get
other
distros working.
Anne
--
fedora-test-list mailing list
fedora-test-list(a)redhat.com
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
4:13 p.m.
On Fri, Nov 14, 2008 at 08:28:17PM +0000, Anne Wilson wrote:
On Friday 14 November 2008 20:12:04 Michael Francis wrote:
> I read your howto good work!
>
Not mine, but I agree it's excellent.
I've lost track here too. If you mean mine, it's more applicable to F9
users as it's mostly about MadWifi. (But thank you.)
If you mean the gentleman Mike, who wrote the detailed one that's linked
from my page, I'll pass it along and I'm sure he'll be pleased.
If you meant neither, then, I've just acted like Ben Stiller in
Zoolander, standing up to take the award that wasn't his, in which case,
as I don't have a coal mining family to return to, I'll simply feel
silly. :)
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
Buffy: Look, I know this new guy's a dork,
but... Well, I have nothing to follow that. He's
pretty much just a dork.
3:40 a.m.
On Friday 14 November 2008 22:13:26 Scott Robbins wrote:
On Fri, Nov 14, 2008 at 08:28:17PM +0000, Anne Wilson wrote:
> On Friday 14 November 2008 20:12:04 Michael Francis wrote:
> > I read your howto good work!
>
> Not mine, but I agree it's excellent.
I've lost track here too. If you mean mine, it's more applicable to F9
users as it's mostly about MadWifi. (But thank you.)
If you mean the gentleman Mike, who wrote the detailed one that's linked
from my page, I'll pass it along and I'm sure he'll be pleased.
If you meant neither, then, I've just acted like Ben Stiller in
Zoolander, standing up to take the award that wasn't his, in which case,
as I don't have a coal mining family to return to, I'll simply feel
silly. :)
And if we mean both? Seriously, thank you to both of you.
Anne
4:50 a.m.
On Sat, Nov 15, 2008 at 09:40:03AM +0000, Anne Wilson wrote:
On Friday 14 November 2008 22:13:26 Scott Robbins wrote:
<snip re which Howto>
> If you meant neither, then, I've just acted like Ben Stiller
in
> Zoolander, standing up to take the award that wasn't his, in which case,
>
And if we mean both? Seriously, thank you to both of you.
In that case, I'm sure I speak for Mike as well when I say that trite
though it sounds, it's reading such things that make the effort of
writing and maintaining such pages worthwhile. Thank you and we're glad
you've found them useful.
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
Angel: Acathla turned to stone, as demons sometimes do, and
was buried
where neither man nor demon would want to look...unless, of course,
they're
putting up low-rent housing.
8:31 a.m.
On Friday 14 November 2008 00:08:00 Scott Robbins wrote:
If you want to do it manually, I have a page that has a link to an
excellent howto at
http://home.roadrunner.com/~computertaijutsu/rhwireless.html
Look for the link to the tutorial by the gentleman named Mike.
There's a great deal on the page about your card as well, but it's
almost all unnecessary with the 2.6.27 kernel, which supports it with
the ath5k module.
Note that the page has nothing to do with NM, it's just about
configuring the card through various command line tools and files.
So basically, it is describing an alternative to NM
for establishing a WiFi connection?
(It wasn't clear to me if it is recommended for all WiFi cards,
or just for the ones listed.)
5:57 p.m.
On Thu, Nov 13, 2008 at 09:28:36AM -0700, Michal Jaegermann wrote:
On Thu, Nov 13, 2008 at 03:44:26PM +0000, Anne Wilson wrote:
>
> I know that the netbook uses a realtek wireless, but I can't remember where I
> found the model.
'lspci -v' should give you all information about PCI devices it can
find although 'lspci -tv' output would be likely more useful on the
first blush. You can be also quite a bit more selective and/or
demanding. 'man lspci' for a lot of information.
Unfortunately, it's not always accurate, especially with newer cards.
For example, for a long time, it was identifying the unsupported
AR5007EG as the supported (at least by MadWifi at the time) AR5006EG.
Even now, it usually says something like AR242 something or other.
> I did write everything down before wiping Linpus, but I'm
> afraid I put it into the proverbial "safe place".
Oh dear, you used Linpus? What netbook was this? I thought Acer was
the only one using Linpus. If this is the Aspire one, it's fairly easy
to get working.
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
Spike: You won. Alright? You came in and you killed them,
and you took their land. That's what conquering nations do. It's
what Caeser did, and he's not going around saying I came, I conquered,
I felt really bad about it.
9:36 a.m.
On Thursday 13 November 2008 23:57:57 Scott Robbins wrote:
Oh dear, you used Linpus? What netbook was this? I thought Acer was
the only one using Linpus. If this is the Aspire one, it's fairly easy
to get working.
:-( It is the Aspire One, and after struggling for a whole week now I still
haven't got it working.
Anne
1:55 a.m.
On Tuesday 11 November 2008 17:00:50 Jesse Keating wrote:
On Tue, 2008-11-11 at 08:43 +0000, Tony Molloy wrote:
> For a wired connection run the network service and disable the
> NetworkManager
> service.
This is just bad advice. Unless you need ipv6, or need advanced
networking features such as bridges, or are setting up a headless system
with static networking, NetworkManager is fine for both wireless and
wired. NetworkManager can have system wide connections configured that
will be brought up at boot time, both dhcp or static.
Don't know about you but I have never had NetworkManager bring up wired
connections with static IP addresses correctly on boot. I works fine for
wireless dhcp addresses.
Regards,
Tony
For the OPs laptop case, NM is even better as you can go from one
location where you're using wireless to another location, plug in a wire
and NetworkManager will automatically attempt to get an address from
that wire and allow you to use the wired network.
There are very few reasons and less each release to revert to the
'network' service.
2:26 a.m.
On Wed, 2008-11-12 at 07:55 +0000, Tony Molloy wrote:
Don't know about you but I have never had NetworkManager bring up
wired
connections with static IP addresses correctly on boot. I works fine for
wireless dhcp addresses.
I was using the network service (just recently matter of fact) , but
with Jesse's statement I thought I would give it a shot again and try it
out (that, and I was performming a new rawhide install last night). So
far it is working, and I am using static IP, bit wired on a desktop.
Mounts my nfs shared dir as well on every boot.
I've seen it fail before and recently in the past few weeks it has but
as of now it doesn.t
P.S. The only failure so far, is doing a general default install via GUI
and trying to enter static IP network info and get an error. Only way
to get around it (without using dhcp) was to use askmethod during boot
up and that configures my connection just fine.
--
Mike Chambers
Fedora Project - Ambassador, Bug Zapper, Tester, User, etc..
mikec302(a)fedoraproject.org
11:31 a.m.
On Tue, Nov 11, 2008 at 07:40:14AM +0000, Anne Wilson wrote:
Networking is the one aspect of Fedora that always confuses me.
It seems to me that on a laptop I want/need NetworkManager to work
with wifi wherever I am working.
Usually wifi gets its addresses through DHCP and you want for
that NetworkManager running.
OTOH, at home I would generally want to work with wired.
If you are in control of a corresponding DHCP server (a big IF) then
the the easiest way is to, _on that server_, lock up a particular IP
number to a MAC address of a wired interface of your laptop,
configure that interface for DHCP and sick NetworkMangler on it.
That way if you are using a wired connection away from home you have
a huge chance that it will work "automagically" too and at home you
still can find your laptop always at the same address. If you do
not care about the same address then disregard "locking" and just
use DHCP.
Home routers usually come with a DHCP server (and for sure if they
have wireless interfaces too) but how configurable that is another
question. If you have a "server type" box on your home network then
you can run your own DHCP server on it as well and that you can
configure until cows come home ('man dhcpd.conf'). Turn off then
that one on a router so they will not compete
If DHCP on a wired interface is not an option then you need
'network' service running as well. Make sure that in corresponding
/etc/sysconfig/network-scripts/ifcfg-ethX there is a line
'NM_CONTROLLED=no'. system-config-network will put that for you,
eventually, and that what the quoted earlier bug was about.
Missing such line amount to 'NM_CONTROLLED=yes' but for your own
sanity in the future you may want to be explicit about it.
Now NM used to have a bug that it ignored NM_CONTROLLED
configuration and was grabbing wrong interfaces too. If that
is still present in F10 or not I do not know. It is a serious
obstacle if there and if NM is used at all forces you into a DHCP
configuration on all interfaces.
Can you
please spell out for me which services I should be using?
And now Jesse Keating will tell you that this is so simple that it
is an envy of the world. As a matter of fact he already did.
Michal
11:45 a.m.
On Tue, Nov 11, 2008 at 10:31:22AM -0700, Michal Jaegermann wrote:
On Tue, Nov 11, 2008 at 07:40:14AM +0000, Anne Wilson wrote:
>
Now NM used to have a bug that it ignored NM_CONTROLLED
configuration and was grabbing wrong interfaces too. If that
is still present in F10 or not I do not know. It is a serious
obstacle if there and if NM is used at all forces you into a DHCP
configuration on all interfaces.
> Can you
> please spell out for me which services I should be using?
And now Jesse Keating will tell you that this is so simple that it
is an envy of the world. As a matter of fact he already did.
As long as they don't forget that some of us boot into text mode and
prefer fluxbox for our WM.
(Actually, I haven't used NM in a while, but I suspect it still expects
some sort of GUI, doesn't it?)
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
Buffy: Are you crazy? You just don't sneak up on people in a
graveyard. You make noise when you walk, you stomp, or... yodel.
1:39 p.m.
On Tuesday 11 November 2008 17:31:22 Michal Jaegermann wrote:
On Tue, Nov 11, 2008 at 07:40:14AM +0000, Anne Wilson wrote:
> Networking is the one aspect of Fedora that always confuses me.
> It seems to me that on a laptop I want/need NetworkManager to work
> with wifi wherever I am working.
Usually wifi gets its addresses through DHCP and you want for
that NetworkManager running.
> OTOH, at home I would generally want to work with wired.
If you are in control of a corresponding DHCP server (a big IF) then
the the easiest way is to, _on that server_, lock up a particular IP
number to a MAC address of a wired interface of your laptop,
configure that interface for DHCP and sick NetworkMangler on it.
That way if you are using a wired connection away from home you have
a huge chance that it will work "automagically" too and at home you
still can find your laptop always at the same address.
My router does handle dhcp, and yes, you can reserve addresses. Unfortunately
it seems to be aware of the present conflict. It lists the new laptop with
the dhcp address, but when I tell it that I want it to reserve a different
address (the one that I gave to NM) it tells me that that address already
exists. I guess I have to get the conflicts sorted out first, then I'll be
able to do this.
If you do
not care about the same address then disregard "locking" and just
use DHCP.
If I reserve the address I could use dhcp. I want a static address, one way
or another, so that when I read the logs I know which computer it is referring
to.
Home routers usually come with a DHCP server (and for sure if they
have wireless interfaces too) but how configurable that is another
question. If you have a "server type" box on your home network then
you can run your own DHCP server on it as well and that you can
configure until cows come home ('man dhcpd.conf'). Turn off then
that one on a router so they will not compete
If DHCP on a wired interface is not an option then you need
'network' service running as well. Make sure that in corresponding
/etc/sysconfig/network-scripts/ifcfg-ethX there is a line
'NM_CONTROLLED=no'. system-config-network will put that for you,
eventually, and that what the quoted earlier bug was about.
Missing such line amount to 'NM_CONTROLLED=yes' but for your own
sanity in the future you may want to be explicit about it.
It did have 'NM_CONTROLLED=yes' but I had changed it. Now I'm unsure
as to
whether NM should control it or not.
Now NM used to have a bug that it ignored NM_CONTROLLED
configuration and was grabbing wrong interfaces too. If that
is still present in F10 or not I do not know. It is a serious
obstacle if there and if NM is used at all forces you into a DHCP
configuration on all interfaces.
> Can you
> please spell out for me which services I should be using?
And now Jesse Keating will tell you that this is so simple that it
is an envy of the world. As a matter of fact he already did.
I'm sure that it is good when it is working correctly, but it really is
confusing. I've struggled with this every time I do a fedora install. Jesse
does know what he's talking about, so I hope he is going to give me some fool-
proof instruction :-)
Anne
2:36 p.m.
On Tue, Nov 11, 2008 at 07:39:36PM +0000, Anne Wilson wrote:
On Tuesday 11 November 2008 17:31:22 Michal Jaegermann wrote:
> On Tue, Nov 11, 2008 at 07:40:14AM +0000, Anne Wilson wrote:
> > Networking is the one aspect of Fedora that always confuses me.
> > It seems to me that on a laptop I want/need NetworkManager to work
> > with wifi wherever I am working.
>
> Usually wifi gets its addresses through DHCP and you want for
> that NetworkManager running.
>
> > OTOH, at home I would generally want to work with wired.
>
> If you are in control of a corresponding DHCP server (a big IF) then
> the the easiest way is to, _on that server_, lock up a particular IP
> number to a MAC address of a wired interface of your laptop,
....
My router does handle dhcp, and yes, you can reserve addresses.
Very good.
Unfortunately
it seems to be aware of the present conflict. It lists the new laptop with
the dhcp address, but when I tell it that I want it to reserve a different
address (the one that I gave to NM) it tells me that that address already
exists.
I think that you misconfigured something.
On your router:
- ask it to give always the same address for a specific MAC
(which will be a MAC of a wired interface of your laptop)
- that address you want to reserve should be from a pool of
addresses which your router gives out via DHCP
- if this is a wireless router then you can reseve an address for
your laptop wifi interface too and that will be a different MAC
and a different address than above
On your laptop:
- configure your wired interface to be handled by DHCP and that
means that you do NOT give any specific address; it will always
get one you reserved on your router anyway
- let NM handle all interfaces; i.e. 'BOOTPROTO=dhcp' and
'NM_CONTROLLED=yes' for every interface configuration file.
- 'service network stop; chkconfig network off' and make sure
that NM service is on and running
That is the simplest and the most flexible - in a sense. It only
depends on capabilities of your DHCP server but you are telling that
yours is "good enough".
Your router, quite sensibly, may not like to reserve an address
which is already in use; especially if it was not given out by a
DHCP lease. It sounds like a resonable sanity checking. :-)
If I reserve the address I could use dhcp. I want a static
address, one way or another, so that when I read the logs I know
which computer it is referring to.
Nominally this address will be not "static" as it will require
a DHCP lease; but with the above it will be always the same.
Michal
2:59 p.m.
On Tuesday 11 November 2008 20:36:26 Michal Jaegermann wrote:
On Tue, Nov 11, 2008 at 07:39:36PM +0000, Anne Wilson wrote:
> On Tuesday 11 November 2008 17:31:22 Michal Jaegermann wrote:
> > On Tue, Nov 11, 2008 at 07:40:14AM +0000, Anne Wilson wrote:
> > > Networking is the one aspect of Fedora that always confuses me.
> > > It seems to me that on a laptop I want/need NetworkManager to work
> > > with wifi wherever I am working.
> >
> > Usually wifi gets its addresses through DHCP and you want for
> > that NetworkManager running.
> >
> > > OTOH, at home I would generally want to work with wired.
> >
> > If you are in control of a corresponding DHCP server (a big IF) then
> > the the easiest way is to, _on that server_, lock up a particular IP
> > number to a MAC address of a wired interface of your laptop,
....
> My router does handle dhcp, and yes, you can reserve addresses.
Very good.
> Unfortunately
> it seems to be aware of the present conflict. It lists the new laptop
> with the dhcp address, but when I tell it that I want it to reserve a
> different address (the one that I gave to NM) it tells me that that
> address already exists.
I think that you misconfigured something.
On your router:
- ask it to give always the same address for a specific MAC
(which will be a MAC of a wired interface of your laptop)
- that address you want to reserve should be from a pool of
addresses which your router gives out via DHCP
- if this is a wireless router then you can reseve an address for
your laptop wifi interface too and that will be a different MAC
and a different address than above
I would try this again, but since I have lost the wifi altogether I don't have
a mac address to give it. It does, however, see the cabled connection at the
address I gave NM.
On your laptop:
- configure your wired interface to be handled by DHCP and that
means that you do NOT give any specific address; it will always
get one you reserved on your router anyway
- let NM handle all interfaces; i.e. 'BOOTPROTO=dhcp' and
'NM_CONTROLLED=yes' for every interface configuration file.
- 'service network stop; chkconfig network off' and make sure
that NM service is on and running
That is the simplest and the most flexible - in a sense. It only
depends on capabilities of your DHCP server but you are telling that
yours is "good enough".
Your router, quite sensibly, may not like to reserve an address
which is already in use; especially if it was not given out by a
DHCP lease. It sounds like a resonable sanity checking. :-)
> If I reserve the address I could use dhcp. I want a static
> address, one way or another, so that when I read the logs I know
> which computer it is referring to.
Nominally this address will be not "static" as it will require
a DHCP lease; but with the above it will be always the same.
Practically, the same, so I'd be happy with that.
Anne
5646
days inactive
5655
days old
182 comments
27 participants
participants (27)
-
"Jóhann B. Guðmundsson" -
A.J. Werkman` -
Anne Wilson -
Antonio Olivares -
Bill Nottingham -
Chuck Anderson -
cornel panceac -
Dominik 'Rathann' Mierzejewski -
Horst H. von Brand -
Jerry Amundson -
Jesse Keating -
John Morris -
Michael Francis -
Michal Jaegermann -
Mike Chambers -
Per Bothner -
Rahul Sundaram -
Ralf Corsepius -
Rick Stevens -
Scott Robbins -
shmuel siegel -
Steve Thompson -
Timothy Murphy -
Timothy Murphy -
Todd Denniston -
Tom Horsley -
Tony Molloy