Topic: GATEWAY NEWS

Thursday, 05 May, 2011, 20:19 PST
Internet connectivity was interrupted late last night Pacific time, when the University's ISP stopped advertising routes to portions of its networks. The interruption affected all services hosted on this system. The outage lasted just over 9 hours, with connectivity being restored shortly after 16:00 UTC.

Sunday, 01 May, 2011, 01:48 PST
Today at approximately 23:00 UTC (nearly 2 hours ago), the host machine restarted, affecting all services hosted here. The cause is under investigation.

Sunday, 27 March, 2011, 04:32 PST

The WA7V FBB BBS is operational once again, following a two-week outage while system upgrades were taking place.  It is connectable via ALWGW:WA7V-8 on port ax9, PNW:WA7V-2 on port 20, ALWHUB:WA7V-4 on port bbs, and ALW:WA7V-7 on its LAN frequency.

Please note that the WA7V FBB BBS is only intended for forwarding between other full-service BBS stations.  End users should use WA7V-8 TNOS BBS instead.

If you are one of my AX.25 forwarding partners and notice that something isn't working correctly, or if you aren't one of my forwarding partners but would like to be, please drop me an email at the address listed  beneath the photo on the home page, or at WA7V@WA7V.#SEWA.WA.USA.NOAM on AX.25.  73 es tnx!

Wednesday, 23 March, 2011, 17:52 PST

As soon as I have an appropriate time slot available, I intend to restart the machine that hosts the Hub_NA convers server, and the PNW:WA7V-2 (X)Net node.  The entire outage should only be for a few minutes, but will obviously disrupt links.  Hopefully convers links will re-establish themselves with minimal fuss, and without complaints of network loops.

Note that this will affect those two services only, and none of the others. The restart is necessary to permit the installation of some serial ports on that server.

--WA7V

Update 24 March 01:00 UTC -- The work has been completed, and the server seems to be running satisfactorily.

Wednesday, 23 March, 2011, 14:59 PST

Over the past couple of weeks, many folks have noticed that services here have been highly disrupted.

It's true.

In January, I replaced the aging box that had been serving up web pages, delivering email, running 3 packet nodes, 2 BBSs, a convers server, performing network filtering and policy-based routing, and a variety of other tasks.  Occasionally, the lack of adequate RAM was causing problems, and the kernel had to kill certain processes when there wasn't enough memory to go around.

The new box has vastly more system resources, and I had made up my mind that I wanted to virtualize the system, to split off the services into several virtual machines. I reasoned that I could be performing updates, making modifications, or even experimenting on one virtual machine (aren't amateur radio operators supposed to experiment?), while the others could be running without interruption.  For applications that hook directly into a Linux kernel's networking stack and use all of the kernel's IP addresses, I would gain the advantage of having multiple kernels, just as if they were distinct physical boxes.

So, when I replaced the hardware, I copied the old system into its own virtual machine, with everything functioning exactly as before, and then prepared to migrate and separate all of the services from that vm into new ones.

Then, nearly 2 weeks ago, the lemming migration started. *sigh*

Read full article: 'Mayhem'

Wednesday, 23 March, 2011, 13:55 PST

On December 16, approximately 3 weeks after the mountaintop site at Spout Springs went off the air, radio silence was broken as the voice repeater and node stack inexplicably returned to life.

To my knowledge, no one has claimed responsibility... or taken credit... for having gone to the repeater / node site and performing whatever tasks were necessary to resurrect the gear.

 Just the same, we're glad to have it back.

Wednesday, 24 November, 2010, 21:00 PST

Once again, we are having problems on the mountain and the packet node stack is down.  This includes WA7V-6 (#ALW 1.25m), WA7V-7 (ALW 2m), and WA7V-9 (ALW96 70cm).  Once again, the weather is such that a drive to the site by automobile will be impossible.  Nevertheless, I'll try to make a trip up there fairly soon to see what the culprit is.

Saturday, 21 June, 2008, 18:54 PST

The 2m and 70cm ports of the packet node stack at Spout Springs are a bit "under the weather."

Although both ALW:WA7V-7 and ALW96:WA7V-9 are technically operational, the RF performance of both nodes have been seriously degraded since about the middle of May.  Since they share a common duplexer, feedline and antenna, the problem is expected to be found in one of those components.  Interestingly, this doesn't seem to be associated with a severe weather event, of the sort that occurs routinely throughout the winter months.

Furthermore, an abundance of snow (including an additional surprise 14"+ snowfall on June 10) continues to prevent a leisurely drive to the radio site by automobile.  Just before the most recent snowfall, it was reported that N7ERT encountered about 4' of snow at the gate which is roughly 2 miles from the site.  Because of the lateness of the season, I've held off visiting the site until I can drive up there.  Besides, I didn't really want to trudge up there through the snow, even if it was on skis or snowshoes, and then have a tower climb to look forward to.  ;)

My current guess is that I'll be visiting the site in early July to determine the problem.  The repair may not happen until a subsequent trip is made on another date, depending on what is needed to fix it.

73, 

WA7V

Friday, 06 April, 2007, 17:32 PST

Once again, WA7V-10 was conspicuously absent from the list of Telpac gateways, even though it was functioning fine and regularly communicating with its primary PMBO.  I thought perhaps the registration had mysteriously disappeared, like it did last time, but such was not the case.  Then I noticed that WA7V-10's primary PMBO, KB6YNO, was listed as offline on the PMBO status page.

Since WA7V-10 was not having any difficulty in establishing a network connection with KB6YNO, it was not falling back on any of its other backup PMBOs in its configuration file.  It would be interesting to know how this would affect the delivery of mail.  I might have to try it to see.

WA7V-10 is now back in the Telpac gateways list, as it is using an alternate PMBO as its primary.

Tuesday, 06 March, 2007, 18:37 PST
I was alerted by N7ZHG that WA7V-10 was not showing up on the Telpac gateway real-time status list and map pages.  It turned out that WA7V-10 wasn't even showing up on the registration page, so I had to re-register.  Once that was done, everything "automagically" appeared.  Hmm!