384.7 IPV6 Stateful Generates Logged Errors, Stateless Does Not

[GHammer]

I enable stateful vs stateless in order to have routable IPV6 addresses.
After doing that, and a quick restart of the router, I checked that the target devices had drawn a routable IPV6 address and then made the proper IPV6 firewall entries.
Shortly after, I noticed the log entries shown below. About every 30 seconds there are three entries.
I first removed the IPV6 firewall entries and restarted the router.
The log entries continued to be generated.
I switched IPV6 back to stateless and restarted.
No errors are logged.

This is a Comcast connection through my cable modem.
The only difference is stateful vs stateless.

Any ideas?

Aug 17 22:03:10 rc_service: watchdog 769:notify_rc start_dnsmasq
Aug 17 22:03:10 dnsmasq[13536]: warning: no upstream servers configured
Aug 17 22:03:12 kernel: Unhandled fault: alignment fault (0x92000021) at 0x00000000006858c6
Aug 17 22:03:40 rc_service: watchdog 769:notify_rc start_dnsmasq
Aug 17 22:03:40 dnsmasq[13557]: warning: no upstream servers configured
Aug 17 22:03:41 kernel: Unhandled fault: alignment fault (0x92000021) at 0x00000000006138c6
Aug 17 22:04:10 rc_service: watchdog 769:notify_rc start_dnsmasq
Aug 17 22:04:10 dnsmasq[13578]: warning: no upstream servers configured
Aug 17 22:04:12 kernel: Unhandled fault: alignment fault (0x92000021) at 0x00000000004bd8c6
Aug 17 22:04:40 rc_service: watchdog 769:notify_rc start_dnsmasq
Aug 17 22:04:40 dnsmasq[13599]: warning: no upstream servers configured
Aug 17 22:04:44 kernel: Unhandled fault: alignment fault (0x92000021) at 0x000000000017c8c6
Aug 17 22:05:10 rc_service: watchdog 769:notify_rc start_dnsmasq
Aug 17 22:05:10 dnsmasq[13626]: warning: no upstream servers configured
Aug 17 22:05:11 kernel: Unhandled fault: alignment fault (0x92000021) at 0x000000000086a8be

 

[Sean B.]

Try setting "Connect to DNS server automatically" to "Enable". Also, I believe Merlin's GUI has a log section specific to IPv6, if so it'd be worth a glance.

 

[GHammer]

Try setting "Connect to DNS server automatically" to "Enable". Also, I believe Merlin's GUI has a log section specific to IPv6, if so it'd be worth a glance.

That setting only uses the DNS entries provided by the ISP instead of my chosen DNS entries. Stateful generates the errors at the same frequency with the setting in either state.
There is no separate IPV6 logging as far as I see.

 

[john9527]

What is the output of

cat /etc/resolv.conf

when it's failing? EDIT: Run the command a few times in a row.

Also, are you using any add-ons like DNSCrypt or ABSolution?

 

[GHammer]

What is the output of

cat /etc/resolv.conf

when it's failing? EDIT: Run the command a few times in a row.

Also, are you using any add-ons like DNSCrypt or ABSolution?

Using no addons. It seems that it has only itself in the resolv file:

admin@RT-AC86U-6828:/# cat /etc/resolv.conf
nameserver 127.0.0.1

 

[john9527]

/Speculation on

Stateful IPv6 has a unique configuration path thru the firmware. There's a bug there that is causing the resolv file to not be configured. dnsmasq sees this, but also has a bug with no configured servers that is causing the kernel error and crashes dnsmasq. The watchdog sees that dnsmasq has crashed and tries to restart it. As the saying goes, 'Lather, Rinse, Repeat'.

/Speculation off

Someone is going to need to walk thru the stateful code to see if they can see why the resolv file isn't being populated.

 

[Sean B.]

The resolv.conf file is correct. It has the localhost address set so all local ( as in running on the router ) processes will use dnsmasq as the dns server. The dns servers configured in the GUI should reside in /etc/resolv.dnsmasq .

 

[Sean B.]

Does the br0 interface successfully obtain a /64 IPv6 IP address when statefull is selected? Viewed via:

ifconfig br0

 

[john9527]

The resolv.conf file is correct. It has the localhost address set so all local ( as in running on the router ) processes will use dnsmasq as the dns server. The dns servers configured in the GUI should reside in /etc/resolv.dnsmasq .

Actually no....but I gave the wrong file too (teach me to respond when I first get up ) The configured servers are in
/tmp/resolv.conf

Can you double check with the cat command there?

 

[Sean B.]

Actually no....but I gave the wrong file too (teach me to respond when I first get up ) The configured servers are in
/tmp/resolv.conf

Can you double check with the cat command there?

Sorry, my check wouldn't be accurate as I'm running Tomato firmware. Tomato retains the configured servers in /etc/resolv.dnsmasq , which is also the default location dnsmasq will store them in, so I made the assumption. I should have looked at Merlins code to verify first.

**EDIT** Checked the code, and neither of us appear to be awake yet, as we both got a little right and a little wrong. The user entered DNS servers should be located in /tmp/resolv.dnsmasq:

if (!(fp_servers = fopen("/tmp/resolv.dnsmasq", "w+"))) {
perror("/tmp/resolv.dnsmasq");
fclose(fp);
goto error;
    }

 

[GHammer]

Actually no....but I gave the wrong file too (teach me to respond when I first get up ) The configured servers are in
/tmp/resolv.conf

Can you double check with the cat command there?

Sorry for the delayed response.

cat /tmp/resolv.conf
nameserver 1.1.1.1
nameserver 8.8.8.8

 

[GHammer]

Does the br0 interface successfully obtain a /64 IPv6 IP address when statefull is selected? Viewed via:

ifconfig br0

Yes, it does.

 

[john9527]

Sorry for the delayed response.

cat /tmp/resolv.conf
nameserver 1.1.1.1
nameserver 8.8.8.8

Interesting....and baffling....

Can you run one more command while in the failing state?
cat /etc/dnsmasq.conf | grep "resolv"

 

[Sean B.]

Sorry for the delayed response.

cat /tmp/resolv.conf
nameserver 1.1.1.1
nameserver 8.8.8.8

Try this for testing: Enable statefull IPv6, then via command line run:

echo "nameserver 2001:4860:4860::8888" >> /tmp/resolv.conf

Then check the logs and see if anything changes.

If that shows no change, I'd suggest checking for existence of /tmp/resolv.dnsmasq .

 

[GHammer]

Interesting....and baffling....

Can you run one more command while in the failing state?
cat /etc/dnsmasq.conf | grep "resolv"

cat /etc/dnsmasq.conf | grep "resolv"
no-resolv
servers-file=/tmp/resolv.dnsmasq

 

[GHammer]

Try this for testing: Enable statefull IPv6, then via command line run:

echo "nameserver 2001:4860:4860::8888" >> /tmp/resolv.conf

Then check the logs and see if anything changes.

If that shows no change, I'd suggest checking for existence of /tmp/resolv.dnsmasq .

Holding off on changing resolv.conf
Here's the contents of /tmp/resolv.dnsmasq

 cat resolv.dnsmasq
server=1.1.1.1
server=8.8.8.8
server=2606:4700:4700::1111
server=2001:4860:4860::8888

 

[Sean B.]

cat /etc/dnsmasq.conf | grep "resolv"
no-resolv
servers-file=/tmp/resolv.dnsmasq

As suspected, dnsmasq's servers are stored in /tmp/resolv.dnsmasq , however Merlin uses a different way of going about it. Rather than adding the resolv-file= directive for the resolv.dnsmasq file which uses the same syntax for server listings as resolv.conf , it's using the servers-file which is much different.

 

[Sean B.]

A caveat of using the servers-file directive is the file it points to is re-read when dnsmasq receives a SIGHUP. It's possible it's only re-read when it specifically receives a SIGHUP and perhaps that isn't happening. An easy check would be to enable statefull and then from command line run:

killall -SIGHUP dnsmasq

 

[GHammer]

A caveat of using the servers-file directive is the file it points to is re-read when dnsmasq receives a SIGHUP. It's possible it's only re-read when it specifically receives a SIGHUP and perhaps that isn't happening. An easy check would be to enable statefull and then from command line run:

killall -SIGHUP dnsmasq

killall: dnsmasq: no process killed

 

[john9527]

killall: dnsmasq: no process killed

Run it several times in a row....you need to catch dnsmasq before it crashes with the kernel error (I still think there is a dnsmasq bug playing in this)c

EDIT: The cobwebs are starting to clear....I remember now that I re-wrote a good portion of the dnsmasq start code for my fork to eliminate the use of the servers-file.