Turris Build issueshttps://gitlab.nic.cz/turris/os/build/-/issues2023-01-11T17:11:34+01:00https://gitlab.nic.cz/turris/os/build/-/issues/334DHCP doesn't assign IPv4 addressed to LAN clients after reboot on Turris 1.x,...2023-01-11T17:11:34+01:00Simon BorekDHCP doesn't assign IPv4 addressed to LAN clients after reboot on Turris 1.x, TOS 5.3.6 ... sometimesinstance of https://gitlab.nic.cz/turris/os/build/-/issues/252
I found no reliable way how to reproduce and no reliable way how to persistently fix the issue when it occurs.
The next reasonable step seems to be finding out, if the issu...instance of https://gitlab.nic.cz/turris/os/build/-/issues/252
I found no reliable way how to reproduce and no reliable way how to persistently fix the issue when it occurs.
The next reasonable step seems to be finding out, if the issue still occurs on TOS 6.0 and look for possible fixes in the context of 6.0 version.
Summary of the information I found follows.
# How to reproduce
Turris 1.x, TOS 5.3.6, default configuration, WiFi set up through Reforis at 2.4 GHz with WPA2, DHCP client on WAN, static IP with DHCP server on LAN
1) switch WiFi to 5 GHz in LuCi, save and apply; or do whatever, then rollback to the snapshot of the initial configuration
2) reboot by disconnecting and reconnecting the power supply or by issuing `reboot` command
* alternatively do whatever, then 2.
I spent a huge amount of time trying to figure out a reliable reproduction method without real success, I originally encountered the problem by just plugging in the router in the morning and connecting a wireless client.
# Expected behavior
* clients connected to LAN (by wire or wirelessly) get proper IPv4 network configuration through DHCP
# Actual behavior
* clients connected to LAN (by wire or wirelessly) obtain no IPv4 configuration, only IPv6 connectivity works
* router itself has IPv4 address assigned and is capable of IPv4 internet communication
* `dnsmasq` on the router is running, but there are no mentions of it in the log obtained by `logread`
* problems usually persist even after router reboot
# How to fix the ocurring problem
* until router reboot:
* SSH using router's IPv6 address, `service restart dnsmasq`
* log output after:
```
...
Mar 9 10:56:15 turris dnsmasq[2095]: started, version 2.80 DNS disabled
Mar 9 10:59:36 turris dnsmasq[2095]: overflow: 2 log entries lost
Mar 9 10:00:01 turris crond[5238]: (root) CMD (/usr/bin/notifier)
Mar 9 10:00:01 turris crond[5239]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Mar 9 10:00:01 turris crond[5237]: (root) CMDEND (/usr/bin/rainbow_button_sync.sh)
Mar 9 10:00:01 turris crond[5236]: (root) CMDOUT (There is no message to send.)
Mar 9 10:00:01 turris crond[5236]: (root) CMDEND (/usr/bin/notifier)
Mar 9 10:00:39 turris dnsmasq: DNS rebinding protection is active, will discard upstream RFC1918 responses!
Mar 9 10:00:39 turris dnsmasq: Allowing 127.0.0.0/8 responses
Mar 9 11:00:42 turris dnsmasq[5386]: started, version 2.80 DNS disabled
Mar 9 11:00:42 turris dnsmasq[5386]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth nettlehash DNSSEC no-ID loop-detect inotify dumpfile
Mar 9 11:00:42 turris dnsmasq-dhcp[5386]: DHCP, IP range 192.168.1.100 -- 192.168.1.249, lease time 12h
Mar 9 11:00:42 turris dnsmasq-dhcp[5386]: read /etc/ethers - 0 addresses
Mar 9 10:01:01 turris crond[5428]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Mar 9 10:01:01 turris crond[5427]: (root) CMDEND (/usr/bin/rainbow_button_sync.sh)
Mar 9 11:01:08 turris dnsmasq-dhcp[5386]: DHCPDISCOVER(br-lan) 192.168.1.203 70:cd:0d:97:7f:6b
Mar 9 11:01:08 turris dnsmasq-dhcp[5386]: DHCPOFFER(br-lan) 192.168.1.203 70:cd:0d:97:7f:6b
Mar 9 11:01:08 turris dnsmasq-dhcp[5386]: DHCPREQUEST(br-lan) 192.168.1.203 70:cd:0d:97:7f:6b
Mar 9 11:01:08 turris dnsmasq-dhcp[5386]: DHCPACK(br-lan) 192.168.1.203 70:cd:0d:97:7f:6b
Mar 9 10:01:09 turris /dhcp_host_domain_ng.py: Refresh unbound leases
...
```
* persistently:
* fix sometimes persisted over reboot, if the reboot is accompanied by restart of the whole local network providing Turris 1.x with internet connectivity (Turris Omnia, TOS 5.3.5 stable), but sometimes, after another Turris 1.x reboot the DHCP server is broken again ... no reliable method to fix persistently known to me at this time
* log output after successful reboot to working state (including the dnsmasq output that is not present on erroneous autostart):
```
...
Mar 9 11:41:11 turris kernel: [ 23.402529] br-lan: port 6(wlan0) entered blocking state
Mar 9 11:41:11 turris kernel: [ 23.407857] br-lan: port 6(wlan0) entered forwarding state
Mar 9 11:41:11 turris kernel: [ 23.420864] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
Mar 9 10:41:11 turris firewall: Reloading firewall due to ifup of wan (eth2)
Mar 9 11:40:57 turris dnsmasq[2095]: started, version 2.80 DNS disabled
Mar 9 11:41:12 turris dnsmasq[2095]: overflow: 2 log entries lost
Mar 9 11:41:12 turris dnsmasq[4728]: started, version 2.80 DNS disabled
Mar 9 11:41:12 turris dnsmasq[4728]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth nettlehash DNSSEC no-ID loop-detect inotify dumpfile
Mar 9 11:41:12 turris dnsmasq-dhcp[4728]: DHCP, IP range 192.168.1.100 -- 192.168.1.249, lease time 12h
Mar 9 11:41:12 turris dnsmasq-dhcp[4728]: read /etc/ethers - 0 addresses
Mar 9 11:41:12 turris dnsmasq-dhcp[4728]: read /etc/ethers - 0 addresses
Mar 9 10:41:16 turris firewall: Reloading firewall due to ifup of wan6 (eth2)
Mar 9 11:41:18 turris dnsmasq-dhcp[4728]: DHCPDISCOVER(br-lan) 192.168.1.203 70:cd:0d:97:7f:6b
Mar 9 11:41:18 turris dnsmasq-dhcp[4728]: DHCPOFFER(br-lan) 192.168.1.203 70:cd:0d:97:7f:6b
Mar 9 11:41:18 turris dnsmasq-dhcp[4728]: DHCPREQUEST(br-lan) 192.168.1.203 70:cd:0d:97:7f:6b
Mar 9 11:41:18 turris dnsmasq-dhcp[4728]: DHCPACK(br-lan) 192.168.1.203 70:cd:0d:97:7f:6b
Mar 9 10:41:18 turris /dhcp_host_domain_ng.py: Refresh unbound leases
Mar 9 10:42:01 turris crond[5029]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Mar 9 10:42:01 turris crond[5028]: (root) CMDEND (/usr/bin/rainbow_button_sync.sh)
Mar 9 10:42:37 turris firewall: Reloading firewall due to ifupdate of wan6 (eth2)
...
```
## Contents of router's /etc/config/dhcp at the time of occuring problem:
```
config dnsmasq
option domainneeded '1'
option boguspriv '1'
option filterwin2k '0'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option nonegcache '0'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.auto'
option nonwildcard '1'
option localservice '1'
option port '0'
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option dhcpv6 'server'
option ra 'server'
list dhcp_option '6,192.168.1.1'
config dhcp 'wan'
option interface 'wan'
option ignore '1'
config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
option loglevel '4'
```https://gitlab.nic.cz/turris/os/build/-/issues/54[feature suggestion] enhance ipv6 privacy2020-02-11T12:20:30+01:00Ghost User[feature suggestion] enhance ipv6 privacysince it came up in the forum https://forum.turris.cz/t/ipv6-best-practice-questions/10423/3
With RFC 4941 for DHCP and RFC 7217 for SLAAC ipv6 privacy can be enhanced, which though currently is not the default (vanilla medkit).
___
RF...since it came up in the forum https://forum.turris.cz/t/ipv6-best-practice-questions/10423/3
With RFC 4941 for DHCP and RFC 7217 for SLAAC ipv6 privacy can be enhanced, which though currently is not the default (vanilla medkit).
___
RFC 7217 for SLAAC - `net.ipv6.conf.default.stable_secret`
recommends that a stable secret is to be generated during device set up, e.g. something like `head -c 16 /dev/urandom | xxd -p | sed "s/..../:&/g; s/://"` (requires package `xxd`) could be utilized.
It would have to be generated and added to sysctl.d (perhaps applied with sysctl -w during setup) prior any iface is setup since 'default' does not apply to any iface already in existence.
`net.ipv6.conf.all.stable_secret` does not work.
___
RFC 4941 for DHCP
> Acceptable values:
> 0 - don’t use privacy extensions.
> 1 - generate privacy addresses
> 2 - prefer privacy addresses and use them over the normal addresses.
Probably should do for existing and added ifaces
```
net.ipv6.conf.default.use_tempaddr = 2
net.ipv6.conf.all.use_tempaddr = 2
```