TNOS ran for 2.5 days without a crash, but then mysteriously restarted this morning at 0735 PST. I eagerly looked for a core dump so I could begin debugging, but there was none. Nor were there any clues waiting for me in the logs. Perhaps it didn't receive a SIGSEGV this time? ...big sigh...

I think I finally have something that I've been seeking for awhile.  I am now getting consistent errors as TNOS shuts down!  The problem appears to occur when a reply to a DNS query is received, and the resource record exceeds the buffer size allocated for it (which is 512 bytes, plus some margin for overhead) in TNOS' domain.c.  This quantity is defined in RFC1035, as mentioned in domain.c's source code.

Read full article: 'Consistent TNOS errors!'

I just had an interesting experience on my Slackware 11.0 workstation at the office.  I installed Nvu Web Authoring System to help facilitate some HTML editing, and it ended up creating more work for me!  I cheated and grabbed a precompiled Slackware package to speed up the process, and it installed without incident.  I then ran it once as root to ensure everything would work properly, and it did.  However when I went back to my own (mere mortal user) shell prompt, I couldn't get Nvu to launch a window no matter how hard I tried.  I tried tweaking on the Mozilla scripts, looking over various files and environment variables, searching the Internet, but found nothing that helped my situation.  The program would go through a few steps and always hang, falling short of actually launching an application window.

Read full article: 'Running Nvu in Linux as an Unprivileged User'

Beginning about 9 January, 2007, the TNOS server here (ALWGW) began going on a crashing spree. TNOS' uptime has been anywhere from a few seconds to a few hours, and then it receives a segmentation violation signal (SIGSEGV) from the operating system and restarts. The log file simply shows a rather unhelpful, A 'crashprotect'-preventable restart occurred from a SIGSEGV signal. Why? And is there any hope in correcting the problem? The answer to the second question is an unqualified, Maybe!

Read full article: 'Desperation!'

Status of #ALW's neighbors on 223 MHz backbone, on 21 Dec 2006. (#ALW is part of the node stack on top of the Blue Mountains in northeast Oregon, near Tollgate and Spout Springs Ski Area).

Read full article: '#ALW:WA7V-6 Netrom Neighbors'

Status of PNW's INP3 and Flexnet neighbor circuits, on 21 Dec 2006.

Read full article: 'PNW:WA7V-2 Link Status'

Status of ALWGW's Netrom neighbor circuits, on 21 Dec 2006.

Read full article: 'ALWGW:WA7V-8 Active Netrom Neighbors'

Notice to gateway operators and other convers server sysops who were depending upon InlandPNW for upstream linking:
I know that some of you noticed configuration changes that occurred over the past six months that may have left your convers links "high and dry."  I sincerely apologize for that.  However, your links are welcome.

Read full article: 'InlandPNW Convers Server Status, December 2006'

Q: Why can't I seem to reach wa7v.ampr.org or 44.12.3.128?  Is this system broken?
A: Read this article for the answer.

Read full article: 'Net-44 Routing'

For quite some time, I've been intending to create some maps of the area so people have some idea of where nodes are, and how to get around the region. I finally got around to putting one together. It isn't anything fantastic, but it's a start--particularly if you are not familiar with the area.

Read full article: 'Map of Columbia Basin and surrounding greater area'