v3 update

[lonnie]

v3 is progressing rather nicely, albeit with a major direction change. We have abandoned the FreeBSD system. We have chosen to stay with Linux so that we can port to other processors, and FreeBSD does not have a very wide supported architecture. It is still me choice of OS, but that is like a religion, so we will not discuss that aspect.

We can expect the first releases of v3 in about 4 to 6 weeks. The first release will look very similar to the old v2 system, and in fact it will be quite similar, except for a major structure change.

There will be a shell with full access to command line tools and scripting and we are keeping the SSH interface. There is a web interface being worked on and we might also bring in the GUI from the StarVx system.

This first release will have a new Atheros driver but will retain the Orinoco and Prism drivers. The new Atheros will initially add DFS and a few tweaks but will not yet have the multiple ESSID or other advanced features. We will need to have the driver base proved out before we started bolting on shiny chrome features.

The bad news is it will be an upgrade and we might not be able to save settings, so that it might not be a seamless upgrade. It also will not be a free upgrade.

[funkywizard]

im glad to hear work is progressing. it really sounds like your old platform was limiting your ability to develop new features and performance, and with the amount of work needed to start completely over, I don't mind that this upgrade will not be free.

[knolan]

Any idea how much you will be looking for an upgrade license? & how much for a new license?

[lonnie]

Please see the other Thread that I started under this new v3 Forum.

Any idea how much you will be looking for an upgrade license? & how much for a new license?

[luka]

Regarding DFS: please put some possibility to define country standard. Ie, my country, which is in Europe, doesnt regulate spectrum like EU states. We have 2.4-2.5 and 5.7-5.8 only. Possible problem: choosing ETSI or FCC may produce problems to us as radio will be choosing frequencies which are not in unlicensed range and supposely not much supported by antennas.

CPE: it would be nice if there would be some cpe only, streched version. For instance, there are wraps with 32 MB ram. Putting cpe version there will cut down cpe costs and thus help to all sides. Also, regarding cpe there will be useful option if you could incorporate in web interface option with limited access, ie to give users possibility to administer "their" side of connection, like internal dhcp, ports, qos and similar, but not to be able to mess up things related with connection to isp, authorisation/authentication and so. It would be also fine to have some oem type and i18n options so that isps can put customised web pages with their logos, comments, translated to local language etc.

Next suggestion, maybe it is the time for you to consider other radios as well. Ralink is becoming popular, their radios are cheap and working fine. They are supporting opensource community and newer products have introduced many advanced features. Realtek chipsets are also ok.

[lonnie]

When we looked at Ralink there was no source code. They had a closed binary and an open source interface.

Same with Realtek --> no source for the main driver, just the interface.

What is the going rate for those radios?

[nelson05]

I'd rather have you continue your strong work with Atheros. You seem to have a great deal of control over what you can do with their hardware (Cloaking!) and they are such a large player in the industry, consistently releasing new products that offer greater performance, more features, less power consumption, etc.

Adding more wireless hardware support would likely distract you from your efforts to build the featureset, performance, and reliability of V3, with little benefit other than marginally less money in hardware costs. We could see similar issues to the Orinoco, Prism, and Atheros cards in V2 where some features were available with one wireless chipset, but not the other or were configured in StarOS using very different interfaces. Of course I may be biased as we standardized on Atheros from the beginning. I do know that some locales do not have ready access to Atheros based products, however, I would like to see V3 get established before effort moves to additional hardware support.

[rasimoes]

Lonnie, just a little question:

The TX Power Control present in VNC's Atheros support can be considered the TPC feature, required by some federal regulatory agencies?

If isn't, TPC is present in StarVx?

Regards,

Rodrigo

[tony]

StarOS has TPC, but no radar (DFS) support yet. StarVX has both DFS and TPC support.

[rasimoes]

Thanks Tony!

Well, V3 when released will support the both features...right?

Regards,

Rodrigo

[tony]

Yes, we expect the initial release of v3 to have DFS and TPC.

[rasimoes]

OK, thanks again!

[phendry]

As your sticking with Linux does it mean the upgrade may be able to be done remotely and not involve me having to climb? The easier it is to upgrade the more chance there is that I will and therefore more upgrade fees coming your way ;)

[lonnie]

Paul, please re-read my very first posting in this thread. We cannot promise, but we will try. Sorry, but that is the best we can do.

[szern]

Gee.. back after being gone for 2 weeks and loads of great news and information.
Yay! V3 is on the way :)

A small plea... I've been waiting for WDS (Transparent Bridging) capability on Atheros for ages..
Please pretty please... try to have it in early...

Throw in multiple wan capability and it'll be like Christmas coming early!

My eternal gratitude and the upgrade fee is yours! :P

- Szern

[Skaught]

StarOS has TPC, but no radar (DFS) support yet. StarVX has both DFS and TPC support.

What exactly does DFS and TPC do for me?

I know what it stands for but that does not tell me much.

[lonnie]

It gives you some nice letters to Google.

DFS avoids radar in the middle of the 5 GHz band. TPC allows you to adjust the power to take into account your antenna gain, thus keeping EIRP within limits for your country.

[Steve]

Will there be any updates to CBQ'ing (maybe QOS) in the initial release of V3. If so, what's new? If not, will there be? I have another OS running on one main router for no other reason than the Queuing and QOS and I absolutely hate it. I'm contemplating an OpenBSD/pf/altq solution just to get rid of it but I'd really like to switch it back to Star-OS. Sorry if this was covered in another thread somewhere.

Glad to hear V3 is coming.

[Steve]

Never mind, answered my own question. Search first, ask second.

This is something we are looking into, however all we can promise at this time is that CBQ will be available, with possibilities to extend it's capabilities in subsequent updates.

[robok]

StarOS has TPC, but no radar (DFS) support yet. StarVX has both DFS and TPC support.

How can I know if DFS is in my StarOS box enabled and works?
Thanx.

[lonnie]

As Tony said the DFS is not in StarOS. In StarVx it is automatic based on the country code and the channel. You cannot over ride it.

How can I know if DFS is in my StarOS box enabled and works?
Thanx.

[robok]

As Tony said the DFS is not in StarOS. In StarVx it is automatic based on the country code and the channel. You cannot over ride it.
I am too sorry, that was wrong question. My right question is:
How can I know if TPC is in my StarOS box enabled and works? /As Tony wrote
"StarOS has TPC, but no radar (DFS) support yet...."/ Because If i have an Atheros card, in item TX Power Ovveride I can`t add word "auto".
??
Thank you.

[lonnie]

TPC is not automatic. It means Transmit Power Control and is so that you can adjust the output power to compensate for the antenna gain.

0 is default, and that is the output that would be the absolute maximum for your country, based on the country code, and tests for noise. The sideband noise is part of the measurement for each country, and the default makes sure that all of the factors are acceptable.

Our TPC goes from 1 dB to 30 dB, where 20 as the practical top limit since the cards cannot go any higher than that. If you do set it higher you are are messing up spectrum on each side of the channel due to your increased noise. Ignore advice to set it to 30 for better results. This is just plain wrong and if you have access to a spectrum analyzer you will see for yourself.

[robok]

Yes, we expect the initial release of v3 to have DFS and TPC.
Great, full working DFS and TPC are very expected features in StarOS.
Thanx.

[robok]

TPC is not automatic. It means Transmit Power Control and is so that you can adjust the output power to compensate for the antenna gain.

0 is default, and that is the output that would be the absolute maximum for your country, based on the country code, and tests for noise. The sideband noise is part of the measurement for each country, and the default makes sure that all of the factors are acceptable.

Our TPC goes from 1 dB to 30 dB, where 20 as the practical top limit since the cards cannot go any higher than that. If you do set it higher you are are messing up spectrum on each side of the channel due to your increased noise. Ignore advice to set it to 30 for better results. This is just plain wrong and if you have access to a spectrum analyzer you will see for yourself.
This is bad idea. Because our regulatory require fully automatic regulation of transmitted power. So the TPC have to be AUTOMATICALLY !, only then it will be valid in according to decree ETSI.

[lonnie]

How can it be fully automatic? Are you saying the radio should somehow sense the gain of the antenna and adjust its power to match? That is not science, that is magic.

[mp3turbo]

:)

robok, TPC is used for "staying in legal limits" what basically means that total radiated power (which is radio output + antenna gain) will be what it should be. Let me show you example:

legal 2.4GHz allowed output power : 20dBm, 100mW

you have 18dB antenna, WITHOUT TPC your radio card outputs let's say 15dB. Total : 33dBm less some loss on pigtail, connectors, cable. This config is totally out of limits.

the same situation, WITH TPC : you set that you have 18dB antenna and system should automatically set radio output to 3-4dB meaning that your total radiated output will be what it is supposed to be = around 20dB.


TPC is not automatic and it can't be. The system has no way how to find out what antenna you use, when you changed it etc.

[robok]

Thank you very much guys for clear explanation.
And when approximately come out the first relese V3 of StarOs?

[luka]

No rush, but would like to see more shaping options in V3, like pcq and htb things.

[oscarBravo]

At the risk of being a PITA, my pet hobbyhorse gets trotted out: what version of the advanced routing daemons will you be incorporating into v3? Quagga 0.98.5 was a huge improvement over the previous Zebra version, but there has been much active development into 0.99 since then. We're running a recent CVS snapshot on our Internet gateway, and it's extremely well-behaved.

[bradg]

At the risk of being a PITA, my pet hobbyhorse gets trotted out: what version of the advanced routing daemons will you be incorporating into v3? Quagga 0.98.5 was a huge improvement over the previous Zebra version, but there has been much active development into 0.99 since then. We're running a recent CVS snapshot on our Internet gateway, and it's extremely well-behaved.

Funny, I was going to ask the same thing this evening. The version of Quagga in v2.10 was much more than a huge improvement over the previous release with Zebra (it actually *worked*). But as pointed out, there has been a lot of ongoing development in Quagga since (and a lot of it has touched OSPF), so I think it's worth looking at. I still occasionally see some odd adjacancy changes that I can't explain fully, but it could be a link issue too, I'm just not 100% sure right now. And, from the 0.99.2 changelog, I think the whole "gettimeofday" issue with timestamps and NTP may now be resolved too :) Possibly the end of the "temporary network outage at 60 minutes of uptime" when NTP sync's up?

As long as we're talking about versions, what version of ISC DHCP might we find in the first release of v3?

The local DHCP server works fine in any case we've tried it, but right now, DHCP relaying is broken in a couple ways. The DHCP relay service sees the request, forwards it, receives an answer, but the reply is somehow malformed (actually, I believe it is sent to the wrong MAC address - the MAC of the requesting device and not to the MAC of the CPE) making use with simple proxy-ARP client bridges (and the device that sits behind it) a total no-go.

That was reportedly addressed in ISC DHCP v3.03 (I think - from memory, don't quote me on it), so I'd really like to see that addressed as well so I can finally centrally manage the last bits of the "legacy network" my sister company has.


Brad

[bminish]

TPC is not automatic. It means Transmit Power Control and is so that you can adjust the output power to compensate for the antenna gain.

The ETSI implementation of TPC is supposed to incorporate a dynamic (automatic) element. the way this is to work is as follows. On a link with a SNR better than necessary to maintain a given link speed the radios at each end are supposed to automatically reduce power to maintain the required SNR for that link to operate. This dynamic power control mechanism must be capable of providing at least 3dB of power reduction.

This type of dynamic power control is quite common on licensed link kit. I have a licenced 13 Ghz link that reduces power once a threshold SNR is reached and alters power levels at each end automatically to maintain that SNR, I.e the power will go up if there is some link fade

The ability to manually set power levels is not the same thing and is not in it's self enough to be fully compliant with ETSI requirements.

.Brendan

[lonnie]

I already told, in your private emails that we would be looking at the 99.x series. Whatever is the latest when we do the update.

At the risk of being a PITA, my pet hobbyhorse gets trotted out: what version of the advanced routing daemons will you be incorporating into v3? Quagga 0.98.5 was a huge improvement over the previous Zebra version, but there has been much active development into 0.99 since then. We're running a recent CVS snapshot on our Internet gateway, and it's extremely well-behaved.

[lonnie]

How can DHCP know the MAC of the CPE if the request comes from the proxy arp device? It gets a request from a MAC and it responds. The proxy arp device is the one that needs to have the DHCP relay because by the time it gets to the AP it is already mashed.

We have not decided if we will use ISC DHCP yet. It is very big and we want to be reducing the image size.

The quagga will be the latest when the release is made.

Funny, I was going to ask the same thing this evening. The version of Quagga in v2.10 was much more than a huge improvement over the previous release with Zebra (it actually *worked*). But as pointed out, there has been a lot of ongoing development in Quagga since (and a lot of it has touched OSPF), so I think it's worth looking at. I still occasionally see some odd adjacancy changes that I can't explain fully, but it could be a link issue too, I'm just not 100% sure right now. And, from the 0.99.2 changelog, I think the whole "gettimeofday" issue with timestamps and NTP may now be resolved too :) Possibly the end of the "temporary network outage at 60 minutes of uptime" when NTP sync's up?

As long as we're talking about versions, what version of ISC DHCP might we find in the first release of v3?

The local DHCP server works fine in any case we've tried it, but right now, DHCP relaying is broken in a couple ways. The DHCP relay service sees the request, forwards it, receives an answer, but the reply is somehow malformed (actually, I believe it is sent to the wrong MAC address - the MAC of the requesting device and not to the MAC of the CPE) making use with simple proxy-ARP client bridges (and the device that sits behind it) a total no-go.

That was reportedly addressed in ISC DHCP v3.03 (I think - from memory, don't quote me on it), so I'd really like to see that addressed as well so I can finally centrally manage the last bits of the "legacy network" my sister company has.


Brad

[lonnie]

The main component of TPC is manual to compensate for the antenna that you install. We have always had the automatic, even with our current v2.

The ETSI implementation of TPC is supposed to incorporate a dynamic (automatic) element. the way this is to work is as follows. On a link with a SNR better than necessary to maintain a given link speed the radios at each end are supposed to automatically reduce power to maintain the required SNR for that link to operate. This dynamic power control mechanism must be capable of providing at least 3dB of power reduction.

This type of dynamic power control is quite common on licensed link kit. I have a licenced 13 Ghz link that reduces power once a threshold SNR is reached and alters power levels at each end automatically to maintain that SNR, I.e the power will go up if there is some link fade

The ability to manually set power levels is not the same thing and is not in it's self enough to be fully compliant with ETSI requirements.

.Brendan

[bradg]

How can DHCP know the MAC of the CPE if the request comes from the proxy arp device? It gets a request from a MAC and it responds. The proxy arp device is the one that needs to have the DHCP relay because by the time it gets to the AP it is already mashed.

We have not decided if we will use ISC DHCP yet. It is very big and we want to be reducing the image size.

The quagga will be the latest when the release is made.

OK, fair enough on Quagga, good news, thank you!

On the DHCP issue, here's what happens:

When running ISC DHCP on the Star-OS box bound to the relevant interface, DHCP to devices behind a simple proxy/bridge works fine. The system ARP table shows the MAC of the bridge device (not the MAC of the device behind it), so I'm assuming that's how the DHCP server sees the request and responds to it (since there is no way to view the leases file, I can't verify what MAC address the server responds to without building a Linux router up with the same version of ISC DHCP in V2.10 and seeing what the leases file shows - and unfortunately I just don't have that kind of time to play with it right now).

However, when running DHCP relay on the Star-OS box, DHCP to devices behind a simple proxy/bridge does not appear to work at all. The relay service forwards the request to the DHCP server, the server responds (showing the MAC address behind the bridge, not the MAC of the bridge), and the requests from the CPE router continue forever - the device behind the bridge never receives a lease successfully. It also doesn't seem to matter what the device behind the bridge is, be it a PC running a flavor of Windows, vairous Linksys routers, various Dlink routers, or various Netgear routers - the end result is the same, no lease. But, when using a PC or other CPE with integral router that is not acting as a proxy/bridge, relaying works exactly as expected.

I had reported this earlier (here - http://forums.star-os.com/showpost.php?p=27964&postcount=9), with a note that this issue may have been fixed in a newer release. I do know that I did not experience this behaviour earlier on a couple parts of our network that were previously using a Karlnet AP tied to a Cisco C1605 doing DHCP relaying. That worked as expected, but we've since replaced that setup with Star-OS routers and continue toward replacing the last three Karlnet AP's out there over the winter.

So, the moral of the story is that relaying from a proxy/bridged device can work (as it did with Cisco+Karlnet), indications are that it is an issue with DHCP relaying, and also that it's possible that it may be fixed in a newer release of ISC DHCP.

Not being able to centrally manage DHCP is getting to be a royal PITA on the last bits of the "old" network, and there is no way we can afford a wholesale changeout of all of the Airbridge and CPE200's out there to work around it. Unfortunately, that's old news, well before my time and rebuild, and financially well beyond my means right now.

I do fully understand about the memory footprint issues, and you need to do what you need to do to stay within the bounds you've set. But, I would ask that you at least keep the DHCP relaying with simple bridges issue in mind when testing new releases and software. I'm quite sure that DHCP relaying to devices behind simple bridges is important functionality to many other people than just myself.


Brad

[peace2300]

so when are we going to get the v3 for war boards

[bminish]

The main component of TPC is manual to compensate for the antenna that you install. We have always had the automatic, even with our current v2.

Care to explain under what paramters it operates and over what power range it will reduce power by.
Does this work with all cards or just CM9's ?

[lonnie]

It works with Atheros cards. This is the thing. We can't divulge how it works. Just accept that it does. How can anyone ever really see a change as small as 3 dB on Rx? The mechanism works based on debug output we have watched, but it really makes little or no change at the Rx. We see more than 3 dB variance just from normal fluctuation.

[bminish]

It works with Atheros cards. This is the thing. We can't divulge how it works. Just accept that it does. How can anyone ever really see a change as small as 3 dB on Rx? The mechanism works based on debug output we have watched, but it really makes little or no change at the Rx. We see more than 3 dB variance just from normal fluctuation.

Lonnie, being told that it 'just works' gives me no confidence whatsoever that this implementation actually meets ETSI requirements.

I don't suppose you are referring to the output drop that atheros cards do to preserve linearity as they shift to higher rates?
This isn't the same thing at all. ETSI would require at least a 3dB drop (if link conditions allow) once the 54 Mbs rate has been reached.

.Brendan

[lonnie]

We use the Atheros "approved" mechansim. We are source code licensees and we are obligated NOT to divulge certain things. One of those is the way the the do TPC. It "works, it is "approved", it is "accepted".

Sorry, but if that is not good enough for you, then you are going to have to do your own driver.

[bminish]

We use the Atheros "approved" mechansim. We are source code licensees and we are obligated NOT to divulge certain things. One of those is the way the the do TPC. It "works, it is "approved", it is "accepted".

Sorry, but if that is not good enough for you, then you are going to have to do your own driver.

Lonnie, Unfortunately I can't take your 'attitude' to the Irish regulator. Does your product, when used with a compatible Atheros card meet the TPC (dynamic and static) as required by ETSI?
Have you submitted anything for the approval process ?

Presumably if I use one of the 'other' Atheros drivers out there that uses a vendor supplied HAL then I am also going to have 'vendor approved' power control.

I have the test equipment and the knowhow to measure accurately the power behaviour on links passing traffic. Do I have to 'see for myself' or would you care to provide something a little more concrete?

For example on links with a RSL of -55dBm or better power will be backed off in 1 dB increments to maximum power reduction of x to maintain the RSL at -55dBm.
In a Nutshell that's how it's specified for my 34 Mb licensed link, And by the way the threshold level for the foldback is user configurable. 55 dBm is about 18 dB below the level where the BER starts to creep up on my 71K link

Valemont have not always demonstrated a full understanding of RF issues. I recall that around a year ago, You were telling us that the missing dB's on our 5.8 links was down to OFDM modulation rather than a pigtail issue with the original pigtails you were supplying.

.brendan

[lonnie]

The Atheros supplied HAL has been submitted and is approved. That is what they bring to the table in all of this, plus the chips. They make good chips.

[lonnie]

Well we upgraded more units today. Not one failure in the procedure and it preserves the IP, bridge status, static routes, RIP on/off status and ESSID as well as mode of the radio. We are very pleased with the upgrade code.

The "big thing" is ACK timing is not working and throughput drops off real bad on anything over 2 miles. The good news is it links up on our 42 km repeaters but throughput is 1/10 of what we are exepcting.

It is so close, but alas, there is still work to do before this is ready for release. which is what testing is for.

It was quite a joyous event when the farthest unit (4 hops at 100 km) came up and did not require a site visit to replace the whole unit. In total we upgraded 10 units today. They work very well, except of course for throughput. Back to the lab, so stay tuned.

All in all, not bad for a totally new release with tons of new code being ported from VxWorks. I hope nobody panics since we are actually elated to have first results so good.

[ianek]

Today i going to change the 'superb' WAR for RB532's units . I'm very sceptic you can make the release be good and working in reasonable time .
I will after the release wait for objective ( not for your or reseller options ) until changing back and i warn everyone who want to change to WAR's to wait.

Ian

[lonnie]

Good luck with your project. Sorry we could not help you in time.

[simcor23]

Excellent news Lonnie,


I have been in just as much a rush as everyone else maybe even more I bought my Wars in october. Since I started static route everything I havent had to manually power cycle in well over 3 to 4 weeks. The great thing about this is I have taught myself a massive amount about routing protocols, subnetting in a very short amount of time. All thanks to the WAR boards. Hooray!

[tog]

Although I personally am not concerned about being able to upgrade StarVx to StarOS and retain settings because I never deployed StarVx, I am happy that you got the upgrade mechanism working and you've got StarOS v3 up and running. I bet Tony will fix that ack timeout problem in no time. If you're using the same ath_hal that the rest of us are using in BSD and Linux, I know the ack timeout adjustment in the ath_hal works :)

[ianek]

Well,
i'm not happy with this solution, i have on same link latency around 50 ms, with WARs it was around 4, but people were killing me for lockups .... I hope you will fix all in some time as it will be good as V2 is .

[peace2300]

So is there in time frame for when we should be getting V3 for war, if so when

[lonnie]

No comment at this time. All I will say is that it is the ONLY thing we are working on and it is in alpha testing on our own LAN, as I have already posted.

When it reaches the point that I am happy with it for our own use, I will release it for you guys. This will not be a repeat of the StarVx release where we had only very limited testing. This is running our whole backbone, but it is not ready for you guys yet.

[dastring]

We've been using VX for a while now and have had varying degrees of success. Generally, VX has had too many problems and we have been unable to use the boards.

Will your first release of V3 run on the WARs or will your first release only run on WRAPs and PCs?

We're looking forward to your release... and hopefully buying more WARs...

DS

[lonnie]

The first release is for the WAR boards. WRAP and PC will be later since that will require porting the software to x86.

[bminish]

The first release is for the WAR boards. WRAP and PC will be later since that will require porting the software to x86.

Where the F*** does this leave us version 2 WRAP people with big OSPF networks that are having massive problems due to the Known OSPF bug in Quagga 98.5?

Even applying changes (say after updating an ACL list) is enough to cause serious problems with the current OSPF implementation which can ripple back up the network.

How about a bug fix release in version 2? Some of us have thousands of dollars tied up in staros licences alone. Are bug fixes too much to expect?

These OSPF issues are affecting, My customers, My stress levels and My Bottom line, every day that this remains unfixed costs me time and money as well as leaving our customers with a perception that We are unreliable.

Come on Valemont help us (Your Customers) out here. if this was Open source I would have fixed this myself months ago.

.brendan

[lonnie]

The current OSPF was supposed to be the fix (according to you) and it seemed to do the trick, but now you tell me it is not good at all and we should spend more time on aother "maybe" fix. We do not have the two days to devote to a trial fix for you. v3 for the WAR is our only priority and we will not take away from that. Sorry.

If we hit a lull where we are testing and not touching the v3 code, we'll spin a new release, but that is only a maybe.

Where the F*** does this leave us version 2 WRAP people with big OSPF networks that are having massive problems due to the Known OSPF bug in Quagga 98.5?

Even applying changes (say after updating an ACL list) is enough to cause serious problems with the current OSPF implementation which can ripple back up the network.

How about a bug fix release in version 2? Some of us have thousands of dollars tied up in staros licences alone. Are bug fixes too much to expect?

These OSPF issues are affecting, My customers, My stress levels and My Bottom line, every day that this remains unfixed costs me time and money as well as leaving our customers with a perception that We are unreliable.

Come on Valemont help us (Your Customers) out here. if this was Open source I would have fixed this myself months ago.

.brendan

[bminish]

The current OSPF was supposed to be the fix (according to you) and it seemed to do the trick, but now you tell me it is not good at all and we should spend more time on aother "maybe" fix. We do not have the two days to devote to a trial fix for you. v3 for the WAR is our only priority and we will not take away from that. Sorry.

If we hit a lull where we are testing and not touching the v3 code, we'll spin a new release, but that is only a maybe.

Firstly, we simply could not have grown the OSPF network to a large enough size to run into this issue with the much more serious Zebra bugs.
As I recall until we came up with how to get OSPF working on Staros no one had actually managed to get OSPF working at all in Staros EVEN though Valememont were claiming that the product supported OSPF.
After extensive testing and troubleshooting(made much harder by Staros being closed source.) We have reported various bugs to you. Every time you have made a big deal out of compiling in small bug fix related changes.

Secondly, do you guys not use a build environment? I simply do not believe that it would take you 2 DAYS to update one package which requires no changes to associated configuration files and recomple. I can do it in a few minutes in the Leaf stuff I am playing with.

As an added bonus you would get (free) debugging of any remaining OSPF issues before you have an official V3 release.

We are your customers and we need your help on this, stop treating us like Sh1t

.brendan

[lonnie]

Of course we use a build environment. That does not mean we simply generate a new release and upload it for the world in 10 minutes. Get serious. Any new release, no matter how simple will take our guys several days of testing. The various images and OEM images take almost a full day of uploading to the website.

Right now we are in the middle of something that cannot be interrupted. To take two days off that development would delay it by 4 days or more. You don't just simply switch gears and jump back to where you left off. Right now there is a clear vision of the new driver and it is taking shape. I will not let anything get in the way of that.

Your initial problems were caused by erratic power. I said to fix the power and put in a UPS. Now activating seems to be the big deal, so do not be activating whenever you feel like it. Schedule them so you can have fewer outages.

The best I can say is if we hit a stumbling block or a lull in the driver development, we will take a look at this new Quagga release. The 99.2 is listed as unstable and that fix you hope is the one has just had another bugzilla entry with another slightly tweaked fix added to the CVS. We will watch it and when I feel comfortable and have the time, we'll do a new release.

[bminish]

Of course we use a build environment. That does not mean we simply generate a new release and upload it for the world in 10 minutes. Get serious. Any new release, no matter how simple will take our guys several days of testing. The various images and OEM images take almost a full day of uploading to the website.

Right now we are in the middle of something that cannot be interrupted. To take two days off that development would delay it by 4 days or more. You don't just simply switch gears and jump back to where you left off. Right now there is a clear vision of the new driver and it is taking shape. I will not let anything get in the way of that.

Your initial problems were caused by erratic power. I said to fix the power and put in a UPS. Now activating seems to be the big deal, so do not be activating whenever you feel like it. Schedule them so you can have fewer outages.

Most of my sites have backup power. Changes still need to be made from time to time

A wrap only build called a beta with a 'use at your own risk' warning simply cannot take that long to develop.
Your in house testing is not worth much seeing as we have had to do all the legwork on the ospf bugs for you to date, including liasing with the Quagga developers

In any case what's to test if you leave everything else alone when you do the rebuild ?

[luka]

Anyways the market and technology are fast moving and fast growing. To prevent losing customers you probably should consider hiring more staff or doing something like. This V3 is in development since several months
and the fact that wrap/pc version will not be available undefined time from now is not encouraging.

[lonnie]

It is easy to say add more staff, but have you ever added staff in the middle of a project? It just slows things down.

I need everyone to just sit back and be patient. You cannot possibly be more stressed than we are right now. There is nothing to be accomplished by threats or pleas. It is a fact of life that it is going to take as long as required.

If you cannot wait for us and have to move to another package then so be it. We are sorry to see that happen, but we are powerless to do anything any differently.

[lonnie]

I will not debate this. Just because we have had the time in the past to make fixes in the blink of an eye does not mean we can or will always do it. For you to expect and demand it is getting tiresome.

There is nothing to be accomplished by threats or pleas. It is a fact of life that it is going to take as long as required. I will get to it when we have a break in the v3 project.

If you cannot wait for us and have to move to another package then so be it. We are sorry to see that happen, but we are powerless to do anything any differently.
Most of my sites have backup power. Changes still need to be made from time to time

A wrap only build called a beta with a 'use at your own risk' warning simply cannot take that long to develop.
Your in house testing is not worth much seeing as we have had to do all the legwork on the ospf bugs for you to date, including liasing with the Quagga developers

In any case what's to test if you leave everything else alone when you do the rebuild ?

[bminish]

I will not debate this. Just because we have had the time in the past to make fixes in the blink of an eye does not mean we can or will always do it. For you to expect and demand it is getting tiresome.



Lonnie, you have never fixed ANY of the OSPF issues ' in the blink of an eye'

.brendan

[lonnie]

I said "we have had the time in the past to make fixes in the blink of an eye", and you can check the Forums for fixes that happened the same day as we were notified. Anyway, I am not responding any further to this. I am not sure what you are trying accomplish by continuing this and sniping at me, but rest assured it is not helpful.

[ianek]

End of Jan is almost here . No beta released, still in alfa testing ?

Jan

[lonnie]

We can report success with the new driver code in AP mode, but it has broken WDS and client mode. The performance is on par with the VxWorks, so now we must get the WDS and client modes working and we can release. That cleanup and more will take at least two more weeks.

The second alpha has run for 3 days with no reboots or other issues except for reduced performance. That code is on 12 machines on our main backbone and some of them at the POP end see all traffic, so we feel reliability is OK.

[lonnie]

5.5 days and counting with no reboot or funny issues on the second Alpha. The new driver is still getting WDS and Client rewriting. AP performance is fine. Once we get Client and WDS we'll put in first beta for a test.

[peace2300]

sounds great hope to keep hearing the good news

[lonnie]

It has been a very good week. Client mode is almost where we need it, and I am hopeful we'll do our third Alpha test early next week. It has been running a brutal stress test on the client for almost 6 hours and no problem. We need a couple more tweaks and it will do.

We'll get a new v2 release out this weekend with the newest Quagga.

[bradg]

Lonnie,

First, thanks for the updates - I've no doubt you are all stressed and frustrated right now, but any communication at all from you does a lot to help keep the user frustration down.

I've got a few questions/requests about v3 I'll detail below.

Just recently, I've run into a couple situations that led to some pondering about services running on each unit, and what interface they bind to.

The situation that started it was the ongoing segmentation of our "old" bridged network into routed segments.

A bit of background - the "old" network is using DHCP servers on the Star-OS units themselves as DHCP relaying doesn't work quite right with most pseudo-bridged clients (but works fine with the onboard DHCP server - any chance of updating DHCP in v2 while you're at it?).

Anyway, I had setup a replacement AP in one spot on the bridged network that the new clients will be connecting to (and migrate additional clients to it over the next few weeks), and without thinking about DHCP much, enabled DHCP relaying back to the central DHCP server. Well, I promptly saw a flurry of traffic from the ethernet interface IP address to the central DHCP server requesting IP's for clients on the ethernet (bridged) side of the network. Of course, the answer is that DHCP relay was listening on all interfaces, not just the one I intended it to listen to.

Leading to a broader question - can you/will you consider allowing users to configure each service for listening/binding to a specific interface or IP address(es)? This would have allowed me to easily and quickly resolve the issue I ran into, and further, allow the units to be secured better.

And, as a response to what I'm pretty sure you're thinking, yes, I know we can create firewall rules to accomplish much of what specific service binding can do. However, firewall rules take skill to write (properly), and take CPU cycles to process. Not binding a service to an interface takes little to no skill or specific knowledge of the service, and doesn't otherwise complicate or slow the process of firewalling packets.

As a side note, security is of great importance to me (as it should be to everyone) - every address in our network is public up to and including the customer's CPE device, so we have to take all the steps protect the things we don't want poked at (from the outside, or the inside), and selective service binding is an easy, and low resource cost way to "contain" many of those issues. It would simplify and reduce our firewall rules and router access lists by probably over 50% just by being able to control bindings.

My second question/request is wether you can or would think about allowing the download/upload of the common text-based configuration files via StarUtil? Specifically, things like DHCP, Quagga, firewall/CBQ configurations and so on? It would also be really nice to be able to completely configure a wireless interface via a text file (similar to the advanced security configuration), and not need to poke at it in two different menus. This would make initial configuration a breeze, and would also be nice to have available for upload/download via StarUtil. For that matter, if the configuration upload/download file from StarUtil were open and a known format, that would accomplish pretty much everything being discussed - we could just build a new configuration offline and upload it rather than wading through the menus.

Thirdly, will the SNMP communities be changeable in v3, and which version of SNMP will be in v3?

And last, has a pricing scheme been established for v3 yet, as well as the narrow channel feature for x86 platforms, for new licenses, as well as upgrades (I know the WAR upgrade was planned to be free, I'm interested in x86 at the moment)? I ask mainly as a curiosity in determining wether or not I'll need to budget for it. This isn't that big of issue either way as we don't have hundreds of licenses (yet). But, like everything else, if we have to have the features, we'll buy the licenses, that's just how it goes!

Thanks for your time and listening, looking forward to v3.


Brad

[oscarBravo]

IWe'll get a new v2 release out this weekend with the newest Quagga. \o/ That would be great - it looks like our current problem with OSPF matches a bug that's been fixed in 0.99.3.

[lonnie]

Our goal has been to provide a system that is very difficult to mess up so you are locked out and the unit is useless at the top of a tower or mountain. Of course some of you are better than we anticipated and it has happened a few times.

If we allow direct manipulation of the config files you will of course lose the layer of protection that we wrap around it. As the guy on the other end of the phone when you call for help, there would not be free support for that type of configuration. We started this all with picoBSD and direct text files. I know all too well how careless people can be and it is really unfair to have me on the phone for an hour to find your typo or errant character, sometime just a simple space or period. I won't go back to that, but we will maybe have a version that uses a shell in addition to our configs so you can edit to your heart's content. Just don't phone me for help. You might know how to configure it just right, but the other 95% of users don't even know what the default route is for, and for them to get into the routing table cannot become my problem.

We will have the v3 base at $60. The shell version will add $10. The 5 & 10 MHz channels will add $20. When we release for x86 the website will be updated to make upgrades and options easy to do. We also have to work on the display since it is getting rather cumbersome for customers who have a lot of licenses.

[phendry]

We will have the v3 base at $60. The shell version will add $10. The 5 & 10 MHz channels will add $20.I take it that the V3 upgrade (with 5 & 10 MHz channels) be free to those who have already purchased WAR boards with StarVX and are now having problems?
When the x86 version is ready, do you know what the price would be to upgrade from V2 (with and without 5 & 10 MHz channels)?

[lonnie]

Do the math with a calculator or in your head if you wish. The difference in price between v2 and v3 is $20. Add in your options, which are 5&10 MHz at $20 and shell at $10.

The software is included with WAR boards and of course is free.

[tog]

Have you tested v3 as an AP for point to multipoint?

[lonnie]

We now have a couple of AP units setup and we are testing. There are very customers so it is not a good test. We don't like to climb 100' towers in winter unless it is an emergency. Our main AP units are WRAP based at the top of 100' towers so these will not get exchanged until it warms up.

[Mark]

We will have the v3 base at $60. The shell version will add $10. The 5 & 10 MHz channels will add $20. When we release for x86 the website will be updated to make upgrades and options easy to do. We also have to work on the display since it is getting rather cumbersome for customers who have a lot of licenses.

holy CRAP, Lonnie.

That's more expensive than your competition now.

I have about 45 licenses now... 45 X 20 = $900 just to upgrade to useability what we have now and then we're going to be adding 350 licenses in the next 2 years. That's an EXTRA $14,000 you just tossed into our budget.

Seriously, you've begun pricing yourself out of business. With Trango offering $150 clients that can do 30Mbit, it starts to become indefensible to try to stick with this, when star-os is going UP in overall cost, while everyone else is coming down.

There's hardly any reason to continue using Star-OS without the narrow or wide channel choices. We figured that with bulk purchases of at least 100 clients at a time, we'd lower the price enough to justify stickign with what we've got, and you just wiped that all out and then some. Our goal was to maintain our clients at $225 or less without antenna, and that isn't now possible.

I've been patiently waiting for V3, and a useable OSPF and BGP so we can expand and raise our reliability to meaningful levels. And, we needed the channel width choice for X86, because most of our AP's are X86 based, and none of the embedded systems can run meaningful BGP. We have sites now with 4 radios that are going to reach 6 to 8 radios, all the way from 900 mhz to 5 .8 ghz and if the FCC lets us, licensed 3.65 ghz too.

But it makes less and less sense to continue down the road with 802.11(x)'s inherent flaws for outdoor use, if the price continues to rise, while competing products with proper polling MAC's are now less costly.

Our whole future deploy has been based on the idea that upgrades will be relatively trivial... maybe $10 bucks to upgrade our current client and AP base, and that future licenses for star-os would be similar in price to what we've been paying. More than doubling the price for a license is likely to result in far less cashflow than sticking with your current prices.

We've had this discussion before... quantity, quantity, quantity, that's what will make you money.. Not big margins.

[simcor23]

Those trangos you speak of is a bit of a stretch, first of all they are $149.00 for a 30 pack and the only do 10Mbps they will only go up to 30Mbps when you purchase the ofdm and firmware upgrade and will also only do 30 with the upcoming AP which will be very pricy. You have to see the * at the bottom of trangos page that advertises the $150 trango units you are talking about. Plus they say distances of 3-13 km which isnt neccessarily true as I have used quite alot of them in my day. Marketing can be very deceiveing there really are no $150 Trangos if you calculate all the costs involved. At least with Valemount there are no gimics and savy marketing and sales guys.

[Mark]

Those trangos you speak of is a bit of a stretch, first of all they are $149.00 for a 30 pack and the only do 10Mbps they will only go up to 30Mbps when you purchase the ofdm and firmware upgrade and will also only do 30 with the upcoming AP which will be very pricy. You have to see the * at the bottom of trangos page that advertises the $150 trango units you are talking about. Plus they say distances of 3-13 km which isnt neccessarily true as I have used quite alot of them in my day. Marketing can be very deceiveing there really are no $150 Trangos if you calculate all the costs involved. At least with Valemount there are no gimics and savy marketing and sales guys.

I am fully aware of all the details about Trango.

There's more costs than just a "cheap" client. I don't know that the Atlas AP will be all that expensive. After all, it appears to be just an atheros or broadcom chipset with Trango's polling MAC stuck on top of it.

As to whether it'll do what it says... Yeah, it will, or close enough for discussion purposes.

But when you add $40 to the cost of a staros CPE, by the time you put a cheap antenna on it, you're pushing 300. For 5 ghz, you're pushing 325, since most 5 ghz antennas are well over 60 bucks.

I've found the practical limit for distance for 5 ghz atheros based clients to be around 5-7 miles. And the throughput is more like 8-10Mbit out that far.

So, a 7 mile Trango unit is 250 (unit plus reflector). A 7 mile Star-os client is 325. How many clients must you have before the AP cost is moot? At either 175 or 75 each (depending on distance), the difference for a 30 client sector is somewhere between 2250 and 5250 for the client end. I expect the Trango to at least somewhat outperform the star-os based clients, at least for throughput.

Still, trango lacks routing at the client end, so you have to add a router, muddying the water a bit more.

Still, everyone else is dropping prices and adding features (except motorola - spit!), and raising prices here is harmful to my ability to compete with a serious residential broadband solution.

[simcor23]

I here what you are saying, I'm not a big fan of the residential wireless business. I tried it for about 4 years and it is just a massive pain in the a** especially the customers, what a headache but there is a market for it if your a patient person. I have been doing strictly businesses and it is alot less stress and they don't mind paying for it. But if you look at the hardware section on Valemounts site they have single radio WAR kits for $215.00 on a 10 pack and for 10 5.8 rootennas from pacwireless are around 40 - 50 bucks if you buy 10 and pester them for a deal. You would be looking under $275 and if you purchased more than 10 they would be even cheaper. Plus all the features Valemount offers. It is well worth it.

[lonnie]

The WarTenna is $250 in 10 packs. Ready to go. It'll pull full Atheros speed. It draws 6W of power. It has a hardware watchdog.

Why even fool with VIA boards since the WAR can do just as well for client and the VIA has no hardware watchdog.

Why fool with WRAP boards since the WAR outperforms it for nearly the same cost.

[luka]

I can understand you had contract regarding cloaking so you should bill it additionally (but anyways mikrotik has cloaking too, and probably madwifi soon), but this 10$ for shell (whatever this option means) is not necessarly.
$60 price should not be commented until we see ready product. Hope you will have good volume discounts.

[Skaught]

I can understand the cost of shell. It has the potential to be a ginormous headache for them.

[Mark]

The WarTenna is $250 in 10 packs. Ready to go. It'll pull full Atheros speed. It draws 6W of power. It has a hardware watchdog.

Why even fool with VIA boards since the WAR can do just as well for client and the VIA has no hardware watchdog.

Why fool with WRAP boards since the WAR outperforms it for nearly the same cost.

The wartenna is not very useful. With only 15 db gain, it's a wide angle beam, not very clean or good rf configuring. The majority of my customers are at the edge or beyond that range at present.

Can't run BGP on a WAR platform, you can't add ram to it.

So, at least SOME of our stuff has to be X86, and using antennas that make it (war platform) viable for our operation, it's pretty darned expensive. I'm looking forward to when I can use the 4 board version sometime in the future for some of our sites, but again, it has its practical limitations.

Also, since we're intending to use some 900 mhz, we're going to have to have at least some of our stuff capable of supporting the current draw of the 900 mhz cards.

A bare board and license is 153 in 10's from valemount, a WRAP and current license can be found for well less than that.

both have well more than enough cpu power for client end.

[lonnie]

You might save a couple of dollars, but you still have a WRAP board with all the issues of power instability and low performance. I can see upgrading existing units but to buy last gen product when new gen is almost the same price just makes no sense.

When you price out everything for a WRAP that we include (board, flash, license, POE injector, keystone jack, patch cable) how much are you really saving? I bet you will spend more unless you are buying in high volume, and if that is the situation, you really should talk to me about higher volume pricing on the WAR boards.

[simcor23]

I was under the impression the wartenna was 2.4 and I was just trying to give an alternative to the 5.8 trangos he was speaking about. The 5.8 rootennas are 19dbi and they are $59.95 for one but I've found you can easily talk them down if you order more than one. By the way lonnie, will Valemount be selling a 5.8ghz rootenna option? I still do not see how the WAR boards are exspensive!!! Are you people insane compare them to anything that comes close as far as quality, support, throughput (other than this V3 hiccup) Drangon wave will do 100 - 200 Mbps full duplex, but a 5km link will cost you $30,000 USD. If you are not happy with Valemount and the direction they are taking do not use them!!! Move to Trango or someone else and I bet you will be twice as frustrated with them. Like the new Atlas Fox products that just came out they wont work with access5800 Ap. Just things like that frustrate me with exspensive gear such as skypilot, proxim, trango etc. There is no way that WARS are too exspensive. Again I am not dealing with residential clients so my view is a little jaded. Dont listen to me as every situation is different and I am extremely biased as Valemount helped my company out many years ago as I had wasted tens of thousands of dollars on proprietary gear from the company formerly known as Orinoco before I stumbled apon Star-os managed to turn my ISP into a profitable business thanks to the wonderful software Star-os. So I am grateful to the boys at Valemount, without them I would not be where I am today. And I don't mind going through some of the frustration of this V3 delay and I love their decision to go the WAR route, as I know the will come through with an excellent product.

[lonnie]

Sorry, I was mistaken on the band.

We have 5.8 GHz on order but they have to do a run just for me, so it should be coming soon. They'll be more money but they will be about 22 or 23 dB. They'll be a nice package if they look like the batch of 19 dB 2.4 GHz Rootennas we just received. I did not even get to post them for sale - SOLD, so we have a larger order in now. Should have the 2.4 GHz in 3 weeks.

[Mark]

You might save a couple of dollars, but you still have a WRAP board with all the issues of power instability and low performance. I can see upgrading existing units but to buy last gen product when new gen is almost the same price just makes no sense.

When you price out everything for a WRAP that we include (board, flash, license, POE injector, keystone jack, patch cable) how much are you really saving? I bet you will spend more unless you are buying in high volume, and if that is the situation, you really should talk to me about higher volume pricing on the WAR boards.

What "power instability" and "low performance" are you talking about?

They're far more than adequate, with stellar reliability for me over the last 20 months. Unless you're trying to pump more than 10+Mbit to clients, the WRAP is just fine. They'll do more than that, too.

As far as the parts go, the WAR doesn't include the injector or PS. So, without any proven record of longevity, and without known good software for it, I just can't figure out why I'd want to jump on the WAR platform just now.

[lonnie]

The WAR boards ship with the DC injector since there is not other DC jack, but do not include the power supply. We also include a toolless cat5 keystone jack in the hopes people will see how to properly wire the cat5.

There is nothing forcing you to use the WAR boards so I'm glad you have a solution that does what you need. It takes the heat off us to provide something for everybody.

[robok]

The main component of TPC is manual to compensate for the antenna that you install. We have always had the automatic, even with our current v2.
Hmm, I don`t know how it set up /TPC/ in StarOs menu in item Tx Power Override. Sometime in previous posts Lonnie says that value in Tx Power Override determine power output from card from its range power otput /didn`t say that value in Tx Power Override is gain of the attached antenna/ ???
Again - value in Tx Power Override is power output from card or gain of the attached antenna?
Thanx.

[lonnie]

You have to take your antenna gain and figure out how much power you can legally supply to it, for your country. Then simply set the power control to that level.

Of course the power setting is from the card. There is no way to measure the antenna output and to even know what the gain is.