I'm glad you got it fixed!
If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
Kind regards!
Need me to do a luci bug report?
A bug report...for what exactly?
Clicking the apply button did not call the /etc/init.d/network restart command, or there are other unknown problems in the call
- Your screenshot doesn't show all the relevant changes made at once
- Nonetheless, feel free to make a report
- Your screenshot still shows the error (by documentation at least) - again, the Wiki notes this should be
0b - I wasn't aware you were making these changes via LuCI until after - but I've never had the issues you described, though
Now I found that the prefix of RA is from ipv6 of lan interface, so there is nothing about odhcpd.
After modifying the ipv6 hint of the lan interface by webui, br-lan will add a ipv6 that used new prefix, but ubus showed status only has one new prefix ipv6
root@OpenWrt:~# cat /etc/config/network
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fdc7:78a6:9cc8::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth0'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.50.254'
option netmask '255.255.255.0'
option ip6assign '64'
option ip6hint '2'
config interface 'wan'
option device 'eth1'
option proto 'pppoe'
option username '-'
option password '-'
option ipv6 'auto'
config interface 'wan6'
option device 'eth1'
option proto 'dhcpv6'
27: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 00:*:*:*:bf brd ff:ff:ff:ff:ff:ff
inet 192.168.50.254/24 brd 192.168.50.255 scope global br-lan
valid_lft forever preferred_lft forever
inet6 fdc7:78a6:9cc8:2::1/64 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 2*:*:*:1a92::1/64 scope global dynamic noprefixroute
valid_lft 259054sec preferred_lft 172654sec
inet6 2*:*:*:1a99::1/64 scope global deprecated dynamic
valid_lft 7152sec preferred_lft 0sec
inet6 fdc7:78a6:9cc8:9::1/64 scope global deprecated dynamic
valid_lft 7152sec preferred_lft 0sec
inet6 fe80::*:*:*:52bf/64 scope link
valid_lft forever preferred_lft forever
root@OpenWrt:~# ubus call network.interface.lan status
{
"up": true,
"pending": false,
"available": true,
"autostart": true,
"dynamic": false,
"uptime": 194,
"l3_device": "br-lan",
"proto": "static",
"device": "br-lan",
"updated": [
"addresses"
],
"metric": 0,
"dns_metric": 0,
"delegation": true,
"ipv4-address": [
{
"address": "192.168.50.254",
"mask": 24
}
],
"ipv6-address": [
],
"ipv6-prefix": [
],
"ipv6-prefix-assignment": [
{
"address": "2*:*:*:1a92::",
"mask": 64,
"preferred": 172621,
"valid": 259021,
"local-address": {
"address": "2*:*:*:1a92::1",
"mask": 64
}
},
{
"address": "fdc7:78a6:9cc8:2::",
"mask": 64,
"local-address": {
"address": "fdc7:78a6:9cc8:2::1",
"mask": 64
}
}
],
"route": [
],
"dns-server": [
],
"dns-search": [
],
"neighbors": [
],
"inactive": {
"ipv4-address": [
],
"ipv6-address": [
],
"route": [
],
"dns-server": [
],
"dns-search": [
],
"neighbors": [
]
},
"data": {
}
}
I don't think this is a problem. The example in the wiki mentions a prefix length of 56, but if the ISP only provides a /60 prefix, then a value longer than 4 bits is useless (at least for any local prefixes created from that provider prefix).
And looking at the actual code in netifd, this option is parsed using strtol, so leading zeros don't make any difference.
@fengchen-lede: Have you checked the lifetime of the old prefixes in the router advertisement? If they are zero, then there isn't any issue. Including the old prefix with 0 lifetime is necessary so that the clients know to stop using that prefix.
1 Like
the old ipv6 of br-lan lifetime is as follows, and RA package is the same as br-lan
valid_lft 7033sec preferred_lft 0sec
ipv6 generated by pc using the old prefix is marked as deprecated.
So why keep prefixes that can't be used?
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.