@psherman, @mk24 thanks for the help. i'm going to go afk now, for real. be back in an hour-ish.
reset to default settings, ethernet worked fine, 192.168.1.1
turned on wifi with former essid and pw, and immediately was unable to connect.
reset to default settings again. ethernet worked fine. enabled wifi, but different essid and pw (just to be sure), and that's working fine too.
so now i think it really is something to do with all the tasmota devices connecting. i have maybe 20 different devices (bulbs and dimmers). does that sound plausible?
Let’s see the configs.
Please copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall
@psherman thanks for having a look!
root@router:~# cat /etc/config/network
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'ffff:ffff:ffff::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
config interface 'wan'
option device 'wan'
option proto 'dhcp'
config interface 'wan6'
option device 'wan'
option proto 'dhcpv6'
root@router:~# cat /etc/config/wireless
config wifi-device 'radio0'
option type 'mac80211'
option path 'platform/18000000.wmac'
option channel '1'
option band '2g'
option htmode 'HT20'
option cell_density '0'
option country 'US'
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option encryption 'psk2'
option key 'password'
option ssid 'essid'
config wifi-device 'radio1'
option type 'mac80211'
option path '1a143000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
option channel '36'
option band '5g'
option htmode 'HE80'
option cell_density '0'
option country 'US'
config wifi-iface 'default_radio1'
option device 'radio1'
option network 'lan'
option mode 'ap'
option encryption 'psk2'
option key 'password'
option ssid 'e55id'
root@router:~# cat /etc/config/dhcp
config dnsmasq
option domainneeded '1'
option boguspriv '1'
option filterwin2k '0'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option nonegcache '0'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
option nonwildcard '1'
option localservice '1'
option ednspacket_max '1232'
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option dhcpv4 'server'
option dhcpv6 'server'
option ra 'server'
option ra_slaac '1'
list ra_flags 'managed-config'
list ra_flags 'other-config'
config dhcp 'wan'
option interface 'wan'
option ignore '1'
config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
option loglevel '4'
root@router:~# cat /etc/config/firewall
config defaults
option syn_flood 1
option input ACCEPT
option output ACCEPT
option forward REJECT
# Uncomment this line to disable ipv6 rules
# option disable_ipv6 1
config zone
option name lan
list network 'lan'
option input ACCEPT
option output ACCEPT
option forward ACCEPT
config zone
option name wan
list network 'wan'
list network 'wan6'
option input REJECT
option output ACCEPT
option forward REJECT
option masq 1
option mtu_fix 1
config forwarding
option src lan
option dest wan
# We need to accept udp packets on port 68,
# see https://dev.openwrt.org/ticket/4108
config rule
option name Allow-DHCP-Renew
option src wan
option proto udp
option dest_port 68
option target ACCEPT
option family ipv4
# Allow IPv4 ping
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
# Allow DHCPv6 replies
# see https://github.com/openwrt/openwrt/issues/5066
config rule
option name Allow-DHCPv6
option src wan
option proto udp
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 ffff::/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
# Allow essential incoming IPv6 ICMP traffic
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
# Allow essential forwarded IPv6 ICMP traffic
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
### EXAMPLE CONFIG SECTIONS
# do not allow a specific ip to access wan
#config rule
# option src lan
# option src_ip 192.168.45.2
# option dest wan
# option proto tcp
# option target REJECT
# block a specific mac on wan
#config rule
# option dest wan
# option src_mac 00:11:22:33:44:66
# option target REJECT
# block incoming ICMP traffic on a zone
#config rule
# option src lan
# option proto ICMP
# option target DROP
# port redirect port coming in on wan to lan
#config redirect
# option src wan
# option src_dport 80
# option dest lan
# option dest_ip 192.168.16.235
# option dest_port 80
# option proto tcp
# port redirect of remapped ssh port (22001) on wan
#config redirect
# option src wan
# option src_dport 22001
# option dest lan
# option dest_port 22
# option proto tcp
### FULL CONFIG SECTIONS
#config rule
# option src lan
# option src_ip 192.168.45.2
# option src_mac 00:11:22:33:44:55
# option src_port 80
# option dest wan
# option dest_ip 194.25.2.129
# option dest_port 120
# option proto tcp
# option target REJECT
#config redirect
# option src lan
# option src_ip 192.168.45.2
# option src_mac 00:11:22:33:44:55
# option src_port 1024
# option src_dport 80
# option dest_ip 194.25.2.129
# option dest_port 120
# option proto tcp
internet still works today with default settings. in about 2 hours, i'll try changing it back to the wifi essid and pw that all the tasmota devices will connect to and see what happens.
thanks again for the help!
i made the switch! the router is back to the old essid and pw, so all the other devices can connect. things seem ok at the moment. even after rebooting the router, my laptop can connect via ethernet and wifi. and i can see all the dimmers and bulbs with tasmota.
reminds me of this:
i narrowed it down to a udev rule i had to give a consistent name to a usb ethernet dongle
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="FF:FF:FF:FF:FF:FF", NAME="usb-net"
erasing that rule seems to stop the problem. i had a bridge that relied on it, but now the bridge relies on the longer name of the form enxffffffffffff.
i have a vm running home assistant, that's what the bridge is for. i am guessing i did it wrong. if anyone wants to take a stab at explaining what might be going on, that would be much appreciated.
seems to be fixed now! thanks again everyone for your support!
wait, now that i've thought about it longer, i am confused. the usb ethernet dongle misconfiguration somehow caused the router to be unable to use its own ethernet ports. is that possible? that's surprising to me, if it is.
my internet is still going up and down.
looking in luci's System log, i noticed the following which might be relevant
Thu Mar 16 23:16:20 2023 kern.warn kernel: [10816.052005] ------------[ cut here ]------------
Thu Mar 16 23:16:20 2023 kern.info kernel: [10816.056638] NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0 timed out
Thu Mar 16 23:16:20 2023 kern.warn kernel: [10816.063634] WARNING: CPU: 0 PID: 0 at 0xffffffc0106ad8f0
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.068936] Modules linked in: pppoe ppp_async nft_fib_inet nf_flow_table_ipv6 nf_flow_table_ipv4 nf_flow_table_inet pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_objref nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_counter nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack mt7915e mt7615e mt7615_common mt76_connac_lib mt76 mac80211 cfg80211 slhc nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_ipv6 nf_log_ipv4 nf_log_common nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c hwmon crc_ccitt compat seqiv leds_gpio xhci_plat_hcd gpio_button_hotplug
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.127823] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G S 5.10.161 #0
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.135294] Hardware name: Linksys E8450 (UBI) (DT)
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.140164] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--)
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.146160] pc : 0xffffffc0106ad8f0
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.149639] lr : 0xffffffc0106ad8f0
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.153117] sp : ffffffc010b2bd80
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.156423] x29: ffffffc010b2bd80 x28: 0000000000000140
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.161727] x27: 00000000ffffffff x26: 0000000000000000
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.167031] x25: 0000000000000000 x24: 0000000000000000
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.172335] x23: ffffff8000bc9480 x22: 0000000000000001
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.177639] x21: ffffffc0109f6000 x20: ffffff8000bc9000
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.182944] x19: 0000000000000000 x18: 0000000000000153
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.188249] x17: 0000000000000000 x16: 0000000000000000
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.193553] x15: ffffffc010a09998 x14: 00000000000003f9
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.198857] x13: 0000000000000153 x12: ffffffc010b2ba58
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.204162] x11: ffffffc010a61998 x10: 00000000fffff000
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.209466] x9 : ffffffc010a61998 x8 : 0000000000000000
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.214770] x7 : ffffffc010a09998 x6 : 0000000000000001
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.220075] x5 : 0000000000000000 x4 : 0000000000000000
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.225379] x3 : 0000000000000000 x2 : ffffff801feb7028
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.230682] x1 : ffffffc00f4d3000 x0 : 000000000000003f
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.235987] Call trace:
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.238426] 0xffffffc0106ad8f0
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.241557] 0xffffffc010099510
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.244687] 0xffffffc010099cc0
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.247819] 0xffffffc01009a538
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.250950] 0xffffffc010000924
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.254080] 0xffffffc01002eb58
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.257211] 0xffffffc01007daa0
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.260342] 0xffffffc0103fccbc
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.263473] 0xffffffc0100023c8
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.266604] 0xffffffc010805ae8
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.269735] 0xffffffc01005c0c4
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.272866] 0xffffffc01005c2a0
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.275997] 0xffffffc010806248
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.279129] 0xffffffc0109808d4
Thu Mar 16 23:16:20 2023 kern.debug kernel: [10816.282259] 0xffffffc010980d64
Thu Mar 16 23:16:20 2023 kern.warn kernel: [10816.285390] ---[ end trace d5368aa83f434099 ]---
What is the timescale? Looks like you have dhcp leases from your isp that are 2 hours in length.
thanks again for taking the time!
it has gone out several times today.
i'll keep more detailed logs about what happens when. i might be misremembering, or not perceiving correctly. what i recall, though, is not just wan, but also the ethernet connection from my laptop to the router goes down. it also goes down between the laptop running homeassistant and the router. also, i recall internet being inaccessible via the 2Ghz and still working via 5Ghz.
The details are really important because they inform what you might need to troubleshoot.
Just because I've been around the block a few times, I'm going to ask a question just in case this applies:
- do you have a USB-C/thunderbolt docking hub with ethernet?
i do have this usb c thunderbolt 4 dock and i am using it for ethernet on the laptop in front of me, named trent-reznor. could that cause problems for the other devices on the network, and not just this laptop, trent-reznor? also, i've been using this dock for years now.
everything is working fine now with the homeassistant laptop (named dojacat) disconnected.
i've disconnected dojacat with the usb ethernet dongle that runs homeassistant in a vm with the bridge.
it seems pretty reliable that the network goes down when i connect dojacat, and dojacat is not connected to the usb c dock.
i'll try connecting dojacat to the network and write down what time something happens and determine what state ethernet and wifi 2Ghz and 5Ghz are in on the dojacat and trent-reznor. i'll do that right after posting this, so this post will serve as the starting timestamp.
i sure hope it's the thunderbolt dock, that would mean i can do something about it! but i also don't think so.
Yes, it could. In fact, I identified a problem with a USB-C adapter in another user's post just a few days ago.
Try putting your computer to sleep or disconnecting it... does the network begin to have issues?
ok, i'll put that other plan on hold. i'll connect and disconnect the dock from trent-reznor 10 times and see if that causes an issue. trent-reznor does not go to sleep, so it's definitely not that.
i read through that other thread, and the thread it links to. that's surprising that so many docks have such issues with ethernet. i would have thought that would be more reliable.
i disconnected and reconnected the usb c thunderbolt hub from trent-reznor 10 times. kept it in each state for around 20 seconds. ran speed test several times, speeds were reasonable for up and down on wifi and ethernet. ip a currently shows wifi has ip and ethernet has ip.
i'll now switch back to connecting dojacat through usb ethernet dongle and seeing what happens.
thanks!
edit: woops, the other end of the ethernet cable for dojacat wasn't actually connected until just now, 21:27 pacific.
Let me know what happens.
Only some devices suffer from these bugs, but it is common enough that when there is an unexplained set of network interruptions, it is one of the things I suggest could be responsible.
22:39 ethernet was down for dojacat. i was gone, so not sure exactly when it happened. dojacat's wifi is off and has been off, so i could test smaller chunks.
my own regular use laptop, trent-reznor, has expected up and down speeds on ethernet, 2ghz, and 5ghz.
my phone is also connected to wifi and has reasonable up and down on 2ghz and 5ghz.
here's some logs from the router
system log (btw, what file is this on the router?)
kernel log (what file is this on the router? /var/log only has some empty files)
going to sleep. i'll try again with tomorrow. i'll do the same thing, except with wifi on on dojacat.
i decided just to redo the whole homeassistant thing in docker containers. no vm, no bridge. everything's working fine so far. i'll return to this post if it goes down again soon.
thanks @psherman, @mk24 for looking at it.
anyone having issues with usb c thunderbolt docks, have a look at this usb c thunderbolt 4 dock. it might not have been causing issues!
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.