Date: Mon, 11 Jan 93 04:30:03 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #11
To: tcp-group-digest
TCP-Group Digest Mon, 11 Jan 93 Volume 93 : Issue 11
Today's Topics:
CPU ID test code
DPMI, etc
Duplicate MID
HELP!
help AND kf5mg's 'stupid but they work for me fixes'
In-Reply-To: AA4RE's DPMI et al...
Internet ampr.org addresses
MID dups problem - Revisited (3 msgs)
Remote in JNOS 107b
Returned mail: User unknown (fwd)
Stability
Unwanted mail
WHAT IS SMACK ?
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Sun, 10 Jan 1993 14:13:42 -0500 (EST)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: CPU ID test code
To: JT@zfja-gate.fuw.edu.pl, tcp-group@ucsd.edu
This is what turned out to be what is known here as an "RTFM" problem.
Borland C offers a "#pragma startup" directive which allows a function
name to be specified that will be run ahead of main(). It should be
easy to link in my assembly language CPU type checked so that it is
called from a C language function referenced with the pragma. The rules
for the pragma say that it has to take a void argument list and return
void, and there is no official way to get it to terminate. However, we
can probably follow the example in C0.ASM and have our C routine call
the _exit() function if the wrong CPU is found.
If this works, it would be a lot less trouble than the ideas you and
I were coming up with, such as modifying C0.ASM or writing an external
loader for NOS.
-- Mike
------------------------------
Date: Fri, 8 Jan 93 22:20:24 PST
From: jmorriso@ee.ubc.ca (John Paul Morrison)
Subject: DPMI, etc
To: ucsd.edu@tcp-group.ee.ubc.ca
I think DPMI protected mode support is very desirable, especially
the 286 mode. I can only speak for our use, but there are piles of
286 class machines that are basically garbage, and that's why we get them!
It would be nice to stick a few AT's in the corner, doing stuff, routing
ftp etc., but NOS is too slow and too unstable for significant
unattended use.
I don't know if 286 protected mode would help, but perhaps by freeing
up more memory, more prorgammers can worry apport stability, and not code
size. Our case: I tried to use NOS (pagri???) as a gateway and ftp
server between two networks. UNfortunately, NOS stopped routing
periodically. So I had to trash NOS on that machine, and I used
PC route, which was faster, but we lost the the ftp, which was nice.
What kind of usage do people here put their machines through?
I would like to be able to dedicate the old machines (286s, 8088s perhaps)
to a couple of tasks, and run them 24 hrs a day. That's because 386
machines are a priority (the department provides 386s for regular
use, but it would take a lot of talking to get a 386 or 486 that *we*
can setup, hack on and get fancy things up and running. Since no one
wants the 286s, they dump them on us).
About the only real 286 solution might be to dredge up a copy of OS/2 1.3
and TCP/IP. Dump in lots of RAM, and then we would get pre-emptive
multitasking, threaded execution, etc. Has anyone tried this?
__________________________________________________________________________
John Paul Morrison |
University of British Columbia, Canada |
Electrical Engineering | .sig file without a cause
jmorriso@ee.ubc.ca VE7JPM |
________________________________________|_________________________________
------------------------------
Date: Mon, 11 Jan 93 09:53:19 GMT
From: Alan Cox <iiitac@pyr.swan.ac.uk>
Subject: Duplicate MID
To: tcp-group@ucsd.edu
I still don't see it as an acceptable solution. It could happen and
with the common practice of distributing NOS as a directory tree you
unzip tweak a few files and run its very likely to occur. Much better
would be to have a single sequence file for MID's and allocate them
as you ax.25 forward and not before. Then you can generate normal bbs
style nnnnn_call addresses.
It's not MUCH work to do it properly
Alan
------------------------------
Date: Mon, 11 Jan 93 00:09:55 EST
From: crompton@NADC.NAVY.MIL (D. Crompton)
Subject: HELP!
To: johan@ece.orst.edu
Johan,
I am experiencing a particulary screwy BBS problem. I consistently
get a system crash when a BBS is sending a message to me. It stops
at the same place each time. As viewed by a trace while it is happenning
the following is seen - I suspect that the subject is being screwed
up by this rather strange line:
Subject: EARTHWINS LAUNCH Message-Id: <921228181039_70304.326_DHP47_1@
CompuServe.com>
I think I have that right - copied from my trace at crash. The crash
is fatal - invalid pointer - no stktrace called - most of the time a
hard reset is required. Qemm exception error at times.
I went back to plain vanilla 107B to eliminate any changes I have made.
Still bad - also had 106 code here - same thing.
I should try entering a bizzare subject line from my other system and
see if I can locally make this happen.
I looked thru forward.c quickly but did not see anyhting obvious.
The above subject line is coming FROM the remote BBS.
Doug
------------------------------
Date: 11 Jan 93 04:37:21 CST
From: Jack Snodgrass <kf5mg@vnet.ibm.com>
Subject: help AND kf5mg's 'stupid but they work for me fixes'
To: <TCP-Group@UCSD.Edu>
crompton@NADC.NAVY.MIL (D. Crompton) writes:
>Johan,
>
> I am experiencing a particularly screwy BBS problem. I consistently
>get a system crash when a BBS is sending a message to me. It stops
>at the same place each time. As viewed by a trace while it is happenning
>the following is seen - I suspect that the subject is being screwed
>up by this rather strange line:
>
>Subject: EARTHWINS LAUNCH Message-Id: <921228181039_70304.326_DHP47_1@
>CompuServe.com>
>
>I think I have that right - copied from my trace at crash. The crash
>is fatal - invalid pointer - no stktrace called - most of the time a
>hard reset is required. Qemm exception error at times.
>
Hey Doug,
This probably should have been sent to the NOS-BBS group, since it
is BBS related. Blame Doug.... not me. :)
Pretty *&@(*&@*(^@ irritating isn't it. My system crashed at least
10 times before I finally got past that stupid bulletin. The R: line
in the Bulletin had R:1234/1234 @: #:0 Z:00000 and NOS bit the big one
when it tried to process it. I posted this info in the NOS-BBS list a
couple of days ago. Guess you missed it, or I didn't make it clear
enough. Anyway... here's my fix that let me process the bulletin. It's
not good, and I'm not proud of it, but it let me process the bulletin
without getting blown out of the water.
I've also included my 'script' language from the Forward.C file.
Maybe Johan can make sense of it and merge his script language with
mine.
In Mailbox.c
This let me get past that stupid earth winds bulletin with the corrupted
R:line.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
if(check_r) {
/* Check for R: lines to start with */
#ifdef notdef
if(!strncmp(m->line,"R:",2)) { /*found one*/
#endif
/* Invalidate R: lines that don't have R:YYMMDD/ */
if((!strncmp(m->line,"R:",2)) && (*(m->line+8) == '/')) {
/*found one*/
.
.
.
.
.
/* if we use 'return addres'
* copy whole 'domain' name
*/
if(Rreturn)
#ifdef notdef
if(strlen(cp) <= OBLEN)
#endif
if((strlen(cp) <= OBLEN) && (strlen(cp)))
strcpy(origbbs,cp);
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
This is what I was using for a 'script' language before Johan put his in.
One of the problems I have with Johan's code is that it doesn't handle
TEXNET's 'inverse' *** Linked to message when forwarding over TEXNET.
You need to be able to wait for multiple lines before you send the [JNOS-H$]
string. For example, I need to wait for:
[AA4RE-H$]
N5AUX>
[AA4RE-H$]
N5AUX>
Then I can send the [JNOS-MH$] string.
The first is for the TEXNET id. The second one is what AA4RE sends back when
it gets the *** linked to kf5mg message. You also have to handle the [] string
when you get it to turn on mbx forwarding. This lets me forward through TEXNET.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
In Forward.c
int Done;
char TmpLine[MBXLINE]
/* . = sends data. Same as Johan's */
/* .w = wait for data */
/* it waits forever, or until */
/* the station times out. */
Done = 0;
while(fgets(m->line,MBXLINE,m->tfile) != NULLCHAR) {
strcpy(TmpLine,m->line);
rip(TmpLine);
if(TmpLine[0] == '.') {
Done = 1;
if(TmpLine[1] == 'w') {
/* We need to 'wait' for something */
for(;;) {
if(recvline(m->user,m->line,MBXLINE) == -1) {
exitbbs(m);
return;
}
if(*m->line == '[') { /* parse the SID */
rip(m->line);
mbx_parse(m);
continue;
}
if(strstr(m->line,&TmpLine[3]) != NULLCHARP) {
break;
}
}
}
else {
/* send the current '.' line */
tputs(m->line + 1);
usflush(m->user);
}
}
else {
/* we are done with the file. */
fclose(m->tfile);
m->tfile = NULLFILE;
if(Done == 0) { /* no '.' lines in the file. */
for(;;) {
if(recvline(m->user,m->line,MBXLINE) == -1) {
exitbbs(m);
return;
}
if(ISPROMPT(m->line))
break;
if(*m->line == '[') { /* parse the SID */
rip(m->line);
mbx_parse(m);
continue;
}
}
}
break;
}
}
73's de Jack - kf5mg
AMPRnet - kf5mg@kf5mg.ampr.org - 44.28.0.14
AX25net - kf5mg@kf5mg.#dfw.tx.usa.na - work (817) 962-4409
Internet - kf5mg@vnet.ibm.com - home (817) 488-4386
------------------------------
Date: Sun, 10 Jan 1993 09:57:10 -0800
From: atheist@Apocalypse.CAD.UCLA.EDU (Jim Small)
Subject: In-Reply-To: AA4RE's DPMI et al...
To: aa6ed@algedi.ampr.org, tcp-group@ucsd.edu
A while back someone posted that some dpmi utilities for bc and msc
were on wustl, Are they located anywhere else? Wustl's been tellingme
that more than 175 concurrent connections exist and cuts me off.
..
------------------------------
Date: 10 Jan 93 15:34:36 CST
From: Jack Snodgrass <kf5mg@vnet.ibm.com>
Subject: Internet ampr.org addresses
To: <TCP-Group@UCSD.Edu>
Can someone explain what you need to do to set up and ampr.org
address using the ampraddr robot? I saw Brian's append on how to add
stuff to the ampr.org file, but he didn't explain what needed to be
added. My IP address is 44.28.0.14, but it's not connected to the
internet. I have a SMTP gateway ( rowdy.lonestar.org ) that my station
can connect to and I have my work id.
I sent the ampraddr robot a message telling it my IP address and gave
it a mx record that pointed to rowdy.lonestar.org. This was a week ago
or so. I still can't send mail to kf5mg@kf5mg.ampr.org. Is that
because I gave it my IP address and it can't connect to it, or is it
something else. Also, can I specify my work id as a secondary id in
case the rowdy.lonestar.org system is down? If I need to remove the
reference to my 44.28.0.14 IP address, how do I do that? Thanks.
73's de Jack - kf5mg
AMPRnet - kf5mg@kf5mg.ampr.org - 44.28.0.14
AX25net - kf5mg@kf5mg.#dfw.tx.usa.na - work (817) 962-4409
Internet - kf5mg@vnet.ibm.com - home (817) 488-4386
------------------------------
Date: 10 Jan 1993 13:19:49 -0500 (EST)
From: "Brian A. Lantz" <BRIANLANTZ@delphi.com>
Subject: MID dups problem - Revisited
To: tony@mpg.phys.hawaii.edu
1. You're preaching to the choir! That's why we are using NOS and not a
"regular" BBS. It IS NOT a problem sending to standard BBSs, since NOS
truncates the BID/MID to 13 characters if it is larger.
2. Whose idea? Don't ask me, I just try to make TNOS co-exist with the
"standard".
3. We need to generate a new MID because NOS handles aliases by using the
same internal MID number for all messages from a common base message.
Thus the problem that OTHERS reported. I simply gave you a way around it.
4. You STILL have the option of IGNORING the fix, and living with the
problem! No skin off my back ;-)
All I know is that the fix WORKS! Until something better comes along, feel
free to use it or ignore it!
73 from Brian A. Lantz KO4KS@KO4KS.#TPAFL.FL.USA.NA 3100813105
Internet: brianlantz@delphi.com
Amprnet: ko4ks@ko4ks.ampr.org [44.98.0.167]
------------------------------
Date: Sun, 10 Jan 1993 14:31:58 -0500 (EST)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: MID dups problem - Revisited
To: BRIANLANTZ@delphi.com, tcp-group@ucsd.edu
I disagree that the chances of MID collision when basing the MID on the
mail receiver instead of the mail sender are not very great. Around here,
for example, everyone seems to start their messages at 1 on New Year's Day.
-- Mike Bilow, <mikebw@ids.net> (Internet)
------------------------------
Date: Mon, 11 Jan 93 02:14:34 UTC
From: n8fow@wsu.n8fow.ampr.org
Subject: MID dups problem - Revisited
To: tcpgroup@ucsd.edu
First, all BBS's in the regular AX25 packet world CAN duplicate
BIDS and MIDS. Want to try it? Put up 2 systems with the same callsign
but different SSID's. They will both put out the EXACT same BIDS and MIDS.
This is a problem with ARES/RACES groups that put a callsign on the BBS
that's that same as a full-service system in town, they will both have
the same BID/MID and if they renumber their messages in January and an
emergency occurs then the neighboring BBS will reject their emergency
mail. And NO, not even AA4RE BBS will generate different BID/MID with
the option in it to do so when you give the BBS different SSID's. It
only works when both systems have the exact same callsign and SSID.
Second, the MID problem should have been dragged off of TCP-GROUP
and moved to the BBS-SYSOP group instead. The source code for the
change would belong here, but not the debate and arguements, that's a BBS
problem and not the TCP/IP protocols problem.
73, Ron Michigan AMPRNet (TCP/IP)
AX25 BBS: N8FOW @ WB8H.#SEMI.MI.USA.NA
AMPRNet : n8fow@n8fow.ampr.org [44.102.0.99]
n8fow@wsu.n8fow.ampr.org [44.102.0.196]
Internet: ron@chaos.eng.wayne.edu
------------------------------
Date: Mon, 11 Jan 93 10:38:02 GMT
From: A.D.S.Benham@bnr.co.uk
Subject: Remote in JNOS 107b
To: TCP-Group@UCSD.Edu
I spent the weekend compiling 1.07b of JNOS to replace my current NOS (my own
compile of JNOS 1.01).
I use Borland C++ v3.0, compiling with 80186 instructions.
Everything seemed to work fine, except for the "remote" command.
Trying "remote g8fsl kick" gives the error "Unknown command g8fsl".
But 'g8fsl' is supposed to be the host, not the command!
Having checked that the command syntax hadn't changed between JNOS versions,
I checked the 1.01 and 1.07 sources in the appropriate areas - identical!
The section of code concerned is in the function "doremote" in file "MAIN.C".
A part of this function reads:
char *host,*cmd;
.....
host = argv[optind++];
cmd = argv[optind];
where 'optind' is an index for the command options (used by getopt).
Putting a few printf's in after these lines gives the following info when
'remote g8fsl kick' is issued:
argv[1] = g8fsl argv[2] = kick host = g8fsl cmd = g8fsl optind = 2
So everything is correct, =except= that cmd is pointing to the wrong argument,
hence the "Unknown command g8fsl" message.
But optind is correct...
I then tried putting some printf's around the assignments:
printf("%u\n",optind);
host = argv[optind++];
printf("%u\n",optind);
cmd = argv[optind];
Issuing the "remote g8fsl kick" command gives the printout:
1
2
followed by, yes, you've guessed;
argv[1] = g8fsl argv[2] = kick host = g8fsl cmd = kick optind = 2
^^^^
and the command working correctly!
I've fixed the problem now by doing:
char *host,*cmd;
int optindcopy;
.....
optindcopy = optind;
host = argv[optindcopy++];
cmd = argv[optindcopy];
but I don't really see why the problem exists. I thought at first it was
the re-reading of optind that fixes the problem, but it isn't.
I've subsequently found that at least one other user of JNOS 107b in my
local area has found that the remote command doesn't work in his build
(using BC++ v3.1).
I'm totally puzzled as to what's going on, but I offer the information in
case anyone else is suffering from the same problem.
Anyway, I'm very happy with my new JNOS. My regards to all concerned,
Andrew Benham
--------------------------------------------------------------------
adsb@bnr.co.uk BNR Europe Ltd, London Road, Harlow, Essex CM17 9NA
+44 279 402372 Fax: +44 279 402100
Home: g8fsl@g8fsl.ampr.org [44.131.19.195] G8FSL@GB3XP
--------------------------------------------------------------------
------------------------------
Date: Sun, 10 Jan 93 17:56:28 MST
From: Larsen Karl VAL-C 678-3145 <klarsen@curie.UCSD.EDU>
Subject: Returned mail: User unknown (fwd)
To: tcp-group@ucsd.edu
>
> ----- Transcript of session follows -----
>
> While connected to ucsd.edu [128.54.16.1] (tcp):
> >>> RCPT To:<tcpip-group@ucsd.edu>
> <<< 550 <tcpip-group@ucsd.edu>... User unknown
> 550 tcpip-group@ucsd.edu... User unknown
>
>
> ----- Unsent message follows -----
> Received: by dirac
> (16.6/16.2) id AA25942; Sun, 10 Jan 93 17:51:43 -0700
> From: Larsen Karl VAL-C 678-3145 <klarsen@dirac>
> Return-Path: <klarsen@dirac>
> Subject: AA4RE and Windows
> To: tcpip-group@ucsd.edu
> Date: Sun, 10 Jan 93 17:51:42 MST
> Mailer: Elm [revision: 66.25]
>
> I have been reading about the idea to have Roy write a version
> of his fine bbs as a windows program. I don't think that is necessary or
> worth the work. Here is what I am doing at this time:
>
> I have a 386-25 with 4 meg ram and have AA4RE ver 12.* in a
> window and JNOS105 in another and Opus 173a in another and all three
> software are not windows compatable but do run well in a *.pif defined
> partition. Since I am part of the packet network I am running the
> wonderful G8BPQ Switch ver 1.46a and have AA4RE and JNOS105 attached to
> the switch. It seems to my uneducated eye to be working fine.
>
> I have been told by other hams that windows does not multitask.
> It can only pretend to do so. Well it does a fine job of pretending. and
> I think those who doubt it works listen to this:
>
> For better or for worse this computer uses a intel 386 cpu that
> is interupt driven. There is no magic way to do things any better than
> windows does to do what it does. Period.
>
> 73, karl k5di@k5di
>
>
>
------------------------------
Date: Mon, 11 Jan 93 10:15:10 GMT
From: Alan Cox <iiitac@pyr.swan.ac.uk>
Subject: Stability
To: tcp-group@ucsd.edu
I've run NOS in various forms as just a router. Its stable with enough
free memory and so long as you don't run some of the buggy application
code on top. To fix NOS requires a pretty major rewrite and from
previous conversation topics on here, people know how to do it, but nobody
has the time.
Alan
------------------------------
Date: Mon, 11 Jan 93 09:44:18 GMT
From: Alan Cox <iiitac@pyr.swan.ac.uk>
Subject: Unwanted mail
To: andy@mimuw.edu.pl, tcp-group@ucsd.edu
Its trivial to add. You just put an extra check of username against a file
in the validate_address code for local addresses.
Alan
------------------------------
Date: Mon, 11 Jan 93 11:58:00 MET
From: Martin W Freiss <freiss.pad@sni.de>
Subject: WHAT IS SMACK ?
To: tcp-group@ucsd.edu
Barry Titmarsh writes:
> it seems to be in new netrom type or tnc type boxes
> some talk about it has been seen in Germany for past 6 months
> but i have never gotten a sensible reply for any one.
> Any Idears? Please
Well, I don't know if my reply is sensible, but from memory...
------------------------------
Date: 10 Jan 1993 15:14:18 -0500 (EST)
From: "Brian A. Lantz" <BRIANLANTZ@delphi.com>
To: johan@ECE.ORST.EDU
MID - Revisited, finished, moving on...
Here is the "absolute" fix to the MID problem. These few lines make a brand
new MID for each message (after the first) generated from an incoming message.
This works equally well with CC's, aliases, etc. The first message in a list
retains the original MID, all others get new numbers.
Ignore previous hack and apply this fix.
All changes are in SMTPSERV.C. The line numbers given are for WG7J107b.
insert lines with '>>', change lines with "**"
smtpserv.c at line 493
extern int Smtpquiet;
>> int index;
if ((Smtpmode & QUEUE) != 0)
smtpserv.c at line 528
#endif
>> index = 0;
** for(ap = tolist;ap != NULLLIST;ap = ap->next, index++){
smtpserv.c at line 584
}
>> if (index && htype(buf) == MSGID) {
>> fprintf (fp, "%s<%ld@%s>\n",Hdrs[MSGID],get_msgid(),Hostname);
>> } else
fputs(buf,fp);
73 from Brian A. Lantz KO4KS@KO4KS.#TPAFL.FL.USA.NA 3100813105
Internet: brianlantz@delphi.com
Amprnet: ko4ks@ko4ks.ampr.org [44.98.0.167]
------------------------------
Date: Mon, 11 Jan 93 09:56:03 GMT
From: Alan Cox <iiitac@pyr.swan.ac.uk>
To: tcp-group@ucsd.edu
Another approach to the windows com port problem is to use a windows
to packet driver interface (waterloo tcp has an example of this), and
use the slip8250 driver in AX.25 mode. This approach could be used
on creating a windows callback layer for BPQ if neccessary.
Be warned windows programming is very different to DOS
Alan
------------------------------
Date: (null)
From: (null)
------------------------------
End of TCP-Group Digest V93 #11
******************************
******************************