What's new

Release Asuswrt-Merlin 386.7 is now available for all models

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
Pick a process, almost any process and dump it. They all have the same "Tainted:" information being displayed.
Code:
killall -s SEGV dnsmasq
killall -s SEGV vsftpd
killall -s SEGV miniupnpd
killall -s SEGV vnstatd
Code:
Jun 29 14:08:14 kernel: CPU: 1 PID: 18692 Comm: dnsmasq Tainted: P           O    4.1.52 #2
Jun 29 14:09:07 kernel: CPU: 3 PID: 3251 Comm: vsftpd Tainted: P           O    4.1.52 #2
Jun 29 14:10:30 kernel: CPU: 0 PID: 3259 Comm: miniupnpd Tainted: P           O    4.1.52 #2
Jun 29 14:12:54 kernel: CPU: 2 PID: 3213 Comm: vnstatd Tainted: P           O    4.1.52 #2
Code:
for i in $(seq 18); do echo $(($i-1)) $(($(cat /proc/sys/kernel/tainted)>>($i-1)&1));done

what does this return for you.
 
Code:
for i in $(seq 18); do echo $(($i-1)) $(($(cat /proc/sys/kernel/tainted)>>($i-1)&1));done

what does this return for you.
I don't have seq.
Code:
# for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18; do echo $(($i-1)) $(($(cat /proc/sys/kernel/tainted)>>($i-1)&1));done
0 1
1 0
2 0
3 0
4 0
5 0
6 0
7 0
8 0
9 0
10 0
11 0
12 1
13 0
14 0
15 0
16 0
17 0
 
In reality, from what I can tell is that it works just fine, and the tainted message is the kernels way of screaming impropriety at the modules being used (or atleast at what it is interpreting).
What is going on is the packet checksum is invalid. You get the csum error in the log, and what follows is just debugging info dumped to the log by the invalid checksum error handler.

The kernel is reported as being tainted because it contains non open source module. It's not an error state, it's just an attribute of every single kernels running on Asus routers. The kernel becomes flagged as tainted the instant it boots and loads proprietary kernel modules from Broadcom, Tuxera and Trend Micro.
 
RMerlin, thx for the hard work. Can you check into this issue with Backhaul Connection Priority that started back in alpha1 on the RT-AC68U firmware, it was good up to 386.5_2:
 

Attachments

  • 1GWanFirst3867alpha1.png
    1GWanFirst3867alpha1.png
    280.2 KB · Views: 108
  • 1GWanFirst38652.png
    1GWanFirst38652.png
    281.8 KB · Views: 102
RMerlin, thx for the hard work. Can you check into this issue with Backhaul Connection Priority that started back in alpha1 on the RT-AC68U firmware, it was good up to 386.5_2:
Everything related to AiMesh is closed source and outside of my control.
 
Everything related to AiMesh is closed source and outside of my control.
Ok, thx. strange that they got rid of the 1G Wan first selection.

If anyone else has a strange issue with Node not wanting to connect via powerline adapters after dirty flashing from alpha just flash 386.5_2 or earlier back on the Node and set it to 1G Wan first and then update to latest version.
 
Ok, thx. strange that they got rid of the 1G Wan first selection.

If anyone else has a strange issue with Node not wanting to connect via powerline adapters after dirty flashing from alpha just flash 386.5_2 or earlier back on the Node and set it to 1G Wan first and then update to latest version.
OR, Perhaps not so STRANGE as I seem to recall reading somewhere...
For 1G to even function, It needs to be set to AUTOMATIC Negotiation.
(However I'm just going from my "Muddy" Memory)

EDIT: thinking about it logically (in some instances) a 1G connection might have to Negotiate with a slower link so I suppose "automatic" negotiation...
instead of 1G-Only... makes some sense.
 
Last edited:
OR, Perhaps not so STRANGE as I seem to recall reading somewhere...
For 1G to even function, It needs to be set to AUTOMATIC Negotiation.
And also you shouldn't mix auto-negotiate with preconfigured rate. I've heard reports of networking equipment defaulting to half-duplex if they fail to auto-negotiate with the other end (because that end has auto-negotiate disabled).
 
OR, Perhaps not so STRANGE as I seem to recall reading somewhere...
For 1G to even function, It needs to be set to AUTOMATIC Negotiation.
(However I'm just going from my "Muddy" Memory)
I think you're confusing gigabit Ethernet auto-negotiation with the AiMesh backhaul network interface priority. Two different things.
 
I upgraded 2 RT-AC68U access point units to asuswrt-merlin 386.7. One unit upgraded OK and is working OK. The other unit requested a manual reboot after the upgrade and after the reboot it appears to operate. However, when I try to access its webpage I got the error "192.168.1.3 refused to connect." and therefore I cannot access the administration screens. I can login successfully using SSH and it displays the correct asuswrt-merlin release level. But no access is possible using the webpages.

Does anyone else have this issue? How can I resolve the issue?
 
Most like to run it on the router itself as you then eliminate other variables like WiFi interference, etc... For those that are hardwired from the PC to router with a verified good patch cable though can go that route.
Yes, I don't even have any wired PCs atm, so it has been nice to be able to do speed tests including packet loss from the router up until now. Packet loss is missing from the history as well so I guess some column/value just is not shown? Is this something within @RMerlin ´s control or some closed module?
 
I upgraded 2 RT-AC68U access point units to asuswrt-merlin 386.7. One unit upgraded OK and is working OK. The other unit requested a manual reboot after the upgrade and after the reboot it appears to operate. However, when I try to access its webpage I got the error "192.168.1.3 refused to connect." and therefore I cannot access the administration screens. I can login successfully using SSH and it displays the correct asuswrt-merlin release level. But no access is possible using the webpages.

Does anyone else have this issue? How can I resolve the issue?
Try 192.168.1.1
 
What is going on is the packet checksum is invalid. You get the csum error in the log, and what follows is just debugging info dumped to the log by the invalid checksum error handler.

The kernel is reported as being tainted because it contains non open source module. It's not an error state, it's just an attribute of every single kernels running on Asus routers. The kernel becomes flagged as tainted the instant it boots and loads proprietary kernel modules from Broadcom, Tuxera and Trend Micro.
While I don't think there is away to actually fix packet checksum issue, would it be possible to prevent the type of packet with the firewall since it seems to result in NXdomain any ways?

similar to how the outbound ipv6 dns is already padded


Code:
-A OUTPUT -p udp -m udp --dport 53 -m u32 --u32 "0x30>>0xf&0x1=0x0" -j OUTPUT_DNS
-A OUTPUT -p tcp -m tcp --dport 53 -m u32 --u32 "0x34>>0x1a&0x3c@0x8>>0xf&0x1=0x0" -j OUTPUT_DNS


-A OUTPUT_DNS -m string --hex-string "|10706f697579747975696f706b6a666e6603636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0d72666a656a6e666a6e65666a6503636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|1131306166646d617361787373736171726b03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0f376d667364666173646d6b676d726b03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0d386d617361787373736171726b03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0f3966646d617361787373736171726b03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|1265666274686d6f6975796b6d6b6a6b6a677403636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|086861636b7563647403636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|076c696e77756469056633333232036e657400|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0f6c6b6a68676664736174727975696f03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0b6d6e627663787a7a7a313203636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|077131313133333303746f7000|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|057371353230056633333232036e657400|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|077563746b6f6e6503636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0e7a786376626d6e6e666a6a66777103636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0a65756d6d6167766e627003636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns

-A logdrop_dns -j LOG --log-prefix "DROP_DNS " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop_dns -j DROP
 
Last edited:
Status
Not open for further replies.

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Staff online

Top