StarV3 v1.3.7 build 2677 has been released.

[tony]

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

Changes since v1.3.6 build 2639
*) Atheros has been updated to be more verbose when the station gets disconnected.
*) Quagga has been upgraded to v0.99.9
*) OLSR has been upgraded to v0.5.4
*) ISC DHCP server has been upgraded to v3.1.0
*) ISC BIND has been upgraded to v9.4.1-P1 (X86 PC)
*) maradns has been upgraded to v1.2.12.08
*) Hardware Watchdog entry on the SSH interface is no longer relevant, and has been removed. (Hardware watchdog is always enabled on supported platforms).
*) Bridged VDS connections should not longer stop passing traffic after an activate.

Problems found in this release include
none

NOTE: The X86-WRAP edition is reported to support the RB220 and RB230 systems very well.
PC Engines ALIX systems have not been tested, however the X86-WRAP or X86-PC editions should run on it.

Supported OLSR Plugins
Plugins that are supported include:
* httpinfo
* txtinfo
* dyn_gw
* dot_draw
* arprefresh

Please refer to the OLSR manuals for proper configuration and use of these plugins.

For Hotspot setup examples, please refer to 1.3.0 (http://forums.star-os.com/showpost.php?p=46851&postcount=1) release notes.
For Atheros Full Duplex setup examples, please refer to 1.3.5 (http://forums.star-os.com/showpost.php?p=49362&postcount=1) release notes.

[berniereynoso]

Tony:

Would you please tell me if WPA encryption on an Access Point Configuration is supported? WAR1 with Engenius 600mw.

I have the WPA script configured like:

# master (authenticator) configuration
process wpa-master
security enabled
wpa-passphrase "mypass"
nas-identifier "StarOS"

Txs,

[DrLove73]

You are using radius??? then don't you need some of this:

own-ipaddr ???
auth-server 127.0.0.1 1812 "MySecret" ???
acct-server 127.0.0.1 1813 "MySecret" ???

If you updated unit form 1.x.x, you won't have new WPA script.

[berniereynoso]

No, I am not using radius, probably the nas-identifier line shouldn't be there, but regardless, it still doesn't work. Txs,

[tony]

Due to the limited storage on the WAR-1, they include full client WPA support, not not Access Point WPA.

[berniereynoso]

Thanks for the response, do you have any suggestions since I will need to use WPA on Access Points?

[DrLove73]

WAR1 is missing some stuff inside Star-OS to be AP. User WAR4 for AP's.

[peace2300]

i think that i would love to be able to use a war1 for a ap only because i would be able to free up some war2's that are only one card ap's

[DrLove73]

Sorry, VNC guys do not like that idea. They have to sell WAR4's as well :-D

[tony]

We do have plans to have AP WPA support in the WAR-1 family of systems, however this will come around the same time as the Interface overhaul.

[ripv]

i think that i would love to be able to use a war1 for a ap only because i would be able to free up some war2's that are only one card ap's

I purposely have war2 ap's with only 1 card active - they work great and have plenty of power to handle a nice busy ap. The cost of the ap after all is not as sensitive as the cpe and I certainly wouldn;t consider replacing my war2 ap's with war1's...;)

[SteveA]

This version includes an image for LR2. What device that that match with? A search came up blank.

thanks

[DrLove73]

XSCALE-LR2 (by source-licence file)

[SteveA]

That was helpful. :)

Search of forum comes up empty, and no card with an LR2 designation is for sale on the web site.

Search of google comes up with Land Rover 2. Probably not a match there.

Is this meant for the general customer base, some specific beta testers of an un-announced product, and/or is it possibly a variation of LS2 or PS2?

[DrLove73]

Can not say. They are probably testing new version of Xscale. I do not know even how Xscale looks like.

[ChrisII]

I've been trying to download Firmware V1.3.7 but everytime i do it says. "You are only allowed to download a single file at a time. Continue." I am not downloading any other files, this was the only file i was going to download, this has happened to me numerous times, last time this happened i started using a different account. (http://files.star-os.com/)

[tog]

Are you perhaps using a download manager or a proxy server or a multi-WAN router that juggles the public IP you are coming from?

[ChrisII]

download manager = no

I have tried freom two different IP Addresses, Our Main firewall our clients go through and i also have my own Real IP address. I still have the same problem when trying to download.

[ripv]

Not very helpful I know but I just tried and it came down OK..

What browser are you using? might be worth clearing out your cookies and
temporary files etc.

[DrLove73]

Also, if you pause one download, you can not continue with another.

[c.davis]

The files website only allows one download per user at a time. If a download is canceled part way through it sometimes keeps you in the downloading state (if a proper quit message isn't sent from your browser for example), therefore refusing subsequant downloads.

ChrisII, I've reset the state for you, now you will be able to download again.

Just a FYI for everyone else, if you find yourself in the same situation please PM myself, Lonnie or Tony and we'll get it cleared up right away.

[ninedd]

Changes since v1.3.5 build 2635
*) Atheros traffic LED blinking behavior on the WAR-1 has been improvedHi. On 1.1.14 the LED blinking for signal strength seems to work as expected, however, on 1.3.6.g.world the LED signal strength on the WAR1 doesn't seem to be working. Is this something we're doing wrong, or is this a change in 1.3.x? I've STF for 'LED' and 'blinking' but didn't see anything definitive. Thank you.

[lonnie]

It sort of helps to describe the problem, rather than simply saying it does not appear to be working.

The LED attaches to the first client radio it finds and shows the signal strength by flashing at various rates (increasing with strength).

How does it flash? Fast, slow, on, off?

[rbolduc]

The WAR-1 contains two ethernet ports, which act as a small 2-port switch. The software will use these two ports as a single interface.

LED lights: (Blue power light = LED 1, LAN1 = LED 5, LAN2 = LED 6)

LED 2: Status / Diagnostic light
This will blink quickly during bootup, then settle to a constant one second 'heartbeat' blink once every second.

Updating the flash (such as saving settings, or doing firmware updates) will cause the LED to blink rapidly.

This LED is also used with the button (see below)

LED 3: VDS Status light
This will turn on when a VDS tunnel has been successfully created, otherwise it is off.

LED 4: Atheros signal level indicator
This will flash to indicate current signal level of the client connection. Solid light indicates a signal of -67dbm or lower, and if the light is off, it the client is not associated.

Button:
While pressed, LED 2 will turn off for roughly one second. If you release the button in this timeframe, the CPE will be rebooted.

If you continue to hold the button, LED 2 will start flashing, slowly at first but will quickly gain pace. Once it reaches a solid state (roughly 10 seconds), the system will reboot, and restore to factory settings (including generating new SSH keys).

Reed

[ninedd]

OK, sorry. Yes, that wasn't a good description. I assumed that everyone was seeing the same behaviour since 1.3.x - so I didn't think I was really reporting a problem. :)

So, what we're seeing with 1.3.x on LED 4 gives us a very fast blink all the time, associated or not. In 1.1.x, the LED worked as expected, with faster blinking as signal strength increased, and finally a solid at -67 or better. When we flash a WAR1 up to 1.3.x, then LED 4 just blinks really quickly all the time, associated or not. This is at least with 1.3.6.g.world that we're seeing this.

[billr]

I must have missed something...

LEDs flashing..

I can't find much searching, but on my 1.3.7 WRAP, the LED nearest the ethernet flashed off/on continuously. 1 per sec or so.. Is this normal?

Apologies if this is previously posted but 1.3.4 I don't think I saw flashing.
Is it also a signal strength indication?

Cheers, Bill

PS I see there is some info above but a difinitive answer would be good!

[lonnie]

There is a problem with the signal level LED which will get fixed. I cannot give a date since we are still awaiting things to arrive here.

[ninedd]

What we've been doing as an interim is using 1.1.14 to align the antenna (since the Signal LED works) and then flashing up to 1.3.6 once we're locked down. Not to bad.

[pti-andy]

There seems to still be serious issues with the 900Mhz performance. The problem with the signal dropping off over time still exists with 1.3.7 and signal is even worse than it is with 1.3.5. At this point there still isn't a 1.3.x version that is stable at 900Mhz except 1.3.6 which degrades over time until going offline completely. The problem is worse with clients that have higher noise levels and drop off in less than an hour. Clients with low noise will stay online for many hours before the signal degrades. While online the performance is high and stable and many times better than all other 1.3.x versions which are unstable and drop packets or simply will not connect at all. No radio paramaters have an effect on the problem including rate and tx power. Below is a summary betwen the last three versions.

1.3.5 RX signal low fluctuating, bandwidth fluctuates and drops packets, stays online.
1.3.6 RX signal high and stable, bandwidth very good, goes offline after time.
1.3.7 RX signal extremely low and fluctuating, bandwidth unusable, goes offline quickly.

Please let me know if this issue is being looked at or if there is more info I can provide.

[SteveA]

Andy,
I've been having the same problem, but not just with 900 Mhz. I have 2 900 MHz backhauls that have been working fine for months. Change to 1.3.5 or 6 or 7 and after awhile (hours to days) the signal degrades from a -69 to high -80's. I have 6 of my 5.8 GHz backhauls converted to 1.3.5-7 as well, and they exhibit the same behavior. The problem occurs when the end points are the same version or different.

For example: Last night a 5.8 backhaul from a metro to a war2 went from -70 dB to -88 dB. I rebooted, reset channel, TX rates, and even 1x vs 2x and the signal strength didn't return. I changed one of the units back to 1.1.14 and the signal strength came back.

With two 900 MHz backhauls and six 5.8 GHz backhauls on 1.3.x, I was experiencing a link decay twice a week. My other 30 or so backhauls on 1.1.14 or other OS have had no problems.

The 1.3.x series has great features, but I have been unable to leave it on backhauls that have otherwise been flawless for months. I'd stay on 1.1.14, but the new versions have those nice features such as working SNMP.

Has anyone else been having these problems or is it just Andy and I with messed up configurations?

[DrLove73]

Just a note: It will be at least one or two weeks until they get settled and start working.

[DLNoah]

FWIW, we have 8 5.x backhauls working on 1.3.0 or 1.3.4 fcc, all but one of them can link up in 2x cloaking (though for signalling reasons not all of them work well on 2x cloaking), and they all link up normally in 1x cloaking. 2 of them are in the high range (5.7-5.8) and 6 of them are in the 5.3 range. A typical setup for us is...

Tx Rate: set to the highest rate the link isn't falling back from, generally 24 or 36
Link Distance: actual +2
Country Code: US
Tx Power Override: 20 (CM-9 card's rated max)
Cloaking: 1x or 2x, as appropriate
No Enhanced ANI
No Hide SSID
No InterBSS
No Short Preamble
Yes SuperA/G
Mode 802.11a, WEP (mostly Open System)

All of these BH links are between -52 and -62 signal strength. We have BH links that aren't as strong, but we just haven't upgraded the firmware on the boards yet (haven't gotten to it). Don't know whether this is any help or not.

[pti-andy]

Andy,
I've been having the same problem, but not just with 900 Mhz. I have 2 900 MHz backhauls that have been working fine for months. Change to 1.3.5 or 6 or 7 and after awhile (hours to days) the signal degrades from a -69 to high -80's. I have 6 of my 5.8 GHz backhauls converted to 1.3.5-7 as well, and they exhibit the same behavior. The problem occurs when the end points are the same version or different.

For example: Last night a 5.8 backhaul from a metro to a war2 went from -70 dB to -88 dB. I rebooted, reset channel, TX rates, and even 1x vs 2x and the signal strength didn't return. I changed one of the units back to 1.1.14 and the signal strength came back.

With two 900 MHz backhauls and six 5.8 GHz backhauls on 1.3.x, I was experiencing a link decay twice a week. My other 30 or so backhauls on 1.1.14 or other OS have had no problems.

The 1.3.x series has great features, but I have been unable to leave it on backhauls that have otherwise been flawless for months. I'd stay on 1.1.14, but the new versions have those nice features such as working SNMP.

Has anyone else been having these problems or is it just Andy and I with messed up configurations?

I'm glad to hear that I'm not the only one. I've been trying for weeks to make a correlation but have been unable to. It does seem to effect the locations with higher noise. This might be why I'm only seeing it with my 900Mhz clients. I have one that will stay alive for days and it has the lowest noise floor but also the lowest signal at -72. Another location has a strong -62 signal and decays within an hour.

The curious thing is that version 1.3.6 performes extremely well before it decays whereas all other 1.3.x versions perform very poorly and drop offline momentarily. I'm not sure what was done with 1.3.6 but it is definately a huge difference. I have a location that won't even come online with any other version but will stay online and pull 2Mbps all day long with 1.3.6. If the decay problem could just be solved we'd have a great thing going.

I'd be willing to do some testing on a beta version as I can reproduce the results consistently and it is extremely important that I get this solved quickly before I loose my customers.

[berniereynoso]

Tony:
Txs for the answer on AP WPA support for War-1, any timeframe?

[lonnie]

It'll be two weeks before we get a dev lab setup.

[keith.yoder]

I upgraded our PC router to 1.3.7, vnc world version and the DNS server appeared to stop working. After we changed everyone's DNS over to our provider's address, I remembered that I had upgraded the version (this was the same day we did a major bandwidth upgrade, and that had us confused for a bit). I put it back to 1.3.5 and everything went back to normal.

This is not really a big deal because we didn´t need any of the new features in 1.3.6 since there are no radio cards in this box. Just thought you'd like to know, though.

Keith

[DrLove73]

You could have used forwarding rules, it wold save you a lot of time at clients.

[SteveA]

Andy
I cannot repeat the signal strength decay problem other than by just waiting and watching. Every few days I see a 10+ point drop on a backhaul by watching cacti.

Yesterday a 5GHz backhaul dropped 15 points. I tried just doing an activate changes with a very minor distance change, and the link reset to full strength right away. Usually change activation does not restore the strength, and more drastic changes are needed.

My limited statistical sample on how I've restored the signal after a decay. I usually go though these steps:

activate minor change: only worked once
Reboot radio : worked 3 or 4 times
Change one end to V1.1.14: worked 10 times or so
change both ends to V1.1.14: Worked in all cases ( about 10 more times)

Not scientific.... but cacti show 2 failure modes. Sometimes the signal decays over a 1 to 2 hour period. Sometimes it decays in 10 minutes or less. The two hour version shows a random walk that tends towards the final weaker value. The quick version is a direct decay to final value, no random walk.

I seldom see the problem if one of the ends of the link is V1.1.14, but it has happened that way twice. Never see the problem if both ends are V1.1.14.

Steve

[Beebe]

Those people with fluctuating signal strengths, and/or links dropping out - you have specified the antenna connector, not just left it on auto, haven't you?

Thanks,
Roger

[pti-andy]

Andy
I cannot repeat the signal strength decay problem other than by just waiting and watching. Every few days I see a 10+ point drop on a backhaul by watching cacti.

Yesterday a 5GHz backhaul dropped 15 points. I tried just doing an activate changes with a very minor distance change, and the link reset to full strength right away. Usually change activation does not restore the strength, and more drastic changes are needed.

My limited statistical sample on how I've restored the signal after a decay. I usually go though these steps:

activate minor change: only worked once
Reboot radio : worked 3 or 4 times
Change one end to V1.1.14: worked 10 times or so
change both ends to V1.1.14: Worked in all cases ( about 10 more times)

Not scientific.... but cacti show 2 failure modes. Sometimes the signal decays over a 1 to 2 hour period. Sometimes it decays in 10 minutes or less. The two hour version shows a random walk that tends towards the final weaker value. The quick version is a direct decay to final value, no random walk.

I seldom see the problem if one of the ends of the link is V1.1.14, but it has happened that way twice. Never see the problem if both ends are V1.1.14.

Steve

Most of what your saying above is true in my situation also except doing an "activate changes" brings it back to full strength in all cases.

With my 900Mhz clients the decay will occur within several hours, sometimes as quick as a half hour but it will always do it with version 1.3.6-7 and will always decay quickly until disconnected from the AP. With previous 1.3.x versions the signal is just erratic and unusable jumping up and down 10dB or more. This is true and repeatable at all of my 900Mhz POPs.

I'd like to point out that 1.3.6 is the only usable version at 900Mhz when this is not happening. 1.3.7 is the worst of them all starting with low signal and then decaying.

No settings such as ANI, super A/G, short preamble, distance, TX power etc. have an effect on the problem.

The antenna port is also manually set.

I do however have one location that is not having this issue frequently. It has the exact same hardware antenna etc. but it is in a poor location surrounded by trees and therefore has a very low noise floor. If I had to guess at any changing condition that triggers the decay I'd say it is noise as those with the highest noise seem to drop off first. This could be just a coincidence though.

[i20access]

Has anyone else using OLSR had trouble with this release? I upgraded my entire mesh to this release and could not even see HNA entries that were on the LAN, let alone HNA entries from the other mesh routers, or even a default route. Was OLSR compiled differently? Any help here would be appreciated. Below is my configuration:


LinkQualityFishEye 1
IpVersion 4
Hna4
{

}
AllowNoInt yes
TosValue 16
Willingness 4
IpcConnect
{
MaxConnections 0
Host 127.0.0.1
}
UseHysteresis no
LinkQualityLevel 0
LinkQualityWinSize 10
Pollrate 0.05
TcRedundancy 2
MprCoverage 2
LoadPlugin "olsrd_httpinfo.so.0.1"
{
PlParam "port" "8001"
PlParam "Net" "10.9.1.0 255.255.255.0"
PlParam "Net" "10.9.9.0 255.255.255.0"
}

Interface "eth0"
{
HelloInterval 0.5
HelloValidityTime 10.0
TcInterval 1.0
TcValidityTime 14.0
MidInterval 5.0
MidValidityTime 15.0
HnaInterval 5.0
HnaValidityTime 15.0
# LinkQualityMult 192.168.0.1 0.40
# Weight 9
}

Interface "wpci0"
{
HelloInterval 0.5
HelloValidityTime 10.0
TcInterval 1.0
TcValidityTime 14.0
MidInterval 5.0
MidValidityTime 15.0
HnaInterval 5.0
HnaValidityTime 15.0
# LinkQualityMult 192.168.0.1 0.40
# Weight 9
}

[tog]

So far only my home client unit is using 1.3.7 with the newer olsrd 0.5.4.

Sorry, all I can say so far is that it has been working perfectly with my existing olsrd 0.5.0 (StarV3 1.3.0) network.

Might I suggest that you take a look at my updated more conservative OLSR config at http://staros.tog.net/wiki/OLSR

[cephlon]

There seems to still be serious issues with the 900Mhz performance. The problem with the signal dropping off over time still exists with 1.3.7 and signal is even worse than it is with 1.3.5. At this point there still isn't a 1.3.x version that is stable at 900Mhz except 1.3.6 which degrades over time until going offline completely. The problem is worse with clients that have higher noise levels and drop off in less than an hour. Clients with low noise will stay online for many hours before the signal degrades. While online the performance is high and stable and many times better than all other 1.3.x versions which are unstable and drop packets or simply will not connect at all. No radio paramaters have an effect on the problem including rate and tx power. Below is a summary betwen the last three versions.

1.3.5 RX signal low fluctuating, bandwidth fluctuates and drops packets, stays online.
1.3.6 RX signal high and stable, bandwidth very good, goes offline after time.
1.3.7 RX signal extremely low and fluctuating, bandwidth unusable, goes offline quickly.

Please let me know if this issue is being looked at or if there is more info I can provide.

I only have one 900 mhz AP. I switched it to 1.3.0 and all 20 clients. The performance was horrible. I started getting emails and calls the next day. I switched everyone back to 1.1.4 and it was back to normal.

All my 2.4 APs have been upgrade and perform much better, especially the cloaked ones.

Not sure why 900mhz did so bad, but I feel that if 1.1.4 is working good I will just leave it there for now.

[pti-andy]

I only have one 900 mhz AP. I switched it to 1.3.0 and all 20 clients. The performance was horrible. I started getting emails and calls the next day. I switched everyone back to 1.1.4 and it was back to normal.

All my 2.4 APs have been upgrade and perform much better, especially the cloaked ones.

Not sure why 900mhz did so bad, but I feel that if 1.1.4 is working good I will just leave it there for now.

That's good advice. I did try going back to version 1.1.14 and it worked better in many cases depending on noise and sensitivity of the client. In a few instances though, only version 1.3.6 would connect. I don't know what is special about that version but it is magic (until it decays and goes offline). I'm hoping that 1.3.6 can be used as a basis for the next version instead of 1.3.7 because 7 doesn't work at all.

One important tip when switching between 1.1.x and 1.3.x is that the TX power is not the same scale. You have to set 1.3.x much higher to get the same output level as 1.1.x and if you then switch back to 1.1.x it will overdrive the RF and not even connect leaving the client stranded.

[DrLove73]

Just a thought. If you keep 1.3.6 and set batch file with Scheduled Tasks, to call "starutil yourIP yourPassword -a" in regular intervals? It should apply changes. On unit in my office it disconnected radio then reconnected to the AP.

[ChrisII]

i will vouch for the signal decay issue in v1.3.x, i have seen, watched and experienced it first hand, i have literally watched signal strengths on some of our towers and have seen signal levels jump from roughly -58 to -82 for various, but not all, clients on 4x. i can't figure out any reasons why other than noise. just wanted to say i have noticed it as well. our v1.1.14 towers dont have this issue.

[DrLove73]

They do not HAVE or do not REPORT issue? There is a big difference, if they do not report it.

I went from 1.1.13 to 1.3.0, to 1.3.4, to 1.3.6 without any problems, both 4x 11b/g and 11a. I do not say that you do not have them, just that I had none.

[tog]

I know that there is an issue with signal decay in 1.3.x if you use tx power "def", so I have to ask if you have confirmed that you have some kind of tx power set at the AP and the clients.

[pti-andy]

I know that there is an issue with signal decay in 1.3.x if you use tx power "def", so I have to ask if you have confirmed that you have some kind of tx power set at the AP and the clients.

I have had this issue with any TX power level and have experimented with changing all other radio parameters and it has no effect on the problem. So far ALL of my 900Mhz clients experience this issue.

I used to think that one of my clients was immune to the problem but I found out what was keeping it from decaying. If you turn on the ping watchdog and make sure its interval is 10 seconds or less it will keep the client from decaying after a while. My other clients having the issue had an interval of 30 seconds and this wasn't enough to keep it alive.

From this discovery it is safe to say that the issue occurs when there is no traffic after a short time. Not that a lack of traffic is the cause but it seems to prevent it from happening. It does still seem that it happens faster with higher noise clients.

All I can say is that this has worked for me so far for an entire day on 6 clients that used to drop every half hour or so. I'm very glad there seems to be a workaround as I have locations that will only work with version 1.3.6. This version is by far the best performer of all versions I've used to date.

I really hope the issue can be located and continue the code in 1.3.6 as the standard since it has outstanding radio performance. 1.3.7 seems to have different radio code as its performance is not nearly as good as 1.3.6.

For those having this issue, try the ping watchdog and see if that fixes it.

[go.fast]

is it an SR9 or XR9 that is exhibiting this behavior?

[ninedd]

1.3.7 seems to have different radio code as its performance is not nearly as good as 1.3.6.Looking at the release notes, it seems that 1.3.7 has primarily changes to the compiled in packages, and not much in the way of driver changes?

Changes since v1.3.6 build 2639
*) Atheros has been updated to be more verbose when the station gets disconnected.
*) Quagga has been upgraded to v0.99.9
*) OLSR has been upgraded to v0.5.4
*) ISC DHCP server has been upgraded to v3.1.0
*) ISC BIND has been upgraded to v9.4.1-P1 (X86 PC)
*) maradns has been upgraded to v1.2.12.08
*) Hardware Watchdog entry on the SSH interface is no longer relevant, and has been removed. (Hardware watchdog is always enabled on supported platforms).
*) Bridged VDS connections should not longer stop passing traffic after an activate.

[pti-andy]

My 900Mhz clients are now XR9's but I started the install using SR9's and then switched.

I realize that there is no changes to the driver published between 1.3.6 and 1.3.7 but there must be something different because 1.3.7 has more than 10dB less signal and far less performance. It's signal also fluctuates drastically just like 1.3.5 did whereas 1.3.6 is rock solid.

As I said before, I have several locations that will not even pass data with 1.3.7 but work perfectly with 1.3.6 exceeding 2Mbps downloads. That's a big difference going from no data at all to 2Mbps just by doing version change!

Another big advantage is that ANI seems to work great on 1.3.6 in situations where there is interference near a client radio. In one location near a cell tower I had a very strong -61 but was dropping packets with 1.3.5 and 1.3.7 whereas 1.3.6 with ANI turned on didn't miss a beat.

One thing is for shure, these versions are not the same.

[tony]

The only thing updated with the Atheros support between 1.3.6 and 1.3.7 is the verbosity. They are otherwise functionally identical.

[timotei]

Usually I do not upgrade until I need to, but I installed 1.3.7 on a few WAR2 (those closest to me, easy available, few customers). And I notice one thing on a 5GHz PtP link with DFS:

After reboot of AP, usually the channel (5680) is found to have
radar and AP changes to 5500. Client connects, but no traffic.

After any small change in wpci config, and activating, the AP is back to 5680. And this time no radar is found. Client connects, all OK.

How does the radar know if I am rebooting or just activating? :p

[pti-andy]

The only thing updated with the Atheros support between 1.3.6 and 1.3.7 is the verbosity. They are otherwise functionally identical.

You may want to check into this again. There is definately something different between 1.3.6 and 1.3.7. Here are some stats with a client. The only difference is the version upgrade. I can switch back and forth all day between the versions and it always comes up with these results.

V1.3.6: RX -62, Noise -100, 1100Kbps average download. Readings stay steady.
V1.3.7: RX -67, Noise -88, 750Kbps average download. Signal and noise fluctuates.

I have several locations that will not even connect with 1.3.7 but work perfectly with 1.3.6. Others have up to 10dB difference in signal between versions.

Like I said, nothing is changing but the version.

[RebCom]

Those of you with signal decay issues, I'm not clear on if you are seeing xmit or rx values decay (or both).
I'm having an issue on one of our WRAP 2.4G AP's recently upgraded to v1.3.6 (from v1.3.0). Receive indication will decay 10db over a short time across the board. If a small change is made on the AP and activated, displayed receive strength will jump back to normal. A few clients that used to work fine now have very poor quality uplink. Downlink is fine. The worst client has an uplink failed packet rate of 90+% and negotiates down to 1Mbps on a signal of -70db, yet downlink is <2% failed. This client has excellent LOS, no obstructions @ less than 2 miles in a rural (quiet) environment. I've swapped client radio to rule that out -- no difference.

[i20access]

I believe there are some underlying OLSR issues with this release. Last week I upgraded this to this release and after modifiying the configuration file to closely replicate tog's suggested config in the StarOS Wiki, I managed to get the network to hobble together. I then started to experience issues with the LinkQuality extensions, so I disabled them all together. This crippled my network entirely -- nodes could not see each other and routes were not propagating. I downgraded to 1.3.5 using the same configuration file on each tower, and like magic the nodes and routes all started working again. Tony, could you please check into this for me? I will be happy to post my configuration file or even give you a login. Please PM me for more info if necessary. I need to get this issue resolved or I can not upgrade my OLSR backbone past 1.3.6. Thank you.

[David L. Vrablic]

Mark,
I am just a tad con-fugelated here.
Did you say when you go back to 1.3.5 the OLSR starts working?
and When you go to 1.3.6 there is trouble or was that when you went to 1.3.7 you started having the trouble?

I am at 1.3.6 and some strangeness just started.
I need to know what way to jump.

[tony]

1.3.7 has the new, and vastly improved OLSR, though you may need to review your configuration if you customized it a lot. 1.3.0 - 1.3.6 all share the same OLSR version.

[David L. Vrablic]

HI TONY!
Welcome back.
Are you a tellen me that I oughter bump everything up to the 1.3.7?
It's a little scarey with the signal problems reports.
I am feeling a little stress here and I don't know which way to turn fer sure.

[tony]

The new release is vastly improved over the previous. The best thing you can do is upgrade a system or two and make sure OLSR does it's job properly.

[tog]

If you disable the LQ extensions on only one host, the rest of the OLSR hosts will not understand that one.

LQ on or off must be the same on all of your OLSR hosts.

[lonnie]

We use 1.3.7 if that tells you anything.

[i20access]

If you disable the LQ extensions on only one host, the rest of the OLSR hosts will not understand that one.

LQ on or off must be the same on all of your OLSR hosts.

LQ off on all my hosts with 1.3.7 is what caused problems for me.

[David L. Vrablic]

Thanks for the replies guys,

I now have a direction to tromp to....
1. Review the current OLSR script.
Make sure LQ is set correctly.
2. Upgrade everything up to 1.3.7
Sit back and see what happens.

[pti-andy]

Those of you with signal decay issues, I'm not clear on if you are seeing xmit or rx values decay (or both).
I'm having an issue on one of our WRAP 2.4G AP's recently upgraded to v1.3.6 (from v1.3.0). Receive indication will decay 10db over a short time across the board. If a small change is made on the AP and activated, displayed receive strength will jump back to normal. A few clients that used to work fine now have very poor quality uplink. Downlink is fine. The worst client has an uplink failed packet rate of 90+% and negotiates down to 1Mbps on a signal of -70db, yet downlink is <2% failed. This client has excellent LOS, no obstructions @ less than 2 miles in a rural (quiet) environment. I've swapped client radio to rule that out -- no difference.


From what I can gather from your situation it looks the same as what I'm seeing. To confirm, the signal decay is at the client end. The RX signal strength and Q% on the client radio will drop over time and disconnect in many cases. The RX strength at the AP does not change. I have confirmed this happening with 1.3.6 and 1.3.7 but only with 900Mhz cards.

The effect of this is a degradation of bandwidth in both directions as well as extreme packet loss. Doing an "Active changes" after making a radio parm change (just type in the same value, don't really change anything) brings it back every time. It also helps quite a bit if you set up a ping watchdog and have it ping the AP every 5 or 10 secs. - 30 secs is too long. This has the effect of preventing the signal decay in most cases.

[SteveA]

Re: "900 MHz signal drop over time" discussion

I'm using the SR9 in a P2P mode with a fairly steady 4 to 10 Mbps of traffic. The TX strength is always manually set, and the antenna is correctly selected. Current signal strength is -68dB. I've found that with V1.3.0+ on either end of the link eventually the signal starts the decay. There is a clear drop as reported by cacti, and the link starts dropping.

It happens on either device, client or AP. activating changes and reboots sometimes reset it completely, sometime reset if for a few minutes. The only thing that appears to really fix it is to change the war to V1.1.14 on both sides of the link.

I see similar issues on my 5.8 GHz backhauls, so this isn't limited to just 900 MHz.

The signal drop happened again yesterday at 5PM. I played with it for 3 hours, tweaking settings, activating, and/or rebooting. The link would not stay up for more than 5 minutes. I changed both units to 1.1.14 and I'm back to 100%Q and full strength signal.

At this point, 1.3.7 is not suitable for backhaul use for my needs. I cannot spend hours every few nights trying to restore backhauls, eventually having to reboot and break existing connections. When I do this during prime time, I invariably get complaints from users whose VPN gets dropped.

Until VNC addresses this issue, I'll have to start deploying another solution as backhaul. I've had no similar problem to date with any V1.3.x access points running multiple clients.

[DrLove73]

I have both 2,4 and 5,8 P2P links, and never saw this issue. Since April 2006, when I converted my then only 5.8 GHz backhaul from madwifi on regular linux to Star-OS V2, I almost never had no issues with it.

Link quality is always the same, and there was no connection disruption. Link is now on 1.3.7.g.world. It is PC x86 version. Distance is 14 Km, with CM9's and Pac grids 29 dBi. Signal is -69, freq is 5745 MHz, rate is 24 Mbps with jumps to 36 Mbps.

With 1.3.x, I had problems on ~5200 MHz, StarV3 reported radar (DFS), and link was all funny, with 100% CPU usage. After switching to upper band, all is excelent.

[bobbyc]

Only thing I've seen is the client signals (as reported from AP association list) drop when no traffic is going over the link. As soon as the client starts passing traffic (or I ping the client from AP), the reported signal slowly creeps back to normal level.

I think what I'm seeing has been reported by Tony as normal behavior in the 1.3.x series.
Bob C

[DrLove73]

Yes I believe so. My links always pass data, but if no data is passed for a longer time, client will be disconnected I believe, and when client reassociate signal calculation takes some data going through.

[SteveA]

There are many variable unaccounted for that could be contributing... noise level, type of noise, local power, type of traffic being transmitted, quantity of traffic, ethernet circuit, etc.

But,.... with V1.1.14 I have consistent signal levels. Granted, I have to monitor them by hand as the SNMP is not available to produce nice graphs as it is in 1.3.x, so I could miss an occasional change.

Since these are my backhauls, I do monitor them constantly. 1.1.14 to 1.1.14 does not appear to produce the signal change behavior. 1.3.x to 1.3.x produces it with fairly high occurance rate. 1.3.x to 1.1.14 appears to produce it at a lower rate. I do not have an a recorded correlation to the problem being client or AP related. I'll have to watch for that.

Hopefully, the 1.3.9 beta mentioned in other thread may fix this. Until then I cannot leave a 1.3.7 unattended.