GeckoV4 4.0.5 build 5542 released (public beta)

[tony]

There is a new GeckoV4 release available for download.

Changes since 4.0.5
*) Atheros 11n now support AMSDU-TX (in addition to AMSDU-RX) for higher performance (enabled automatically). - see notes below
*) Sync option now applies the AP's local distance option live and is not propagated to clients.
*) Fixed a scan & connect issue with HT5 / HT10, where a client would sometimes fail to connect to an AP using a frequency > 5700 Mhz.
*) Many Atheros improvements to assist in performance.

** MIPS-COMPEX support is not available in this release, but will be in a future update.

AMSDU Notes:
This feature Aggregates MAC Service Data Units (AMSDU) to increase TX performance on your link. Since this is a service unit aggregation, small packets (100 bytes or less) of the same QoS class will be aggregated to increase performance. This increase is quite noticeable with TCP (via aggregating return ACKs) and UDP (VoIP) traffic.

The AMSDU feature is prone to failure with high error rates on weak links, however we have countered this with a robust transmit and retry scheduler that should keep things balanced. Because of this new scheduler, you may notice a slight increase in system load which is nothing to be alarmed about.

This feature is not tunable at this time, and is enabled by default when AMPDU Aggregation is selected.

Licensed Frequency support (LF country code) is almost complete, and should be available in a release soon.

Please post your results in this thread.

[pachitoone]

Licensed Frequency support (LF country code) is almost complete, and should be available in a release soon.

Please post your results in this thread.

I'm waiting for this to make a test. Thanks.

[Stratolinks]

Tried this on a site...

Was running 1.5.17, Single Board Computer with P4m@2GHz, 2Gig RAM, 2 Intel Pro 1000 Ethernet ports, 2 R52NM Mini PCI cards. (system has been up for several months on 1.5.17).

Installed 4.0.5, when unit rebooted it showed that everything was OK since each radio showed the 1 association for the remote end of each P2P link that was there previously. One remote is another SBC with x86 1.5.17 with an R52Nm card, the other is a metro with an WLM54AGP23 card running 1.4.27.1 and has another radio for an AP for clients). Problem was the remote end of each was not actually reachable. I connected around to the remote end of one of the links via a back door link on one of the units behind it. I tried an activate changes on the remote end, it reconnects, but still won't pass traffic. I sent 1.5.17 to the initial system and rebooted. Everything looked normal again, although I had to do an 'activate and save' to get the remote end to drop and reconnect before it would pass traffic (although I have seen this frequently in 1.5.17 when the AP end drops the connection for a short time, the client won't pass data after the AP comes back up).

Couldn't try this for long when I did since there are about 200 clients behind one of the links on that system.

Have not tried this version yet where it would be a client to an older system.

[go.fast]

I put 4.0.5 on a new laguana board today and created 3 new sectors.
I moved 2 clients over as PtP links and held off on the 3rd client PtP link till I test it a bit.
One link is my link and I have about 100 subs coming off me.

I'm getting almost 60megs both ways.

The other link I was not able to get to the ethernet to do my testing.
I will do that pretty soon.

[tony]

If you are able to provide us a login before, and after the upgrade to 4.0.5, it would help tremendously.

Thanks again

Tried this on a site...

Was running 1.5.17, Single Board Computer with P4m@2GHz, 2Gig RAM, 2 Intel Pro 1000 Ethernet ports, 2 R52NM Mini PCI cards. (system has been up for several months on 1.5.17).

Installed 4.0.5, when unit rebooted it showed that everything was OK since each radio showed the 1 association for the remote end of each P2P link that was there previously. One remote is another SBC with x86 1.5.17 with an R52Nm card, the other is a metro with an WLM54AGP23 card running 1.4.27.1 and has another radio for an AP for clients). Problem was the remote end of each was not actually reachable. I connected around to the remote end of one of the links via a back door link on one of the units behind it. I tried an activate changes on the remote end, it reconnects, but still won't pass traffic. I sent 1.5.17 to the initial system and rebooted. Everything looked normal again, although I had to do an 'activate and save' to get the remote end to drop and reconnect before it would pass traffic (although I have seen this frequently in 1.5.17 when the AP end drops the connection for a short time, the client won't pass data after the AP comes back up).

Couldn't try this for long when I did since there are about 200 clients behind one of the links on that system.

Have not tried this version yet where it would be a client to an older system.

[tony]

Not too bad. Thank you for the update.

I put 4.0.5 on a new laguana board today and created 3 new sectors.
I moved 2 clients over as PtP links and held off on the 3rd client PtP link till I test it a bit.
One link is my link and I have about 100 subs coming off me.

I'm getting almost 60megs both ways.

The other link I was not able to get to the ethernet to do my testing.
I will do that pretty soon.

[lonnie]

I would advise you to test this out on a small sector where you can have the new 4.0.5 running on everything. Run it and hopefully get comfortable with it so you can feel safe in putting it everywhere. The 4.x series is the way forward and we'll make sure it works to other 4.x latest firmwares. Mixed firmware is not good as it we have no hope of fixing any issues when the one end is end of life.

When I do an upgrade of a sector I push the firmware from my desktop using starutil and then login to all units with putty and apply the upgrade one by one. I have all the putty session open and can watch the progress. They should all reboot and come up and work. We are interested in any issues and will do our best to make quick fixes for anything that is seriously limiting the use.

Tried this on a site...

Was running 1.5.17, Single Board Computer with P4m@2GHz, 2Gig RAM, 2 Intel Pro 1000 Ethernet ports, 2 R52NM Mini PCI cards. (system has been up for several months on 1.5.17).

Installed 4.0.5, when unit rebooted it showed that everything was OK since each radio showed the 1 association for the remote end of each P2P link that was there previously. One remote is another SBC with x86 1.5.17 with an R52Nm card, the other is a metro with an WLM54AGP23 card running 1.4.27.1 and has another radio for an AP for clients). Problem was the remote end of each was not actually reachable. I connected around to the remote end of one of the links via a back door link on one of the units behind it. I tried an activate changes on the remote end, it reconnects, but still won't pass traffic. I sent 1.5.17 to the initial system and rebooted. Everything looked normal again, although I had to do an 'activate and save' to get the remote end to drop and reconnect before it would pass traffic (although I have seen this frequently in 1.5.17 when the AP end drops the connection for a short time, the client won't pass data after the AP comes back up).

Couldn't try this for long when I did since there are about 200 clients behind one of the links on that system.

Have not tried this version yet where it would be a client to an older system.

[Stratolinks]

One thing I forgot to mention on the X86 system I posted earlier was that every time I do a save and activate from the Atheros 11n Configuration screen, the system reboots (but at least it does save the setting first so it comes back up with the new settings). Since I have not tried this version on any other platform yet, I do not know if this is unique to only the X86 PC version or not. This happens on both of the sites I have tried this on thus far. The 2 sites use slightly different single board computers, one had dual Gig Ethernet, the other is single, otherwise they are virtually identical.

Wasn't it stated in a previous beta of this series that the AP is compatible with clients in the 1.4 and 1.5 release series? Obviously not optimum, but at least compatible.

The improvements listed for this version are for 11n. The only 11n on our network, as yet, is on the backbone, so that is where I tried it. Catch is there are a number of WAR4 Metro that are mini POPs fed by a connection to one of our backbone routers. ALL our client facing APs are running 1.4.27.1 since it just works, compared to anything else thus far, (I am hoping this Gecko series will change that). That means that this release as an AP has to be able to talk to a client that is 1.4.27 in 11a mode, or 1.5.17 in 11n mode.

With the many interconnections on the backbone of the network it is not feasible to roll this to all of them. It has to be done step by step and the AP still has to talk to the clients whether the client is 1.5.17 or 1.4.27. Most of my backbone is currently running 1.5.17, with a number of micropops that are running 1.4.27 linked back to the backbone via a point to point link with the AP end running 1.5.17. Yes, I will try this on a few select location in the coming weeks and report again.

I guess my hopes were a little too high yet for this Beta release. But we must keep looking forward, and keep up the good work.

[lonnie]

The 4.0.5 has been tested against 1.3, 1.4 and 1.5 in our test setup and my own unit even connects with an xyz adsl router with wireless. It would sure help if someone can setup a system that can be left for us to play with.

We can't fix what we can't see. Most of the 11n improvements are a result of someone giving us free rein to poke and prod in a real live environment. He has a parallel system that can be kicked in if we thrash something, which we have done a few times. In the end the system has gone from usable to nearly flying at over 35 miles, in HT20.

I should not have to say this but we would never release a firmware that crashed and rebooted on every save. If something like that is ever seen it is fixed.

x86 is tested on WRAP boards and Alix boards. We have no PC style Mobos for testing so you could start by giving us the F9 log on bootup so we can see the chipset info and make sure you have the unused mobo peripherals shut off in BIOS.

[go.fast]

I noticed today that 4.0.5 as well as 4.0.3 have an issue with site survey.
When I do a site survey from the client it typically shows me just the ap it is connected to.
Sometimes it may show me all the aps it can see, but I believe that is after a reboot or maybe a save and activate.

Also,

The physical board layout for the laguana cards wpci# is much different from the software .
The software is telling me wpci1 is what is in wpci4 of the board.
This I noticed today also on 2 different laguana boards.
Which explains why the 3 sector ap I put up yesterday had the wrong essid's for the particular port.
I had them arranged in compass like essids, north, west, south.
When we fired it up, we noticed the essid's didn't match up to what we thought we had laid out.
We were using the boards layout when we preprogrammed the board to go up at that sight.

I hope the board layout doesn't change, that will be a huge mess.