hi,
wireless-tools is deprecated since time ago. iw/rfkill should be used instead it.
these packages still depend on it:
conky dracut-modules-olpc i3status knemo olpc-netutils python-iwlib wavemon weplab wicd wifi-radar wifiroamd wlassistant xsupplicant
https://bugzilla.redhat.com/show_bug.cgi?id=687924
Xose Vazquez Perez (xose.vazquez@gmail.com) said:
wireless-tools is deprecated since time ago. iw/rfkill should be used instead it.
Not to be entirely glib, but with this and the net-tools dependencies... we're taking patches. Mere notification is not as useful as contribution.
Bill
On 03/28/2011 09:00 PM, Bill Nottingham wrote:
Xose Vazquez Perez (xose.vazquez at gmail.com) said:
wireless-tools is deprecated since time ago. iw/rfkill should be used instead it.
Not to be entirely glib, but with this and the net-tools dependencies... we're taking patches. Mere notification is not as useful as contribution.
Some of them are so trivial, that it looks like nobody is working on it: $ rpm -ql initscripts | xargs egrep "/route |/ifconfig " --color /etc/rc.d/init.d/network: /sbin/route add -$args /etc/sysconfig/network-scripts/ifup-aliases:eval $(LC_ALL= LANG= /sbin/ifconfig | LC_ALL=C sed -n ' /etc/sysconfig/network-scripts/ifup-aliases: LC_ALL=C /sbin/route -n \ /etc/sysconfig/network-scripts/ifup-aliases: /sbin/ifconfig $parent_device:${DEVNUM} down /etc/sysconfig/network-scripts/ifup-aliases: /sbin/ifconfig $parent_device:$rdevip down /etc/sysconfig/network-scripts/ifup-aliases: /sbin/ifconfig $DEVICE netmask $NETMASK broadcast $BROADCAST; /etc/sysconfig/network-scripts/ifup-aliases: /sbin/ifconfig ${DEVICE} ${IPADDR} netmask ${NETMASK} broadcast ${BROADCAST} /etc/sysconfig/network-scripts/ifup-aliases: /sbin/ifconfig $parent_device:${DEVNUM} down
net-tools is obsolete since '99 (Red Hat Linux 6.0 - Linux-2.2), *12 years* ago!
It's a *shame* that all leading distributions, still rely on the old *BSD way to do networking.
On Sun, Apr 17, 2011 at 7:11 PM, Xose Vazquez Perez xose.vazquez@gmail.com wrote:
On 03/28/2011 09:00 PM, Bill Nottingham wrote:
Not to be entirely glib, but with this and the net-tools dependencies... we're taking patches. Mere notification is not as useful as contribution.
Some of them are so trivial, that it looks like nobody is working on it:
Have you actually looked at these uses?
$ rpm -ql initscripts | xargs egrep "/route |/ifconfig " --color /etc/rc.d/init.d/network: /sbin/route add -$args
$args is arbitrary and user-specified, so if you want to replace this line, you'd need to build something that transparently converts arbitrary arguments to route(8) to arguments to ip(8) - but why bother doing this at all, really? I can't see what would we gain by replacing /sbin/route with /sbin/route-through-ip, and replacing a dependency on net-tools with a dependency on net-tools-emulator.
/etc/sysconfig/network-scripts/ifup-aliases:eval $(LC_ALL= LANG= /sbin/ifconfig | LC_ALL=C sed -n '
ifup-aliases is a huge, complex shell script, and AFAIK the "ip" way of doing things is rather different. Porting ifup-aliases line-by-line is probably possible, but hardly the obviously right thing to do.
Both of these cases are strongly tied to the old syntax/semantics, and AFAIK only rarely used.
It's a *shame* that all leading distributions, still rely on the old *BSD way to do networking.
Does it actually hurt anything? I'd say that if these are the most important uses you could find, the porting effort is basically finished. Mirek
Xose Vazquez Perez wrote:
Some of them are so trivial, that it looks like nobody is working on it: $ rpm -ql initscripts | xargs egrep "/route |/ifconfig " --color /etc/rc.d/init.d/network: /sbin/route add -$args /etc/sysconfig/network-scripts/ifup-aliases:eval $(LC_ALL= LANG= /sbin/ifconfig | LC_ALL=C sed -n ' /etc/sysconfig/network-scripts/ifup-aliases: LC_ALL=C /sbin/route -n \ /etc/sysconfig/network-scripts/ifup-aliases: /sbin/ifconfig $parent_device:${DEVNUM} down /etc/sysconfig/network-scripts/ifup-aliases: /sbin/ifconfig $parent_device:$rdevip down /etc/sysconfig/network-scripts/ifup-aliases: /sbin/ifconfig $DEVICE netmask $NETMASK broadcast $BROADCAST; /etc/sysconfig/network-scripts/ifup-aliases: /sbin/ifconfig ${DEVICE} ${IPADDR} netmask ${NETMASK} broadcast ${BROADCAST} /etc/sysconfig/network-scripts/ifup-aliases:
/sbin/ifconfig
$parent_device:${DEVNUM} down
All these hits are in the legacy "network" service or the legacy "ifup" scripts which go with it.
Newsflash: the network service is DEPRECATED!!! That's what NetworkManager is for.
net-tools is obsolete since '99 (Red Hat Linux 6.0 - Linux-2.2), *12 years* ago!
And the network service is obsolete since at least Fedora 10, when Anaconda started defaulting to NetworkManager. (The live images already did default to NM at that point.)
It's a *shame* that all leading distributions, still rely on the old *BSD way to do networking.
They don't. They use NetworkManager by default, which doesn't use any of the scripts you mentioned there.
Kevin Kofler
Once upon a time, Kevin Kofler kevin.kofler@chello.at said:
Newsflash: the network service is DEPRECATED!!! That's what NetworkManager is for.
Newsflash: NM doesn't replace the network service yet. Maybe when NM can do everything ifup/ifdown can do, the discussion about deprecation can happen, but until then, please stop saying NM replaces the network service.
On Sun, Apr 24, 2011 at 05:25, Chris Adams cmadams@hiwaay.net wrote:
Once upon a time, Kevin Kofler kevin.kofler@chello.at said:
Newsflash: the network service is DEPRECATED!!! That's what NetworkManager is for.
Newsflash: NM doesn't replace the network service yet. Maybe when NM can do everything ifup/ifdown can do, the discussion about deprecation can happen, but until then, please stop saying NM replaces the network service.
+1
Am 24.04.2011 07:30, schrieb Farkas Levente:
On Sun, Apr 24, 2011 at 05:25, Chris Adams cmadams@hiwaay.net wrote:
Once upon a time, Kevin Kofler kevin.kofler@chello.at said:
Newsflash: the network service is DEPRECATED!!! That's what NetworkManager is for.
Newsflash: NM doesn't replace the network service yet. Maybe when NM can do everything ifup/ifdown can do, the discussion about deprecation can happen, but until then, please stop saying NM replaces the network service.
+1
+1
i am runnign 35 fedora-setups, 20 of them production and NM is the frist thing which is disabled because it is useless for static configs and "ifcfg-eth0", "ifcfg-eth0:1".... are much better to handle becuase they normally touched once
Chris Adams cmadams@hiwaay.net wrote:
Once upon a time, Kevin Kofler kevin.kofler@chello.at said:
Newsflash: the network service is DEPRECATED!!! That's what NetworkManager is for.
Newsflash: NM doesn't replace the network service yet. Maybe when NM can do everything ifup/ifdown can do, the discussion about deprecation can happen, but until then, please stop saying NM replaces the network service.
One thing I liked a lot with my ifconfig scripts/wpa_supplicant pairing is that when wireless is spotty, the network doesn't keep going up and down. Instead, applications see lots of dropped packets. When reauthentication can take 5 to 10s (or more), assuming that the connection is steady when its just spotty can result in better behavior. Also nice when quickly swapping ethernet cables. A "network is gone" event gets different reactions from applications (particularly those that are NM-aware which makes those applications MUCH more annoying to deal with in these cases) than "some packets were lost". An option to "persist connections despite something probably not actually existing" would be nice for situations like this.
--Ben
Ben Boeckel wrote:
One thing I liked a lot with my ifconfig scripts/wpa_supplicant pairing is that when wireless is spotty, the network doesn't keep going up and down. Instead, applications see lots of dropped packets. When reauthentication can take 5 to 10s (or more), assuming that the connection is steady when its just spotty can result in better behavior. Also nice when quickly swapping ethernet cables. A "network is gone" event gets different reactions from applications (particularly those that are NM-aware which makes those applications MUCH more annoying to deal with in these cases) than "some packets were lost". An option to "persist connections despite something probably not actually existing" would be nice for situations like this.
I've found NM to actually be quite tolerant of spotty wireless connections. In fact, usually, it's me who triggers a reconnect (or if possible, a connect to a different access point, e.g. when I'm at the university in a shared building with the business university (WU), I try switching from eduroam to eduroam-wu when reception of my university's eduroam is poor), NM just happily stays "connected" even with 100% packet loss.
Kevin Kofler
Kevin Kofler kevin.kofler@chello.at wrote:
I've found NM to actually be quite tolerant of spotty wireless connections. In fact, usually, it's me who triggers a reconnect (or if possible, a connect to a different access point, e.g. when I'm at the university in a shared building with the business university (WU), I try switching from eduroam to eduroam-wu when reception of my university's eduroam is poor), NM just happily stays "connected" even with 100% packet loss.
Ah, that's different than when I last used NM on my laptop due to these issues (F13 beta-ish timeframe).
--Ben
On 04/24/2011 10:43 PM, Ben Boeckel wrote:
Kevin Kofler kevin.kofler@chello.at wrote:
I've found NM to actually be quite tolerant of spotty wireless connections. In fact, usually, it's me who triggers a reconnect (or if possible, a connect to a different access point, e.g. when I'm at the university in a shared building with the business university (WU), I try switching from eduroam to eduroam-wu when reception of my university's eduroam is poor), NM just happily stays "connected" even with 100% packet loss.
Ah, that's different than when I last used NM on my laptop due to these issues (F13 beta-ish timeframe)
It isn't useful to talk about NM from that time period anymore. There has been major rewrites of it and current NM is not even comparable really. Try the latest and then offer comments.
Rahul
On Sun, Apr 24, 2011 at 07:10:48PM +0200, Kevin Kofler wrote:
Ben Boeckel wrote:
One thing I liked a lot with my ifconfig scripts/wpa_supplicant pairing is that when wireless is spotty, the network doesn't keep going up and down. Instead, applications see lots of dropped packets. When reauthentication can take 5 to 10s (or more), assuming that the connection is steady when its just spotty can result in better behavior. Also nice when quickly swapping ethernet cables. A "network is gone" event gets different reactions from applications (particularly those that are NM-aware which makes those applications MUCH more annoying to deal with in these cases) than "some packets were lost". An option to "persist connections despite something probably not actually existing" would be nice for situations like this.
I've found NM to actually be quite tolerant of spotty wireless connections. In fact, usually, it's me who triggers a reconnect (or if possible, a connect to a different access point, e.g. when I'm at the university in a shared building with the business university (WU), I try switching from eduroam to eduroam-wu when reception of my university's eduroam is poor), NM just happily stays "connected" even with 100% packet loss.
Well, I have opposite experience with my wired connection. It takes only about 5 flip-flop (carrier on/carrier off) in 10 seconds for NM to consider connection down.
On Sun, 2011-04-24 at 23:06 +0200, Tomasz Torcz wrote:
On Sun, Apr 24, 2011 at 07:10:48PM +0200, Kevin Kofler wrote:
Ben Boeckel wrote:
One thing I liked a lot with my ifconfig scripts/wpa_supplicant pairing is that when wireless is spotty, the network doesn't keep going up and down. Instead, applications see lots of dropped packets. When reauthentication can take 5 to 10s (or more), assuming that the connection is steady when its just spotty can result in better behavior. Also nice when quickly swapping ethernet cables. A "network is gone" event gets different reactions from applications (particularly those that are NM-aware which makes those applications MUCH more annoying to deal with in these cases) than "some packets were lost". An option to "persist connections despite something probably not actually existing" would be nice for situations like this.
I've found NM to actually be quite tolerant of spotty wireless connections. In fact, usually, it's me who triggers a reconnect (or if possible, a connect to a different access point, e.g. when I'm at the university in a shared building with the business university (WU), I try switching from eduroam to eduroam-wu when reception of my university's eduroam is poor), NM just happily stays "connected" even with 100% packet loss.
Well, I have opposite experience with my wired connection. It takes only about 5 flip-flop (carrier on/carrier off) in 10 seconds for NM to consider connection down.
When carrier state changes happen, NM sets the carrier state internally, but won't do anything about it for 4 seconds. If you get another carrier change within that 4 seconds, NM pushes the action off for another 4 seconds. If you get another, then it pushes it off for another 4 seconds. So basically, whenever the device settles down and stops spamming carrier changes, NM won't do anything for 4 seconds.
The next question, what's causing your carrier to flip-flop int he first place?
Dan
On Wed, Apr 27, 2011 at 01:58:57PM -0500, Dan Williams wrote:
On Sun, 2011-04-24 at 23:06 +0200, Tomasz Torcz wrote:
On Sun, Apr 24, 2011 at 07:10:48PM +0200, Kevin Kofler wrote:
Ben Boeckel wrote:
One thing I liked a lot with my ifconfig scripts/wpa_supplicant pairing is that when wireless is spotty, the network doesn't keep going up and down. Instead, applications see lots of dropped packets. When reauthentication can take 5 to 10s (or more), assuming that the connection is steady when its just spotty can result in better behavior. Also nice when quickly swapping ethernet cables. A "network is gone" event gets different reactions from applications (particularly those that are NM-aware which makes those applications MUCH more annoying to deal with in these cases) than "some packets were lost". An option to "persist connections despite something probably not actually existing" would be nice for situations like this.
I've found NM to actually be quite tolerant of spotty wireless connections. In fact, usually, it's me who triggers a reconnect (or if possible, a connect to a different access point, e.g. when I'm at the university in a shared building with the business university (WU), I try switching from eduroam to eduroam-wu when reception of my university's eduroam is poor), NM just happily stays "connected" even with 100% packet loss.
Well, I have opposite experience with my wired connection. It takes only about 5 flip-flop (carrier on/carrier off) in 10 seconds for NM to consider connection down.
When carrier state changes happen, NM sets the carrier state internally, but won't do anything about it for 4 seconds. If you get another carrier change within that 4 seconds, NM pushes the action off for another 4 seconds. If you get another, then it pushes it off for another 4 seconds. So basically, whenever the device settles down and stops spamming carrier changes, NM won't do anything for 4 seconds.
That's not what I'm seeing: messages-20110403:Mar 29 13:08:11 mother NetworkManager[1285]: <info> (nf): carrier now OFF (device state 3) messages-20110403:Mar 29 13:08:11 mother NetworkManager[1285]: <info> (nf): device state change: 3 -> 2 (reason 40) messages-20110403:Mar 29 13:08:11 mother NetworkManager[1285]: <info> (nf): deactivating device (reason: 40). messages-20110403:Mar 29 13:08:21 mother NetworkManager[1285]: <info> (nf): carrier now ON (device state 2) messages-20110403:Mar 29 13:08:21 mother NetworkManager[1285]: <info> (nf): device state change: 2 -> 3 (reason 40) messages-20110403:Mar 29 13:09:06 mother NetworkManager[1285]: <info> (nf): carrier now OFF (device state 3) messages-20110403:Mar 29 13:09:06 mother NetworkManager[1285]: <info> (nf): device state change: 3 -> 2 (reason 40) messages-20110403:Mar 29 13:09:06 mother NetworkManager[1285]: <info> (nf): deactivating device (reason: 40). messages-20110403:Mar 29 13:09:07 mother NetworkManager[1285]: <info> (nf): carrier now ON (device state 2) messages-20110403:Mar 29 13:09:07 mother NetworkManager[1285]: <info> (nf): device state change: 2 -> 3 (reason 40) messages-20110403:Mar 29 13:09:09 mother NetworkManager[1285]: <info> (nf): carrier now OFF (device state 3) messages-20110403:Mar 29 13:09:09 mother NetworkManager[1285]: <info> (nf): device state change: 3 -> 2 (reason 40) messages-20110403:Mar 29 13:09:09 mother NetworkManager[1285]: <info> (nf): deactivating device (reason: 40). messages-20110403:Mar 29 13:09:11 mother NetworkManager[1285]: <info> (nf): carrier now ON (device state 2) messages-20110403:Mar 29 13:09:11 mother NetworkManager[1285]: <info> (nf): device state change: 2 -> 3 (reason 40) messages-20110403:Mar 29 13:09:17 mother NetworkManager[1285]: <info> (nf): carrier now OFF (device state 3) messages-20110403:Mar 29 13:09:17 mother NetworkManager[1285]: <info> (nf): device state change: 3 -> 2 (reason 40) messages-20110403:Mar 29 13:09:17 mother NetworkManager[1285]: <info> (nf): deactivating device (reason: 40). messages-20110403:Mar 29 13:09:17 mother NetworkManager[1285]: <info> (nf): canceled DHCP transaction, DHCP client pid 7250
At this point I need to manually do "nmcli con up uuid xxx" to have connection working again.
The next question, what's causing your carrier to flip-flop int he first place?
Power problems at the other end of ehternet cable. Beyond my control.
On Wed, 2011-04-27 at 23:01 +0200, Tomasz Torcz wrote:
On Wed, Apr 27, 2011 at 01:58:57PM -0500, Dan Williams wrote:
On Sun, 2011-04-24 at 23:06 +0200, Tomasz Torcz wrote:
On Sun, Apr 24, 2011 at 07:10:48PM +0200, Kevin Kofler wrote:
Ben Boeckel wrote:
One thing I liked a lot with my ifconfig scripts/wpa_supplicant pairing is that when wireless is spotty, the network doesn't keep going up and down. Instead, applications see lots of dropped packets. When reauthentication can take 5 to 10s (or more), assuming that the connection is steady when its just spotty can result in better behavior. Also nice when quickly swapping ethernet cables. A "network is gone" event gets different reactions from applications (particularly those that are NM-aware which makes those applications MUCH more annoying to deal with in these cases) than "some packets were lost". An option to "persist connections despite something probably not actually existing" would be nice for situations like this.
I've found NM to actually be quite tolerant of spotty wireless connections. In fact, usually, it's me who triggers a reconnect (or if possible, a connect to a different access point, e.g. when I'm at the university in a shared building with the business university (WU), I try switching from eduroam to eduroam-wu when reception of my university's eduroam is poor), NM just happily stays "connected" even with 100% packet loss.
Well, I have opposite experience with my wired connection. It takes only about 5 flip-flop (carrier on/carrier off) in 10 seconds for NM to consider connection down.
When carrier state changes happen, NM sets the carrier state internally, but won't do anything about it for 4 seconds. If you get another carrier change within that 4 seconds, NM pushes the action off for another 4 seconds. If you get another, then it pushes it off for another 4 seconds. So basically, whenever the device settles down and stops spamming carrier changes, NM won't do anything for 4 seconds.
That's not what I'm seeing:
Looking at the code, the 4-second delay is only used when the device is actually connected to something. State 3 == DISCONNECTED, state 2 == UNAVAILABLE, so it's performing as expected here. Were there actually an IP address assigned to 'nf' then the 4-second delay would be used. Given that nothing really happens to the device when it's DISCONNECTED anyway, the logs you see are pretty much a NOP for NM.
Dan
messages-20110403:Mar 29 13:08:11 mother NetworkManager[1285]: <info> (nf): carrier now OFF (device state 3) messages-20110403:Mar 29 13:08:11 mother NetworkManager[1285]: <info> (nf): device state change: 3 -> 2 (reason 40) messages-20110403:Mar 29 13:08:11 mother NetworkManager[1285]: <info> (nf): deactivating device (reason: 40). messages-20110403:Mar 29 13:08:21 mother NetworkManager[1285]: <info> (nf): carrier now ON (device state 2) messages-20110403:Mar 29 13:08:21 mother NetworkManager[1285]: <info> (nf): device state change: 2 -> 3 (reason 40) messages-20110403:Mar 29 13:09:06 mother NetworkManager[1285]: <info> (nf): carrier now OFF (device state 3) messages-20110403:Mar 29 13:09:06 mother NetworkManager[1285]: <info> (nf): device state change: 3 -> 2 (reason 40) messages-20110403:Mar 29 13:09:06 mother NetworkManager[1285]: <info> (nf): deactivating device (reason: 40). messages-20110403:Mar 29 13:09:07 mother NetworkManager[1285]: <info> (nf): carrier now ON (device state 2) messages-20110403:Mar 29 13:09:07 mother NetworkManager[1285]: <info> (nf): device state change: 2 -> 3 (reason 40) messages-20110403:Mar 29 13:09:09 mother NetworkManager[1285]: <info> (nf): carrier now OFF (device state 3) messages-20110403:Mar 29 13:09:09 mother NetworkManager[1285]: <info> (nf): device state change: 3 -> 2 (reason 40) messages-20110403:Mar 29 13:09:09 mother NetworkManager[1285]: <info> (nf): deactivating device (reason: 40). messages-20110403:Mar 29 13:09:11 mother NetworkManager[1285]: <info> (nf): carrier now ON (device state 2) messages-20110403:Mar 29 13:09:11 mother NetworkManager[1285]: <info> (nf): device state change: 2 -> 3 (reason 40) messages-20110403:Mar 29 13:09:17 mother NetworkManager[1285]: <info> (nf): carrier now OFF (device state 3) messages-20110403:Mar 29 13:09:17 mother NetworkManager[1285]: <info> (nf): device state change: 3 -> 2 (reason 40) messages-20110403:Mar 29 13:09:17 mother NetworkManager[1285]: <info> (nf): deactivating device (reason: 40). messages-20110403:Mar 29 13:09:17 mother NetworkManager[1285]: <info> (nf): canceled DHCP transaction, DHCP client pid 7250
At this point I need to manually do "nmcli con up uuid xxx" to have connection working again.
The next question, what's causing your carrier to flip-flop int he first place?
Power problems at the other end of ehternet cable. Beyond my control.
-- Tomasz Torcz To co nierealne -- tutaj jest normalne. xmpp: zdzichubg@chrome.pl Ziomale na życie mają tu patenty specjalne.
On Fri, Apr 29, 2011 at 12:30:02PM -0500, Dan Williams wrote:
Looking at the code, the 4-second delay is only used when the device is actually connected to something. State 3 == DISCONNECTED, state 2 == UNAVAILABLE, so it's performing as expected here. Were there actually an IP address assigned to 'nf' then the 4-second delay would be used. Given that nothing really happens to the device when it's DISCONNECTED anyway, the logs you see are pretty much a NOP for NM.
I would really /love/ it if NM could log the human readable state names and reason codes, rather than the cryptic numbers.
On Fri, 2011-04-29 at 19:21 -0400, Chuck Anderson wrote:
On Fri, Apr 29, 2011 at 12:30:02PM -0500, Dan Williams wrote:
Looking at the code, the 4-second delay is only used when the device is actually connected to something. State 3 == DISCONNECTED, state 2 == UNAVAILABLE, so it's performing as expected here. Were there actually an IP address assigned to 'nf' then the 4-second delay would be used. Given that nothing really happens to the device when it's DISCONNECTED anyway, the logs you see are pretty much a NOP for NM.
I would really /love/ it if NM could log the human readable state names and reason codes, rather than the cryptic numbers.
Done and rolled into the 0.8.999 (0.9-rc2) release:
http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=c4b922e... https://admin.fedoraproject.org/updates/NetworkManager-0.8.999-1.fc15,Networ...
Reason codes too. Just for you Chuck :) (that's a lie, it's been requested before but I figured since Chuck asked I might as well just do it)
Dan
On Wed, May 04, 2011 at 02:26:10PM -0500, Dan Williams wrote:
On Fri, 2011-04-29 at 19:21 -0400, Chuck Anderson wrote:
On Fri, Apr 29, 2011 at 12:30:02PM -0500, Dan Williams wrote:
Looking at the code, the 4-second delay is only used when the device is actually connected to something. State 3 == DISCONNECTED, state 2 == UNAVAILABLE, so it's performing as expected here. Were there actually an IP address assigned to 'nf' then the 4-second delay would be used. Given that nothing really happens to the device when it's DISCONNECTED anyway, the logs you see are pretty much a NOP for NM.
I would really /love/ it if NM could log the human readable state names and reason codes, rather than the cryptic numbers.
Done and rolled into the 0.8.999 (0.9-rc2) release:
http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=c4b922e... https://admin.fedoraproject.org/updates/NetworkManager-0.8.999-1.fc15,Networ...
Reason codes too. Just for you Chuck :) (that's a lie, it's been requested before but I figured since Chuck asked I might as well just do it)
By me no less :P thanks for writing it.
--CJD
On Sun, 2011-04-24 at 19:10 +0200, Kevin Kofler wrote:
Ben Boeckel wrote:
One thing I liked a lot with my ifconfig scripts/wpa_supplicant pairing is that when wireless is spotty, the network doesn't keep going up and down. Instead, applications see lots of dropped packets. When reauthentication can take 5 to 10s (or more), assuming that the connection is steady when its just spotty can result in better behavior. Also nice when quickly swapping ethernet cables. A "network is gone" event gets different reactions from applications (particularly those that are NM-aware which makes those applications MUCH more annoying to deal with in these cases) than "some packets were lost". An option to "persist connections despite something probably not actually existing" would be nice for situations like this.
I've found NM to actually be quite tolerant of spotty wireless connections. In fact, usually, it's me who triggers a reconnect (or if possible, a connect to a different access point, e.g. when I'm at the university in a shared building with the business university (WU), I try switching from eduroam to eduroam-wu when reception of my university's eduroam is poor), NM just happily stays "connected" even with 100% packet loss.
If the driver/supplicant report that they are still connected, then NM says you're still connected; we'd need wpa_supplicant debug logs to figure out what's going on here. When this happens, if you do 'iwconfig wlan0' does it show a valid BSSID? If so, then the driver has a problem because it says it's still connected, but cannot pass traffic to/from the AP.
Dan
On Sun, 2011-04-24 at 16:35 +0000, Ben Boeckel wrote:
deal with in these cases) than "some packets were lost". An option to "persist connections despite something probably not actually existing" would be nice for situations like this.
Or, more simply, just a short time-out on cable disconnect (say 10 seconds) before treating the connection as down?
On Tue, 2011-04-26 at 09:46 -0700, Adam Williamson wrote:
On Sun, 2011-04-24 at 16:35 +0000, Ben Boeckel wrote:
deal with in these cases) than "some packets were lost". An option to "persist connections despite something probably not actually existing" would be nice for situations like this.
Or, more simply, just a short time-out on cable disconnect (say 10 seconds) before treating the connection as down?
NM has had one for a while: 4 seconds. THe problem with longer is that then any time you do disconnect the cable or undock your laptop, NM would think that you were still connected for 10 seconds (or more) until if flipped over to wifi. So there's a conflict here between people that occasionally pull out the network cable to do stuff, and between people that dock/undock and move from wired to wifi.
Dan
On 04/27/2011 08:48 PM, Dan Williams wrote:
NM has had one for a while: 4 seconds. THe problem with longer is that then any time you do disconnect the cable or undock your laptop, NM would think that you were still connected for 10 seconds (or more) until if flipped over to wifi. So there's a conflict here between people that occasionally pull out the network cable to do stuff, and between people that dock/undock and move from wired to wifi.
But when you switch from wired to wifi you get a new IP so all your connections are lost. Having to wait a few seconds more will not add too much annoyance to the process. On the other end, if someone steps on my cable, I think it is unreasonable that I only have 4 seconds to fix it before losing my connections.
I think 4 seconds is too low. And 10 seconds too, I'd say.
Why not configurable? Or, why not to ask the user? ("wired carrier lost for xx seconds, switching to wifi in xx seconds: button<switch now>, button<add another minute>")
Roberto Ragusa mail@robertoragusa.it wrote:
Why not configurable? Or, why not to ask the user? ("wired carrier lost for xx seconds, switching to wifi in xx seconds: button<switch now>, button<add another minute>")
Personally, I've seen that it's usually "I want to be on this network until I disconnect". My example was the wireless in my dorm room. Going from my room to a friend's, there was a region of no connection (brick walls, distance, what have you) whereas my destination had good reception via either the windows or the fact that it was just 10 feet away, vertically. NM would drop my wireless and connect to the campus wireless as a fallback. This drops me out of my network and I had to manually fix the problem. Similar problems where the authenticated network was spotty but the non-authenticated network was fine.
--Ben
On Wed, 2011-04-27 at 13:48 -0500, Dan Williams wrote:
On Tue, 2011-04-26 at 09:46 -0700, Adam Williamson wrote:
On Sun, 2011-04-24 at 16:35 +0000, Ben Boeckel wrote:
deal with in these cases) than "some packets were lost". An option to "persist connections despite something probably not actually existing" would be nice for situations like this.
Or, more simply, just a short time-out on cable disconnect (say 10 seconds) before treating the connection as down?
NM has had one for a while: 4 seconds. THe problem with longer is that then any time you do disconnect the cable or undock your laptop, NM would think that you were still connected for 10 seconds (or more) until if flipped over to wifi. So there's a conflict here between people that occasionally pull out the network cable to do stuff, and between people that dock/undock and move from wired to wifi.
That's a point. How about no timeout when there's an alternative connection available, timeout when there isn't?
Adam Williamson awilliam@redhat.com wrote:
That's a point. How about no timeout when there's an alternative connection available, timeout when there isn't?
In the presence of many wireless connections, not all are equal in regards to access to things and should be treated as such (see other thread).
--Ben
On 2011-03-26, Xose Vazquez Perez xose.vazquez@gmail.com wrote:
wireless-tools is deprecated since time ago. iw/rfkill should be used instead it.
Really? I thought iw can control mac80211 drivers only and not all wireless drivers have been ported to mac80211 yet http://wireless.kernel.org/en/users/Drivers.
-- Petr
On Tue, Mar 29, 2011 at 07:24:01AM +0000, Petr Pisar wrote:
On 2011-03-26, Xose Vazquez Perez xose.vazquez@gmail.com wrote:
wireless-tools is deprecated since time ago. iw/rfkill should be used instead it.
Really? I thought iw can control mac80211 drivers only and not all wireless drivers have been ported to mac80211 yet http://wireless.kernel.org/en/users/Drivers.
Yes, sadly, that is correct.
John
-
Adam Williamson -
Ben Boeckel -
Bill Nottingham -
Casey Dahlin -
Chris Adams -
Chuck Anderson -
Dan Williams -
Farkas Levente -
John W. Linville -
Kevin Kofler -
Miloslav Trmač -
Petr Pisar -
Rahul Sundaram -
Reindl Harald -
Roberto Ragusa -
Tomasz Torcz -
Xose Vazquez Perez