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: zdzich...@chrome.pl Ziomale na życie mają tu patenty specjalne. > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
