StarV3 v1.3.3 build 2582 has been released.

[tony]

The new release is available for download from files.star-os.com.

Changes since v1.3.2 build 2569
*) Resolved an issue where some clients would not associate.
*) Client association information is now listed in the system log.
*) Resolved an issue where some messages would be displayed on the SSH interface, rather than the system log.

Problems found in this release include
none

NOTE: The X86-WRAP edition is fully compatible with the Geode-based RB220 & RB230.

Full Duplex setup example
To make use of a Full Duplex PtP connection, follow these simple steps:

System A
wpci1:
FD Role: FD-TX
FD Grp#: 1
Network Type: Station
Essid: A
wpci2:

FD Role: FD-RX
FD Grp#: 1
Network Type: Access Point
Essid: B

System B

wpci1:
FD Role: FD-RX
FD Grp#: 1
Network Type: Access Point
Essid: A
wpci2:

FD Role: FD-TX
FD Grp#: 1
Network Type: Station
Essid: B
After that is complete, add an IP to one of the Atheros interfaces (wpci1 or wpci2, doesn't matter), and you will now be able to ping between the two systems.

You can also secure your connection by enabling WPA or WEP, and using ACLs.

The Full Duplex device to monitor via SNMP, and configure via iptables is wfd0.

[billr]

As title.
As with 1.3.2, the same issue - no-one on the AP (b) will associate.
Can give more detail but I expect there will be others with the same issue..
WRAP, card is NMP 8602, b mode

Users are 90% laptops with all sorts of clients (centrino etc..)

[greg]

Tis working well for me on half dozen AP's that I've upgraded. All associations are showing up. A couple AP's service war1 only and others are many different brands on 11b units. None of the clients are notebooks to one of our AP's.

[lonnie]

billr, can you get me a login of the AP where nobody will associate? We have not seen that issue and so far you are the only guy with no associations. The issue with some units not associating was fixed and I am not aware of any issues, until your recent report.

Could it be any sort of other issue? I would expect you to see a few people connecting, but with none, then it leads me to speculate there are other issues and I would like to check it out if you can get me a login.

[DrLove73]

billr, have you disabled ALL checkboxes under "options"? Hide ESSID, Short Preamble (an must disable for 11b), Super A/G.
Also set rate to auto and cloaking to 1x. Check if ESSID is not misspeled by mistake! Save and reboot.

[wwalcher]

I upgraded to 1.3.2 a couple of days ago and implemented a DFS link between a Metro AP and a WAR2 Client (using UZ as country code). I was using 5500-5700Mhz for the range, and the link settled in at 5520. I was getting 2500Kb/sec and a low -70's link. It appeared to be working well. But, the second card in the WAR2 was functioning as an AP, and I was experiencing the association problems that have been noted. So, I reverted back to 1.3.0 (or 1.3.1) and changed thd DFS link back to a 2x cloaked 802.11a link (using US as the country code).

Tonight, I upgraded to 1.3.3 and reestablished the DFS link. The AP association problems on the 2nd WAR2 card were thankfully gone. However, the DFS link was very poor. I showed a 95-100 quality on the WAR2 client side, but on the Metro board, the link quality bounced around from 0-50. I could never get more the 800Kb/sec on the link and it was usually around 400Kb/sec. Also, the CPU load on the Metro board was much higher (between 30-80%) than when I did not have DFS turned on (less than 5%). The Metro board also rebooted twice.

I then converted the DFS link back to a 2x cloaked 802.11a link, still using the 1.3.3 world generic firmware. This fixed the link problem. I got over 1600Kb/sec on the 2x link and the link quality is good on both sides. Also, no more reboots.

[billr]

Hi,

Lonnie, thanks, but the unit is behind so many nat layers it is very difficult for outside to get in. I will try again but I can't instantly because the wisp we run is a part time operation and I have a day job.

DR - I have checked as you say and that is not the problem, but I will recheck.

Can I send a log or something?
Sorry if I appear unhelpful but the unit is not exposed to the outside world..

OH some of the clients as I say are b/g centrino and wifi cards (linksys etc) so should cope with g as well..

[billr]

I have tried 1.3.3 g World again and partial success
I switched the AP to station and did a scan and it can see other of our stations..
I switched it back to AP and disabled acl.
NOW clients are associating!!
So it seems to be a radius issue..

There does not seem to be radius info in the log - where is it please, so I can see if our radius is down..?

No, radius is working on another AP using V2..

As soon as I enable acl radius - no one can associate..
Back to 1.3.0

[DrLove73]

Aaaa, RADIUS... So ACL by RADIUS must make trouble. They were fixing that becouse of the 5-min reassociation.

Have you tried 1.3.3b? It should have much more syslog data about clients!

[billr]

Hmm where is 1.3.3b?
I can't find it for WRAP anyway.

I think there is one for WAR ?

[DrLove73]

You are right, WAR-2/4 only. Thread with link is:
http://forums.star-os.com/showthread.php?p=48716#post48716

[billr]

Thanks but the problem is with a WRAP board..
I can't replace it!

Cheers..

[eoinok]

Hi guys, we seem to be having a definite DFS freq issue. What we orginally thought might be down to psu etc where we turned on a 2nd card (as reported on another thread), has happened again. As in the WAR4 rebooted itself with just one card enabled. Also the Q% of our link seems to be a bit all over the place since the upgrade to V1.3.0., even though the throughput has been fantastic?

We will be upgrading our network to 1.3.3 tonight, and I will report back here if the upgrade fixed our issue.

[tony]

Thank you for the report billr. I have been able to duplicate the issue you reported, and have it resolved for the upcoming release.

DFS testing is on-going, but should work well for the majority.

[Onebit]

Hi guys, we seem to be having a definite DFS freq issue. What we orginally thought might be down to psu etc where we turned on a 2nd card (as reported on another thread), has happened again. As in the WAR4 rebooted itself with just one card enabled. Also the Q% of our link seems to be a bit all over the place since the upgrade to V1.3.0., even though the throughput has been fantastic?

We will be upgrading our network to 1.3.3 tonight, and I will report back here if the upgrade fixed our issue.

@eoinok

I think you are addressing the same problem I have struggled with the last weeks. When DFS is enabled the cpu loads are very high and the watchdog triggers a reboot.

Tony is informed about the problem since v1.3.0.
Among other things I am unable to use v.1.3.x because of this.

Also when the reboots disappear I can't believe that any 1.3.x version will be able to deliver usual throughputs when DFS is enabled because of the additional CPU load.

I am going to test v1.3.3 tomorrow regarding this and am hoping that there is some sort of improvement.

[billr]

Tony,

No problem - you are putting out great software but I am only too happy to report what I can if there are problems.

Cheers, Bill.

[hatster]

Tony,

You mentioned "upcoming release" above. I think i should hold off upgrading my AP's and wait for this release, any ideas when this will be ? is this to be the last release for a while ?

Thanks,

Kev.

[DrLove73]

If you use radius acl authentication, hold off until 1.3.4. If not, your guess is good as mine. I will wait 1.3.4, I am in no hurry, 1.3.0 works well for me.

[eoinok]

Hi guys, we have upgraded to 1.3.3 successfully (mix of WRAPs, WAR2, WAR4 & metro). Some of the links quality (5ghz) has definitely improved over 1.3.0. Locking of the links down to a particular rate certainly seems to help.
So far, our DFS issue has not reared its head, but it is too early to comment yet!!!

One thing that definitely did not work, is OSLR. We tried to migrate to OSLR from RIP, and it was a disaster! We had OSLR running on 1.1.13 fine for a good few months before the "OSLR bug" caused us a problem and me moved back to RIP.
We know that our OSLR configs are good, as I said before, we were running OSLR without any problems before.

I was wondering is there anyone running OSLR on this new code? As in 1.3.X


Eoin

[knolan]

The upgrade Eoin is refering to is the same upgrade I am referencing in the following post.

http://forums.star-os.com/showthread.php?t=7071



Tog has suggested using the new config posted on the wiki

http://staros.tog.net/wiki/OLSR


I will try this the next Planned Engeering Works windows I can get - More than likely 1am next Friday morning :(

Regards,
Keith

[tog]

I am running an all-OLSR network with a mix of 1.1.14 and 1.3.0 OLSR routers. It is working well, but you will want to take a look at the updated config from the wiki that knolan just mentioned.

[pti-andy]

After upgrading a WAR-2 from 1.3.0 to 1.3.3 the Ethernet link settings now say "unsupported by hardware." I've had issues with the 1.3.x release not supporting the 10M Full Duplex setting (stays at half duplex) where 1.1.x worked fine. Now the settings seem to be gone alltogether? Any ideas?

[DrLove73]

Well, you could always try different type of LAN card. Cant you? Even if it is one linked with licence, you could put in another and use that one?

[therealboss]

I get "unsupported by Ethernet.", I thought we could adjust the setting on Ethernet from auto to 100 or 10, Full or Half Duplex, you cant now?

I see this on both WAR2's & WAR4's running 1.3.3

[tony]

The duplex settings should be available on all platforms except for the WAR-1, which is a 2-port switch.

I will look into this, thanks.

[lonnie]

Did you buy that card from us or from another Gateworks reseller? The reason I ask is that we have discovered there might be some Gateworks clones or even a new Gateworks board that uses a different Ethernet PHY. We do not have support code for the new PHY.

After upgrading a WAR-2 from 1.3.0 to 1.3.3 the Ethernet link settings now say "unsupported by hardware." I've had issues with the 1.3.x release not supporting the 10M Full Duplex setting (stays at half duplex) where 1.1.x worked fine. Now the settings seem to be gone alltogether? Any ideas?

[Onebit]

I have tested v1.3.3 concerning the high cpu workload when DFS is enabled.

But in front of this I changed my test method because Tony and Lonnie say that my netio tests are the source of error.

Now I use a ordinary SMB file transfer. This means simple Windows to Windows file transfer over a StarOS 802.11a wireless link with DFS enabled.
SMB is a very common used protocol in my StarOS network so I hope I can corroborate my test results.

Here are the test results with different wireless settings (SuperAG, WEP, Short Preamble):
Always a reboot after about 1 minute SMB file transfer!

When you don't believe in my test results, please tell me what's going wrong!

[tony]

We have never said we do not believe in your test results.

The area you are in is extremely noisy, and with DFS enabled it only amplifies this (causing excessive system load on the WAR). With pushing the system to full throughput, using netio or any other throughput testing mechanisms will bring the system to it's failsafe breaking point, causing it to reboot.

For the time being, I would recommend using a non-DFS channel in areas with excessive noise and other interference.

We are working on a solution to the problem you, and one other person are experiencing.

[Onebit]

My test setup is indoor (under ground) and the site survey on the 802.11a client says there is only the 802.11a station from the test setup with -45dbm signal level.

I don't know how my test setup will absorb any noise from outdoor? I don't know what's going wrong. There are no airports, radars or something else in the neighborhood. We live in a very rural area with very much forests around and nothing else.

[DrLove73]

Can you try testing outside? about 30-100m apart and with lowered tx power?
Set it so signal is ~-60.

Maybe bouncing of signal acros the room is cousing interference? I am not RF expert, but it would not hurt.

[lonnie]

If there is an issue with DFS simply stop using it. If it crashes on a full load test stop doing the load test and put a cap on the throughput using CBQ.

I am interested and I believe you that there is an issue, BUT, I am not going to drop everything and dig into DFS code. We simply wish to let Atheros fix such things because we MUST keep the DFS code clean if we are ever going to get DFS2 certified. Unless I can get DFS2 certified there is no reason to even have it, thus, I cannot make any fixes or we'll never get certified.

It's a Catch 22 situation, and your best bet is to simply either avoid full load situations or DFS channels until there is a fix.

I'll also mention that 95% of all instability is the result of inadequate power adapters. You might think you have a good supply but my warning bells go off whenever someone tells me that a system crashes under heavy load. Forgive me, but I have dealt with so many issues over the years that are resolved with better power or cabling.

My test setup is indoor (under ground) and the site survey on the 802.11a client says there is only the 802.11a station from the test setup with -45dbm signal level.

I don't know how my test setup will absorb any noise from outdoor? I don't know what's going wrong. There are no airports, radars or something else in the neighborhood. We live in a very rural area with very much forests around and nothing else.

[pti-andy]

Did you buy that card from us or from another Gateworks reseller? The reason I ask is that we have discovered there might be some Gateworks clones or even a new Gateworks board that uses a different Ethernet PHY. We do not have support code for the new PHY.

This has happened on all of the WAR-2 boards I have upgraded so far and they are all VNC boards with the Intel Ethernet. I have never purchased anything else. I downgraded to 1.3.2 and the settings come back. It is only with version 1.3.3 that this happens.

[tony]

Onebit's post has been moved due to inappropriate content, not suitable for the forums.

Please continue your discussion of the matter with Lonnie directly via PM or e-mail.

[lonnie]

I have checked about a dozen units and I have found a WAR4 that exhibits the message. We will investigate the Unsupported message.

This has happened on all of the WAR-2 boards I have upgraded so far and they are all VNC boards with the Intel Ethernet. I have never purchased anything else. I downgraded to 1.3.2 and the settings come back. It is only with version 1.3.3 that this happens.