StarV3 v1.2.6b build 2363 is ready for testing

[tony]

The BETA has been released, and is available on http://files.star-os.com/

The Status of this BETA is stable, though use with caution and provide as much feedback as possible.

While the change log is not complete at the moment, there are some changes listed on this thread http://forums.star-os.com/showthread.php?t=6714, and previous BETA postings (1.2.1b and newer)

Changes since v1.2.5b build 2361
*) Atheros AP set to '802.11g only' now accepts clients set to 802.11b/g
*) Resolved a hang that can occur when changing from 802.11g only, to 802.11b or 802.11a bands.

There are a few known incompatibilities and/or problems with this releases:
*) "802.11g only", as well as 802.11g cloaking x2 and x4 modes may cause low Q%, and/or low performing links. (fixed in next release)

Some operational differences include (mainly related to regulatory requirements):
*) Atheros channel and country code list no longer contains an 'All Channel' setting (## and #!).
*) U1 country code (US + FCC3) no longer contains the FCC3 channels, however country UZ can be used in it's place for systems that require them.
*) Due to the nature of our unique rate control, the rate specified is now a MAX rate, and not a FIXED rate.

For best operation, please ensure your client and AP use the same country code.

For those wanting to try the live upgrade feature via starutil, simply add the -a (apply) flag to the command line when uploading the firmware.
This requires that your system is using build 2321 or newer, and starutil 1.16.

HotSpot notes:
The HotSpot offered is vastly different from the version offered in V2.

To configure the HotSpot, there is a new 'hotspot' pull-down menu entry. The configuration script should be self explanitory.

The website users log into is now hosted on your own webserver, and not on the StarV3 box itself. We have offered a login webpage template on our files website, though any ChilliSpot login portal will work just as well.

While in the SSH interface, you can press ALT-H to view the on-line hotspot users. If there is a star (*) next to the IP address, that means the user has authenticated. The rest of the screen should be explanatory.

The hotspot user manipulation support via utilistar is also supported.

Sample HotSpot configuration steps:

Remove all IPs from wpci1 (this will be the AP the users log into)
Make sure your DNS server listed in "advanced->dns server list" is valid, as the hotspot service will require it.
Update RIP and OSPF (if used) to only advertise the Ethernet interface, as to not propagate the hotspot's private IP range.
Enter the HotSpot configuration script and enter the following commands:
hotspot enabled
interface wpci1
radius 1.2.3.4 <-- change to your radius server
radius_secret MySecret <-- change
login_server http://my-auth.server.com/ <-- change to the url where you installed the login script.
login_server_secret 5d8cp1fr9ua <-- change to match the one specified in your login script
dhcp_network 192.168.57.0/24
dhcp_dns 1.2.3.4 <-- change to your DNS server
Enter this in your NAT script: masq from 192.168.57.0/24 to dev ether1
Activate Changes, and you are done.If you use the default domain (hotspot.star-os.com), and default IP range of 192.168.57.0/24, then your customers can use the "exit" keyword in the Internet Explorer address bar to go to the logout page, if the popup window is closed. You can setup similar keywords for your own network if you do not use the default settings.


Notes regarding the Login script:

This is the web-based login prompt your HotSpot users will see when they try to access the Internet.

The system requirements needed for the Login script is a webserver and a stock install of PHP. (Perl login scripts are also available).

The only purpose of the login script is to collect a username and password from the user, and forward it back to the V3 hotspot system for authentication and can be hosted anywhere.

[nelson05]

With the improvements/changes to 'g' mode and cloaking listed below and the most recent beta's change to allow 802.11b/g clients to associate to an AP in 'g' only mode, I had a quick couple of questions:

*) "802.11g only" mode no longer offers 802.11b / ERP protection (more robust)
*) "802.11g only" now uses pure OFDM rates. 802.11b CCK rates are now only offered in the 802.11b/g mode.


Are there performance or stability improvements when running an AP in 802.11g only mode in both cloaked and non-cloaked modes? My google searches for ERP protection in this arena didn't turn up much and I am intrigued at the "more robust" part of the release notes.

Also, is there a similar advantage in setting clients (both cloaked and non-cloaked) to 802.11g only mode? Would the best setup for an all v3 network with the new driver be 802.11g only mode on both AP and client?

[soulmata]

Once again I had the problem I had with earlier beta releases.

I update the client, it works OK. I update the AP, upon reboot the connection shows up as "-95 / -95" on the client end and cannot pass data, though it claims it is associated.

Disabling WEP fixes the problem.

This is going from 1.1.13 to 1.2.6b on the AP end

Now, with 1.2.6b on both client and AP, the connection works fine - only with WEP disabled

The instant WEP is turned on, 128bit with matching key, open-system, the connection stops working

This will be a problem since unfortunately 100% of our CPEs connect to our towers by using WEP


Both systems are:

WAR4
CM9
In 802.11g mode
AP at 2462
Client at auto
transmit rate auto (though I have tried 6/6 18/18 24/24/)
link distance 3.00 miles
country code US
TX power def
cloaking 1x

short preamble, super a/g

[tony]

802.11g networks normally spend a lot of time trying to keep legacy 802.11b systems happy (since they do not understand OFDM). This protection generates extra RF traffic, processing and overall performance penalties on the 11g networks.

802.11g only disables this protection, allowing the 802.11g network to run more smoothly seeing as there will be no legacy 802.11b clients on the AP.

For best results, both the AP and Client should be set to 802.11g only.

With the improvements/changes to 'g' mode and cloaking listed below and the most recent beta's change to allow 802.11b/g clients to associate to an AP in 'g' only mode, I had a quick couple of questions:

*) "802.11g only" mode no longer offers 802.11b / ERP protection (more robust)
*) "802.11g only" now uses pure OFDM rates. 802.11b CCK rates are now only offered in the 802.11b/g mode.


Are there performance or stability improvements when running an AP in 802.11g only mode in both cloaked and non-cloaked modes? My google searches for ERP protection in this arena didn't turn up much and I am intrigued at the "more robust" part of the release notes.

Also, is there a similar advantage in setting clients (both cloaked and non-cloaked) to 802.11g only mode? Would the best setup for an all v3 network with the new driver be 802.11g only mode on both AP and client?

[tony]

I've just done some quick tests between a WAR-4 (1.2.6b) and X86-PC (1.2.5b) using 128-bit WEP, and found there to be no issues with either Open System, or Shared Key.

Question: What key number (1..4) are you using on your AP, and Clients?

Once again I had the problem I had with earlier beta releases.

I update the client, it works OK. I update the AP, upon reboot the connection shows up as "-95 / -95" on the client end and cannot pass data, though it claims it is associated.

Disabling WEP fixes the problem.

This is going from 1.1.13 to 1.2.6b on the AP end

Now, with 1.2.6b on both client and AP, the connection works fine - only with WEP disabled

The instant WEP is turned on, 128bit with matching key, open-system, the connection stops working

This will be a problem since unfortunately 100% of our CPEs connect to our towers by using WEP


Both systems are:

WAR4
CM9
In 802.11g mode
AP at 2462
Client at auto
transmit rate auto (though I have tried 6/6 18/18 24/24/)
link distance 3.00 miles
country code US
TX power def
cloaking 1x

short preamble, super a/g

[tog]

Soulmata, can you also quick try 104-bit WEP instead of 128-bit to see if it works?

I've never had such problems and that's the major difference between your settings and mine that springs to mind at the moment.

Tony, a clarification if you please... 802.11g only mode at the AP now will understand an 11b/g client transmitting at 11 but the AP itself will never transmit at 1, 2, 5.5 or 11, right?

[soulmata]

Key #4

I can repeat it easily... turn WEP on... no connection... turn WEP off... hooray data passes.

Revert to 1.1.13 and it works

I will try 104bit and switching keys to check in just a minute

[tony]

Tog, if the AP is set to 802.11g only, and the client is set to 802.11b/g, the negotiated rates will exclude the CCK 1, 2, 5.5, and 11. This said, your client will only transmit in OFDM.

[soulmata]

tony: I selected Key 1 and it worked just fine

I switch back to Key 4... and the connection is dropped.

[tony]

Just for a clarification, when you change the key #, do you change it on both ends, or only on one system?

tony: I selected Key 1 and it worked just fine

I switch back to Key 4... and the connection is dropped.

[tog]

Key #4

I can repeat it easily... turn WEP on... no connection... turn WEP off... hooray data passes.

Revert to 1.1.13 and it works

I will try 104bit and switching keys to check in just a minute

Hm it's also worth mentioning that I've never used anything except key #1.

Perhaps you could try that, as well?

Ok, Tony, thanks. I would assume this would mean if my client were forced tx rate 11, 11g-only mode at the AP would cause that client to not be able to communicate at all then. I will have to be careful to change some of my APs from 11g to 11b/g mode before upgrading.

[soulmata]

I change(d) the key on both ends

[tony]

Tog, You are correct. If your client is forced to a CCK rate, it will not even be able to associate, let alone pass traffic.

soulmata, thanks.

[tog]

I'm betting very few people ever use anything except key #1 so you may have just discovered another issue that can be fixed before going gold with 1.3.0 :)

[soulmata]

Also, out of curiousity: On the AP, the Frequency field has a tilde next to the channel:

"2437`"

Is that an indication of something?

[tony]

Is this the SSH desktop that shows this, or the configuration dialog? If it's the dialog, that would mean somebody added it by accident and can be removed.

[soulmata]

SSH display

But nevermind, it seemed to be the same UTF corruption I get from time to time when logging in to V3. Logging back in made it disappear


Now that I am happy with the link, I will say that performance as usual is outstanding:

rx rate: 7085 KB/sec (Press Ctrl-C to exit)
tx rate: 5679 KB/sec (Press Ctrl-C to exit)


Not bad at all for a 2.4GHz shot in a crowded area over 2 miles using WAR4s

[tog]

My ssh display gets corrupted after rebooting a StarV3 system. I have to go to putty's menu and reset the terminal if I want to connect to another StarOS/StarV3 GUI.

I am ssh'ing from a FreeBSD box to the StarV3 systems instead of directly to the StarV3 systems so my ssh session is not over upon rebooting the StarV3 system.

[tony]

Time for me to take a break. Will be back tomorrow.

Have a good day everybody.

[tog]

Thanks for all your great work on the new StarV3 release and for working with us.

[bobbyc]

After upgrading from 1.1.13, I am seeing slow speeds due to the quality and rate of the client taking a dive shortly after a file transfer. Using the built in speedtest also brings this on. The clients are WAR1, SR9, and x2 cloaking.
The AP is WAR4.
I have also seen it happen on a 802.11g PTP (WAR4's) that is x2 cloaking and rate 18 using WLM54G client and SR2 AP. Signals are -75 on the PTP.

A good example of the connection going bad is this: From my house, I uploaded the .pkg file to this customer WAR1 over the wireless link, and it was blazing fast. After rebooting the WAR1 and AP and testing out this beta, and determining I had to downgrade, the .pkg was uploading fast for about 1/3 of the way thru, and then it went very slow the rest of the way.

The built in speedtests also worked just fine with 1.1.13, but now with this beta they cause the clients with lower signal (although rock solid with 1.1.13) to get poor quality and rate to drop.

I do think it is related to signal, because I have 5 SR9 WAR1 clients, and 3 of them are around -71 signal locked at 18mbps, and two are -76 and locked at 12mbps. The AP is locked at 18mbps. I see this happen to the customers at -76. Their rate will go to 6, and quality all over the place; usually below 50.

These SR9 customers, and my PTP, are rock solid with 1.1.13.

I did try setting the SR9 AP and clients to auto, but didn't help.
Bob C

[billr]

I am seeing the same thing..

AP WAR4 WLM54 to client Wrap CM9

Initially transfer starts at 10 Mbits/s then it drops to 2 or less.
AP locked at 36, client locked at 24, -65 to -70 signal, x2 cloaking, g only.

I can give more detail if required but I noticed this strange drop in speed also.

[therealboss]

I have a WRAP unit for testing with 2 CM9's in it. One CM9 on 2.4 & one CM9 on 5.8. Signal is the same for both 2.4 & 5.8 as it was before upgrade from 2080.

[mimbach]

I setup cacti to graph eth0, wpci0, wpci1, (quality, signal, and noise on wpci0 and 1)
The traffic graphs are working great. The signal, quality, and noise for both wpci0 and 1 only show little bits of data here and there. Ideas?

[knolan]

I've noticed that the new Max transmission speed is causing one of my backhaul links to flick between 12mb and 18mb.


Is there anyway VNC could give guidelines at to what signal strenght we should be running links at for the different speeds.

eg.

802.11a
-83 = 6Mb
-81 = 9Mb
-80 = 12Mb
-75 = 18Mb

etc.


Thanks
Keith

[tog]

It actually depends on the radio card and also the conditions. You could actually have a -70 that only likes 12mbit in one location and a -70 nets you 24 or 36 in another location.

The best answer really is look at the radio card's specs as a general guideline.

[lonnie]

You have missed the point. If you do not want it to flicker, then you set it to the SLOWEST rate that it hits. Then you have no flicker because it will not ramp up. There is no magic and if it cannot use 18 mbps it will go to 12 mbps. The old control would have stayed at 18 mbps and you would have had packet loss.

I've noticed that the new Max transmission speed is causing one of my backhaul links to flick between 12mb and 18mb.


Is there anyway VNC could give guidelines at to what signal strenght we should be running links at for the different speeds.

eg.

802.11a
-83 = 6Mb
-81 = 9Mb
-80 = 12Mb
-75 = 18Mb

etc.


Thanks
Keith

[rbolduc]

After upgrading from 1.1.13, I am seeing slow speeds due to the quality and rate of the client taking a dive shortly after a file transfer. Using the built in speedtest also brings this on. The clients are WAR1, SR9, and x2 cloaking.
The AP is WAR4.
I have also seen it happen on a 802.11g PTP (WAR4's) that is x2 cloaking and rate 18 using WLM54G client and SR2 AP. Signals are -75 on the PTP.

A good example of the connection going bad is this: From my house, I uploaded the .pkg file to this customer WAR1 over the wireless link, and it was blazing fast. After rebooting the WAR1 and AP and testing out this beta, and determining I had to downgrade, the .pkg was uploading fast for about 1/3 of the way thru, and then it went very slow the rest of the way.

The built in speedtests also worked just fine with 1.1.13, but now with this beta they cause the clients with lower signal (although rock solid with 1.1.13) to get poor quality and rate to drop.

I do think it is related to signal, because I have 5 SR9 WAR1 clients, and 3 of them are around -71 signal locked at 18mbps, and two are -76 and locked at 12mbps. The AP is locked at 18mbps. I see this happen to the customers at -76. Their rate will go to 6, and quality all over the place; usually below 50.

These SR9 customers, and my PTP, are rock solid with 1.1.13.

I did try setting the SR9 AP and clients to auto, but didn't help.
Bob C

Same thing I have been seeing for quite a while with the betas, I have 1.2.6b on the AP and I started to upgrade the clients (7 war1's 1 wrap) after 1 War upgrade after the reboot of the client the quality went all over and was not stable I was lucky to be able to upload the old 1.1.3 version but lost the connection so I had to have the client power cycle the unit and it came back 100% quality and working on the 1.1.3 just fine.. I am not sure what changed between the betas and the release version but I just cant seem to get the betas working anywhere as good as the release.. guess thats why it's beta ;)


Reed

[DrLove73]

It was assumed in another thread, on another problem, that problems could have something to do with WLM54G (23dBi ones?). Try with CM9's?

[rbolduc]

It was assumed in another thread, on another problem, that problems could have something to do with WLM54G (23dBi ones?). Try with CM9's?

Have not yet, but all mine are WLM54G's , my backhaul links are cm9's and those I can say work great !

[Stratolinks]

Here is a suggestion that I hope may be something to work into an upcoming release.

How about a configurable idle disconnect time similar to what you had under V2 with Prism. I am finding that the logs get filled with all these disconnect and connect lines for the older stuff that isn't WAR (well actually isn't Star-OS). That will allow us to work at getting all the old users switched to WAR1s as the old equipment they have fails. I can't see how this could hurt the performance of the WAR1 as a client. I always program the ping watchdog on the client WAR1 to keep the connection alive and reboot after 5 minutes of losing touch. Can't do this on the old stuff.

No matter what your decision on this idea is it could not turn me away from Star-OS. The Star-OS V3 AP (on WRAP and WAR) with the WAR1 clients absolutely rocks.

I have confidence the upcoming web interface will be tweaked and tweaked until you are happy with it. At that point I suspect that 90% of us will be happy with it too.

Keep up the incredible work.

[rbolduc]

Have not yet, but all mine are WLM54G's , my backhaul links are cm9's and those I can say work great !


Well back to 1.1.13-2080 on everything and all is rock solid, I had to drive to 5 customers to reload firmware, because after upgrading to beta It would show a connection and good signal but no IP and the ones that were working kept getting page not found, choppy videos, and mail that would not send..


Reed

[mimbach]

Guys we are getting ready to do redundancy with our upstream. So we had to drop olsr and put ospf into use again since we will be interfacing with cisco routers.
I wanted everyone to know that the first set of towers moved over to ospf seems to be working well on the new ospf.

Mimbach

[i20access]

The BETA has been released, and is available on http://files.star-os.com/

The Status of this BETA is stable, though use with caution and provide as much feedback as possible.

While the change log is not complete at the moment, there are some changes listed on this thread http://forums.star-os.com/showthread.php?t=6714, and previous BETA postings (1.2.1b and newer)

Changes since v1.2.5b build 2361
*) Atheros AP set to '802.11g only' now accepts clients set to 802.11b/g
*) Resolved a hang that can occur when changing from 802.11g only, to 802.11b or 802.11a bands.

There are a few known incompatibilities and/or problems with this releases:
*) "802.11g only", as well as 802.11g cloaking x2 and x4 modes may cause low Q%, and/or low performing links. (fixed in next release)

Some operational differences include (mainly related to regulatory requirements):
*) Atheros channel and country code list no longer contains an 'All Channel' setting (## and #!).
*) U1 country code (US + FCC3) no longer contains the FCC3 channels, however country UZ can be used in it's place for systems that require them.
*) Due to the nature of our unique rate control, the rate specified is now a MAX rate, and not a FIXED rate.

For best operation, please ensure your client and AP use the same country code.

For those wanting to try the live upgrade feature via starutil, simply add the -a (apply) flag to the command line when uploading the firmware.
This requires that your system is using build 2321 or newer, and starutil 1.16.

HotSpot notes:
The HotSpot offered is vastly different from the version offered in V2.

To configure the HotSpot, there is a new 'hotspot' pull-down menu entry. The configuration script should be self explanitory.

The website users log into is now hosted on your own webserver, and not on the StarV3 box itself. We have offered a login webpage template on our files website, though any ChilliSpot login portal will work just as well.

While in the SSH interface, you can press ALT-H to view the on-line hotspot users. If there is a star (*) next to the IP address, that means the user has authenticated. The rest of the screen should be explanatory.

The hotspot user manipulation support via utilistar is also supported.

Sample HotSpot configuration steps:

Remove all IPs from wpci1 (this will be the AP the users log into)
Make sure your DNS server listed in "advanced->dns server list" is valid, as the hotspot service will require it.
Update RIP and OSPF (if used) to only advertise the Ethernet interface, as to not propagate the hotspot's private IP range.
Enter the HotSpot configuration script and enter the following commands:
hotspot enabled
interface wpci1
radius 1.2.3.4 <-- change to your radius server
radius_secret MySecret <-- change
login_server http://my-auth.server.com/ <-- change to the url where you installed the login script.
login_server_secret 5d8cp1fr9ua <-- change to match the one specified in your login script
dhcp_network 192.168.57.0/24
dhcp_dns 1.2.3.4 <-- change to your DNS server
Enter this in your NAT script: masq from 192.168.57.0/24 to dev ether1
Activate Changes, and you are done.If you use the default domain (hotspot.star-os.com), and default IP range of 192.168.57.0/24, then your customers can use the "exit" keyword in the Internet Explorer address bar to go to the logout page, if the popup window is closed. You can setup similar keywords for your own network if you do not use the default settings.


Notes regarding the Login script:

This is the web-based login prompt your HotSpot users will see when they try to access the Internet.

The system requirements needed for the Login script is a webserver and a stock install of PHP. (Perl login scripts are also available).

The only purpose of the login script is to collect a username and password from the user, and forward it back to the V3 hotspot system for authentication and can be hosted anywhere.


Any ETA on the new release? I have a bunch of x2 "G" links that are suffering from low preformance.

[lonnie]

Close but not yet ready.

[tog]

Take your time I say :)

[keith.yoder]

I have been having fun with the new SNMP capabilities. Thanks for including them this beta. I am wondering if it would be possible to include the bytes sent and received for each associated client in for a given AP, sort of like you do for signal strength, etc. I think you already keep these statistics because when you double click on a client in the association list, the transfer data is available.

[tony]

Not a problem.

The RX and TX bytes, including the current throughput in bytes/sec are already provided for each association via snmp.

For example, vnAssocRxBytes will be the total RX bytes for that session.

[mimbach]

Tony,
When a link has little traffic we get solid snmp stats for the experimental oids.
When a link has .5+mb we get sparatic data.
In both cases the ethernet, wpci snmp data works great.
Ideas?

[mimbach]

Guys,
When I make changes like add an ip address to an interface and activate changes is ospf set to restart after the ip adress change is applied?
Thanks,

Mimbach

[tony]

The traffic stats are correct, however all stats are collected every 5 seconds.

Yes, OSPF and RIP will restart after an IP settings are changed.

[billr]

Hi all,

Correct me if I'm wrong (happens often....) but this new release is going to be the fabled and eagerly awaited V 1.3 ??
As I have said before, take your time to get it right..

(running on V 1.1.13 build 2080 on WRAP as this gives better performance with a G x2 cloaked link CM9 to WLM54G AP than the beta above. But I can live with this..)

Cheers, Bill.

[tony]

Yes, once this gets out of beta, it will become 1.3.0.

[i20access]

Tony, will the new beta make it out today?? I have having some SERIOUS problems with my "G" links. Phone is ringing off the hook :( Please HELP!


Thanks,

[lonnie]

I'm not sure what part of the world everybody is in, but where we are it is Sunday and every now and then we take Sunday off. The beta will not be released today.

The BEST advice I can give is to step back to 2080 and check back Wednesday.

[Stratolinks]

My question would be:
Why would you roll out a beta in a production environment without being ready to back it down to what was working if there was a problem? You can't really expect it to be fixed on a whim just because you are having trouble. Back things down to what worked and wait for the next update and try again.

[billr]

For heaven's sake, give the guys some rest..

Please take Sat and Sun off....

Then you will write better code on Monday !!
I'm on 2080 and it is fine (ok missing some bits but it WORKS)

OH and BTW in my opinion it is NOT a great idea (as said above) to rely on BETAs in your production environment. We have 2080 on our customer links, and the beta out to me on a test where it doesn't matter and I have other routes into our network anyway....

Cheers, Bill

[tony]

We will have a new BETA out soon, but not before we resolve the last few remaining Atheros issues, which may take a few days.

For those currently having 11G issues, temporarily roll back the system to 2080, and await the new release.

[i20access]

The BETA works for these links, just marginally. 2080 does not work at ALL on these links. I have TRIED rolling back. Thank you for your advise to roll back, but unfortunately that is not an option for me. I simply asked a question, I did NOT need flamed for it. Good day.

[tony]

I am pleased to hear that the new release works (somewhat) where 2080 does not, and hopefully the next release will get it going even better.

[lonnie]

Mark, it was simply the timing of the request. Let me just say that we really want this new release ourselves and that we also run most of our backbone on the new beta.

It has taken longer than anticipated but that is because this new driver is a rewrite and we are finding things that needed a different approach. I figure that in most situations it is already better than the previous driver and I am fairly sure that the next release will make this wait worthwhile.

As I have said a few other times, we are on the job, but we are human. Weekends are never a good time to be frantic and asking for a new release.

The BETA works for these links, just marginally. 2080 does not work at ALL on these links. I have TRIED rolling back. Thank you for your advise to roll back, but unfortunately that is not an option for me. I simply asked a question, I did NOT need flamed for it. Good day.

[rbolduc]

The BETA works for these links, just marginally. 2080 does not work at ALL on these links. I have TRIED rolling back. Thank you for your advise to roll back, but unfortunately that is not an option for me. I simply asked a question, I did NOT need flamed for it. Good day.

I would think there is a bigger problem to be addressed with the links if the 1.1.13-2080 doesn't work and the newest beta works kinda so so..Is this a new link you created just to run the beta? if its a "live" link what did you do a few months back before the beta's started coming out? Where it is a beta I personally don't worry too much about it I just downgrade and try to describe the problems I was having so the guys can take that info and use it if needed.. I don't want to sound harsh but thats what a beta is.. and thats thats why Valemount puts it out so we can find bugs and quirks with it if there are any before releasing it into "release" status..

I feel if you want to leave a bug report on Sunday so be it, hey I work in the off days too sometimes, but I wouldn't expect a reply back..Something about Family's and needing time to relax ;)

And by now you have to understand the timing and Lonnie, I myself probably would have said the same thing, I don't think it was intentional or personal though.

Reed

[sligbot]

Has anyone successfully got the hotspot software working on this release? We've been playing with things this afternoon but the software doesn't seem to want to cooperate. The hotspot word will go from dark to yellow and back after about 30 seconds once we've saved and activated things.
--Rich

[tog]

I have not yet tried it, but what does your hotspot config look like? I am familiar with chillispot by itself which is why I'm bothering to respond and try to help without yet having tried the version of chilli that's in StarV3.

Just the lines that are uncommented please. It actually takes only a very small configuration to do everything you should need to do.

[sligbot]

Ok. Here's my config file:

hotspot enabled
interface wpci1
radius 10.1.4.9
radius_authport 1812
radius_acctport 1813
radius_secret #######
radius_nasid laptop
session_timeout 86400
idle_timeout 3600
login_server http://hotspot.star-os.com/
login_server_secret #######
dhcp_network 192.168.57.0/24
dhcp_dns 216.185.252.130
domain hotspot.gbtel.ca


NAT:
masq from 192.168.57.0/24 to dev ether1

DNS: added valid DNS server and can ping out

IP's: No IP address currently running on WPCI1. Internal 10.x.x.x IP on ether1.

We're using V2 for all of our hotspot solutions. We currently have 8 sites setup with PayPal and they're working well but there are CPU issues with the WRAP boards that we're not pleased with. We'd also like to use the WAR boards because of their increased features. Please let me know if there's any other info that is required to troubleshoot this issue.

--Rich

[tony]

The login server you provided (hotspot.star-os.com) was only an example, and is not actually a real site. You will need to provide a login server (consisting of a web server, and a stock install of PHP) to hand out the login page.

You can download the login page from our downloads site.

[pananix]

Folks,

I have deployed build 2363 on a moderately trafficked part of my network. I have one VDS I that gets some usage (but not much). I just noticed that the VDS is passing small packets, but not passing large packets -- seems to choke.

I tried reducing the MTU to 1400, but it didn't help. Anyone noticed a VDS problem with the new BETA and what the optimum MTU setting might be (or if the problem lies elsewhere)?

Thanx,

David-

[tony]

The optimum MTU setting throughout the network the VDS connects through, is 1500. If there is a system in the middle with a smaller MTU, or has some form of MTU / MSS clamping, then you may find that large packets will not get through.

[pananix]

The optimum MTU setting throughout the network the VDS connects through, is 1500. If there is a system in the middle with a smaller MTU, or has some form of MTU / MSS clamping, then you may find that large packets will not get through.

No such problem. The VDS passes from WRAP board w/ 2363 to a WAR-4 w/2363 to a WRAP w/2080 to a WRAP w/2080 where it terminates. All MTUs are 1500.

Just for grins, I tried from the WRAP w/2363 to the WAR-4 w/2363. Backing the WAR-4 and WRAP down to 2080 and the VDS works. Introducing 2363 as either or both end points, and all but small packets fail to pass.

David-

[tony]

Hmmm... This must be a 'feature'.. Yah, that's what it is. :)

We will look into this. Thank you for pointing it out.

[pananix]

Hmmm... This must be a 'feature'.. Yah, that's what it is. :)

We will look into this. Thank you for pointing it out.

FYI, what I'm using this for is passing IPv6 from a server out to my router. I got some complaints, then noticed that while AAAA lookups worked (small udp packets), web pages would not load or only partially load (the small parts). I may try a smaller MTU for the VDS link and see what happens.

David-

[ccishuntington]

I am just starting to play around with the BETA and wanted to test out the WPA functionality. I would like it to set up as an access point so that I can connect to it from windows. This is what I found in some earlier post from previous betas...


process wpa-master

security enabled
wpa-proto wpa
wpa-mgmt psk
wpa-passphrase "Test_Phrase"
Is there more that I have to add? And is there a way to download these script so that I can review it easer than threw the ssh client?

Thanks
-Ryan

[soulmata]

Is anyone having issues with iptables in 1.2.6b?

Edit: No, just another dropoff.

Every once in a while, the PTP office link I have with these units running 1.2.6b is dropping. The association remains, but it passes no data. Only a reboot cures it.

[therealboss]

Is anyone having issues with iptables in 1.2.6b?

Edit: No, just another dropoff.

Every once in a while, the PTP office link I have with these units running 1.2.6b is dropping. The association remains, but it passes no data. Only a reboot cures it.

I had the same problem and would have to reboot every day, I have taken off the beta for now.

[soulmata]

It isn't happening predictably, but is happening frequently. Sometimes multiple times per day, sometimes only once every other day. But it has been pretty consistent.

[therealboss]

Yes same here, once twice within 45mins and then it ran for 27.5 hours. But once I changed back from the beta the problem went away. I just dont have the time at the moment to test the beta right now so I thought I would wait a few weeks and maybe try out the next beta.

[tog]

I had the same problem and would have to reboot every day, I have taken off the beta for now.

I had the same problem with the beta client I had running at my place. A couple times within 10 days I would be sending 4 or 5mbit towards the AP and my connection would die (still show associated, though) and I'd have to reboot. That connection is using 11a with 2x cloaking.

[therealboss]

I had the same problem with the beta client I had running at my place. A couple times within 10 days I would be sending 4 or 5mbit towards the AP and my connection would die (still show associated, though) and I'd have to reboot. That connection is using 11a with 2x cloaking.


Tog
Same here 11a with 2x cloaking, I'm sure Tony will get it fixed.

[tony]

The upcoming release should resolve many of the remaining issues.

[skyclimber]

I did not see Q% issue with v3 1.13c stable.
Upgrading to V3 1.2.6 (2362) i start to get low Q%, and packet lost. Techs had some issues on install when reading site survey. Sites signal shown were not accurate. While staying in same direction a site appears at -1 dB and after refresh -60dB after other refresh -91dB.

Maybe the issue is already known.

Thanks,

Louis

[lonnie]

Just something to whet your appetite for upcoming release. Real soon now.

This is a WAR4 unit with about 50 customers. The association screen shot is a 900 MHz unit with poor signal but you can see it is quite usable, judging by the throughput test.

The uptime is low because I just updated. This release is HOT off the press.

[rbolduc]

Drool, Drool ;)

[DrLove73]

All good things are worth waiting and longing :D

[pananix]

Just something to whet your appetite for upcoming release. Real soon now.

This is a WAR4 unit with about 50 customers. The association screen shot is a 900 MHz unit with poor signal but you can see it is quite usable, judging by the throughput test.

The uptime is low because I just updated. This release is HOT off the press.


Just put up 1.2.7b on several systems. Appears that the VDS routed from wpci to wpci still has issues (i.e., it doesn't work correctly). Seems to work ethernet to ethernet, though.

[knolan]

Where did you download 1.2.7b? I can't find it on the files web site?


Thanks
Keith

[tony]

The 1.2.7b release is not available yet. We had it posted on our download website in error, for roughly 10 minutes. There are still a few updates needing to be implemented before it'll go public.

The release that did sneak out is safe, but be prepared to update to the new release once it's available.

[DrLove73]

The 1.2.7b release is not available yet. We had it posted on our download website in error, for roughly 10 minutes. There are still a few updates needing to be implemented before it'll go public.


Please clarrify. Implementation means just compiling and will be done in next 24h, or you still have to complete/finish some parts/issues, and will pass more than 24h until release?

[Beebe]

Can't wait :)

[tony]

There are a few issues that still need some attention before we can release. The release will be available no less than 12h from now.

[rbolduc]

The 1.2.7b release is not available yet. We had it posted on our download website in error, for roughly 10 minutes. There are still a few updates needing to be implemented before it'll go public.

The release that did sneak out is safe, but be prepared to update to the new release once it's available.


LOL its a YSYL BETA download.. ;)

[tony]

Yep, that's exactly what it was. :)

The proper 1.2.7b release will have several additional fixes including the VDS issue some of you have experienced.

It should be ready for release tomorrow mid-day.

[pananix]

Yep, that's exactly what it was. :)

The proper 1.2.7b release will have several additional fixes including the VDS issue some of you have experienced.

It should be ready for release tomorrow mid-day.

Big NOTE: 1.2.7b -- of the 6 systems I upgraded, two reset completely to factory (192.168.1.1 and admin/1234). I was using the ./starutil IP pass -a -f vnc-<blah_.pkg> syntax then sending a starutil -reboot.

These two systems had not done that in the past using this same procedure.

Might want to look at that.

Ciao-

[tony]

What platform?

[pananix]

What platform?

Sorry. These were two WRAP boxes (forgot that minor point). I have no idea how big the flash is, could be only 16M (I do have a couple that size still deployed). But I suspect following the upgrade if I just performed the reboot from the system and told it to save the config I would have been OK. But I'm lazy and like shortcuts ;-).

[tony]

Thanks. What release did you upgrade from?

[pananix]

Thanks. What release did you upgrade from?

From 1.2.6b (build 2363) using starutil v16 on Linux (if it makes a difference).

[tony]

Thanks

[DLNoah]

Had 1.2.6b on a PtMP link, one of the clients is a WRAP board that was running V3 1.1.13. The client is set up to bridge ether1 to the radio card, would associate on the tower with a signal of -55, and the ether1 interface would ping through, but the internal router could not successfully request an IP address from our DHCP server. Tried upgrading the client board to 1.2.6b, did not resolve the issue, downgraded the AP to 1.1.13 and the client was able to pull an address. I have not tested and cannot test at this time 1.2.8b or various combinations thereof; I'll try to do it on Saturday.

[tony]

"but the internal router could not ..."

What, and where is this internal router?

[DLNoah]

Internal router is a Linksys wireless router, cable run from the WAN port on the router via the PoE to the WRAP board that is the client device.

[tony]

Does the DHCP server reside on the AP itself? (I'm assuming so). Is you AP bridged, or routed? I know you would have the AP card bridged for WDS with 1.1.13.

When you get around to upgrading to 1.2.8b, make sure you disable bridging on the AP card as it is no longer needed for WDS to function.

[DLNoah]

Sent you a PM with as many details as I can provide.

[tony]

Much appreciated, thank you.