Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
4.7.1.0.8771
#1
I am pleased to release Version 4.7.1.0.8771.


download at https://cp.sync.com/dl/1a27395a0#cs8v5p4...w-eq2xqe5s


Please test this on an easy to access system and make sure it is stable for your situation. The firmware has been tested for general function on an indoor environment. Your outdoor and long term use "might" not be the same. I have NOT had any issues with upgrading and absolutely NO BRICKS have been created. I will say this is a safe release and your long term use will determine its reliability.


PLEASE post any reports, good or bad of your testing and use. Your feedback is important and helps me to make repairs.


Main Features of the 4.7.1.0.8771 Release


- Licensed Frequency support.
- Bridging support.
- Hidden ESSID.
- Full Duplex.
- Basic SYNC support.
- added support for the War1A systems
- make sure you do NOT use u-APSD on the clients
- some tweaks to Auto Noise Immunity (ANI). Seems to not cause any issues
- further code audit for data locks. revert some patches that inadvertantly disabled the reset mechanism


The following versions have been tested


- Gateworks Ventana
- PC Engines APU
- War1B
- Gateworks Laguna
- Gateworks Avila
- SIAM-C0113208R1 or War1A
Reply
#2
I've applied this .8771 build to one of our WAR1B Access Points and to all it's WAR1B and WAR1A-SIAM Clients (both 'N' and 'BG' clients) and no-bricks. Everything came back online and associated as expected.
Reply
#3
Thanks ninedd. Hope it helps.

Note: I know it is not yet perfect but it should be better.
Reply
#4
It ran for 2 hours 12 minutes before it went fubar.

The ping watchdog (which is pinging one of the clients) is set to ping every 60 seconds on successful and every 20 seconds on unsuccessful, and to reboot after 6 pings. That should equal 2-3 minutes of non-communication before it reboots. The reset mechanism didn't reset in that time and the ping watchdog rebooted the AP.


.jpg   4.7.1.0-8771_Feb03_17_Fubar.jpg (Size: 61.87 KB / Downloads: 37)
Reply
#5
What is the Reset Mechanism watching for? What mechanism does it use to try to detect a fubar?
Reply
#6
The reset is watching for errors in the Atheros chipset. When certain errors are determined the chip, in fact the TCP stack for that radio is taken down and rebuilt. In short an activate is performed.
Reply
#7
ninedd, and anyone else who can test this : Please set your bps / kBps to show in Bits/s in System/ configure bps. I am very interested in the actual rate when the AP goes away. kBps loses some info through scaling and I would like to know if the rate is 0.0 or some other small number.
Reply
#8
OK. I've set a few WAR1B AP's to kbit instead of our normal kBytes.
I expect it'll be 0.0 since no clients are 'pingable' and since all clients will be 'deauthed due to inactivity'. But we'll see if I can catch it doing it's furbar thing before it reboots.
Reply
#9
Thank you. I need to know if the rate control goes to real zero or just very low.

ninedd Wrote:OK. I've set a few WAR1B AP's to kbit instead of our normal kBytes.
Reply
#10
ninedd Wrote:OK. I've set a few WAR1B AP's to kbit instead of our normal kBytes.
I expect it'll be 0.0 since no clients are 'pingable' and since all clients will be 'deauthed due to inactivity'. But we'll see if I can catch it doing it's furbar thing before it reboots.
It took 22 minutes, there is no traffic flowing wirelessly, the clients aren't pingable (the ping window is pinging a -56 DualPol client at 10.10.3.156) and the traffic in and out is 0.0 bps.


.jpg   Feb_04_17_812PM_4.7.1.0-8771.jpg (Size: 53.31 KB / Downloads: 36)

In 2-3 minutes, the Ping Watchdog (which is also pinging 10.10.3.156) would have rebooted the AP. The Fubar Detection Mechanism didn't detect or reset/activate the system.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)