OpenWrt/LEDE Project

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by PussAzuki - 14.05.2019
Last edited by Hans Dedecker - 31.05.2019

FS#2282 - The package odhcpd seems to be something wrong

Hello, this occurs on PSG1218 ver. A (MTK MIPS) on a fresh build from trunk.
I have used the 6in4 tunnel for a long time, and keep the same config for so long, so I want to have a clean flash, and it looks to go bad.
I lost the public network IPv6 default gateway and got an IPv6 default gateway for the intranet starting with fe80:

It seems that keeping the configuration unchanged for a long time may lead to some hidden problems. And they may only show up when you take a clean flash.

I have collected some information by logread and windump, and I hope it can do something.

Closed by  Hans Dedecker
31.05.2019 16:39
Reason for closing:  Works for me
Additional comments about closing:  

I will close the bug record for now.
Feel free to re-open if the issue pops up again; but please provide tcpdump traces of the RA messages and the IPv6 messages being exchanged when you try to ping a public IPV6 address in such scenario

PussAzuki commented on 14.05.2019 15:04

It looks like I didn't save the dump file correctly.

Admin
Jo-Philipp Wich commented on 14.05.2019 18:25

Please provide your network and firewall configuration

PussAzuki commented on 14.05.2019 18:36

Things in the /etc/config/dhcp

config dnsmasq

option authoritative '0'
option domainneeded '1'
option rebind_protection '1'
option rebind_localhost '1'
option localservice '1'
option noresolv '1'
option nonwildcard '1'
list server '127.0.0.1#1053'

config dhcp 'lan'

option interface 'lan'
option ra 'server'
option dhcpv6 'server'
option dhcpv4 'server'
option leasetime '168h'
option start '2'
option limit '63'
option ra_default '1'
option ra_management '1'

config dhcp 'wan'

option interface 'wan'
option ignore '1'

config odhcpd 'odhcpd'

option maindhcp '1'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
option loglevel '7'

I use a local dns resolver named Pcap-dnsproxy.

Things changed in the /etc/config/network

config interface 'lan'

option type 'bridge'
option ifname 'eth0.1'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option ipaddr '192.168.123.1'

config interface 'henet'

option proto '6in4'
option peeraddr '66.220.18.42'
option ip6addr '2001:470:x:abcd::2/64'
option mtu '1424'
option ip6prefix '2001:470:y:abcd::/64'

Things in the /etc/config/firewall

config defaults

option syn_flood '1'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
option flow_offloading '1'
option flow_offloading_hw '1'

config zone

option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option network 'lan'

config zone

option name 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
option network 'wan wan6 henet wwan'

config forwarding

option src 'lan'
option dest 'wan'

config rule

option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'

config rule

option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'

config rule

option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'

config rule

option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'

config rule

option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'

config rule

option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'

config rule

option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'

config rule

option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'

config rule option name 'Allow-ICMPv6-Input'

option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'

config rule

option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'

config rule

option name 'Allow-IPSec-ESP'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'

config rule

option name 'Allow-ISAKMP'
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'

config ruleconfig rule

option name 'Allow-protocol-41'
option src 'wan'
option proto '41'
option target 'ACCEPT'

config rule

option name 'Allow-protocol-59'
option src 'wan'
option proto '59'
option target 'ACCEPT'
option extra '-m length --length 40'

config include

option path '/etc/firewall.user'
PussAzuki commented on 14.05.2019 21:04

The package dnsmasq-full seems to have the same problem, would it be a system error instead of a software error?
I also used a patch to make it possible to allow multiple callbacks to be registered according to the project fullcone
https://github.com/LGA1150/openwrt-fullconenat it should be nothing to do with the problem because I tested it without including this patch,the result looks like being the same

PussAzuki commented on 18.05.2019 09:26

Is there anything I can offer? At present, it seems that dnsmasq-full and odhcpd/odhcpd-ipv6only have problems on my machine. With the former, the Android phone has only one internal network starting with fe80, and cannot connect to other ipv6 addresses. The latter got two public network addresses (one for SLAAC and one for non-SLAAC) and one for intranet addresses starting with fe80 on ipv6, and then it seems that the lifetime of 1800 seconds can't connect to other ipv6 addresses. I have been using another router to dial, and then this router is wirelessly bridged to reduce my relative distance to another router.

PussAzuki commented on 23.05.2019 13:24

After many clean flashes, odhcpd metaphysically can renew the client's contract. But after restarting the odhcpd service, it can no longer renew the client. This is really a metaphysical bug.

Project Manager
Hans Dedecker commented on 23.05.2019 13:57

Please attach logread traces of your findings.
Also the included windump.txt file does not show any RA message (did you wait long enough ?) while the odhcpd traces clearly indicate RA messages are sent

PussAzuki commented on 23.05.2019 14:09

Do I just change odhcpd's log level to 7 then reconnect the connection and use windump on Windows? If you can give me what exact command I need to use with windump, it should be better.

PussAzuki commented on 23.05.2019 15:18

The windump started after I plugged the wire, and tcpdump started from 28 minutes.

PussAzuki commented on 23.05.2019 15:25

This time it looks like there is no problem...

Project Manager
Hans Dedecker commented on 26.05.2019 19:00

I cannot see anything wrong in the tcpdump; prefix 2001:470:d:1ca4::/64 is sent in RA prefix info option with the onlink and autonomous flags set as expected. The router lifetime is set to 1800 as expected with the other and managed flags set.
It would be interesting to see if you have an issue what the actual status is of the lan (ifstatus lan) and the contents of the RA messages.

Checking the dhcp config why are you setting ra_default to 1 ?
In principle this should not be set as odhcpd auto learns if a default route is present and should not be overwritten by ra_default config

PussAzuki commented on 27.05.2019 05:02

The file I uploaded is the one with no errors. It seems that everything is normal now. But if I use a wired link and then use a wireless connection on the same computer, it may not work properly again. But I can’t guarantee that it will be 100% recurring.A long time ago, whether I setted ra_default to 1, it wouldn't work properly, and I think it's a bug...now I need more time to find out when and how.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing