< ^ txt
Mon Feb 10 06:00:01 EST 2020
========================================
Slept from eleven to seven.
Woke briefly around five.
Cloudy with a 50 percent chance of snow showers.
Near steady temperature in the mid 20s.
North winds 10 to 15 mph.
Work
----------------------------------------
- Fix DKIM on Friede
Done.
- Work on mail submission
Done.
Twenty-minute walk at lunch.
Partly sunny and not too cold.
Saw a pair of crows and a (broad-winged?) hawk.
Finished the new smarthost!
Left on time for once.
Home
----------------------------------------
Got home before dark.
I've long endured a problem where NetworkManager takes a long time to bring up my wired network connection after resuming from sleep.
Today, I got curios, and poked into the problem.
```
🐚 bava ~ $ journalctl --unit=NetworkManager
[…]
Feb 09 20:36:53 bava NetworkManager[589]: <info> [1581298613.5738] manager: NetworkManager state is now ASLEEP
Feb 10 18:05:58 bava NetworkManager[589]: <info> [1581375958.2631] manager: sleep: wake requested (sleeping: yes enabled: yes)
Feb 10 18:05:58 bava NetworkManager[589]: <info> [1581375958.2632] device (enp3s0): state change: activated -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
Feb 10 18:05:58 bava NetworkManager[589]: <info> [1581375958.3217] manager: NetworkManager state is now CONNECTED_GLOBAL
Feb 10 18:05:58 bava NetworkManager[589]: <info> [1581375958.3407] device (br0): detached bridge port enp3s0
Feb 10 18:05:58 bava NetworkManager[589]: <info> [1581375958.3407] device (enp3s0): released from master device br0
Feb 10 18:05:58 bava NetworkManager[589]: <info> [1581375958.3412] device (enp3s0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'managed')
Feb 10 18:06:00 bava NetworkManager[589]: <info> [1581375960.4595] device (enp3s0): carrier: link connected
Feb 10 18:06:00 bava NetworkManager[589]: <info> [1581375960.4604] device (enp3s0): state change: unavailable -> disconnected (reason 'carrier-changed', sys-iface-state: 'managed')
Feb 10 18:06:00 bava NetworkManager[589]: <info> [1581375960.4611] policy: auto-activating connection 'enp3s0' (70c51517-3fbf-4eba-9c76-41bd38e62be2)
Feb 10 18:06:00 bava NetworkManager[589]: <info> [1581375960.4615] device (enp3s0): Activation: starting connection 'enp3s0' (70c51517-3fbf-4eba-9c76-41bd38e62be2)
Feb 10 18:06:00 bava NetworkManager[589]: <info> [1581375960.4616] device (enp3s0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Feb 10 18:06:00 bava NetworkManager[589]: <info> [1581375960.4620] device (enp3s0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Feb 10 18:06:00 bava NetworkManager[589]: <info> [1581375960.4624] device (enp3s0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Feb 10 18:06:00 bava NetworkManager[589]: <info> [1581375960.4639] device (br0): attached bridge port enp3s0
Feb 10 18:06:00 bava NetworkManager[589]: <info> [1581375960.4640] device (enp3s0): Activation: connection 'enp3s0' enslaved, continuing activation
Feb 10 18:06:00 bava NetworkManager[589]: <info> [1581375960.4642] device (enp3s0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
Feb 10 18:06:00 bava NetworkManager[589]: <info> [1581375960.4648] device (enp3s0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed')
Feb 10 18:06:00 bava NetworkManager[589]: <info> [1581375960.4651] device (enp3s0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
Feb 10 18:06:00 bava NetworkManager[589]: <info> [1581375960.4682] device (enp3s0): Activation: successful, device activated.
Feb 10 18:06:30 bava NetworkManager[589]: <info> [1581375990.5902] device (br0): carrier: link connected
```
Ah, br0 always connects exactly thirty seconds after the underlying interface (quickly) comes up.
This feels like an artificial delay.
https://bbs.archlinux.org/viewtopic.php?id=207379
> This delay is caused by Spanning Tree Protocol (STP) which is enabled by default to detect and resolve loops in bridged networks. Since your bridge is just for VM's there are unlikely to be loops and you can safely turn this off.
```
🐚 bava ~ $ nmcli connection show br0 | grep stp
bridge.stp: yes
🐚 bava ~ $ sudo nmcli connection modify br0 bridge.stp no
🐚 bava ~ $ sudo systemctl restart NetworkManager
```
Nope, that didn't fix it.
Oh, it might be IPv6.
The interface was set to "automatic" but I'm not using IPv6 on my LAN.
This seems to have eliminated the delay bringing up the bridge on wake from suspend:
```
🐚 bava ~ $ sudo nmcli connection modify br0 ipv6.method ignore
```
https://news.ycombinator.com/item?id=22292003
> Unrelated fact: Tom Swift is why tasers are called tasers. Their inventor, Jack Cover (https://en.wikipedia.org/wiki/Jack_Cover), named them by acronymizing "Thomas A. Swift's Electric Rifle" (TASER).
Servings: grains 7/6, fruit 3/4, vegetables 4/4, dairy 6/2, meat 4/3, nuts 0/0.5
Breakfast: cucumber, celery, banana, apple, two eggs
Brunch: bagel with cream cheese, coffee
Lunch: yogurt, orange, tomato
Dinner: pizza
130/80
< ^ txt