Date: Sat, 15 May 93 04:30:09 PDT
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 #125
To: tcp-group-digest
TCP-Group Digest Sat, 15 May 93 Volume 93 : Issue 125
Today's Topics:
8530 Cards -- will trade for code
Bug in BPQ ? (2 msgs)
Correction to ppplcp.c for configuration bug
WAMPES and BPQ
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: Fri, 14 May 93 11:10:34 EDT
From: "John R. Ackermann" <jra@law7.daytonoh.ncr.com>
Subject: 8530 Cards -- will trade for code
To: tcp mailing list <tcp-group@ucsd.edu>,
Our group got hold of a bunch (about 40) of 8530 SCC-based
communications cards (they were used for IBM 2730 and RJE emulation in a
PC). It appears that they should work with NOS by a) bypassing the
RS232 drivers so a TTL level is available, and b) probably changing the
clock frequency to get a proper division to our baud rates (the current
crystal is at 6.something MHz, I think, to generate 64kB).
The boards support DMA transfers, but I am told that (at least for their
intended application) the rev level I have doesn't do DMA properly. I
don't know if there's a software or hardware (other than getting new
PALs) workaround that would make the DMA transfer work with something
like the PI driver.
I've played around a little with the cards, and they seem to
almost-but-not-quite work with the generic SCC driver. I have too many
things on my plate (and too few helpers) to be able to finish up the job
of interfacing these things to NOS, either with the SCC or DMA drivers.
Under the terms of the deal under which we got the cards, we can't
resell them but we'd be very willing to give several to someone who
would finish (and document) the work necessary to use these as an SCC
card under NOS. We might also be able to trade some for other hardware...
If anyone's interested, let me know.
John
------------------------------
Date: Fri, 14 May 1993 11:15:56 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: Bug in BPQ ?
To: g4klx@g4klx.demon.co.uk, tcp-group@ucsd.edu
Regardless of the quality of code from G8BPQ, my general practice in fixing
bugs and incompatibilities in the NOS netrom implementation has been to use
G8BPQ as a de facto standard. This was how I fixed the TxSeq bug in NOS a
couple of months ago, for example.
Speaking as someone who has done a lot of work with the NOS netrom code,
which isn't actively worked on by anyone whom I know about, it is extremely
buggy. NOS still does not correctly process L4 ACKs, and it sends out many
redundant L4 I-frames which have already been ACK'ed. In some case, the
only check on NOS behavior is the exhaustion of the window size or the
qlimit kicking in.
I happen to think that the G8BPQ software is very solid and well written.
However, even if it is not, it is unquestionably more solid than NOS netrom.
-- Mike Bilow, <mikebw@ids.net> (Internet)
N1BEE @ WA1PHY.#EMA.MA.USA.NA (AX.25)
------------------------------
Date: Fri, 14 May 1993 23:59:51 -0400
From: "Brandon S. Allbery" <bsa@kf8nh.UCSD.EDU>
Subject: Bug in BPQ ?
To: tcp-group@ucsd.edu
Johan Reinalda, WG7J, has reworked NOS netrom support extensively in his JNOS
releases. I don't claim that they're bug-free, especially since we don't talk to
any netrom nodes locally so I don't bother to compile it in, but quite a few JNOS
users seem to be using his netrom code without problems.
Meanwhile, last I heard WA8BXN was *still* fixing netrom bugs in MSYS, so we
certainly aren't the only ones struggling with it :-)
++Brandon
------------------------------
Date: Fri, 14 May 93 12:26:34 -0700
From: "Dana H. Myers" <dana@fafnir.la.locus.com>
Subject: Correction to ppplcp.c for configuration bug
To: tcp-group@ucsd.edu
Hey gang,
I finally had a chance to try using PPP with NOS (the WG7J 1.07b version).
I found that my NOS machine would not configure with our dialup router.
The problem was that the router was requesting authentication using CHAP
and NOS was attempting to negotiate PAP. However, in ppplcp.c, the code
which changes the authentication configuration option was corrupting the
option. This resulted from calling put16() to insert two octets in the
buffer, then copying the optional data from the CHAP option over the
authentication value.
If anyone has questions or comments, please feel free to contact me at
the e-mail address or telephone number below.
The following fragment of code in the lcp_option() function from JNOS
1.07b, with the simple bug fix:
----- start of included code -----
static void
lcp_option( bpp, value_p, o_type, o_length, copy_bpp )
struct mbuf **bpp;
struct lcp_value_s *value_p;
byte_t o_type;
byte_t o_length;
struct mbuf **copy_bpp;
{
struct mbuf *bp;
register char *cp;
register int toss = o_length - OPTION_HDR_LEN;
if ((bp = alloc_mbuf(o_length)) == NULLBUF) {
return;
}
cp = bp->data;
*cp++ = o_type;
*cp++ = o_length;
switch ( o_type ) {
case LCP_MRU:
cp = put16(cp, value_p->mru);
toss -= 2;
#ifdef PPP_DEBUG_OPTIONS
if (PPPtrace & PPP_DEBUG_OPTIONS)
trace_log(PPPiface, " making MRU: %d", value_p->mru);
#endif
break;
case LCP_ACCM:
cp = put32(cp, value_p->accm);
toss -= 4;
#ifdef PPP_DEBUG_OPTIONS
if (PPPtrace & PPP_DEBUG_OPTIONS)
trace_log(PPPiface, " making ACCM: 0x%08lx", value_p->accm);
#endif
break;
case LCP_AUTHENT:
cp = put16(cp, value_p->authentication);
toss -= 2;
#ifdef PPP_DEBUG_OPTIONS
if (PPPtrace & PPP_DEBUG_OPTIONS)
trace_log(PPPiface, " making Auth Protocol: 0x%04x",
value_p->authentication);
#endif
break;
case LCP_MAGIC:
cp = put32(cp, value_p->magic_number);
toss -= 4;
#ifdef PPP_DEBUG_OPTIONS
if (PPPtrace & PPP_DEBUG_OPTIONS)
trace_log(PPPiface, " making Magic Number: 0x%08lx",
value_p->magic_number);
#endif
break;
case LCP_PFC:
#ifdef PPP_DEBUG_OPTIONS
if (PPPtrace & PPP_DEBUG_OPTIONS)
trace_log(PPPiface, " making Protocol compression");
#endif
break;
case LCP_ACFC:
#ifdef PPP_DEBUG_OPTIONS
if (PPPtrace & PPP_DEBUG_OPTIONS)
trace_log(PPPiface, " making Addr/Ctl compression");
#endif
break;
case LCP_ENCRYPT: /* not implemented */
case LCP_QUALITY: /* not implemented */
default:
#ifdef PPP_DEBUG_OPTIONS
if (PPPtrace & PPP_DEBUG_OPTIONS)
trace_log(PPPiface, " making unimplemented type %d", o_type);
#endif
break;
};
while ( toss-- > 0 ) {
*cp++ = pullchar(copy_bpp);
}
bp->cnt += o_length;
append(bpp, bp);
}
----- end of included code -----
* Dana H. Myers KK6JQ | Views expressed here are *
* (310) 337-5136 | mine and do not necessarily *
* dana@locus.com DoD #466 | reflect those of my employer *
* This Extra supports the abolition of the 13 and 20 WPM tests *
* "Dammit Bones, spare me the lecture and give me the shot!" *
------------------------------
Date: Fri May 14 10:33:11 1993
From: iiitac@pyr.swan.ac.uk
Subject: WAMPES and BPQ
To: tcp-group@ucsd.edu
I can describe exactly what I see off two stations using BPQ 4.01 (quite old).
That is netrom connect packets that are 2 bytes longer than WAMPES expects.
Changing WAMPES to say netrom connect requests must be n bytes or larger stopped
the incompatibility. I have mailed G8BPQ via packet with a report and will see
what he says.
What I don't know is whether BPQ is wrong in adding a pair of private bytes
to the connect request, or whether WAMPES is wrong in not accepting packets
with unspecified private data tacked on the end of connect requests.
Is there a paticular reason WAMPES checks the connection request size precisely
KA9Q doesn't, TheNET doesn't and WAMPES only checks that one type of frame
carefully.
Alan
------------------------------
End of TCP-Group Digest V93 #125
******************************
******************************