Those do not seem overtly high.
241 divided by 114237 = % of dropped packets.
89 divided by 552733 = % of dropped packets.
That said, if you can lower the 5ghz packet drops you would be in better shape.
Obviously the lower the drops, the better.
Also, before you ask why the packets are bad the answer is it depends on the wireless environment in your living area.
Only you can figure that out.
You can try alternate channels or adjusting the TX power levels but wifi is very subjective to a given environment & what is active in it.
gil80 wrote:
slidermike wrote:
gil,
the best way to know if you have an issue related to errors is to see if your clients are slow or disconnecting.
If not, then no your error count is not impacting the wifi traffic in any measurable way.
Also your question if X errors is in a normal range for a time frame is irrelevant.
Errors as a percent of packets sent is a better gauge of having too many or too few but again, if your clients seem fine then all is well.
If your losing 5%+ packets (errors) then I would expect an unhappy network.
1% is probably not noticed.
gil80 wrote:
Getting Tx errors. Is that amount within normal range for this up time?
Anyone got serial output or syslog output from the rebooting unit? I added additional debug info to the build.
I haven't cracked open my R8500 yet to put a serial cable on it, but would syslog persist across boots in a way that would be helpful to you? If so, I can happily enable and test that.
Anyone got serial output or syslog output from the rebooting unit? I added additional debug info to the build.
I haven't cracked open my R8500 yet to put a serial cable on it, but would syslog persist across boots in a way that would be helpful to you? If so, I can happily enable and test that.
Sometimes the crash is printed to syslog, of course this only helps if syslog is sent to a syslog server, e.g. another linux box or a windows pc with a syslog server app running. _________________ KONG PB's: http://www.desipro.de/ddwrt/
KONG Info: http://tips.desipro.de/
Joined: 21 Nov 2010 Posts: 278 Location: North America
Posted: Mon Apr 25, 2016 5:22 Post subject:
<Kong> wrote:
Anyone got serial output or syslog output from the rebooting unit? I added additional debug info to the build.
Yes. I have a serial PuTTY log showing an R8500 softbricked into a boot loop after flashing Kong build 29440M Take 3 compiled 4-18-2016. All the firmwares from build 29300M Take 6 up to the current build 29440M Take 4 compiled 4-24-2016 will softbrick the router if any of the 5GHz radios are configured as a Repeater, Repeater Bridge , or Client Bridge and the router is power cycled. ( Client and Adhoc modes were not tested.) To recover power off the router, press and hold the reset button, power up the router and then release the button after 15 seconds. This resets the firmware to defaults which sets all the radios to AP mode and the router will boot up normally. To avoid the bricking problem, I returned to Kong build 29300M Take 5 compiled 4-13-2016.
The serial log doesn't show anything useful in my opinion. In this example, wl0 (eth1) is configured as a Repeater:
Anyone got serial output or syslog output from the rebooting unit? I added additional debug info to the build.
Yes. I have a serial PuTTY log showing an R8500 softbricked into a boot loop after flashing Kong build 29440M Take 3 compiled 4-18-2016. All the firmwares from build 29300M Take 6 up to the current build 29440M Take 4 compiled 4-24-2016 will softbrick the router if any of the 5GHz radios are configured as a Repeater, Repeater Bridge , or Client Bridge and the router is power cycled. ( Client and Adhoc modes were not tested.) To recover power off the router, press and hold the reset button, power up the router and then release the button after 15 seconds. This resets the firmware to defaults which sets all the radios to AP mode and the router will boot up normally. To avoid the bricking problem, I returned to Kong build 29300M Take 5 compiled 4-13-2016.
The serial log doesn't show anything useful in my opinion. In this example, wl0 (eth1) is configured as a Repeater:
- Magnetron1.1
No, it shows exactly the problem. Sending SIGTERM, it boots because it is told to do so:
Quote:
Sending SIGTERM to all processes
Received SIGTERM
unmounting /
unmounting /
Sending SIGKILL to all processes
unmounting /
unmounting /
br0: port 4(eth3) entered disabled state
device eth3 left promiscuous mode
br0: port 4(eth3) entered disabled state
br0: port 3(eth2) entered disabled state
device eth2 left promiscuous mode
br0: port 3(eth2) entered disabled state
Restarting system. <<=== First reboot. Cause unknown. Eth1 (Wl0) is configured as a Repeater.
Btw. Repeater Mode is still not working in the current driver release for th R8XXX and there is still a workaround in the the wireless config tool to avoid a boot loop, that crashes the unit right at startup. Thus crash in Repeater would be considered xpected right now. Anyone with a crash reboot in AP mode? _________________ KONG PB's: http://www.desipro.de/ddwrt/
KONG Info: http://tips.desipro.de/
...
Btw. Repeater Mode is still not working in the current driver release for th R8XXX and there is still a workaround in the the wireless config tool to avoid a boot loop, that crashes the unit right at startup. Thus crash in Repeater would be considered xpected right now. Anyone with a crash reboot in AP mode?
No crashes here. AP mode only.
Router: R8000
Firmware: DD-WRT v3.0-r29440M kongac (04/24/16)
Kernel: Linux 3.10.101 #8 SMP Wed Apr 20 21:12:56 CEST 2016 armv7l
Status: OK
Reset: NO. Dirt - WebUI
Errors: None so far.
Well, the aforementioned issue I had with 29440M where it simply stopped passing IP traffic (but all the lights looked normal) happened again. This time, though, it happened with the build I rolled back to: 29200M. It took 3.5 days, but it happened exactly the same. Simply power-cycling the router solved this.
This was a very fresh install, manually re-entered all of my settings in the webif. That included QoS, Port Mappings, DHCP reservations, moved the radios to WPA2-Personal. Otherwise pretty stock setup.
I'll set up a syslog server here later today and then move to 29440M to catch the next time this happens.
Well, the aforementioned issue I had with 29440M where it simply stopped passing IP traffic (but all the lights looked normal) happened again. This time, though, it happened with the build I rolled back to: 29200M. It took 3.5 days, but it happened exactly the same. Simply power-cycling the router solved this.
This was a very fresh install, manually re-entered all of my settings in the webif. That included QoS, Port Mappings, DHCP reservations, moved the radios to WPA2-Personal. Otherwise pretty stock setup.
I'll set up a syslog server here later today and then move to 29440M to catch the next time this happens.
