Raspberry Pi 4 WAN port lost connection after period of time

Installing and Using OpenWrt
1

Hi, does anyone know why my raspberry pi 4's WAN port always lost connection after period of time? Restart the WAN port will help but it will happen again after period of time. I'm using USB3 to ethernet for the WAN port and the default ethernet port for LAN.

Here is the log when it lost connection. Thank you.

Tue May 31 23:15:07 2022 kern.warn kernel: [206007.491439] ------------[ cut here ]------------
Tue May 31 23:15:07 2022 kern.info kernel: [206007.496203] NETDEV WATCHDOG: eth1 (ax88179_178a): transmit queue 0 timed out
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.503420] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:473 0xffffffc010623980
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.511253] Modules linked in: pppoe ppp_async iptable_nat brcmfmac xt_state xt_nat xt_conntrack xt_REDIRECT xt_MASQUERADE xt_FLOWOFFLOAD xt_CT pppox ppp_generic nf_nat nf_flow_table_hw nf_flow_table nf_conntrack ipt_REJECT cfg80211 ax88179_178a xt_time xt_tcpudp xt_multiport xt_mark xt_mac xt_limit xt_comment xt_TCPMSS xt_LOG usbnet usbhid slhc nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_filter ip_tables hid_generic crc_ccitt compat brcmutil snd_bcm2835(C) hid evdev nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 snd_rawmidi snd_seq_device snd_pcm_oss snd_pcm_dmaengine snd_pcm snd_timer snd_mixer_oss snd_hwdep snd_compress snd soundcore nls_utf8 vfat fat nls_iso8859_1 nls_cp437 uhci_hcd ohci_platform ohci_hcd
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.582409] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G         C        5.4.188 #0
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.589889] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.595807] pstate: 60400005 (nZCv daif +PAN -UAO)
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.600680] pc : 0xffffffc010623980
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.604250] lr : 0xffffffc010623980
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.607819] sp : ffffffc010003da0
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.611214] x29: ffffffc010003da0 x28: 0000000000000140
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.616610] x27: 00000000ffffffff x26: 0000000000000000
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.622006] x25: 0000000000000000 x24: 0000000000000000
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.627401] x23: 0000000000000001 x22: ffffff807c557000
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.632796] x21: ffffff807c557480 x20: ffffffc010926000
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.638191] x19: 0000000000000000 x18: 0000000000000000
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.643585] x17: 0000000000000000 x16: 0000000000000000
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.648979] x15: 0000000000000000 x14: 07740775076f0720
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.654374] x13: 07640765076d0769 x12: 0774072007300720
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.659768] x11: 0765077507650775 x10: 0771072007740769
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.665163] x9 : 076d0773076e0761 x8 : 077207740720073a
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.670557] x7 : 0729076107380737 x6 : 0000000000000001
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.675951] x5 : ffffffc0103a8f78 x4 : 0000000000000001
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.681345] x3 : ffffffc010928e64 x2 : 0000000000000004
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.686740] x1 : 0000000000000004 x0 : 0000000000000040
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.692135] Call trace:
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.694663]  0xffffffc010623980
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.697884]  0xffffffc0101150e8
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.701106]  0xffffffc010115908
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.704327]  0xffffffc0100813f4
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.707548]  0xffffffc0100a92fc
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.710769]  0xffffffc0100fad9c
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.713990]  0xffffffc0100810e4
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.717211]  0xffffffc010082e30
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.720432]  0xffffffc010087e00
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.723653]  0xffffffc0100d6c54
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.726875]  0xffffffc0100d6e4c
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.730096]  0xffffffc010760498
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.733318]  0xffffffc0108a0874
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.736539]  0xffffffc0108a0c80
Tue May 31 23:15:08 2022 kern.warn kernel: [206007.739760] ---[ end trace f8aae5ce8015a21f ]---

Just an extra problem that annoys me is the possible DNS-rebind attack detected. Is it possible that the log stops recording it without disabling the Rebind protection? Thank you.

Tue May 31 23:30:50 2022 daemon.warn dnsmasq[2244]: possible DNS-rebind attack detected: apd-pcdnwxlogin.teg.tencent-cloud.net
Tue May 31 23:30:50 2022 daemon.warn dnsmasq[2244]: possible DNS-rebind attack detected: apd-pcdnwxlogin.teg.tencent-cloud.net
Tue May 31 23:30:50 2022 daemon.warn dnsmasq[2244]: possible DNS-rebind attack detected: apd-pcdnwxlogin.teg.tencent-cloud.net
Tue May 31 23:30:50 2022 daemon.warn dnsmasq[2244]: possible DNS-rebind attack detected: apd-pcdnwxlogin.teg.tencent-cloud.net
Tue May 31 23:30:50 2022 daemon.warn dnsmasq[26626]: possible DNS-rebind attack detected: apd-pcdnwxlogin.teg.tencent-cloud.net
Tue May 31 23:30:50 2022 daemon.warn dnsmasq[2244]: possible DNS-rebind attack detected: apd-pcdnwxlogin.teg.tencent-cloud.net
Tue May 31 23:30:50 2022 daemon.warn dnsmasq[2244]: possible DNS-rebind attack detected: apd-pcdnwxlogin.teg.tencent-cloud.net
2

This means the DNS reply is a private IP or invalid address, you can disable this:

screen111

Stop having a Private IP or invalid IPs as a DNS response.

user@machine:~$ nslookup apd-pcdnwxlogin.teg.tencent-cloud.net 1.1.1.1
Server:         1.1.1.1
Address:        1.1.1.1#53

Non-authoritative answer:
Name:   apd-pcdnwxlogin.teg.tencent-cloud.net
Address: 0.0.0.1

:spiral_notepad: 0.0.0.1 is [generally] not a valid IP address.

3

How do I know if I got invalid IP/Private IP as a DNS response or not?
I have tried my ISP DNS, Google DNS and reset the openwrt hosts file as default but it is still the same.

4

I showed you - nslookup

5

I using windows cmd to do nslookup and it shows this. Is that normal?

Server:  OpenWrt.lan
Address:  192.168.1.1

* No internal type for both IPv4 and IPv6 Addresses (A+AAAA) records available for apd-pcdnwxlogin.teg.tencent-cloud.net
6
  • You're supposed to receive the correct answer, so no it's not normal.
  • Your OpenWrt will not provide the response of 0.0.0.1 - because that would be a rebind (or invalid) IP address - you must disable Rebind Protection
Wed Jun  1 11:29:37 2022 daemon.warn dnsmasq[26440]: possible DNS-rebind attack detected: apd-pcdnwxlogin.teg.tencent-cloud.net
Wed Jun  1 11:30:01 2022 daemon.warn dnsmasq[26440]: possible DNS-rebind attack detected: apd-pcdnwxlogin.teg.tencent-cloud.net
Wed Jun  1 11:31:11 2022 daemon.warn dnsmasq[26440]: possible DNS-rebind attack detected: apd-pcdnwxlogin.teg.tencent-cloud.net

See another thread on this same topic - post No. 18 mentions something; but not sure it will work in your case:

TBH, I wouldn't advise allowing invalid replies, such as invalid or Private IPs from Public DNS servers.

7

So the only way to stop it from logging is to disable the rebind protection or whitelist the domain right?
Is that possible to stop it from logging without disable the rebind protection?
Because it keeps on spamming on the system log and I suspect it caused my WAN port lost connection after a period of time.

8
  • You might be able to change the log level of dnsmasq?
  • You could configure your clients via DHCP Option No. 6 to use the Public DNS instead of the OpenWrt's dnsmasq instance
  • You could make a DNS record on the OpenWrt

You asked this question already:

I provided you information. Maybe others can respond too.

Can you explain why you want to stop the log; but don't wish to disable rebind?

I doubt that.

You are aware that malicious Rebind Responses could be attacks, correct?

  • Do you know what LAN device is attempting to resolve apd-pcdnwxlogin.teg.tencent-cloud.net?
    • If so, you could block it, the response is [seemingly] invalid anyway
9

Ohh Just follow what you say and I notice that is come from DVG-F2452. But unfortunately that I have to use the router as AP so I cannot block it.

10

If you accept the risk and trust the DNS answer, just whitelist the domain to allow RFC1918 responses in the DHCP and DNS General Settings.

Also, there have been many issues reported with the ax88179 adapter. Most people (including me) have better results and stability with UE300 adapters.

2 Likes
11

Alright. I think I better just leave it there.

I see. Mine's adapter is also using ax88179. No wonder sometimes will lost connection. Thanks for the info.

12

See from this thread:

1 Like
13

I see. thanks for the info.

1 Like
14

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.