Joined: 08 May 2018 Posts: 14244 Location: Texas, USA
Posted: Fri Jun 15, 2018 14:16 Post subject: Re: Linksys E4200v1
BrainSlayer wrote:
kernel-panic69 wrote:
Pdobrien3 wrote:
How can identify this crash you speak of? I have a bunch of this in my syslog:
#1064 (0x42a780)->0x42a080: 0 sec 0 usec 0x403499
But nothing before or after to identify the crashed module
My crash usually occurs after #1086 as shown in syslog excerpt below. Note the bold red lines that indicate the process thread that crashes and eventually restarts.
Jun 12 22:13:48 DD-WRT user.info : #1086 (0x4327e0)->0x0: 0 sec 989602 usec 0x403461
Jun 12 17:13:48 DD-WRT user.err : Caught SIGSEGV (11) in dd_timer_create
Jun 12 17:13:48 DD-WRT user.err : Fault at memory location 0x0000001c due to address not mapped to object (1).
Jun 12 17:13:48 DD-WRT user.err : Thread 1460: nas
Jun 12 17:13:48 DD-WRT user.err : === Context:
Jun 12 17:13:48 DD-WRT user.err : ZERO:00000000 AT:00000000 V0:00000000 V1:0000043f A0:00000000 A1:00000000
Jun 12 17:13:48 DD-WRT user.err : A2:0000043f A3:00000000 T0:00000000 T1:00000000 T2:7f8b5208 T3:7f8b4ffa
Jun 12 17:13:48 DD-WRT user.err : T4:00000001 T5:00000000 T6:00000000 T7:20636573 S0:778705e0 S1:00000000
Jun 12 17:13:48 DD-WRT user.err : S2:00000014 S3:00401301 S4:77920000 S5:77920000 S6:77920000 S7:00000000
Jun 12 17:13:48 DD-WRT user.err : T8:00000000 T9:778f7a60 K0:00000000 K1:00000000 GP:778705e0 SP:7f8b56f8
Jun 12 17:13:48 DD-WRT user.err : FP:00000000 RA:77842d0b
Jun 12 17:13:48 DD-WRT user.err : === Backtrace:
Jun 12 17:13:48 DD-WRT user.err : # Text at 0x77833ffd is not mapped; trying prior frame pointer.
Jun 12 17:13:49 DD-WRT user.err : # Text at 0x77833fff is not mapped; terminating backtrace.
Jun 12 17:13:49 DD-WRT user.err : /usr/lib/libutils.so[0x77834000](dd_timer_create+0x00000064)[0x77842d0d]
Jun 12 17:13:49 DD-WRT user.err : /usr/lib/libutils.so[0x77834000](dd_timer_create+0x00000062)[0x77842d0b]
Jun 12 17:13:49 DD-WRT user.err : === Code:
Jun 12 17:13:49 DD-WRT user.err : 77842cc8: f1304d18 6c069814 6538e840 ea4b6a01 e8a06476 9d42250a 9d412a03 6005720e
Jun 12 17:13:49 DD-WRT user.err : 77842ce8: 98a4f030 4d10f212 f01017ec d2069858 9a3cf389 f0302906 f21d988c ec404c11
Jun 12 17:13:49 DD-WRT user.err : 77842d08: >6a00653c f0309967 c94c980c f29d9206 65384809 da7cf389 e8406a00 920ed947
Jun 12 17:13:49 DD-WRT user.err : 77842d28: 6a00da20 650017d5 6a00dca4 dcc5e820 6a03f000 0b04f0bb 3240f400 659ae269
Jun 12 22:14:00 DD-WRT user.info : nas : NAS daemon successfully stopped
Jun 12 22:14:02 DD-WRT user.info : nas : NAS daemon hanging, send SIGKILL
Jun 12 22:14:02 DD-WRT user.info : NAS : NAS lan (wl0 interface) successfully started
Jun 12 22:14:02 DD-WRT user.info : NAS : NAS lan (wl1 interface) successfully started
Jun 12 22:14:12 DD-WRT kern.warn kernel: br0: received packet on eth2 with own address as source address
Not sure if you have to have syslogd and klogd both enabled to see it, but that is what is enabled on mine.
in the middle of your log your time changes 5 hours from 17 to 22
can you explain this?
Yes, this is the NTP bug or whatever it is or was that was going on. I have my timezone set to local, but it seems that the kernel's timezone skews things or something(?), even though the router status page shows local time. Time in syslog is still screwed up and has inconsistencies. That log excerpt is a direct copy and paste, no snippet-ing or anything. See my previous post with attachment, you will see its 22 for all user.info entries and 17 for all user.err entries. That's why I was setting it to the default time zone or UTC/Zulu before, but it still had weird inconsistencies, I think. I'd have to go through my saved logs and check.
EDIT: See attached photos. 5 hours or so askew, I didn't screenshot both of them at the exact same time, but.
Joined: 26 Mar 2013 Posts: 1858 Location: Hung Hom, Hong Kong
Posted: Fri Jun 15, 2018 16:41 Post subject: Re: Linksys E4200v1
kernel-panic69 wrote:
Yes, this is the NTP bug or whatever it is or was that was going on. I have my timezone set to local, but it seems that the kernel's timezone skews things or something(?), even though the router status page shows local time. Time in syslog is still screwed up and has inconsistencies. That log excerpt is a direct copy and paste, no snippet-ing or anything. See my previous post with attachment, you sill see its 22* for all user.info entries and 17* for all user.err entries. That's why I was setting it to the default time zone or UTC/Zulu before, but it still had weird inconsistencies, I think. I'd have to go through my saved logs and check.
Do cheap routers have a real-time clock chip that allows accurate hardware-based time-keeping? I don't think so. AFAIK, even Raspberry Pi don't have a dedicated real-time hardware clock, usually in the form of a chip.
As a result, you will have to use the CPU and a software process to run the clock, which could lead to clock skew due to heavy workload! The solution would be a periodic sync(hronization) with an external, accurate atomic clock source.
That's how I tried to explain the problem, Your Honor and Your Curiosity! _________________ Router: Asus RT-N18U (rev. A1)
Drink, Blink, Stretch! Live long and prosper! May the Force and farces be with you!
I think I have discovered a possible workaround until this is fixed permanently. Set WPA re-key interval to 99999 and reboot router daily. I am at around 20 hours of uptime with no nas crash and no wi-fi client issues.
EDIT: Currently at 1 day, 4:11 hours of uptime with no reboot. No nas crash and no wi-fi client issues. Going to ride it out and see if this stabilizes the issue, may re-test with the default WPA re-key interval and a reboot to see if it was just a no-reset flash glitch, but seems to have settled things out. I can only think that it is coincidental with WPA re-key interval, and probably client connected time. That is probably the last thing to check besides wireless media streaming.
Its too early for me to tell since I've only had 10 hours uptime but I think you may be on to something. I tried your workaround this morning and wifi has been behaving so far.
I was literally having to disconnect and reconnect wi-fi every 1-2 hours (sometimes LESS!) until I changed that particular setting. At 1 day, 6:40 and still no crash and everything is behaving.
Seriously your problem sounds similar as the problem of my Linksys EA2700 since r33607 until now. But my case does not effect any NAS (I've no NAS) but all any wifi client devices whatever phones, notebooks and smart TV. Yes I am literally having to disconnect and reconnect wi-fi from my wifi client devices every 1-2 hours (sometimes LESS!), otherwise the most TCP/UDP connections via wifi hang.
Joined: 08 May 2018 Posts: 14244 Location: Texas, USA
Posted: Fri Jun 15, 2018 17:07 Post subject:
parco wrote:
kernel-panic69 wrote:
rumbleroast wrote:
kernel-panic69 wrote:
I think I have discovered a possible workaround until this is fixed permanently. Set WPA re-key interval to 99999 and reboot router daily. I am at around 20 hours of uptime with no nas crash and no wi-fi client issues.
EDIT: Currently at 1 day, 4:11 hours of uptime with no reboot. No nas crash and no wi-fi client issues. Going to ride it out and see if this stabilizes the issue, may re-test with the default WPA re-key interval and a reboot to see if it was just a no-reset flash glitch, but seems to have settled things out. I can only think that it is coincidental with WPA re-key interval, and probably client connected time. That is probably the last thing to check besides wireless media streaming.
Its too early for me to tell since I've only had 10 hours uptime but I think you may be on to something. I tried your workaround this morning and wifi has been behaving so far.
I was literally having to disconnect and reconnect wi-fi every 1-2 hours (sometimes LESS!) until I changed that particular setting. At 1 day, 6:40 and still no crash and everything is behaving.
Seriously your problem sounds similar as the problem of my Linksys EA2700 since r33607 until now. But my case does not effect any NAS (I've no NAS) but all any wifi client devices whatever phones, notebooks and smart TV. Yes I am literally having to disconnect and reconnect wi-fi from my wifi client devices every 1-2 hours (sometimes LESS!), otherwise the most TCP/UDP connections via wifi hang.
Try changing the re-key interval to 99999 on the wireless security tab and rebooting and see if it helps, that is what I did as a workaround / test to see if that affected anything.
Joined: 08 May 2018 Posts: 14244 Location: Texas, USA
Posted: Fri Jun 15, 2018 17:12 Post subject: Re: Linksys E4200v1
mwchang wrote:
Do cheap routers have a real-time clock chip that allows accurate hardware-based time-keeping? I don't think so. AFAIK, even Raspberry Pi don't have a dedicated real-time hardware clock, usually in the form of a chip.
As a result, you will have to use the CPU and a software process to run the clock, which could lead to clock skew due to heavy workload! The solution would be a periodic sync(hronization) with an external, accurate atomic clock source.
That's how I tried to explain the problem, Your Honor and Your Curiosity!
I do sync via ntp client and it still has some kind of screwy bug that does weird things to the syslog / klog timestamps. I forgot to put something in the timeserver box on the setup page, so I changed it to the closest timeserver pool and still got this during reboot:
Code:
Jan 1 00:00:06 DD-WRT user.info : process_monitor successfully started
Jan 1 00:00:06 DD-WRT user.info : wland : WLAN daemon successfully stopped
Jan 1 00:00:06 DD-WRT user.info : wland : WLAN daemon successfully started
Jan 1 00:00:07 DD-WRT user.info : WAN is up. IP: 192.168.0.4
Jan 1 00:00:07 DD-WRT daemon.debug ntpclient[1402]: Connecting to us.pool.ntp.org [128.138.141.172] ...
Jun 15 15:32:56 DD-WRT daemon.info ntpclient[1402]: Time set from us.pool.ntp.org [128.138.141.172].
Jun 15 15:32:56 DD-WRT daemon.info process_monitor[1401]: cyclic NTP Update success (servers us.pool.ntp.org)
Jun 15 15:32:56 DD-WRT daemon.debug process_monitor[1401]: Restarting cron (time sync change)
Jun 15 15:32:56 DD-WRT user.info : cron : cron daemon successfully stopped
Jun 15 15:32:56 DD-WRT user.info : process_monitor : Process Monitor successfully stopped
Jun 15 15:32:56 DD-WRT user.info : cron : cron daemon successfully started
Jun 15 15:32:56 DD-WRT cron.info cron[1420]: (CRON) STARTUP (fork ok)
Jun 15 15:32:56 DD-WRT user.info : process_monitor successfully started
Jun 15 15:32:56 DD-WRT daemon.debug process_monitor[1421]: We need to re-update after 3600 seconds
Jun 15 15:32:56 DD-WRT daemon.info process_monitor[1421]: set timer: 3600 seconds, callback: ntp_main()
Jun 15 15:33:04 DD-WRT user.info : NAS : NAS lan (wl0 interface) successfully started
Jun 15 15:33:04 DD-WRT user.info : NAS : NAS lan (wl1 interface) successfully started
Jun 15 15:33:04 DD-WRT user.info : klogd : kernel log daemon successfully stopped
Jun 15 15:33:04 DD-WRT kern.notice kernel: klogd: exiting
Jun 15 15:33:04 DD-WRT user.info : syslogd : syslog daemon successfully stopped
Jun 15 10:33:05 DD-WRT syslog.info syslogd exiting
Jun 15 10:33:05 DD-WRT syslog.info syslogd started: BusyBox v1.28.4
Jun 15 15:33:05 DD-WRT user.info : klogd : klog daemon successfully started
Jun 15 15:33:05 DD-WRT kern.notice kernel: klogd started: BusyBox v1.28.4 (2018-06-10 15:40:00 CEST)
Jun 15 15:33:05 DD-WRT user.info : httpd : http daemon successfully stopped
Jun 15 15:33:05 DD-WRT daemon.info httpd[1317]: httpd server shutdown
Jun 15 15:33:05 DD-WRT daemon.info httpd[1445]: httpd server started at port 80
Jun 15 15:33:05 DD-WRT user.info : resetbutton : resetbutton daemon successfully stopped
Jun 15 15:33:05 DD-WRT user.info : resetbutton : resetbutton daemon successfully started
I tried to see if there was a ticket for this anomaly on svn, and found nothing. @BS, do I need to open a ticket?
EDIT: I added this to the other post in this thread, and meant to add it here, might as well. Found an old new ticket regarding timestamps here:
Status: Working
Reset: No
Errors: When I try to connect via FileZilla on port 22 I see this error:
Error: Received unexpected end-of-file from SFTP server
Error: Could not connect to server
Wrong forum.
Maybe wrong forum but very relevant
Ever since the last update to dropbear, the newer more robust SFTP protocol which FileZilla among many other programs and apps use no longer works on BS builds. <Kong> fixed it within 1 or 2 builds, not sure why BrainSlayer hasn't allowed the fix to be sinked.
I feel posts pointing this out have been ignored because it would appear most users use WinSCP
On a basic install of WinSCP the option to "fall back to SCP mode" is checked by default and the older SCP protocol still works. _________________ Location 1
R7800- DD-WRT v3.0-r53562 (10/03/23) Gateway
WNDR3400v1 DD-WRT v3.0-r35531_mega-nv64k (03/26/18 ) Access Point
WRT160Nv3 DD-WRT ?v3?.0-r35531 mini (03/26/18 ) Access Point
WRT54GSv5 DD-WRT v24-r33555_micro_generic (10/20/17) Repeater
Location 2
R7800- DD-WRT v3.0-r51855 (02/25/23) Gateway
R6300v2- DD-WRT v3.0-r50671 (10-26-22) Access Point
WNDR3700v2 DD-WRT v3.0-r35531 std (03/26/18 ) Access Point
E1200 v2 DD-WRT v3.0-r35531 mega-nv64k (03/26/18 ) Gateway(for trivial reasons)
RBWAPG-5HACT2HND-BE RouterOS-v6.46.4 (2/21/20) Outdoor Access Point
2x RBSXTG-5HPACD RouterOS-v6.46.4 (2/21/20) PTP Bridge 866.6Mbps-1GbpsLAN
Location 3
2x R7000- DD-WRT v3.0-r50671 (10/26/22) Access Points
2x RBWAPG-60AD RouterOS-v6.45.9 (04/30/20) PTP Bridge 2.3Gbps-1GbpsLAN
2x RBSXTsqG-5acD RouterOS-v6.49.7 (10/14/22) PTP Bridge 866.6Mbps-1GbpsLAN Thank You BrainSlayer for ALL that you do & have done, also to "most" everyone here that shares their knowledge
The reason there are different times shown is because until the network is up, the router has no way to know what time it is. Router SoCs probably have a clock built in, but it isn't battery backed up like on PCs so it is always Jan. 1 1970 at midnight UTC when they power up.
Not sure why you see a mix of times, there may be some processes that don't pick up the setting of TZ (timezone) or have a minimum set of time functions built in that don't include timezone support. I wouldn't worry about it, it isn't indicative of a bug.
Joined: 08 May 2018 Posts: 14244 Location: Texas, USA
Posted: Sat Jun 16, 2018 2:22 Post subject:
slice1900 wrote:
The reason there are different times shown is because until the network is up, the router has no way to know what time it is. Router SoCs probably have a clock built in, but it isn't battery backed up like on PCs so it is always Jan. 1 1970 at midnight UTC when they power up.
Not sure why you see a mix of times, there may be some processes that don't pick up the setting of TZ (timezone) or have a minimum set of time functions built in that don't include timezone support. I wouldn't worry about it, it isn't indicative of a bug.
Then why would BS ask me why there's a 5-hour skew in timestamps after sync-up to ntp server? I'd have to backtrack to initial flash to present, and I do mean literally, to see if this is nothing new or to see which build the skew started at. Some processes may read the TZ file, while others not, perhaps. That is a good point and observation. I have seen where it was an incorrect shared libc issue, i.e. libc.so.5 vs libc.so.6, but not entirely sure on this one.
Joined: 18 Mar 2014 Posts: 12915 Location: Netherlands
Posted: Sat Jun 16, 2018 7:12 Post subject:
parco wrote:
kernel-panic69 wrote:
rumbleroast wrote:
kernel-panic69 wrote:
I think I have discovered a possible workaround until this is fixed permanently. Set WPA re-key interval to 99999 and reboot router daily. I am at around 20 hours of uptime with no nas crash and no wi-fi client issues.
EDIT: Currently at 1 day, 4:11 hours of uptime with no reboot. No nas crash and no wi-fi client issues. Going to ride it out and see if this stabilizes the issue, may re-test with the default WPA re-key interval and a reboot to see if it was just a no-reset flash glitch, but seems to have settled things out. I can only think that it is coincidental with WPA re-key interval, and probably client connected time. That is probably the last thing to check besides wireless media streaming.
Its too early for me to tell since I've only had 10 hours uptime but I think you may be on to something. I tried your workaround this morning and wifi has been behaving so far.
I was literally having to disconnect and reconnect wi-fi every 1-2 hours (sometimes LESS!) until I changed that particular setting. At 1 day, 6:40 and still no crash and everything is behaving.
Seriously your problem sounds similar as the problem of my Linksys EA2700 since r33607 until now. But my case does not effect any NAS (I've no NAS) but all any wifi client devices whatever phones, notebooks and smart TV. Yes I am literally having to disconnect and reconnect wi-fi from my wifi client devices every 1-2 hours (sometimes LESS!), otherwise the most TCP/UDP connections via wifi hang.
Status: Working
Reset: No
Errors: When I try to connect via FileZilla on port 22 I see this error:
Error: Received unexpected end-of-file from SFTP server
Error: Could not connect to server
Wrong forum.
Maybe wrong forum but very relevant
Ever since the last update to dropbear, the newer more robust SFTP protocol which FileZilla among many other programs and apps use no longer works on BS builds. <Kong> fixed it within 1 or 2 builds, not sure why BrainSlayer hasn't allowed the fix to be sinked.
I feel posts pointing this out have been ignored because it would appear most users use WinSCP
On a basic install of WinSCP the option to "fall back to SCP mode" is checked by default and the older SCP protocol still works.
Thank you very much for your support. At least I didn't know WinSCP supports older SCP protocol. Thanks for info. I hope BrainSlayer can fixed that. I do not have chance to use Kong Builds because I have WRT1900AC. _________________ Kaan's World | @mkaand | PLEX Archive | Trakt.tv
Joined: 08 May 2018 Posts: 14244 Location: Texas, USA
Posted: Sat Jun 16, 2018 14:31 Post subject:
egc wrote:
For broadcom routers NAS is the process which handles your wifi, it has nothing to do with Network Attached Storage
I guess I need to specify (wireless) network authentication service (nas) in future discussions, so it is not confused with NAS (network attached storage)...
EDIT: Looking at the syslog from my last reboot, I'm wondering if the ntp update timer and the nas re-key timer have been clashing, causing a problem
Joined: 26 Mar 2013 Posts: 1858 Location: Hung Hom, Hong Kong
Posted: Mon Jun 18, 2018 12:17 Post subject:
kernel-panic69 wrote:
I guess I need to specify (wireless) network authentication service (nas) in future discussions, so it is not confused with NAS (network attached storage)...
EDIT: Looking at the syslog from my last reboot, I'm wondering if the ntp update timer and the nas re-key timer have been clashing, causing a problem
Did you try disabling all NAS functions?
Would that reduce the clock skew to less than 5 hours? _________________ Router: Asus RT-N18U (rev. A1)
Drink, Blink, Stretch! Live long and prosper! May the Force and farces be with you!
Posted: Mon Jun 18, 2018 15:48 Post subject: Re: Linksys E4200v1
mwchang wrote:
kernel-panic69 wrote:
I think I have discovered a possible workaround until this is fixed permanently. Set WPA re-key interval to 99999 and reboot router daily. I am at around 20 hours of uptime with no nas crash and no wi-fi client issues.
Interesting observation if not discovery here... Thank you, Your Curiosity!
I have this set to 0 and my WiFi clients have stopped disconnecting.
Joined: 06 Jun 2006 Posts: 7492 Location: Dresden, Germany
Posted: Tue Jun 19, 2018 19:13 Post subject:
mwchang wrote:
kernel-panic69 wrote:
I guess I need to specify (wireless) network authentication service (nas) in future discussions, so it is not confused with NAS (network attached storage)...
EDIT: Looking at the syslog from my last reboot, I'm wondering if the ntp update timer and the nas re-key timer have been clashing, causing a problem
Did you try disabling all NAS functions?
Would that reduce the clock skew to less than 5 hours?
consider that the nas daemon has nothing todo with storage here. its the broadcom wpa authentication daemon _________________ "So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
Joined: 08 May 2018 Posts: 14244 Location: Texas, USA
Posted: Wed Jun 20, 2018 1:54 Post subject:
Grolll123 wrote:
mwchang wrote:
kernel-panic69 wrote:
I think I have discovered a possible workaround until this is fixed permanently. Set WPA re-key interval to 99999 and reboot router daily. I am at around 20 hours of uptime with no nas crash and no wi-fi client issues.
Interesting observation if not discovery here... Thank you, Your Curiosity!
I have this set to 0 and my WiFi clients have stopped disconnecting.
WebGUI minimum setting is 1, but this is quite interesting. I may try that if I continue to have issues in r36154 until the next build is posted.
BrainSlayer wrote:
mwchang wrote:
kernel-panic69 wrote:
I guess I need to specify (wireless) network authentication service (nas) in future discussions, so it is not confused with NAS (network attached storage)...
EDIT: Looking at the syslog from my last reboot, I'm wondering if the ntp update timer and the nas re-key timer have been clashing, causing a problem
Did you try disabling all NAS functions?
Would that reduce the clock skew to less than 5 hours?
consider that the nas daemon has nothing todo with storage here. its the broadcom wpa authentication daemon
Exactly what I was saying, but apparently there was still some confusion Thanks again for all your hard work, BS!
Thanks again for all your hard work, BS!