Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#2204 - odhcpd: dhcpv6 preffered lifetime halved on renew of static lease #7052

Closed
openwrt-bot opened this issue Mar 25, 2019 · 8 comments
Closed
Labels

Comments

@openwrt-bot
Copy link

rogerjames99:

Model Linksys WRT1900ACS
Architecture ARMv7 Processor rev 1 (v7l)
Firmware Version Lede SNAPSHOT r9506-42f2e07ba0 / LuCI Master (git-19.061.64392-718fb97)
Kernel Version 4.14.103
odhcpd 2019-02-27-16c5b6c9-3

When using systemd-networkd to request a static ipv6 address from from an openwrt router. I run into the problem illustrated by the following trace. The address to follow is IA_ADDR 2001:8b0:1418:4c2f::9 pltime:2372 vltime:2372

34 dhcp6 renew (xid=1c3ff1 (server-ID hwaddr type 1 c25627d4a752) (IA_NA IAID:9 T1:1186 T2:1897 (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295) (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:2372 vltime:2372)) (option-request DNS-server DNS-search-list NTP-server SNTP-servers) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (elapsed-time 0))
35 dhcp6 reply (xid=1c3ff1 (server-ID hwaddr type 1 c25627d4a752) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (opt_82) (DNS-server fda0:4d7f:afbb:4c2f::1) (IA_NA IAID:9 T1:580 T2:928 (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:1161 vltime:1161) (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295)))

Note that the pltime has been halved in the routers reply!

42 dhcp6 renew (xid=973c61 (server-ID hwaddr type 1 c25627d4a752) (IA_NA IAID:9 T1:580 T2:928 (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295) (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:1161 vltime:1161)) (option-request DNS-server DNS-search-list NTP-server SNTP-servers) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (elapsed-time 0))
43 dhcp6 reply (xid=973c61 (server-ID hwaddr type 1 c25627d4a752) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (opt_82) (DNS-server fda0:4d7f:afbb:4c2f::1) (IA_NA IAID:9 T1:285 T2:456 (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:571 vltime:571) (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295)))

52 dhcp6 renew (xid=4f072e (server-ID hwaddr type 1 c25627d4a752) (IA_NA IAID:9 T1:285 T2:456 (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295) (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:571 vltime:571)) (option-request DNS-server DNS-search-list NTP-server SNTP-servers) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (elapsed-time 0))
53 dhcp6 reply (xid=4f072e (server-ID hwaddr type 1 c25627d4a752) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (opt_82) (DNS-server fda0:4d7f:afbb:4c2f::1) (IA_NA IAID:9 T1:130 T2:208 (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:261 vltime:261) (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295)))

and so on until

274: 106 01:45:01.745699 c2:56:27:d4:a7:52 > b8:27:eb:d4:eb:54, ethertype IPv6 (0x86dd), length 198: (flowlabel 0xc541e, hlim 64, next-header UDP (17) payload length: 144) fe80::c056:27ff:fed4:a752.547 > fe80::ba27:ebff:fed4:eb54.546: [udp sum ok] dhcp6 reply (xid=3eeea5 (server-ID hwaddr type 1 c25627d4a752) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (opt_82) (DNS-server fda0:4d7f:afbb:4c2f::1) (IA_NA IAID:9 T1:4294967295 T2:4294967295 (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295) (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:0 vltime:0)

At which point the client gives up and removes the address from the interface and does not attempt to reaccquire it.

I can get round this by having the client request an infinite lease. But I would prefer not to.

This does not look like the correct behaviour to me. Leasetime half life is a matter for the client not the server.

Steps to reproduce

  1. Configure a network to request a static ipv6 lease.

:/etc/systemd/network $ cat 10-peglegpete.network
[Match]
Name=peglegpete

[Network]
DHCP=yes
IPv6AcceptRA=yes

[Address]
Address=2001:1111:2222:3333::9/64

[DHCP]
DUIDType=link-layer-time
DUIDRawData=00:01:21:44:28:4a:b8:27:eb:71:99:03
IAID=9

  1. Set up a static lease in odhcpd using matching DUID and IAID data. Remember to prefix the DUID with the DUID-LLT type code 0001.
@openwrt-bot
Copy link
Author

rogerjames99:

Sorry misspelt preferred in the title.

@openwrt-bot
Copy link
Author

dedeckeh:

The preferred and valid lifetime of an IPv6 address is based on the preferred and valid lifetime of the prefix from which an IPv6 address is allocated.
So in this case it needs to checked what the prefix preferred and valid lifetimes are (ip -6 addr show) when a reply is sent to the client

@openwrt-bot
Copy link
Author

rogerjames99:

The trace shows the client trying to renew a lease that it has been given in response to a solicit with rapid commit, also client id. My tracing misses this. The solicit packet is similar to this one.

dhcp6 solicit (xid=2b2e8f (rapid-commit) (IA_NA IAID:9 T1:0 T2:0) (option-request DNS-server DNS-search-list NTP-server SNTP-servers) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (elapsed-time 6368))

What we are seeing in the first pair of packets in the trace is the first renewal attempt using the preferred and valid times sent in this response. Subsequent pairs use the values sent back to the client in the previous pair.

Packets 34 and 35 sent 2372 received 1161
Packets 42 and 43 sent 1161 received 571
Packets 52 and 53 sent 571 received 261
...
Packet 274 received 0

@openwrt-bot
Copy link
Author

dedeckeh:

I want to see the valid/preferred lifetime of the global IPv6 addresses on the gateway; this will make clear if the observed behavior is normal or not

@openwrt-bot
Copy link
Author

rogerjames99:

Sorry, I misunderstood.

Here are all the addresses on the router.

root@peglegpete:~# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 532
link/ether c0:56:27:d4:a7:52 brd ff:ff:ff:ff:ff:ff
inet6 fe80::c256:27ff:fed4:a752/64 scope link
valid_lft forever preferred_lft forever
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP qlen 532
link/ether c2:56:27:d4:a7:52 brd ff:ff:ff:ff:ff:ff
5: sit0@NONE: mtu 1480 qdisc noop state DOWN qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
6: ifb0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN qlen 32
link/ether d2:dd:a0:03:4b:8b brd ff:ff:ff:ff:ff:ff
7: ifb1: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN qlen 32
link/ether a6:f0:5b:61:1a:fb brd ff:ff:ff:ff:ff:ff
8: bond0: <BROADCAST,MULTICAST400> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether ee:8b:42:a1:70:16 brd ff:ff:ff:ff:ff:ff
11: teql0: mtu 1500 qdisc noop state DOWN qlen 100
link/void
12: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether c2:56:27:d4:a7:52 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.1/24 brd 192.168.10.255 scope global br-lan
valid_lft forever preferred_lft forever
inet6 2001:8b0:1418:4c2f::1/64 scope global dynamic
valid_lft 4015sec preferred_lft 4015sec
inet6 fda0:4d7f:afbb:4c2f::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::c056:27ff:fed4:a752/64 scope link
valid_lft forever preferred_lft forever
14: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP qlen 1000
link/ether c2:56:27:d4:a7:53 brd ff:ff:ff:ff:ff:ff
inet6 fe80::c056:27ff:fed4:a753/64 scope link
valid_lft forever preferred_lft forever
15: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP qlen 1000
link/ether c2:56:27:d4:a7:54 brd ff:ff:ff:ff:ff:ff
inet6 fe80::c056:27ff:fed4:a754/64 scope link
valid_lft forever preferred_lft forever
21: openvpn: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN qlen 100
link/[65534]
inet 10.8.0.1 peer 10.8.0.2/32 scope global openvpn
valid_lft forever preferred_lft forever
inet6 2001:8b0:1418:4c2e::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::5150:5259:f107:58e6/64 scope link
valid_lft forever preferred_lft forever
28: pppoe-wan: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN qlen 3
link/ppp
inet 217.169.13.4 peer 81.187.81.187/32 scope global pppoe-wan
valid_lft forever preferred_lft forever
inet6 2001:8b0:1111:1111:0:ffff:d9a9:d04/128 scope global dynamic
valid_lft 4015sec preferred_lft 415sec
inet6 fe80::7c0b:9028:fedc:13c8/10 scope link
valid_lft forever preferred_lft forever

@openwrt-bot
Copy link
Author

dedeckeh:

It would be interesting to see the lifetime of the IPv6 addresses on the lan after the client has renewed. Would it be possible to check the lifetime of the IPv6 addresses after the 1st and 2nd renew by the client ?

@openwrt-bot
Copy link
Author

rogerjames99:

Hans,
Looking at the code in dhcpv6-ia.c around line 842 to 852. Should prefix_pref and prefix_valid have leasetime added to them before now is subtracted?

uint32_t prefix_pref = addrs[i].preferred; uint32_t prefix_valid = addrs[i].valid;
if (!valid_addr(&addrs[i], now))
continue;
if (prefix_pref != UINT32_MAX)
prefix_pref -= now;
if (prefix_valid != UINT32_MAX)
prefix_valid -= now;

The times in sent in the renew request are relative but now is absolute. I cannot verify this as I do not have an openwrt build environment set up.

Roger

@openwrt-bot
Copy link
Author

rogerjames99:

Our posts crossed. I have attached the system-networkd logs for the time of the trace. They show the times being set on the interface.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant