Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
4.8.8878
#1
I am pleased to add the following releases, Version 4.8.8878. for the WAR-1B. Others will follow in the coming week.

It is available for download at https://cp.sync.com/dl/4bd9ff300#5imn6u3...r-rfcrd8vi

Please test on an easy to access system and make sure it is stable for your situation. The firmware has been stress tested for general function and throughput in 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.8.8878 Release
- FULL Licensed Frequency support.
- FULL Bridging support.
- FULL Hidden ESSID.
- NO Full Duplex.
- NO Basic SYNC support.
- never show lowest rate. Will indicate the last good packet rate

- make sure you do NOT use u-APSD on the clients

- This is our ALL NEW driver and I need to have the core functionality tested for reliability, mainly to see if the AP stall issue is gone. PLEASE give this a test in a spot that has problems.

The following versions have been added and tested

- WAR-1B
Reply
#2
lonnie Wrote:- never show lowest rate. Will indicate the last good packet rate

I'm still seeing 1 Mbit rates on any connection that goes over 30 seconds idle time. The 4.8 line is the only version to do that.

This .AVI shows what I'm seeing... if I ping everything to pass some data, all the connections go to their negotiated rate. If I let them all be idle, anything that has a real idle time of 30+ seconds will 'snap' right at that 30 second mark to show 1 Mbit RX rates. (I play these .avi's with Windows Media Player... I think QuickTime is able to play them too)

[video]http://toddchamberlain.com/staros/C42800481521.avi[/video]
Reply
#3
I'll double check that. I run OLSR so there is never really any idle time. I'll have to disable it and see what happens.

ninedd Wrote:I'm still seeing 1 Mbit rates on any connection that goes over 30 seconds idle time. The 4.8 line is the only version to do that.

This .AVI shows what I'm seeing... if I ping everything to pass some data, all the connections go to their negotiated rate. If I let them all be idle, anything that has a real idle time of 30+ seconds will 'snap' right at that 30 second mark to show 1 Mbit RX rates. (I play these .avi's with Windows Media Player... I think QuickTime is able to play them too)

[video]http://toddchamberlain.com/staros/C42800481521.avi[/video]
Reply
#4
Have you any report on the stall issue?
Reply
#5
lonnie Wrote:Have you any report on the stall issue?
When an AP is freshly rebooted, they can run for a couple days sometimes without issues. When they do have an issue - if we do an 'activate' it generally smartens it up, but typically for a shorter amount of time (ie, the problem will re-surface in a couple/few hours, instead of a couple/few days like a reboot generally does). That's why I've always been suspect if this has anything to do with the actual driver or not... it's so inconsistent. Sometimes nothing for 3 or 5 days, and then 3-5 times PER day at other times.

In any event - to answer your question, I haven't seen an AP go to 0 clients since we've run 4.8 - but we haven't run anything longer than a couple days either. Our AP #49, has rebooted a few times, likely due to the ping watchdog. On the weekend, I did see it unable to communicate with the client I was pinging from my laptop - which is a WAR1B 'TestInShed' CPE that's right at the tower. Again - I don't know what that was - but it's a WAR1B CPE with a -63 signal and it's right in the shed at the tower and we simply use it for pinging and testing - so no real amount of data going across it, just a test CPE that we can get at from both the Wireless side and from the Ethernet side as well. So, this weekend I was pinging 10.49.3.25 from my laptop (which is pinging the wireless side of that TestInShed CPE through the APs wireless) and it missed... 20 or 30 pings in a row and then came back. The CPE hadn't rebooted and I noticed it just as it started re-pinging, so I don't know if it was just that CPE, or if everything wasn't communicating.

In any even - to answer your question - I haven't seen a 0 Clients on 4.8 as of yet.
Reply
#6
lonnie Wrote:I'll double check that. I run OLSR so there is never really any idle time. I'll have to disable it and see what happens.
On the AP, we run a static route on the Ethernet side (backhaul on the Ethernet is always going to the same wired ethernet destination) and then on the AP-Wireless interface, it has a static IP and it DHCP's IP's to it's CPE's via ISC-DHCP with Static Mac assignments. The CPE's then have their DHCP Clients fetching those numbers, which gives them their Static IP, and their Default Route and Gateway - which is back to the AP's wcpi card.
Reply
#7
lonnie Wrote:I run OLSR so there is never really any idle time. I'll have to disable it and see what happens.
So, you run OLSR between the Wireless interface on the AP and the wireless interface on the CPE? Do those CPE's get their numbers via ISC DHCP from the AP and wouldn't that give them Gateway at the same time?
Reply
#8
ISCHCP provides static IP based on mac. I realize OLSR is not required, but using it does make the other IP addresses on it accessible to the rest of the system.

If you want to run OLSR make CERTAIN you do not have any duplicate subnets. If you leave the typical 192.168.2.x on the second ethernet then you will have a problem. A BIG problem since all units with that subnet calculate that the easiest way is through their own 192.168.2.x IP and it certainly is not connected to anything.
Reply
#9
I do not see the Tx drop. It remains at the higher rate. The Rx does drop, so I will hunt for the rx reporting and make it do the same as the Tx.

UPDATE: There is no corresponding rx rate with a simple index, so it will be way more complex to not show the current rx rate but keep the last higher rate. This happens in the rx interrupt so I want to keep processing to a minimum. Doing a rate table lookup and compare is quite expensive in terms of cpu cycles and is to be avoided in an interrupt. Sorry, but the Rx rate is what it is.

ninedd Wrote:I'm still seeing 1 Mbit rates on any connection that goes over 30 seconds idle time. The 4.8 line is the only version to do that.

This .AVI shows what I'm seeing... if I ping everything to pass some data, all the connections go to their negotiated rate. If I let them all be idle, anything that has a real idle time of 30+ seconds will 'snap' right at that 30 second mark to show 1 Mbit RX rates. (I play these .avi's with Windows Media Player... I think QuickTime is able to play them too)

[video]http://toddchamberlain.com/staros/C42800481521.avi[/video]
Reply
#10
This 4.8 is the only version to ever do this.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)