StarV3 v1.1.3 build 1500 has been released for all editions.

[tony]

The new release can be downloaded from the http://www.star-os.com/starv3 downloads page.

Please refer to the following thread for an X86-PC list of supported ethernet devices: http://forums.star-os.com/showthread.php?t=5694

Please use the PC cross-over release available on the download page to upgrade your StarOS Router and Server systems.

[knolan]

I've just tried to upgrade one of our PC Routers from v2 to v3.

After upgrading to the cross over version, everything works ok.

After this this I upload the v3 firmware (I have tried both 1.1.2-1421 & 1.1.3-1500)

The problem I am facing is after rebooting I get the message
Not found any [active partition] in HDD
DISK BOOT FAILURE, INSERT SYSTEM DISK AND PRESS ENTER


The motherboard is an EPOX EP-LXA-M running chipset i440LX and the harddrive is connected to IDE1 as the Primary Master


Is this problem fixable - or should I just keep this machine running v2


Regards,
Keith

[tony]

That specific system may need to stay with v2 if it is unable to boot v3. You may wish to try a BIOS update to see if it helps.

[go.fast]

Can you expand upon this:

"ALL: h323 should not work as expected when using nat."

http://www.star-os.com/release-notes/starv3-1.1.3.htm


Thanks

George

[tony]

Looks like a type-o that will be corrected. Thanks.

[Stratolinks]

I just finished upgrading 4 of our backhaul links to V3 today. That's a total combined climb of 554ft but this is fun right?

2 of the units are intel 815 chipset with a supported watchdog, the other 2 are intel 440bx chipset that do have an unsuported watchdog timer, but the screens on all them are showing the watchdog timer highlighted. Is this a glitch or just an undocumented feature? :p

So far they all seem to be working OK, althoug I am getting a small ping loss of about 0.5% on one linek when there wasn't one before. It's probably nothing, but I am looking into it.

Putty under windows works fine to V3 and V2. SSH from a terminal window on my trusty old Mac computer running OS X 10.3.9 to V2 worked fine, no mouse, but who needs one. SSH to V3 however doesn't work correctly. Not only is there no mouse (as expected) but also no keyboard. If I open a terminal in X-11, the mouse works, but no keyboard. From a command line on my FedoraCore3 (Linux) machine I can ssh to a V2 box OK, but I can't ssh to a V3 box. It asks for the password then it just comes back connection closed. I would guess this is some obscure little change but it would be really nice if you can find out why it is doing this, and get it back to the way it used to be if it is reasonably possible.
:confused:

Any Suggestions?

[therealboss]

I just finished upgrading 4 of our backhaul links to V3 today. That's a total combined climb of 554ft but this is fun right?

snip

I can't ssh to a V3 box. It asks for the password then it just comes back connection closed.


Are you admin on your ssh, try ssh (IP) -l admin

That should work from your linux box.

[Stratolinks]

Are you admin on your ssh, try ssh (IP) -l admin

That should work from your linux box.

Actually I found out this morning that the box that was refusing the connection is also refusing it from Putty now too. I tried connecting to another V3 from the linux box and it does work. It doesn't look the greatest on a pure text environment, but it does work. The fedora box has no GUI it is run from a flash card and runs Intermapper to monitor the network.

I still have an active ssh connection open to the box that is now refusing any more connections. The only difference that I can see for it right now is that it is showing the quagga-watchdog as not running while all the others are, and ntp as not running while all the others are. An activate changes does not make it come back to life. I am hesitant to reboot it just in case it doesn't come back up correctly. One thing that is different on this unit is there is a third CM9 that is currently disabled.

I'm not saying the ssh issue is actually VNC's problem, I am just wondering if there was some subtle change made that causes it to not work natively on the Mac any more. I will also try putty for Mac (a program that I always thought was pointless since ssh was already built into the OS, and in X11).

I am open to suggestions.

[lonnie]

The SSH is all new and requries new and up to date clients with xterm for the console type.

There is always a watchdog timer. If there is no suitable hardware one available we use a software watchdog, which is not as reliable, but is better than nothing.


I just finished upgrading 4 of our backhaul links to V3 today. That's a total combined climb of 554ft but this is fun right?

2 of the units are intel 815 chipset with a supported watchdog, the other 2 are intel 440bx chipset that do have an unsuported watchdog timer, but the screens on all them are showing the watchdog timer highlighted. Is this a glitch or just an undocumented feature? :p

So far they all seem to be working OK, althoug I am getting a small ping loss of about 0.5% on one linek when there wasn't one before. It's probably nothing, but I am looking into it.

Putty under windows works fine to V3 and V2. SSH from a terminal window on my trusty old Mac computer running OS X 10.3.9 to V2 worked fine, no mouse, but who needs one. SSH to V3 however doesn't work correctly. Not only is there no mouse (as expected) but also no keyboard. If I open a terminal in X-11, the mouse works, but no keyboard. From a command line on my FedoraCore3 (Linux) machine I can ssh to a V2 box OK, but I can't ssh to a V3 box. It asks for the password then it just comes back connection closed. I would guess this is some obscure little change but it would be really nice if you can find out why it is doing this, and get it back to the way it used to be if it is reasonably possible.
:confused:

Any Suggestions?

[lonnie]

It sounds like a kernel panic is getting ready to happen. What is memory usage like? Be prepared to power cycle since it might not even reboot by software and do not save settings. My advice is to reboot it ASAP rather than letting it simply crash.

Actually I found out this morning that the box that was refusing the connection is also refusing it from Putty now too. I tried connecting to another V3 from the linux box and it does work. It doesn't look the greatest on a pure text environment, but it does work. The fedora box has no GUI it is run from a flash card and runs Intermapper to monitor the network.

I still have an active ssh connection open to the box that is now refusing any more connections. The only difference that I can see for it right now is that it is showing the quagga-watchdog as not running while all the others are, and ntp as not running while all the others are. An activate changes does not make it come back to life. I am hesitant to reboot it just in case it doesn't come back up correctly. One thing that is different on this unit is there is a third CM9 that is currently disabled.

I'm not saying the ssh issue is actually VNC's problem, I am just wondering if there was some subtle change made that causes it to not work natively on the Mac any more. I will also try putty for Mac (a program that I always thought was pointless since ssh was already built into the OS, and in X11).

I am open to suggestions.

[tony]

The watchdog will show as enabled on the interface, as it will revert to a software-based watchdog if there is no hardware one available.

Under OSX, the keyboard should work under SSH under the Terminal, and both mouse and keyboard should work under X11.

To use your function keys in ssh under OSX, you need to press command, and the key in question otherwise the OS will handle the function key itself.

command-F10 will give you access to the menu.

Note: the OSX version I use is 10.4.7.

[Stratolinks]

It sounds like a kernel panic is getting ready to happen. What is memory usage like? Be prepared to power cycle since it might not even reboot by software and do not save settings. My advice is to reboot it ASAP rather than letting it simply crash.

When I got back to the office today and read your response I decided to reboot it an be prepared for a trip there, just in case. I still had the open ssh connection working so I opened another window to run a continuous ping so I could tell the instant it came back up. It got 9 pings out then the unit stopped responding, before I could get the reboot clicked. It was up 23:48:28 when it stopped. about 55 customers out of service for a grand total of 21 minutes. Fortunately this is the closest one to me and is only 100ft up a silo.

edit - Memory usage was 25M of the 128Meg.

Now I know, when I can't get an ssh connection in, assume it needs a re-boot. After the reboot everything looks normal and the pings are back where they should be with no losses.

BTW, for the ones with the supported hardware watchdog, what is its action when the time elapses, and what is the time that has to elapse? I assume it just does a board reset, right?

Thanks again for the advice.

PS The command -f10 trick works in terminal to get at the menu. I just got so used to typing alt-f to get at the menus and old habits are hard to break.

[Stratolinks]

First go to Terminal Preferences and change the option for 'Declare terminal type' to xterm-color.

Then open a new terminal window if you don't already have one open.

Then under the Terminal menu select the Window Settings option, in the popup list at the top of that window select Keyboard, then near the bottom of the windows click the check box beside 'Use option key as meta key' then click the Use Settings as Defaults button.

Now the option key becomes the alt key (probably already labelled that way on most keyboards). Pressing alt-f brings down the file menu, alt-x exits, etc...

Of course you type in the ssh command as follows:
ssh 192.168.1.1 -l admin

[ninedd]

...when I can't get an ssh connection in, assume it needs a re-boot...FWIW, there are times when we have a machine in distress like this (can't even SSH in) that we sometimes have still been able to (only sometimes) transmit a "starutil 1.2.3.4 pass -reboot" and get it to happen remotely without having to visit the site.

[lonnie]

When any watchdog timer expires it reboots. There is no other action it could take since the kernel has typically crashed. It cannot send messages or do any system cleanup. It just does the only thing it can and reboots so that hopefully the system comes up in a clean state.

[Stratolinks]

FWIW, there are times when we have a machine in distress like this (can't even SSH in) that we sometimes have still been able to (only sometimes) transmit a "starutil 1.2.3.4 pass -reboot" and get it to happen remotely without having to visit the site.

Good advice to keep around for later, but this unit went totally dead just as I was about to reboot it. It no longer passed any data or even responded to pings. Of course this is the odd situation where a hardware watchdog may have rebooted it just fine. I swapped out the CPU board with one with a newer chipset that has a supported watchdog on it so hopefully, if this ever happens again, it will reboot.

[Stratolinks]

When any watchdog timer expires it reboots. There is no other action it could take since the kernel has typically crashed. It cannot send messages or do any system cleanup. It just does the only thing it can and reboots so that hopefully the system comes up in a clean state.

Actually there are many watchdogs that just trigger an interrupt, although not much good if you ask me. Maybe OK if the kernel just got stalled on some process, but that would only help out bad software, certainly not needed for VNC. The reset type is the only useful type that may be able to recover from a major kernel panic or strange hardware behavior to attempt to keep the system running.

Only question remains is what is the maximum time delay on the supported Intel chipset watchdog? Just would like to know so that I can best interpret the monitoring software reports when it says a device was off-line for 2min 15sec. I could presume that it was a reboot. Totally non-critical but would just like to know.

That misbehaving unit was causing lots of network weirdness for any traffic routed through it. After the power cycle everything came up exactly as it should have and all network weirdness is gone. May just have to play with one of these links now to see what sort of speed it can do on Turbo mode. 3 out of 4 of these links are out in rural areas where we couldn't detect anything at all on any 5.7 - 5.8 GHz channels. At the last station we could find a wee bit of signal about 90deg off our path which we then narrowed down to a local municipalities 2-way radio repeater. Would you believe they use a 5.8GHz link to send audio to do simulcast from the 3 repeater locations to cover the entire county.

Thanks again.

[lonnie]

I guess I was talking about OUR watchdogs. Of course I know that you can simply trigger an interrupt, but that is not the behaviour we use since it is of little value on a kernel meltdown.

The watchdog delay is about 30 seconds to 1 minute.

That 5.8 GHz audio feed was really just a scam but they don't know it. A real analog radio repeater would have been WAY cheaper and more reliable. I guess the saying, that to a six year old with a hammer the whole world looks like a nail really is true, and also, there is a sucker born every minute will always be true.

Actually there are many watchdogs that just trigger an interrupt, although not much good if you ask me. Maybe OK if the kernel just got stalled on some process, but that would only help out bad software, certainly not needed for VNC. The reset type is the only useful type that may be able to recover from a major kernel panic or strange hardware behavior to attempt to keep the system running.

Only question remains is what is the maximum time delay on the supported Intel chipset watchdog? Just would like to know so that I can best interpret the monitoring software reports when it says a device was off-line for 2min 15sec. I could presume that it was a reboot. Totally non-critical but would just like to know.

That misbehaving unit was causing lots of network weirdness for any traffic routed through it. After the power cycle everything came up exactly as it should have and all network weirdness is gone. May just have to play with one of these links now to see what sort of speed it can do on Turbo mode. 3 out of 4 of these links are out in rural areas where we couldn't detect anything at all on any 5.7 - 5.8 GHz channels. At the last station we could find a wee bit of signal about 90deg off our path which we then narrowed down to a local municipalities 2-way radio repeater. Would you believe they use a 5.8GHz link to send audio to do simulcast from the 3 repeater locations to cover the entire county.

Thanks again.

[Stratolinks]

I guess I was talking about OUR watchdogs. Of course I know that you can simply trigger an interrupt, but that is not the behaviour we use since it is of little value on a kernel meltdown.

The watchdog delay is about 30 seconds to 1 minute.

That 5.8 GHz audio feed was really just a scam but they don't know it. A real analog radio repeater would have been WAY cheaper and more reliable. I guess the saying, that to a six year old with a hammer the whole world looks like a nail really is true, and also, there is a sucker born every minute will always be true.

Sucker born every minute - P.T. Barnum

Of course it was a scam, they just want a continued long-term service contract. A friend of mine bid on that contract but was not even given any consideration because his company could do what they wanted for a quarter the cost. Until I did the scan I just didn't know what frequencies they were using.

Reminds me of another saying - A fool and his money are soon parted.