lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 26 Mar 2018 10:33:55 -0500
From:   Dan Williams <dcbw@...hat.com>
To:     Pavel Machek <pavel@....cz>
Cc:     Woody Suwalski <terraluna977@...il.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        kernel list <linux-kernel@...r.kernel.org>,
        Linux-pm mailing list <linux-pm@...r.kernel.org>,
        Netdev list <netdev@...r.kernel.org>
Subject: Re: linux-next on x60: network manager often complains "network is
 disabled" after resume

On Sun, 2018-03-25 at 08:19 +0200, Pavel Machek wrote:
> > > > Ok, what does 'nmcli dev' and 'nmcli radio' show?
> > > 
> > > Broken state.
> > > 
> > > pavel@amd:~$ nmcli dev
> > > DEVICE  TYPE      STATE        CONNECTION
> > > eth1    ethernet  unavailable  --
> > > lo      loopback  unmanaged    --
> > > wlan0   wifi      unmanaged    --
> > 
> > If the state is "unmanaged" on resume, that would indicate a
> > problem
> > with sleep/wake and likely not a kernel network device issue.
> > 
> > We should probably move this discussion to the NM lists to debug
> > further.  Before you suspend, run "nmcli gen log level trace" to
> > turn
> > on full debug logging, then reproduce the issue, and send a pointer
> > to
> > those logs (scrubbed for anything you consider sensitive) to the NM
> > mailing list.
> 
> Hmm :-)
> 
> root@amd:/data/pavel# nmcli gen log level trace
> Error: Unknown log level 'trace'

What NM version?  'trace' is pretty old (since 1.0 from December 2014)
so unless you're using a really, really old version of Debian I'd
expect you'd have it.  Anyway, debug would do.

> root@amd:/data/pavel# nmcli gen log level help
> Error: Unknown log level 'help'

nmcli gen help

> root@amd:/data/pavel# nmcli gen log level
> Error: value for 'level' argument is required.
> root@amd:/data/pavel# nmcli gen log level debug

This should be OK.

> root@amd:/data/pavel# cat /var/log/sys/log

It routes it to whatever the syslog 'daemon' facility logs to (however
that's configured on your system).  Usually /var/log/messages or
/var/log/daemon.log or sometimes your distro configures it to
/var/log/NetworkManager.log.

Or if you're using a systemd-based distro, it would probably be in the
systemd journal so "journalctl -b -u NetworkManager"

> Where do I get the logs? I don't see much in the syslog...

> And.. It seems that it is "every other suspend". One resume results
> in
> broken network, one in working one, one in broken one...

Does your distro use pm-utils, upower, or systemd for suspend/resume
handling?

Dan

Powered by blists - more mailing lists