View Full Version : StarV3 WAR Edition v1.0.0 build 1090 has been released.
The new release can be downloaded from the http://www.star-os.com/starv3 downloads page.
Work on the StarV3 x86 WRAP Edition has begun.
Finally. :)
When should we expect radius authetication and pppoe server?
--
Konstantin
lonnie
05-17-2006, 04:42 PM
We are now in the final stages for the x86 V3 release. All attention is now on porting the driver from xscale, so I will ask for patience.
Actually there is no other choise than wish you bug-free code. :)
The beta tag is gone! Congratulations, v3 having reached its current state I feel is even better news than the initial release of v3 was.
v3 for x86 will be great, it will be nice to convert some of my APs to cloaking by installing v3 on the CPE WRAPs.
Things are moving along well, v3 for x86 and that cheap CPE solution that's coming and we are set for a while.
It's been a lengthy ride, but well worth it. Things will only improve from this point onward.
Oh, crap, I forgot:
"How's QoS coming?" :)
lol, it's almost complete. :)
Can we still upgrade this ver using Utilistar? Instructions say to use starutil - is this a change or perhaps I've neglected reading the instructions afore?
Utilistar is starutil compatible, and works with the WAR platform for auto-login, firmware upload, and configuration backup / restore.
Congratulations, well done on v1.0.0
FWIW, I upgraded 7 live Wars last night. 6 went perfectly. #7 locked up on reboot and required a personal visit around 2am, main wireless router for our system. Couldn't ping from the ethernet link when I got to the shop. Cycled power and it came up fine.
Which version were you upgrading from?
Beta-18 on all of them. Culprit has three radios and is the main link to 3 backbones located in my server room. I waited until very late to flash, this was the one that locked up months ago when upgrading from an earlier beta. You said there was a bug and it was related to load. The flash went fine but not the reboot. Actually, I'm not sure if it's the exact same unit as before but it's in the same location. Not a big deal, I would be a bit more upset if it was either of the two mountain tower locations. I've been to one in the middle of the night more than once but the other one is terrible access on the best of days. The techs love getting to it, they get to pull out the 4wheelers but it's still a rough ride even on those.
I am pleased to hear it wasn't a mountain repeater. We have many of those ourselves, and it's a pain having to pull a 4am quad trip to replace a system.
I'm glad your system is back up and running.
Not even counting any bench test boards, I've flashed 8 live production boards about... 10 times each over the last 60 days. That has never happened to me.
It sounds like that particular WAR4 might be a little bit cranky. If it were me, I'd probably replace it. If it is not replaced it is at least already in the best location it could be in for you. :)
It sucks to do so for such a minor issue, but it is an issue nonetheless and it would make me uncomfortable to leave it in production doing an important job.
If nothing else you could maybe use it at a customer premise or some other less important job.
nickwhite
05-18-2006, 02:05 PM
Hey guys. I think I may have found a possible bug - looks like cosmetic only, or maybe related to bridging, although I was bridging prior to this. I have 3 WAR4 boards that I've upgraded to the new v1.0.0 1090. Since doing so, the "rx" column in Beacon shows 0 for all data streams, although the "tx" shows actual data. This is on all active interfaces on these boards. All interfaces are bridged. Two of the boards are our main backbone link, and are bridged (ether1 bridged to wpci1). The other is an AP and the wpci1 is bridged to vds1 (in order to manage customer equipment). The backbone pair is running CM9s, the AP is running two SR2's, one is disabled. Like I said, I think it's only cosmetic, as I haven't had any customer complaints, and I see "tx" data streams.
-Nick
Yes, I see what you mean. This only happens on bridged interfaces, and will be resolved in the next release. This only effects beacon's ability to report 'tx' data, and is cosmetic only.
Thank you for pointing it out.
We run a fully routed network with all of the masq commands in our Staros V2 core router.
We tried to configure a War4 with Version 1, and cannot pass data from Wpci1 to Wpci2 without a masq statement. We don't have any masq statements in any of our WRAP boards. We know we are on the net via wpci2 because the time was set and we can ping from the WAR out to the net.
We are pretty sure that we had this working on the Beta release 16?
There are no routing issues with the latest release of star-v3. Can you provide me with some details regarding your WAR setup? (via PM or email)
Please include:
IPs and bridge-group on each interface.
Any vlan or vds tunnels you have
your static routing table, and whether you are using policy routing, rip or ospf.
Thanks!
lonnie
05-19-2006, 12:00 PM
If you wish I will login and see what is happening. Please send me the IP and password.
The problem has been resolved via PM.
Thanks!
I've got a 533mhz War with 3 CM9's in it. It is my main unit that connects 3 different 5.x segments out to customers. I run static routes and it doesn't have any FW, CBQ or NAT scripts running. I tried to take as much load off of this as I can think of. I turned off connection tracking. The only things enbled on this, outside the ordinary, are policy routing and 4x cloaking on two segments. Ping times from outside are very stable, almost always in single digits to this unit where they jump up significantly, usually 30-50 ms but spike up higher at times. Does cloaking and/or policy routing use much in the way of resources? I'm going to try moving one segment off to a 2 port war by itself to see if that gets rid of the latency. I'm moving 5-6 MB over these connections. The system load average shows .09 .05 .01
There should be minimal (if any) performance impact with policy routing. Cloaking is normally quite reliable, with low latency.
On occasion, the client-mode cards will do a periodic survey scan, which can cause the latency to spike to 30-100ms for a second or two, which is normal.
I noticed it had a 15v ps and changed it to an 18 yesterday. It is purring along fine now, 12+ hours in the green using pingplotter.
mrmike
06-10-2006, 12:08 PM
Do I have to go to Ver 1.0.1 to get rid of the N association problem? It is still occuring in ver 1.0.0
It is normal to get 'N' entries, and does not represent an issue with the AP. It may be an idea to upgrade, however v1.0.0 should be Ok. Make sure your WAR clients are all up to date, especially if they are still running beta releases.
mrmike
06-10-2006, 09:17 PM
The N associations are coming from the few D-Link bridges I have. I can't quite afford to replace everything yet.
mrmike
06-11-2006, 08:34 PM
I have the 810+ DLinks. The other problem is the HighGain 2400's.
I don't know about 810+, I do use G810. They have a firmware v2.20 update that actually helps, though I have had it break the ability to DHCP for some. It's oddness but what the hell, I expect some oddness on those cheap bridges.
It is normal to first see an association from the default MAC of the unit and then an association from the MAC address it cloned from the device attached to its ethernet port. 5 minutes later the default MAC of the actual G810 will go to N and eventually go away. This is normal.