Reply to topic

[SOLVED] How can I lock kwallet from the command line?

User avatar sparhawk
Registered Member
Posts
420
Karma
0
OS
I'd like for kwallet to be locked when my computer is suspended. I understand that you can lock kwallet automatically when the screensaver starts, but sometimes I manually suspend the computer, which bypasses the screensaver. There is a poll for this.

Since it appears that this is not possible, I'd like to write a suspend/hibernation script to lock the wallet. Is it possible to lock the wallet from the command line?

Last edited by sparhawk on Sat Apr 20, 2013 9:52 am, edited 1 time in total.
User avatar bcooksley
Administrator
Posts
19765
Karma
87
OS
Running the following should cause all wallets to be closed. Please note that if applications are interacting with the wallets, it may not work, in which case you may need to use the per-wallet interface instead.
Code: Select all
qdbus org.kde.kwalletd /modules/kwalletd closeAllWallets


KDE Sysadmin
[img]http://forum.kde.org/content/bcooksley_sig.png[/img]
User avatar sparhawk
Registered Member
Posts
420
Karma
0
OS
Thank you again; that works great!

For the future, is there anywhere where all of these commands are documented?
User avatar bcooksley
Administrator
Posts
19765
Karma
87
OS
To the best of my knowledge, there is no written documentation on these, however many KDE applications do use D-Bus and often offer an interface over which certain actions can be invoked.

You can use the tools 'qdbus' and 'qdbusviewer' to interact with applications connected to D-Bus.


KDE Sysadmin
[img]http://forum.kde.org/content/bcooksley_sig.png[/img]
User avatar sparhawk
Registered Member
Posts
420
Karma
0
OS
bcooksley wrote:You can use the tools 'qdbus' and 'qdbusviewer' to interact with applications connected to D-Bus.


Thanks again. I did have a brief look at qdbus, but I found it hard to know which method to use, and what additional parameters to use in some cases. I guess it is what it is. Cheers.
User avatar sparhawk
Registered Member
Posts
420
Karma
0
OS
I wanted to automatically lock kwallet when suspending. However, it doesn't seem to work so well. Quoting myself from this thread.

sparhawk wrote:It seems that this hack doesn't really integrate with KDE so well. I find that when waking from suspend, I no longer connect automatically to the wireless. It's not a matter of kwallet popping up a dialogue box, as I merely need to click on the wireless name in the plasmoid to reconnect now (with no password required).


I guess that's not surprising, given your warnings.
User avatar bcooksley
Administrator
Posts
19765
Karma
87
OS
What you could try and do is enable the screen lock on resume functionality, which should trigger a screensaver - and thus allow the "lock on screensaver" functionality to safely close the wallet in a normal, expected manner.

Given that Network Management did not need to open the wallet to retrieve the password to connect, the lack of automatic connection may be another issue altogether though. Does it normally automatically connect on login?


KDE Sysadmin
[img]http://forum.kde.org/content/bcooksley_sig.png[/img]
User avatar sparhawk
Registered Member
Posts
420
Karma
0
OS
bcooksley wrote:What you could try and do is enable the screen lock on resume functionality, which should trigger a screensaver - and thus allow the "lock on screensaver" functionality to safely close the wallet in a normal, expected manner.


Ah okay. Not a bad idea, although then I'd have to type my password in twice on wake. Not too bad though.

EDIT: although thinking about this, if I lock the screen on resume, is there any additional security to be gained from locking the wallet specifically? If it's unlocked, and no one can log in as me, isn't it still safe?

bcooksley wrote:Given that Network Management did not need to open the wallet to retrieve the password to connect, the lack of automatic connection may be another issue altogether though. Does it normally automatically connect on login?


Yes it does. I assumed it was something to do with it thinking it needed access even though the password was cached. It seems like the network passwords are stored in the wallet.

EDIT2: Hmm… Having lived with a few more suspend/wake cycles, I'm not sure if I'm hitting a different issue. Now (with no changes to the wallet system), it occasionally takes ages (e.g. minutes) to connect to my default network. It's circumstantial evidence, but if I then click on my network, then it's almost instantaneous.

EDIT3: With a few more days of running sleep/wake cycles, I'm almost certain that my comments in EDIT2 are correct. Almost every time I wake from suspend, it takes about a minute or more to connect. If I open up the network plasmoid and click on my network, it's almost instantaneous. (I've had the wallet open at all times, to prevent potential issues confounding my testing.)
User avatar bcooksley
Administrator
Posts
19765
Karma
87
OS
It could be that NetworkManager is waiting for the system to settle down and for scans to complete before it connects to the strongest network signal. Unfortunately it is hard to know why this is happening without some detailed logs from NetworkManager unfortunately. Could you try and time the delay to see if it happens to occur when the clock moves on to the next minute?

If this is what is happening, NetworkManager may not be handling the suspend properly.


KDE Sysadmin
[img]http://forum.kde.org/content/bcooksley_sig.png[/img]
User avatar sparhawk
Registered Member
Posts
420
Karma
0
OS
bcooksley wrote:It could be that NetworkManager is waiting for the system to settle down and for scans to complete before it connects to the strongest network signal.

FWIW I am only in range of a single wifi signal that is set to connect to automatically.[/quote]

bcooksley wrote:Unfortunately it is hard to know why this is happening without some detailed logs from NetworkManager unfortunately.

Should I check these logs?

bcooksley wrote:Could you try and time the delay to see if it happens to occur when the clock moves on to the next minute?

No, the last time I checked, it took almost two minutes to automatically connect, and finally connected at 40 seconds past the minute.
User avatar bcooksley
Administrator
Posts
19765
Karma
87
OS
Even with only a single network in the area, a site survey will often wait out the full amount of time to give all available access points the chance to be detected, depending on the channel they are on and to account for interference.

The NetworkManager logs can usually be found in /var/log/NetworkManager/ or similar - it is distribution dependent unfortunately.


KDE Sysadmin
[img]http://forum.kde.org/content/bcooksley_sig.png[/img]
User avatar sparhawk
Registered Member
Posts
420
Karma
0
OS
bcooksley wrote:Even with only a single network in the area, a site survey will often wait out the full amount of time to give all available access points the chance to be detected, depending on the channel they are on and to account for interference.


That's a possibility, although it was working fine in the last version (Kubuntu 12.10). It seems quite a strange "feature" to add, though.

bcooksley wrote:The NetworkManager logs can usually be found in /var/log/NetworkManager/ or similar - it is distribution dependent unfortunately.


Okay, it's in the kernel logs for Ubuntu (/var/log/kern.log). The output is pasted below. I've included the automatic idle-induced suspend, the wake up, and the connection of the wifi.

Code: Select all
May  8 13:03:12 sparhawk-XPS-17 kernel: [55775.373280] wlan0: deauthenticating from 00:1e:52:78:51:1f by local choice (reason=3)
May  8 13:03:12 sparhawk-XPS-17 kernel: [55775.423098] cfg80211: Calling CRDA to update world regulatory domain
May  8 13:03:12 sparhawk-XPS-17 kernel: [55775.427006] cfg80211: World regulatory domain updated:
May  8 13:03:12 sparhawk-XPS-17 kernel: [55775.427009] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
May  8 13:03:12 sparhawk-XPS-17 kernel: [55775.427010] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
May  8 13:03:12 sparhawk-XPS-17 kernel: [55775.427011] cfg80211:   (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
May  8 13:03:12 sparhawk-XPS-17 kernel: [55775.427012] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
May  8 13:03:12 sparhawk-XPS-17 kernel: [55775.427013] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
May  8 13:03:12 sparhawk-XPS-17 kernel: [55775.427014] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
May  8 13:03:15 sparhawk-XPS-17 kernel: [55778.200879] PM: Syncing filesystems ... done.
May  8 13:03:15 sparhawk-XPS-17 kernel: [55778.638236] bbswitch: enabling discrete graphics
May  8 13:31:25 sparhawk-XPS-17 kernel: [55778.996155] pci 0000:01:00.0: power state changed by ACPI to D0
May  8 13:31:25 sparhawk-XPS-17 kernel: [55778.996197] Freezing user space processes ... (elapsed 0.01 seconds) done.
May  8 13:31:25 sparhawk-XPS-17 kernel: [55779.010815] Freezing remaining freezable tasks ... (elapsed 6.60 seconds) done.
May  8 13:31:25 sparhawk-XPS-17 kernel: [55785.609032] Suspending console(s) (use no_console_suspend to debug)
May  8 13:31:25 sparhawk-XPS-17 kernel: [55785.609609] sd 1:0:0:0: [sdb] Synchronizing SCSI cache
May  8 13:31:25 sparhawk-XPS-17 kernel: [55785.609682] sd 0:0:0:0: [sda] Synchronizing SCSI cache
May  8 13:31:25 sparhawk-XPS-17 kernel: [55785.609992] sd 0:0:0:0: [sda] Stopping disk
May  8 13:31:25 sparhawk-XPS-17 kernel: [55785.611366] sd 1:0:0:0: [sdb] Stopping disk
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.195984] PM: suspend of devices complete after 587.716 msecs
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.196143] PM: late suspend of devices complete after 0.157 msecs
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.196315] r8169 0000:0a:00.0: System wakeup enabled by ACPI
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.211933] xhci_hcd 0000:04:00.0: System wakeup enabled by ACPI
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.243917] ehci-pci 0000:00:1d.0: System wakeup enabled by ACPI
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.260062] ehci-pci 0000:00:1a.0: System wakeup enabled by ACPI
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.291778] PM: noirq suspend of devices complete after 95.775 msecs
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.291980] ACPI: Preparing to enter system sleep state S3
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.304008] PM: Saving platform NVS memory
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.305403] Disabling non-boot CPUs ...
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.407487] smpboot: CPU 1 is now offline
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.511335] smpboot: CPU 2 is now offline
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.511851] Broke affinity for irq 23
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.511853] Broke affinity for irq 43
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.511855] Broke affinity for irq 44
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.511857] Broke affinity for irq 45
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.511859] Broke affinity for irq 46
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.511860] Broke affinity for irq 47
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.511862] Broke affinity for irq 48
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.511864] Broke affinity for irq 49
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.511865] Broke affinity for irq 50
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.511867] Broke affinity for irq 52
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.615179] smpboot: CPU 3 is now offline
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.719021] smpboot: CPU 4 is now offline
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.719570] Broke affinity for irq 55
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.720578] smpboot: CPU 5 is now offline
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.722045] smpboot: CPU 6 is now offline
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.722635] Broke affinity for irq 16
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.723663] smpboot: CPU 7 is now offline
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.724015] Extended CMOS year: 2000
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.725083] ACPI: Low-level resume complete
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.725122] PM: Restoring platform NVS memory
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.725727] Extended CMOS year: 2000
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.725759] CPU0: Thermal monitoring handled by SMI
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.725784] Enabling non-boot CPUs ...
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.725842] smpboot: Booting Node 0 Processor 1 APIC 0x1
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.736771] Disabled fast string operations
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.736786] CPU1: Thermal monitoring handled by SMI
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.739139] CPU1 is up
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.739189] smpboot: Booting Node 0 Processor 2 APIC 0x2
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.750114] Disabled fast string operations
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.750129] CPU2: Thermal monitoring handled by SMI
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.752460] CPU2 is up
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.752516] smpboot: Booting Node 0 Processor 3 APIC 0x3
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.763445] Disabled fast string operations
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.763460] CPU3: Thermal monitoring handled by SMI
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.765881] CPU3 is up
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.765939] smpboot: Booting Node 0 Processor 4 APIC 0x4
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.776864] Disabled fast string operations
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.776879] CPU4: Thermal monitoring handled by SMI
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.779236] CPU4 is up
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.779283] smpboot: Booting Node 0 Processor 5 APIC 0x5
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.790212] Disabled fast string operations
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.790228] CPU5: Thermal monitoring handled by SMI
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.792654] CPU5 is up
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.792712] smpboot: Booting Node 0 Processor 6 APIC 0x6
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.803638] Disabled fast string operations
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.803652] CPU6: Thermal monitoring handled by SMI
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.806040] CPU6 is up
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.806084] smpboot: Booting Node 0 Processor 7 APIC 0x7
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.817013] Disabled fast string operations
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.817029] CPU7: Thermal monitoring handled by SMI
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.819464] CPU7 is up
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.826569] ACPI: Waking up from system sleep state S3
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.912536] ehci-pci 0000:00:1a.0: System wakeup disabled by ACPI
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.944483] ehci-pci 0000:00:1d.0: System wakeup disabled by ACPI
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.960475] pci 0000:01:00.0: power state changed by ACPI to D0
May  8 13:31:25 sparhawk-XPS-17 kernel: [55786.992469] xhci_hcd 0000:04:00.0: System wakeup disabled by ACPI
May  8 13:31:25 sparhawk-XPS-17 kernel: [55787.008493] PM: noirq resume of devices complete after 144.104 msecs
May  8 13:31:25 sparhawk-XPS-17 kernel: [55787.008657] PM: early resume of devices complete after 0.114 msecs
May  8 13:31:25 sparhawk-XPS-17 kernel: [55787.008681] i915 0000:00:02.0: setting latency timer to 64
May  8 13:31:25 sparhawk-XPS-17 kernel: [55787.008729] ehci-pci 0000:00:1a.0: setting latency timer to 64
May  8 13:31:25 sparhawk-XPS-17 kernel: [55787.008761] ehci-pci 0000:00:1d.0: setting latency timer to 64
May  8 13:31:25 sparhawk-XPS-17 kernel: [55787.008773] ahci 0000:00:1f.2: setting latency timer to 64
May  8 13:31:25 sparhawk-XPS-17 kernel: [55787.008871] r8169 0000:0a:00.0: System wakeup disabled by ACPI
May  8 13:31:25 sparhawk-XPS-17 kernel: [55787.008914] iwlwifi 0000:03:00.0: RF_KILL bit toggled to enable radio.
May  8 13:31:25 sparhawk-XPS-17 kernel: [55787.008957] mei 0000:00:16.0: irq 54 for MSI/MSI-X
May  8 13:31:25 sparhawk-XPS-17 kernel: [55787.008970] snd_hda_intel 0000:00:1b.0: irq 56 for MSI/MSI-X
May  8 13:31:25 sparhawk-XPS-17 kernel: [55787.123653] Extended CMOS year: 2000
May  8 13:31:25 sparhawk-XPS-17 kernel: [55787.232259] usb 1-1.4: reset high-speed USB device number 3 using ehci-pci
May  8 13:31:25 sparhawk-XPS-17 kernel: [55787.335923] ata5: SATA link down (SStatus 0 SControl 300)
May  8 13:31:25 sparhawk-XPS-17 kernel: [55787.343894] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
May  8 13:31:25 sparhawk-XPS-17 kernel: [55787.349486] ata6.00: configured for UDMA/133
May  8 13:31:25 sparhawk-XPS-17 kernel: [55787.351857] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
May  8 13:31:25 sparhawk-XPS-17 kernel: [55787.352605] ata2.00: ACPI cmd 00/00:00:00:00:00:a0 (NOP) rejected by device (Stat=0x51 Err=0x04)
May  8 13:31:25 sparhawk-XPS-17 kernel: [55787.353250] ata2.00: ACPI cmd 00/00:00:00:00:00:a0 (NOP) rejected by device (Stat=0x51 Err=0x04)
May  8 13:31:25 sparhawk-XPS-17 kernel: [55787.353447] ata2.00: configured for UDMA/133
May  8 13:31:25 sparhawk-XPS-17 kernel: [55787.375949] sd 1:0:0:0: [sdb] Starting disk
May  8 13:31:25 sparhawk-XPS-17 kernel: [55787.396032] usb 2-1.5: reset full-speed USB device number 3 using ehci-pci
May  8 13:31:25 sparhawk-XPS-17 kernel: [55787.491023] btusb 2-1.5:1.0: no reset_resume for driver btusb?
May  8 13:31:25 sparhawk-XPS-17 kernel: [55787.491027] btusb 2-1.5:1.1: no reset_resume for driver btusb?
May  8 13:31:25 sparhawk-XPS-17 kernel: [55788.262662] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off
May  8 13:31:25 sparhawk-XPS-17 kernel: [55789.516675] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
May  8 13:31:25 sparhawk-XPS-17 kernel: [55789.517987] ata1.00: ACPI cmd ef/5a:00:00:00:00:a0 (SET FEATURES) succeeded
May  8 13:31:25 sparhawk-XPS-17 kernel: [55789.520476] ata1.00: ACPI cmd ef/5a:00:00:00:00:a0 (SET FEATURES) succeeded
May  8 13:31:25 sparhawk-XPS-17 kernel: [55789.521433] ata1.00: configured for UDMA/133
May  8 13:31:25 sparhawk-XPS-17 kernel: [55789.536744] sd 0:0:0:0: [sda] Starting disk
May  8 13:31:25 sparhawk-XPS-17 kernel: [55789.557133] PM: resume of devices complete after 2552.268 msecs
May  8 13:31:25 sparhawk-XPS-17 kernel: [55789.557580] Restarting tasks ... done.
May  8 13:31:25 sparhawk-XPS-17 kernel: [55789.570829] video LNXVIDEO:00: Restoring backlight state
May  8 13:31:25 sparhawk-XPS-17 kernel: [55789.570833] video LNXVIDEO:01: Restoring backlight state
May  8 13:31:25 sparhawk-XPS-17 kernel: [55789.570926] bbswitch: disabling discrete graphics
May  8 13:31:25 sparhawk-XPS-17 kernel: [55789.784344] pci 0000:01:00.0: power state changed by ACPI to D3cold
May  8 13:31:27 sparhawk-XPS-17 kernel: [55791.250076] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
May  8 13:31:27 sparhawk-XPS-17 kernel: [55791.257030] iwlwifi 0000:03:00.0: Radio type=0x1-0x2-0x0
May  8 13:31:27 sparhawk-XPS-17 kernel: [55791.478825] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
May  8 13:31:27 sparhawk-XPS-17 kernel: [55791.629219] r8169 0000:0a:00.0 eth0: link down
May  8 13:31:27 sparhawk-XPS-17 kernel: [55791.629259] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
May  8 13:33:37 sparhawk-XPS-17 kernel: [55921.504242] wlan0: authenticate with 00:1e:52:78:51:1f
May  8 13:33:37 sparhawk-XPS-17 kernel: [55921.510388] wlan0: send auth to 00:1e:52:78:51:1f (try 1/3)
May  8 13:33:37 sparhawk-XPS-17 kernel: [55921.514141] wlan0: authenticated
May  8 13:33:37 sparhawk-XPS-17 kernel: [55921.516048] wlan0: associate with 00:1e:52:78:51:1f (try 1/3)
May  8 13:33:37 sparhawk-XPS-17 kernel: [55921.519964] wlan0: RX AssocResp from 00:1e:52:78:51:1f (capab=0x1431 status=0 aid=2)
May  8 13:33:37 sparhawk-XPS-17 kernel: [55921.522340] wlan0: associated
May  8 13:33:37 sparhawk-XPS-17 kernel: [55921.522366] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
May  8 13:33:37 sparhawk-XPS-17 kernel: [55921.522441] cfg80211: Calling CRDA for country: AU
May  8 13:33:37 sparhawk-XPS-17 kernel: [55921.532767] cfg80211: Regulatory domain changed to country: AU
May  8 13:33:37 sparhawk-XPS-17 kernel: [55921.532769] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
May  8 13:33:37 sparhawk-XPS-17 kernel: [55921.532770] cfg80211:   (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
May  8 13:33:37 sparhawk-XPS-17 kernel: [55921.532771] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2300 mBm)
May  8 13:33:37 sparhawk-XPS-17 kernel: [55921.532772] cfg80211:   (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2300 mBm)
May  8 13:33:37 sparhawk-XPS-17 kernel: [55921.532773] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
User avatar bcooksley
Administrator
Posts
19765
Karma
87
OS
Thanks. I couldn't see anything too out of the ordinary there to indicate why it may be taking so long to resume the connection.
Perhaps monitoring of the NetworkManager log files might reveal more clues as to why it is waiting?

(Note that KDE Network Management doesn't control the automatic connection, that is left up to NetworkManager to perform when it is possible)


KDE Sysadmin
[img]http://forum.kde.org/content/bcooksley_sig.png[/img]
User avatar sparhawk
Registered Member
Posts
420
Karma
0
OS
bcooksley wrote:Perhaps monitoring of the NetworkManager log files might reveal more clues as to why it is waiting?


Sorry, perhaps I was being vague. I meant that in Ubuntu, the NetworkManager log files are all mixed into the kernel logs, which are what I pasted in my last post.
User avatar bcooksley
Administrator
Posts
19765
Karma
87
OS
Hmm, that is unfortunate then, as there is nothing of particular detail in there which can help.
You'll need to ask the NetworkManager folks why this happens then I guess, as only they will know how to enable the debugging output from NetworkManager needed to ascertain why it is waiting so long to initiate a connection.


KDE Sysadmin
[img]http://forum.kde.org/content/bcooksley_sig.png[/img]

 
Reply to topic

Bookmarks



Who is online

Registered users: adsbn, Baidu [Spider], beerislife, benita, Bing [Bot], extinct, gerdeg, Google [Bot], JesusM, nettek, protonic, Shane15, Skrachen, Sogou [Bot]