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#2282 - The package odhcpd seems to be something wrong #7170

Closed
openwrt-bot opened this issue May 14, 2019 · 12 comments
Closed

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

openwrt-bot opened this issue May 14, 2019 · 12 comments
Labels

Comments

@openwrt-bot
Copy link

PussAzuki:

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.

@openwrt-bot
Copy link
Author

PussAzuki:

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

@openwrt-bot
Copy link
Author

jow-:

Please provide your network and firewall configuration

@openwrt-bot
Copy link
Author

PussAzuki:

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'

@openwrt-bot
Copy link
Author

PussAzuki:

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

@openwrt-bot
Copy link
Author

PussAzuki:

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.

@openwrt-bot
Copy link
Author

PussAzuki:

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.

@openwrt-bot
Copy link
Author

dedeckeh:

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

@openwrt-bot
Copy link
Author

PussAzuki:

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.

@openwrt-bot
Copy link
Author

PussAzuki:

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

@openwrt-bot
Copy link
Author

PussAzuki:

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

@openwrt-bot
Copy link
Author

dedeckeh:

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

@openwrt-bot
Copy link
Author

PussAzuki:

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.

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