StarV3 v1.1.5b build 1659 (beta-4) is ready for testing

[tony]

The new release is available for testing. It is BETA, and should not be used on mission-critical systems.

Downgrading back to previous V3 releases is possible.

This release should be considered more or less stable, however please refer to all the beta release notes, and do not upgrade any critical systems as some issues may still be outstanding.

For more information, please visit the release page.
http://www.star-os.com/release-notes/starv3-1.1.5b-1659.htm

Please post your results in this thread.

Primary focus of this release is compatibility, and low signal testing.

[bobbyc]

I flashed a WRAP 2c from 1509 to this build. It won't detect atheros cards. It detects prism 2.5.

I only tested 5004 based cards, since this WRAP doesn't have the bios update.

This particular WRAP was detecting CM9s fine with the previous 3 betas.
The WAR detects atheros and prism 2.5 fine.
Thanks,
Bob C

[tony]

Does it fail to detect the CM9 continually (even after rebooting), or was it just the one time?

[tog]

I will test 1659 on my bench WAR4 and WAR2 in a little while and let you all know at least whether my WARs detected atheros cards.

If it works I'll then go put 1659 on that production WAR4 that's a 5 minute drive.

[bobbyc]

Hi,
Continuously. I tried multiple CM9's and 1 SR2.

[tony]

Thank you. I will have to do some investigations into why the WRAP release does not work correctly.

[tog]

No problem detecting atheros cards under 1.1.5b on a WAR4. No change in the "low receive signal" problem I described for 1655 though.

With 1.0.3 installed on the remote station, AP displayed sig/ack -71/-71

Immediately after rebooting remote station to 1.1.5b/1659, AP showed -71/-93 and the remote station is an N. I'm driving over there now to plug into the ethernet and put 1.0.3 back on that board so the 5GHz link will come back up.

[tog]

One change in behavior from 1655 to 1659 regarding this issue:

When I drove over and logged into that board via ethernet it was displaying a receive signal of -70. It was displaying the remote AP as all 00:00:00:00:00:00 for the MAC, though- not associated. The only change in behavior from 1655 is that the displayed signal strength is now accurate and matches the site survey's displayed signal strength.

I flashed back to 1.0.3 and came right up like normal again.

Since the AP was displaying the ack signal as ridiculously low I think the underlying problem still exists.

[tkerns]

I loaded beta-1659 onto one of my WAR's.... the one that has been the most problematic with "N"s. it has been running for 36 minutes now. Clients associated and running. Signals look better than before (was on 1.1.0).

A couple minor display issues. speed of 5.5 shows as 5.500 and there seems to be issues with sort on idle. Tried to determine, but it looks like every couple minutes several associated but not active clients will go to the top of the list. their idle times do not change, so you end up with clients with minutes ahead of active clients with 0 idle time.

Tim Kerns
CV-Access, Inc.

[tkerns]

As I was typing the last message, my OTHER War went to all "N" associations. It was running 1.0.3, so..... I now have 2 WAR's on 1.1.5b-1659. This will be a good test of the beta as these 2 units have 36 and 45 clients each and are very active AP's. High noise environment on one AP.

Noticed that this release only displays one sig and one rate. Is my assumption correct that this is the "rec" signal and the Tx rate?

These are single radio WAR-4 and WAR-2, the WAR-2 has an SR2 and the WAR-4 has a WLM54g.

[bobbyc]

Since the AP was displaying the ack signal as ridiculously low I think the underlying problem still exists.

Here's my results of testing. I only have one WAR and one WRAP at my disposal right now, so I haven't been able to test with the WRAP client being build 1659.
This is 802.11b mode locked to 11mbps.

1509 WAR CM9 AP Q93 -83 -83 11 11
1509 WRAP CM9 CL Q100 -80 -80 11 11
640KB/s rx/tx

1659 WAR CM9 AP Q18 -77 11
1509 WRAP CM9 CL Q100 -80 -90 11 11
640 KB/s rx/tx

1659 WAR CM9 AP (test on hold until WRAP atheros detection is resolved)
1659 WRAP CM9 CL (doesn't detect atheros cards)

Notice after the AP was flashed to 1659, the ack reported by the 1509 client is -90.
Bob C

[tony]

Thank you for the detailed information bobbyc, the problem has been resolved and a new beta will be released today.

[tog]

You found and fixed (or are in process of fixing) the "deaf receiver" problem specifically?

[tony]

It does resolve the signal related issues and 'deafness' some are having. I've not been able to duplicate your issue with it not associating, however I would suspect the problem that has been resolved may help.

[tog]

If my station will no longer be deaf, then your new driver should be pretty def (http://www.urbandictionary.com/define.php?term=def) indeed.

http://www.clevelandclinic.org/health/health-info/Pictures/behind%20ear%20hearing%20aid.GIF


I look forward to testing the next build you release.

[tkerns]

I have the WAR WLM54g running in "b" only mode, I changed to b/g applied changes, it came back, clients associated slowly, added Super AG mode and applied changes, it again came back but clients associated slower than before, I then changed config back to "b" only and took off Super AG, applied changes and lost communication with the WAR. No ping responce. Luckly I have a remote power controller so I cycled power and the WAR came back, was able to log in, etc.

I don't think this is unique to this beta as I've lost access before when applying changes using 1.1.0.

Tim Kerns

[tog]

It happens, but it's extremely rare. I can remember twice in the last 6 months I've had to go power cycle a WAR because it became non-responsive after an activate changes. Seems like it had to be a serious total meltdown hardware hang since the hardware watchdog and the ping watchdog weren't resetting the system.

[bobbyc]

Thank you for the detailed information bobbyc, the problem has been resolved and a new beta will be released today.

Thanks. I like to help/beta test.
Bob C

[tkerns]

I have been running for over 4 hours now and it is looking GREAT.. good job on this release.

I have not seen a single "N"... did you remove it :)

I have noticed one more minor display error. These have nothing to do with function. In the display log it appears to be using 2 different times. Most log entries I see are time stamped with the actual time of the AP, but I had a loser trying to hack in and "dropbear" messages appear to be in zulu or utc, or what ever time you want to call it. basically time with no offset.

Again I want to say this release looks GREAT for 2.4 and all my CB3's.

From one of your most harsh and vocal critics,

Tim Kerns

[tony]

I am very pleased to see the system is working well.

Because the ssh server is started before the ntp client updates the system time (which can take a very long while), the system logs will have a time different between ssh, and the rest of the system.

Hopefuly the next beta will resolve many of the last remaining Atheros issues.

[tkerns]

Tony,
Once the NTP updates the time, it looks as though "dropbear" messages are using GMT (zulu and utc reflects my military and pilot training) instead of the new time with the offset. Again this doesn't affect function and not a big deal. Just need to be aware of the different time stamp.

Tim

[tkerns]

I have these messages in the log this AM. It is only on the WAR-4 with a single WLM54g radio.

kernel: ip_ct_ras: decoding error: out of bounds

and about 20 of these:

kernel: wifi0: stuck beacon; resetting (bmiss count 4)

Are the 1st message related to a loser trying to hack into around this time? Flooding with different usernames and passwords.

Tim Kerns
CV-Access, Inc.

[tony]

The first one is a h323 nat message (got a malformed packet). It should be considered informational, and will not effect the system.

The second one can happen when operating on a noisy 11b or 11g channel. For the most part, it should be harmless and transparent to the associated clients, however if it continually occurs in a short time frame, you may need to change the channel.

[tkerns]

Thanks Tony

the messages on stuck beacon were over night and have not re-appeared since about 6 AM... I will continue to monitor, but I'm limited on avail channels as the verticle in this area is very noisy.

Tim Kerns

[tony]

Keep an eye on it, however you should be Ok.