Re: wireless-tools/net-tools are DEPRECATED

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx          Ziomale na Åycie majÄ tu patenty specjalne.
> 


-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux