Topic: GATEWAY NEWS

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!

Saturday, 10 February, 2007, 21:02 PST

Last night, an ALWGW user had another Internet SMTP message arrive that caused a TNOS 2.40 SIGSEGV crash.  The symptoms were the same as those encountered previously (I would recommend reading the background in "Long-term mystery SOLVED," if you haven't already), except that this time there was no X-Face: line present in the header.  The crash did occur in reject.c, but this time it was the To: field causing the problem.  Again, examining the message, no unusual characters were present, although the line was a bit long.

I reviewed and compared the earlier problem messages with the new one, and finally determined what I believe is the key to this issue.  It is not so much the actual content or type of characters that are present in the header lines causing the crashes, but rather the number of characters in any given header line.  It appears to cause a problem when any one line in the headers has more than 256 characters.  When viewed from a 2007 frame of reference, this is a significant weakness!  I will go back and examine the code as I have time, and see if I can come up with a fix.

For now, I have added a line to my Postfix header checks that silently drops any header line exceeding 255 characters:

/^.{256,}/   IGNORE

Many mailers wrap long header lines anyway.  RFC-822 certainly provides for that option.

Note: Interestingly, every time this problem has cropped up on my system, the troublesome message has come through a Yahoo group!

Tuesday, 06 February, 2007, 01:23 PST

For a few years, I have been having an intermittent problem with certain, infrequent Internet SMTP messages inducing TNOS crashes on ALWGW.  The occurrences have caused more than one headache, but I am glad to say that I now have a solution for it!

Note: The information in this article is still relevant, but the solution is superceded by More TNOS SMTP crashes and a workaround.

Read full article: 'Long-term mystery SOLVED!'

Friday, 02 February, 2007, 22:45 PST

Here is my current version of the shell script to process the gateways (encap.txt) file for updating an iproute2-based Linux AMPRNet gateway.  I call it "iproute2_ampr_munge."  This is a spin-off of the "tunnel-munge" script by N8FOW and updated by VE3TIX.

Read full article: 'Current iproute2 based gateways "munge" script'

Sunday, 28 January, 2007, 23:53 PST

I'm having an odd quirk with one of my forwarding partners, between his JNOS BBS and my FBB BBS. In sessions where my FBB has initiated a connection to his system, my board is not accepting bulletins from his system.

Read full article: 'FBB BBS Quirk'

Saturday, 27 January, 2007, 05:54 PST

I added a Telpac node to the system here, after having numerous conversations and a couple of demonstrations of the Winlink 2000 system by N7ZHG.  Compiling and installing DL5DI's telpac-node program was quick and easy.  Interfacing it with my existing AX.25 nodes and BBSs could not have been simpler.  If you are a Winlink 2000 user, WA7V-10 is now one of your options available for a Telpac gateway.

Read full article: 'Telpac (Winlink 2000) Gateway Node Added'

Friday, 26 January, 2007, 16:52 PST

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...

Wednesday, 24 January, 2007, 00:08 PST

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!'