384.7 IPV6 Stateful Generates Logged Errors, Stateless Does Not

[Sean B.]

What specific router are you using? I apologize if you already stated previously.

 

[GHammer]

ASUS RT-AC86U

 

[Sean B.]

Hah, just like it says right at the bottom of all your posts. Yikes, sometimes my ADD gets the best of me. I'll continue researching the issue in relation to Merlins code and see what I can find.

 

[RMerlin]

Kill the watchdog service, it will make it easier for you to troubleshoot things without dnsmasq being constantly restarted/recrashed.

Once done with your tests, reboot the router to properly restart with a working watchdog.

 

[GHammer]

Kill the watchdog service, it will make it easier for you to troubleshoot things without dnsmasq being constantly restarted/recrashed.

Once done with your tests, reboot the router to properly restart with a working watchdog.

Thanks for the suggestion.
I will resume in the morning.

 

[john9527]

Kill the watchdog service, it will make it easier for you to troubleshoot things without dnsmasq being constantly restarted/recrashed.

Thanks for the suggestion.

I think you need to kill both watchdog services (IIRC there's actually a watchdog for the watchdog). Kill watchdog02 first.

 

[RMerlin]

I think you need to kill both watchdog services (IIRC there's actually a watchdog for the watchdog). Kill watchdog02 first.

There's no longer a second watchdog (or, at least it's not there all the time - my router only shows one).

 

[Sean B.]

@RMerlin , is this a one-off issue to your knowledge? Or have you had reports of/come across this issue with stateful LAN IPv6 from other users?

 

[RMerlin]

@RMerlin , is this a one-off issue to your knowledge? Or have you had reports of/come across this issue with stateful LAN IPv6 from other users?

Only a small handful of people are running 384.7 alpha builds, which has a newer version of dnsmasq. Therefore, not enough users to establish any meaningful statistics.

 

[john9527]

There's no longer a second watchdog (or, at least it's not there all the time - my router only shows one).

Got me curious....for some reason it looks like they don't run it on AC88U, AC3100 or AC5300. Looks like it should be running on AC86, but I may have missed something in my quick look.

 

[john9527]

@RMerlin , is this a one-off issue to your knowledge? Or have you had reports of/come across this issue with stateful LAN IPv6 from other users?

I'd also guess that stateful config isn't the primary used config.

 

[RMerlin]

Got me curious....for some reason it looks like they don't run it on AC88U, AC3100 or AC5300. Looks like it should be running on AC86, but I may have missed something in my quick look.

Whatever the reason, whoever at Asus came up with the idea of a watchdog for the watchdog was either too lazy to figure out why that first watchdog needed a watchdog in the first place, or he got bored and needed to write "something" to justify his paycheck

 

[john9527]

Whatever the reason, whoever at Asus came up with the idea of a watchdog for the watchdog was either too lazy to figure out why that first watchdog needed a watchdog in the first place, or he got bored and needed to write "something" to justify his paycheck

And it's an 'aw sh*t" recovery.....reboot.

 

[Sean B.]

Whatever the reason, whoever at Asus came up with the idea of a watchdog for the watchdog was either too lazy to figure out why that first watchdog needed a watchdog in the first place, or he got bored and needed to write "something" to justify his paycheck

Dogs get destructive when left alone, first one just needed a buddy . Though I would have figured the watchdog watching the watchdog would have been one in hardware, not both in software.

Watchdogs aside, looking into that kernel fault I came across this in the ARM community forums speaking on the exact error ( aside from the addressing ):

The compiler will assume that a pointer is correctly aligned for the type (e.g. a pointer to a 32-bit type will be aligned to a 32-bit boundary). If you cast a pointer then it assumes you know what you are doing, and that the resultant pointer will be correctly aligned.

Further increases my feeling this issue is rooted in code, and not use or configuration. While this issue screams doing so, I'm really dragging my feet on bringing it up in/or searching through dnsmasq's mailing list. Simply because I hate mailing lists.

 

[Sean B.]

Thanks for the suggestion.
I will resume in the morning.

Are you by chance running entware-ng, or something of the sort for opt? If strace is available, an output from it running dnsmasq in stateful config would be great to check.

 

[Sean B.]

Changes made to forward.c, in this commit, are in the area of suspect. Just based on code location/function/timeline .. it's Sunday night - brain won't parse detailed code inspection.

 

[GHammer]

dnsmasq may be restarting as part of the normal startup, then the changes would be lost. To really confirm, the dnsmasq.conf edits should really be done in a dnsmasq.postconf script.
Make a /jffs/scripts/dnsmasq.postconf and set it executeable with the following

#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh

pc_delete "no-resolv" $CONFIG
pc_replace "servers-file=/tmp/resolv.dnsmasq" "resolv-file=/tmp/test.conf" $CONFIG

A new day.
The result of this is disturbing to me as I did this in stateless mode. dnsmasq has not errored in stateless mode until now.

Aug 20 11:00:00 rc_service: service 31520:notify_rc restart_dnsmasq
Aug 20 11:00:00 custom_script: Running /jffs/scripts/dnsmasq.postconf (args: /etc/dnsmasq.conf ) - max timeout = 120s
Aug 20 11:00:00 dnsmasq[31524]: warning: no upstream servers configured

 

[GHammer]

Are you by chance running entware-ng, or something of the sort for opt? If strace is available, an output from it running dnsmasq in stateful config would be great to check.

No, except for the things we've done and opening ports to a webserver hosted here, plain vanilla.

 

[john9527]

A new day.
The result of this is disturbing to me as I did this in stateless mode. dnsmasq has not errored in stateless mode until now.

Did you also recreate the /tmp/test.conf file per @Sean B. (sorry I didn't explicitly remind you)


then run:

echo "nameserver 8.8.8.8" > /tmp/test.conf & echo "nameserver 2001:4860:4860::8888" >> /tmp/test.conf

 

[GHammer]

Did you also recreate the /tmp/test.conf file per @Sean B. (sorry I didn't explicitly remind you)


then run:

echo "nameserver 8.8.8.8" > /tmp/test.conf & echo "nameserver 2001:4860:4860::8888" >> /tmp/test.conf

In place.

admin@RT-AC86U-6828:/tmp/home/root# cat /tmp/test.conf
nameserver 8.8.8.8
nameserver 2001:4860:4860::8888