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. -- Tomasz Torcz To co nierealne -- tutaj jest normalne. xmpp: zdzichubg@xxxxxxxxx Ziomale na życie mają tu patenty specjalne. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
