PDA

View Full Version : StarV3 v1.2.5b build 2361 is ready for testing


tony
07-01-2007, 09:39 AM
The BETA has been released, and is available on http://files.star-os.com/


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)

Please do not upgrade your system unless you have access to it via the ethernet, in case you need to downgrade.

Please post your results as there are bound to be a few issues left to iron out before we remove the BETA status.

Changes since v1.2.4b build 2358
*) OSLR now works as expected, and will no longer randomly quit.
*) OLSR is restarted during an activate changes once again.
*) IE country code now supports channels up to 5875 MHz.

There are a few known incompatibilities and/or problems with this releases:
*) Switching from 802.11g only to 11a, or 11b may cause the system to hang, and eventually reboot via watchdog. (resolved in the upcoming 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.

tog
07-01-2007, 02:02 PM
olsrd 0.5.0 is working for me now in this build!

therealboss
07-01-2007, 02:11 PM
Found a small problem I think.
I installed 2361 over 2080 on a WRAP and rebooted, the WRAP would not connect to the AP even after "activate changes", done 3 times and waited 10mins to see if it came back up. I rebooted the WRAP and the link came up again. To test it again I changed the SSID on the AP and the WRAP lost connection, I changed the essid on the WRAP to the same as the AP and still no connection, rebooted the WRAP and bingo! It connected again.

Hope this helps..

tony
07-01-2007, 02:16 PM
What Atheros settings are you using on the WRAP and AP?

therealboss
07-01-2007, 02:54 PM
Both radios are CM9's
Setting are the same for both the AP & the CPE, contry code same on both.

Settings are:-

No WEP
Mode = a
Cloaking = x2
Super A/G = yes
Short Preamble = yes
Hide SSID = yes ( but when I turned it off on the AP, the CPE still said hidden under a site survey).
TX Power = 18
InterBSS = off

If I ran a site survey, I could see the AP, but it would not connect. I thought that I it was due to the fact that the AP was on a channel that the CPE used dfs, but I changed country code and also changed channel to a none dfs channel but same problem.

lonnie
07-01-2007, 03:29 PM
Did you have auto for rate? How about mode? Are you G or B/G? The should both match.

tony
07-01-2007, 04:40 PM
Two more pieces of information will help:

1. What is the country code you are using (IE ?)
2. What is the software version used on your AP? I know the WRAP (CPE) is using the new version.

therealboss
07-01-2007, 05:47 PM
Rate = auto, but I also used 12, 18 & 24 but had the same problem.

Country code = IE but I could not get it to connect, changed to UK and it connected only after a reboot.

AP Running 2080, AP is a WAR4

tony
07-01-2007, 06:05 PM
Ok. The problem is that you are using hidden ssid on a passive-based channel (required for DFS networks). What is happening is the 2080 AP is not actually using passive mode for IE, but the client is expecting it (will work once the AP is upgraded when you get around to it). What you can do in the meantime is move the AP to a channel that is not marked with a '*'.

Since 2080 does not show '*' for passive channels, you may need to refer to the CPE for channel choices.

Once you do this, you should be good to go.

i20access
07-01-2007, 09:10 PM
Did pseudo bridging make it into this release?

tony
07-01-2007, 09:19 PM
No, it is not currently available on the WAR-1 release due to space constraints. Once we implement the new Web interface, that will allow us to add some last remaining items, such as Pseudo bridging.

mimbach
07-01-2007, 10:24 PM
All seems to be well with 1.2.5b. Olsr seems to be working well. If it goes well tonight and through the day tomorrow on our northern section of the network we will try a more widespread deployment tomorrow night. I will post another post in the next day or two with another update.

Mimbach

tony
07-01-2007, 11:16 PM
Sounds good. There will be a new release tomorrow morning that will resolve some of the last remaining issues, and all should be good.

knolan
07-02-2007, 02:21 AM
Advise for people in Ireland upgrading to this version. (Could also be an issue with anyone else using the DFS frequencies)


Ok. The problem is that you are using hidden ssid on a passive-based channel (required for DFS networks). What is happening is the 2080 AP is not actually using passive mode for IE, but the client is expecting it (will work once the AP is upgraded when you get around to it). What you can do in the meantime is move the AP to a channel that is not marked with a '*'.

Since 2080 does not show '*' for passive channels, you may need to refer to the CPE for channel choices.

Once you do this, you should be good to go.


If you upgrade one side of a link to v1.25b and the link was using a DFS frequency the link will not come back up. in order to upgrade these links upgrade the far end first.


Regards,
Keith

knolan
07-02-2007, 04:12 AM
With the new beta the signal strenght seems to have a problem. Below are screen shots from before and after the upgrade.

The hardware involved is;

Wrap 1e
WLM54 AG23 Radios

The settings in use didn't change


Channel = 5805
Transmit Rate = 6
Link Distance = 30.00
Country Code = US
Power Override = def
Cloaking = 2X

InterBSS Relay = ON
Short Preamble = ON
SuperA/G = ON
AP Power Saving = ON

Operating Mode = 802.11a

Regards,
Keith

http://www.corkcommunitybroadband.ie/images/v1.1.13.png
http://www.corkcommunitybroadband.ie/images/v1.2.5b.png

eoinok
07-02-2007, 05:01 AM
I will also add to this that a site survey from the cpe before and after the upgrade/downgrade reported the same sig stenght. As in it was reporting -75 before and afterwards.
We have another WRAP running the same version and exactly the same settings incl the exact same frequency, and we have no issue like this.
The difference is, on the one we have an issue with is running WLM54 cards, and the one we dont is running CM9's.

So I would maybe suggest it could be a driver thingy or something to do with the WLM54 AG23 cards.

Lonnie, Tony, if you do wish to have a poke around, I can provide you with the public IP to the AP and you can upgrade/downgrade the AP at will as it is still a test site for us.

rkreigh
07-02-2007, 07:47 AM
I can't seem to get the hotspot service to light-up, I followed the directions that tony posted.

XSCALE-WAR Edition 1.2.5b (build 2361) on a WAR 2 with CM9

Thanks,
-Russ

tony
07-02-2007, 10:15 AM
Did you activate changes after you configured your hotspot?

If you can PM me the hotspot configuration you used, that would be a great help.

tony
07-02-2007, 10:21 AM
Also, for those using the WLM54AG-23 cards, try setting the transmit power to 23, and not def and see if your signal improves.

knolan
07-02-2007, 10:35 AM
Also, for those using the WLM54AG-23 cards, try setting the transmit power to 23, and not def and see if your signal improves.

I have set the transmit power to 23 and it made no difference, I also set the country code to IE, again no difference. I've upgraded and downgraded the board a few times and everytime the result is the same, with v1.1.13 the signal is a lot better than with v1.2.5b, however on the CPE's if a I do a site Survey I see the original signal level reported.

The quality of the link doesn't seem to be impacted, as the throughput seems to be the same.

Maybe the problem is just a reporting issue? or could we have a hardware issue that only shows itself with the new version.

Thanks
Keith

tony
07-02-2007, 10:37 AM
The signal levels are averaged, and will take some traffic for the values to settle.

Also, ensure you have your antenna settings correct, as this can cause issues as well. The settings are the same as 2080, though the new support is much more strict and will ignore all traffic it hears coming from the other port, if you accidentally configured it wrong.