Please have someone else confirm but I had to remove crash files from:
/sys/fs/pstore
After doing so and rebooting router starts normally.
1 Like
You can also turn off the router and turn it back on again to remove the pstore contents stored in RAM. As long as the /sys/fs/pstore contents are removed, the router will return to normal operations.
1 Like
You want static IP on your computer set to say 192.168.1.35 and subnet mask 255.255.255.0. If you still cannot access router then you could try powering off then holding down reset button and keeping it held down then powering on and keep holding reset down - you should see orange light - then you can let reset button go and once router booted you should be able to access router then. At that point I'm not sure if you can flash to different firmware - someone else can hopefully advise.
1 Like
As @mightymos and @quarky mentioned, you can either clear the content of /sys/fs/pstore/ and reboot the router from cli or do a power cycle of the router which would fix the issue. You are on the list of users who are waiting for a fix for this issue.
1 Like
Ty. Iād forgotten that Iād seen that elsewhere. Just been busy and distracted.
Now I just need to figure out why my other RT3200 is throwing errors to the logread when I upgraded via auc:
daemon.notice hostapd: handle_probe_req: send failed
:
followed by
:
daemon.notice hostapd: ACS: Survey is missing noise floor
The simple (but unsatisfying) solution is to delete my configs and start fresh.
Okay, I can try this, thank you.
I'm no expert but looking at what you posted it looks like the interface enp39s0 is down it should be up
sudo ip link set enp39s0 up
okay, I held the reset for 30 seconds, this is the result.
Edit: I just realized I was pinging myself. I am very stupid, sorry. I can't ping 192.168.1.1.
Something is not right here, when you ping private ip 192.168.1.1 why are you seeing destination not reachable response from a public ip?
I don't understand.
You should see that response from the interface ip you have assigned to the ensp390s interface (192.168.1.100). Can you try to ping using the interface ensp39s0 or the ip assigned to that interface as the source?
I think the arp table on the Linux machine still thinks the pc is connected directly to a modem (assuming pc is being switched between direct connection and router to allow posting online with non-working router). How to clear arp table on Linux (simplest but inconvenient way is to simply reboot while connected to router instead)? Does this also imply modem is in passthrough mode?
arp -d should delete the arp entry for that IP. But I don't think it's something related to arp. Let him do a ping using the interface ip as the source and see how it comes. If it's a debian or ubuntu the command should be something like this:
ping -I ensp39s0 192.168.1.100
Thank you to the god gamer lynx, my router is working fine now.
2 Likes
That is because the ip addr add command was incorrect. By default it adds only a single IP, it doesn't set up a route to a subnet. You need to specify the size of the network using CIDR notation like this:
sudo ip addr add 192.168.1.100/24 dev enp39s0
This configures your PC that IP addresses from 192.168.1.1 to 192.168.1.254 should be reached via enp39s0, and its IP in that network is 192.168.1.100. If you just do an ip addr add without the slash and subnet size, you get a single IP on the adapter with a network size of /32-- there is only one IP in the network. Thus you could ping yourself at 192.168.1.100, but nowhere else.
Wi-Fi works great with my Googel Pixel 3a running GrapheneOS, but for some reason it takes a really long time to connect on my PC running openSUSE Tumbleweed. I've never had this issue in the past, any ideas?
video of this happening, conections takes about five minutes.
What is the significance of this on mesh peer connect:
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.548775] ------------[ cut here ]------------
Thu Sep 30 10:03:58 2021 kern.warn kernel: [ 21.553407] WARNING: CPU: 1 PID: 1196 at __skb_flow_dissect+0x1a0/0x13cc
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.560099] Modules linked in: xt_connlimit pppoe ppp_async nf_conncount iptable_nat xt_state xt_nat xt_helper xt_conntrack xt_connmark xt_connbytes xt_REDIRECT xt_MASQUERADE xt_FLOWOFFLOAD xt_CT wireguard pppox ppp_generic nf_nat nf_flow_table nf_conntrack mt7915e mt7615e mt7615_common mt76_connac_lib mt76 mac80211 libchacha20poly1305 libblake2s ipt_REJECT chacha_neon cfg80211 xt_time xt_tcpudp xt_tcpmss xt_statistic xt_recent xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_ecn xt_dscp xt_comment xt_TCPMSS xt_LOG xt_HL xt_DSCP xt_CLASSIFY slhc sch_cake poly1305_neon nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 libcurve25519_generic libchacha libblake2s_generic iptable_raw iptable_mangle iptable_filter ipt_ECN ip_tables hwmon crc_ccitt compat fuse sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_tcindex cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit act_mirred act_gact nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.560280] x_tables nf_reject_ipv6 ifb ip6_udp_tunnel udp_tunnel veth vfat fat autofs4 nls_utf8 nls_iso8859_1 nls_cp437 seqiv uas usb_storage leds_gpio xhci_plat_hcd gpio_button_hotplug
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.664497] CPU: 1 PID: 1196 Comm: napi/phy1-7 Tainted: G S 5.10.64 #0
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.672317] Hardware name: Linksys E8450 (UBI) (DT)
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.677186] pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--)
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.683188] pc : __skb_flow_dissect+0x1a0/0x13cc
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.687796] lr : __skb_get_hash+0x6c/0x130
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.691883] sp : ffffffc010db3990
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.695190] x29: ffffffc010db3990 x28: ffffff8001bf1280
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.700496] x27: 0000000000000000 x26: 0000000000000008
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.705801] x25: 0000000000000000 x24: ffffff800365d418
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.711105] x23: 000000000000004a x22: ffffffc010db3b00
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.716409] x21: 000000000000ffba x20: ffffffc010a89580
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.721713] x19: ffffff80037aa300 x18: 00069452b66d9eec
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.727018] x17: 0000000000000015 x16: ffffffc0107e83e0
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.732324] x15: 0000000000000001 x14: 0000000000000070
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.737628] x13: 0000000000000080 x12: ffffffc010867488
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.742932] x11: 0000000000000001 x10: 0000000000000001
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.748237] x9 : 0000000000000021 x8 : ffffff8000bdc200
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.753541] x7 : 0000000000000000 x6 : 0000000000000000
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.758845] x5 : 0000000000000000 x4 : 0000000000000000
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.764149] x3 : ffffffc010db3b00 x2 : 0000000000000000
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.769453] x1 : 0000000000000000 x0 : 0000000000000000
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.774757] Call trace:
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.777199] __skb_flow_dissect+0x1a0/0x13cc
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.781460] __skb_get_hash+0x6c/0x130
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.785232] ieee80211_schedule_txq+0x784/0x9cc [mac80211]
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.790731] ieee80211_schedule_txq+0x964/0x9cc [mac80211]
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.796229] ieee80211_tx_pending+0xe0/0x240 [mac80211]
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.801452] tasklet_action_common.constprop.0+0x164/0x17c
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.806929] tasklet_action+0x24/0x30
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.810583] _stext+0x124/0x28c
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.813716] do_softirq+0x74/0x80
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.817021] __local_bh_enable_ip+0x88/0x90
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.821197] napi_threaded_poll+0x94/0xf0
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.825200] kthread+0x120/0x124
Thu Sep 30 10:03:58 2021 kern.debug kernel: [ 21.828419] ret_from_fork+0x10/0x18
Thu Sep 30 10:03:58 2021 kern.warn kernel: [ 21.831985] ---[ end trace df02c2995fdd6ba6 ]---
Do others that use mesh 802.11s see this too in logread upon mesh peer connect? Sometimes one of my RT3200's will not connect to the mesh pending reboot. I wonder if this might be the reason.
Thanks for the suggestion but didn't seem to have any effect for me.
Still convinced its a multicast vs unicast issue.
See there are some new settings around the multicast querier. From reading sounds like it should all work without enabling them but will try playing around with them just in case.
Any other suggestions?
I configured two of my boxes as 802.11s, I am yet to see significant issues.....will report back if I see any.