Date: Tue, 30 Mar 93 04:30:09 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 #82
To: tcp-group-digest
TCP-Group Digest Tue, 30 Mar 93 Volume 93 : Issue 82
Today's Topics:
Internet gsteway
ka9q telnet linemode support
Marshall Rose on OSI
TCP-Group Digest V93 #80 (2 msgs)
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: Mon, 29 Mar 93 10:28:22 MST
From: "Marvin Match" <match@[128.110.44.31]>
Subject: Internet gsteway
To: keithm@wicat.com, tcp-group@ucsd.edu
>
>Date: Fri, 26 Mar 1993 18:46:59 GMT
>From: mvb.saic.com!unogate!news.service.uci.edu!usc!zaphod.mps.ohio-state.edu!darwin.sura.net!sgiblab!spies!wicat!keithm@network.UCSD.EDU
>Subject: Internet Gateway
>To: packet-radio@ucsd.edu
>
>My office mates and I are preparing to put in a packet/internet
>gateway in our office.
Keith, this is great!, but how about trying to co-ordinate with the rest
of the Utah packet community. Have you been following the the discussions
about developements in Utah? I'll try to fill you in.
1. Recently, (last 2 or 3 months) we've had an increadable amount
of INTER-CLUB discussion about the current state of the packet
radio network in Utah. Representatives from UPRA, UARC, UUARC,
BYUARC, VHF society, TCP-IP Users Group, Utah County ARES,
The State of Utah, and others have voiced their disappointment
in the current state of affairs, and have pledged time and
money to correct the problems. As we look into things we're
finding that most of the problems we see (frequent collisions,
high traffic caused by bbs transfers, etc., you name it) are
a result of thinking that "Well, the packet net is grinding to a
halt, therfore we need to add more nodes to handle more traffic"
and of course this compounds the problem because it doesn't
provide a better path, just adds traffic.
2. There is already an Internet gateway going in at BYU. It'll
likely land on 70cm. and provide 9600 baud access.
3. We have asked John Lloyd for additional freqs. in the past as
individuals, and he has (rightly so) commented that "I'm willing
to co-ordinate more freqs. for packet, but before I do, maybe
we should get the blessing of the other groups, so as to assure
that everyone agrees that this is the thing to do."
To this end, we (read group of various Utah ham clubs) will
(or maybe have by now) ask John for at least one additional
2M freq. for Utah county, and 1 or 2 addititional 70cm freqs. for
Utah county. This way ARES can have 145.03 all to themselves.
4. I proposed to the group that we build a real backbone through
Utah. (I know, this has been talked about before) My plan calls
for full-duplex, 1.5Mbps, microwave relay stations crossing the
state East to West and North to South, with access nodes in
each major population center, providing 56Kbps, and 9600bps
spigots. To date, this plan has been recieved well enough that
funds have been committed to study the proposal and to build
a prototype. I've repeatedly posted to tcp-group asking for
comments, and most of the responses have been in agreement with
the plan.
Now, in the interest of Internet bandwidth, I'll come back to earth
>We have an ethernet connection in the office
>and would like to gateway this to packet (probably on 2m).
>
Assuming that this is the best use of this resource (I'm not convinced
that it is). How about considering 70cm, 9600 or 19.2K bps, and let
another node (or two, or three) service the 1200 baud 2M guys and
funnel that traffic to you at the higher rate?
>I have a few questions that are un answered at this point, but mostly
>what I would like is to correspond via e-mail to someone who has done
>this.
>
We are currently bringing an Internet-packet gateway on line here at
the University of Utah. We're using JNOS 108c. We've had mucho problemo
getting this thing to work. It's been a couple of months in the making,
so I hope you guys have alot of time. Are you familiar with NOS?
To be fair, many of the problems we've been chasing are a result of
using an HP9000-S850 to provide a SLIP link. We've recently aquired
an ethernet card (thanks Matt!) so we'll soon abandon the HP.
>My current thoughts are to use the KA9Q NOS as the gateway running
>on a spare 286 PC that we have.
This'll work, but you need 640K base mem and a Meg or so of extended
or the machine will spend all of it's time pounding its hard drive to
death.
>I understand that NOS can talk
>to a KISS mode TNC as well as to ethernet, but may require Clarkson
>drivers for the ethernet. Do these drivers come with NOS? If not
>can I FTP them from somewhere?
>
Depends on the particular ethernet card. Tell me what card you have. I
probably have the driver, or I can tell you where to ftp it from.
>Anyone care to elmer me through this project?
>
Sure. As long as you're willing to co-ordinate with the rest of us! I think
this is where the discussion should start.
Please get involved with us. We need everyone's input. I hope my earlier
comments don't dissuade you and your office-mates. Things always look
harsher in print than intended. My point is, that I would like to see you
do something that can be integrated into the overall plan.
>Thanks!
>
>--
> Keith McQueen, Wicat Systems Inc. , (801)224-6400 | My opinions are |
> Packet: n7hmf @ nv7v.UT.USA.NA | all mine... |
> Internet: keithm@wicat.com | ...so there! |
>
>------------------------------
My pleasure,
Marvin Match
KA7TPH
------------------------------
Date: Mon, 29 Mar 1993 17:54:11 -0500
From: cep4478@ultb.isc.rit.edu (C.E. Piggott )
Subject: ka9q telnet linemode support
To: tcp-group@ucsd.edu
Can anybody more qualified than me assess how much work it would be to
implement RFC-1184 (and the other references to telnet LINEMODE) into
the incoming telnet support (mailbox) of NOS?
On our IBM AIX 3.2 machine, telnetting into the NOS switch means you
don't have backspace, kill, etc. processing, unless you escape back to
telnet and type:
telnet> mode line-by-line
however, if the NOS mailbox requested line mode prior to asking for the
username, it would work OKAY.
Chris
------------------------------
Date: Mon, 29 Mar 93 11:31:49 -0800
From: brian (Brian Kantor)
Subject: Marshall Rose on OSI
To: tcp-group
"... OSI is effectively dead, and is therefore unlikely to exhibit any
positive influence on the market. [...] the author merely notes that,
although he has spent a lot of time working with OSI, he's come to the
conclusion that OSI is now more of a problem than a solution. True,
there are some good ideas there, but these are overshadowed by many
more bad ideas. So, perhaps the future of OSI is that we will scavange
bits and pieces of it, but the author believes that OSI as a whole has
already reached its apogee and is now approaching the 'crash and burn'
phase."
- Marshall T. Rose, _The Internet Message_, p19
------------------------------
Date: Mon, 29 Mar 93 10:08:55 EST
From: Postmaster@alis3.daytonoh.ncr.com
Subject: TCP-Group Digest V93 #80
To: tcp-group@ucsd.edu
Returned Mail: Could not find any To: or Cc: recipients.
*** Returned Mail Message Follows: ***
------------------------------
Date: Sun, 28 Mar 93 04:30:11 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Subject: TCP-Group Digest V93 #80
To: tcp-group-digest@ucsd.edu
TCP-Group Digest Sun, 28 Mar 93 Volume 93 : Issue 80
Today's Topics:
Ftpmotd in jnos v108d (2 msgs)
G8BPQ with IP Router
KA9Q NOS questions... (2 msgs)
TCP-Group Digest V93 #79 (2 msgs)
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: Sat, 27 Mar 93 17:43:49 EST
From: Steve Urich <beyonet!steve@gvls1.VFL.Paramax.COM>
Subject: Ftpmotd in jnos v108d
To: TCP-Group@ucsd.edu
Hello, for those of you who are interested I have changed the
ftpmotd in jnos ftpserv to conform to internet standards. I
have put the motd in my version of net and also in a version
of pa0gri. It works with most of the original ka9q ftpcli
including net and most nos except the jnos client with has
a verbose default problem that somebody changed. I sent my
changes to Johan and explained the problem. Its due to the
client remaining quiet till a remote command is ordered
giving it a V_NORMAL verbose. Then the ftpmotd gets shown
when a data port is able to be read verbose. It works normal
with net and other versions of nos clients showing the motd
at 230 AFTER the login as it should be. I mainly changed the
motd routine and added it also to my server because of the
way it was sent out at 220 breaking my ka9q net client. Since
I don't have a dos box to compile jnos I can't fix the jnos
client myself without some debugging since the initial test
with wa3dsp Doug has proven to be ok with my client by a
slight difference in the jnos client because of its verbose.
Since I can't debug and compile jnos because I don't have
a dos box I had wa3dsp compile it for me. It worked ok for
me but the jnos client was coded differently then the vanilla
client code. It looks easy enough to debug if I had a dos
machine an compiler. Here are the diffs to the change from
220 to 230 for the motd.
73 - Steve
----Start `diff -c' ftpserv.c v1.08d----
*** ftpserv.old Wed Mar 24 18:20:45 1993
--- ftpserv.new Fri Mar 26 01:26:59 1993
***************
*** 55,62
};
/* Response messages */
! static char banner[] = "220- %s, KA9Q-NOS FTP version %s\n";
! static char banner1[] = "220 Ready on %s";
static char badcmd[] = "500 Unknown command\n";
static char binwarn[] = "100 Warning: type is ASCII and %s appears to be
binary\n";
static char unsupp[] = "500 Unsupported command or option\n";
--- 55,62 -----
};
/* Response messages */
! static char banner[] = "220 %s, KA9Q-NOS FTP version %s\n";
! static char banner1[] = "230 Ready on %s";
static char badcmd[] = "500 Unknown command\n";
static char binwarn[] = "100 Warning: type is ASCII and %s appears to be
binary\n";
static char unsupp[] = "500 Unsupported command or option\n";
***************
*** 173,179
long t;
int cnt,i;
struct sockaddr_in socket;
- FILE *fp;
sockmode(s,SOCK_ASCII);
memset((char *)&ftp,0,sizeof(ftp)); /* Start with clear slate */
--- 173,178 -----
long t;
int cnt,i;
struct sockaddr_in socket;
sockmode(s,SOCK_ASCII);
memset((char *)&ftp,0,sizeof(ftp)); /* Start with clear slate */
***************
*** 197,209
log(s,"open FTP");
usprintf(s,banner,Hostname,Version);
- if((fp = fopen(Ftpmotd,"r")) != NULL) {
- while(fgets(buf,128,fp)) {
- rip(buf);
- usprintf(s,"220- %s\n",buf);
- }
- fclose(fp);
- }
time(&t);
cp = ctime(&t);
--- 196,201 -----
log(s,"open FTP");
usprintf(s,banner,Hostname,Version);
time(&t);
cp = ctime(&t);
***************
*** 211,218
if((cp1 = strchr(cp,'\n')) != NULLCHAR)
*cp1 = '\0';
#endif
-
- usprintf(s,banner1,cp);
loop: if((cnt = recvline(s,buf,sizeof(buf))) == -1){
/* He closed on us */
--- 203,208 -----
if((cp1 = strchr(cp,'\n')) != NULLCHAR)
*cp1 = '\0';
#endif
loop: if((cnt = recvline(s,buf,sizeof(buf))) == -1){
/* He closed on us */
***************
*** 568,574
struct ftpserv *ftp;
char *pass;
{
! char *path;
char *p;
int anony = 0;
--- 558,564 -----
struct ftpserv *ftp;
char *pass;
{
! char *path,buf[128],*cp;
char *p;
long t;
FILE *fp;
***************
*** 570,575
{
char *path;
char *p;
int anony = 0;
path = mallocw(200);
--- 560,567 -----
{
char *path,buf[128],*cp;
char *p;
+ long t;
+ FILE *fp;
int anony = 0;
path = mallocw(200);
***************
*** 590,595
if((p = strchr(path,';')) != '\0')
*p = '\0'; /* delimit initial cd */
#endif
if(!anony){
usprintf(ftp->control,logged);
--- 582,598 -----
if((p = strchr(path,';')) != '\0')
*p = '\0'; /* delimit initial cd */
#endif
+ time(&t);
+ cp = ctime(&t);
+ usprintf(ftp->control,banner1,cp);
+
+ if((fp = fopen(Ftpmotd,"r")) != NULL) {
+ while(fgets(buf,sizeof(buf),fp)) {
+ rip(buf);
+ usprintf(ftp->control,"230- %s\n",buf);
+ }
+ fclose(fp);
+ }
if(!anony){
usprintf(ftp->control,logged);
---End of diff cut here---
--
|Stephen Urich| Internet:steve@zero.com | "Cattle mutilations |
|NIC: SU2 | UUCP:uunet!beyonet!steve | are up!" --Sneakers |
|ARS: WB3FTP | Packet:WB3FTP@WB3FTP.#EPA.PA.USA.NOAM | ax25<->PBBS<->IPGATE|
|Bensalem, PA |Radio:wb3ftp@wb3ftp.ampr.org[44.80.8.44]| TCP/IP-FTP-SMTP-UNIX|
------------------------------
Date: Sat, 27 Mar 93 17:43:49 EST
From: Steve Urich <beyonet!steve@gvls1.VFL.Paramax.COM>
Subject: Ftpmotd in jnos v108d
To: TCP-Group@ucsd.edu
Hello, for those of you who are interested I have changed the
ftpmotd in jnos ftpserv to conform to internet standards. I
have put the motd in my version of net and also in a version
of pa0gri. It works with most of the original ka9q ftpcli
including net and most nos except the jnos client with has
a verbose default problem that somebody changed. I sent my
changes to Johan and explained the problem. Its due to the
client remaining quiet till a remote command is ordered
giving it a V_NORMAL verbose. Then the ftpmotd gets shown
when a data port is able to be read verbose. It works normal
with net and other versions of nos clients showing the motd
at 230 AFTER the login as it should be. I mainly changed the
motd routine and added it also to my server because of the
way it was sent out at 220 breaking my ka9q net client. Since
I don't have a dos box to compile jnos I can't fix the jnos
client myself without some debugging since the initial test
with wa3dsp Doug has proven to be ok with my client by a
slight difference in the jnos client because of its verbose.
Since I can't debug and compile jnos because I don't have
a dos box I had wa3dsp compile it for me. It worked ok for
me but the jnos client was coded differently then the vanilla
client code. It looks easy enough to debug if I had a dos
machine an compiler. Here are the diffs to the change from
220 to 230 for the motd.
73 - Steve
----Start `diff -c' ftpserv.c v1.08d----
*** ftpserv.old Wed Mar 24 18:20:45 1993
--- ftpserv.new Fri Mar 26 01:26:59 1993
***************
*** 55,62
};
/* Response messages */
! static char banner[] = "220- %s, KA9Q-NOS FTP version %s\n";
! static char banner1[] = "220 Ready on %s";
static char badcmd[] = "500 Unknown command\n";
static char binwarn[] = "100 Warning: type is ASCII and %s appears to be
binary\n";
static char unsupp[] = "500 Unsupported command or option\n";
--- 55,62 -----
};
/* Response messages */
! static char banner[] = "220 %s, KA9Q-NOS FTP version %s\n";
! static char banner1[] = "230 Ready on %s";
static char badcmd[] = "500 Unknown command\n";
static char binwarn[] = "100 Warning: type is ASCII and %s appears to be
binary\n";
static char unsupp[] = "500 Unsupported command or option\n";
***************
*** 173,179
long t;
int cnt,i;
struct sockaddr_in socket;
- FILE *fp;
sockmode(s,SOCK_ASCII);
memset((char *)&ftp,0,sizeof(ftp)); /* Start with clear slate */
--- 173,178 -----
long t;
int cnt,i;
struct sockaddr_in socket;
sockmode(s,SOCK_ASCII);
memset((char *)&ftp,0,sizeof(ftp)); /* Start with clear slate */
***************
*** 197,209
log(s,"open FTP");
usprintf(s,banner,Hostname,Version);
- if((fp = fopen(Ftpmotd,"r")) != NULL) {
- while(fgets(buf,128,fp)) {
- rip(buf);
- usprintf(s,"220- %s\n",buf);
- }
- fclose(fp);
- }
time(&t);
cp = ctime(&t);
--- 196,201 -----
log(s,"open FTP");
usprintf(s,banner,Hostname,Version);
time(&t);
cp = ctime(&t);
***************
*** 211,218
if((cp1 = strchr(cp,'\n')) != NULLCHAR)
*cp1 = '\0';
#endif
-
- usprintf(s,banner1,cp);
loop: if((cnt = recvline(s,buf,sizeof(buf))) == -1){
/* He closed on us */
--- 203,208 -----
if((cp1 = strchr(cp,'\n')) != NULLCHAR)
*cp1 = '\0';
#endif
loop: if((cnt = recvline(s,buf,sizeof(buf))) == -1){
/* He closed on us */
***************
*** 568,574
struct ftpserv *ftp;
char *pass;
{
! char *path;
char *p;
int anony = 0;
--- 558,564 -----
struct ftpserv *ftp;
char *pass;
{
! char *path,buf[128],*cp;
char *p;
long t;
FILE *fp;
***************
*** 570,575
{
char *path;
char *p;
int anony = 0;
path = mallocw(200);
--- 560,567 -----
{
char *path,buf[128],*cp;
char *p;
+ long t;
+ FILE *fp;
int anony = 0;
path = mallocw(200);
***************
*** 590,595
if((p = strchr(path,';')) != '\0')
*p = '\0'; /* delimit initial cd */
#endif
if(!anony){
usprintf(ftp->control,logged);
--- 582,598 -----
if((p = strchr(path,';')) != '\0')
*p = '\0'; /* delimit initial cd */
#endif
+ time(&t);
+ cp = ctime(&t);
+ usprintf(ftp->control,banner1,cp);
+
+ if((fp = fopen(Ftpmotd,"r")) != NULL) {
+ while(fgets(buf,sizeof(buf),fp)) {
+ rip(buf);
+ usprintf(ftp->control,"230- %s\n",buf);
+ }
+ fclose(fp);
+ }
if(!anony){
usprintf(ftp->control,logged);
---End of diff cut here---
--
|Stephen Urich| Internet:steve@zero.com | "Cattle mutilations |
|NIC: SU2 | UUCP:uunet!beyonet!steve | are up!" --Sneakers |
|ARS: WB3FTP | Packet:WB3FTP@WB3FTP.#EPA.PA.USA.NOAM | ax25<->PBBS<->IPGATE|
|Bensalem, PA |Radio:wb3ftp@wb3ftp.ampr.org[44.80.8.44]| TCP/IP-FTP-SMTP-UNIX|
------------------------------
Date: Sun, 28 Mar 93 09:00:50 GMT
From: g4klx@g4klx.demon.co.uk (Jonathan Naylor)
Subject: G8BPQ with IP Router
To: TCP-Group@ucsd.edu
Hi All
I put BPQ406E.ZIP into the wrong incoming directory. It is now in
/hamradio/packet/tcpip/incoming.
Sorry
Jonathan
------------------------------
Date: Sat, 27 Mar 1993 11:41:17 -0600 (CST)
From: gerry@cs.tamu.edu (Gerald J Creager)
Subject: KA9Q NOS questions...
To: tcp-group@ucsd.edu
I recently shipped this to the group, but I've seen neither the question, nor
any responses, so I guess it went to a bit bucket in the sky... Let's try
again.
I recently downloaded Phil's latest from ucsd.edu. I tried to bring it up
initially with an autoexec.nos configured for jnos 107b. With the exception of
the attach asy statement, I have changed nothing, but I'm seeing some
interesting anomolies and NEED some help.
1. Hardware config:
'386DX/'387, 4 Mb memory, 130 Mb hard disk, 3 Mb free on NOS logical drive, 6
Mb free on a separate logical drive for /temp.
2. Software Config:
QEMM/386, ansi.sys, the world loaded high, 633k available.
3. TNC config:
PacComm Tiny-2 with "node" (higher speed) parts, port speed 9600 baud, radio
speed 1200 baud, ROM rev. 1.1.6b (PacComm)
4. Recent history:
Works "fine" with jnos, older karncode (tm) and g1emmCode (tm). Worked fine at
higher radio rates with DataEngine testing last year.
5. Symptoms:
A. When I issue *ANY* sort of transmission, with trace turned on, I see an
ax.25 "bad header" message in trace.
B. Occassionally, say, <10% of the time, I see what looks to the code
(appparently) like a good ax.25 packet but is gibberish.
C. Other systems see the packets I'm pumping out, and they look normal to
them. A connect request using either native ax.25 or tcp/ip results in the
other system thinking it can really talk to me, but I cannot make sense of the
replys.
I have used both the ax25ui and ax25i constructs in the attaach asy command
line, with similar results. Since I haven't pulled down the source yet, I have
no "documentation" to work with... I need more disk space, and I'm working oin
that issue.
Anyone got thoughts? I was wondering if KISS wasn't compiled into the code,
possibly... If that's the case, I guess I need to learn something about RCS
and grab a copy of Borland C++ 3.x...
Thanks,
Gerry n5jxs
gerry@cs.tamu.edu
------------------------------
Date: Sat, 27 Mar 93 17:01:07 EST
From: Mike Gallaher <mg@bds.bds.com>
Subject: KA9Q NOS questions...
To: gerry@cs.tamu.edu (Gerald J Creager)
Try using "kissui" or "kissi" instead of "ax25ui"/"ax25i".
If you use ax25 encapsulation, it just sends raw ax25 packets to the
serial port, assuming that whatever hears them will transmit them
literally (like an 8530 card). If you use kiss encapsulation, it
prepends a kiss "data follows" byte to the ax25 packet; this is
what the TNC expects, to distinguish data from parameter-setting commands,
for instance. At least, that's what I've been able to glean from
looking at the source, and playing with it for a few minutes.
I haven't seen any documentation either.
mg
------------------------------
Date: Sat, 27 Mar 93 15:05:15 EST
From: Postmaster@alis3.daytonoh.ncr.com
Subject: TCP-Group Digest V93 #79
To: tcp-group@ucsd.edu
Returned Mail: Could not find any To: or Cc: recipients.
*** Returned Mail Message Follows: ***
------------------------------
Date: Sat, 27 Mar 93 04:30:06 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Subject: TCP-Group Digest V93 #79
To: tcp-group-digest@ucsd.edu
TCP-Group Digest Sat, 27 Mar 93 Volume 93 : Issue 79
Today's Topics:
3COM Sniffer
Anyone seen this problem before ? (2 msgs)
any System V release 3 ports of NOS/NET (KA9q)/slip
AX25 and Linux (2 msgs)
LAPB bugs
Latest BPQ with IP Router
TCP-Group Digest V93 #78 (2 msgs)
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, 26 Mar 93 11:28:05 EST
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: 3COM Sniffer
To: tcp-group@ucsd.edu
I put the file eprobe.zip in the ucsd.edu incoming. It is a PUBLIC
DOMAIN ethernet monitor program from 3COM for any of there ethernet
board products. It is a nifty way to monitor ethernet traffic on a
PC. It has filtering modes and detailed viewing.
I thought this might be of interest to the ampr group. If it is not
appropriate to have it on here then take it off.
Doug
------------------------------
Date: Fri, 26 Mar 93 10:10:09 CST
From: andyw@aspen.cray.com (Andy Warner)
Subject: Anyone seen this problem before ?
To: tcp-group@ucsd.edu (TCP Group)
Has anyone seen NOS behave in the following way ?
An interface is set up to work in datagram mode, but sometimes
NOS decides to start talking in VC mode (to just one or two
stations, not everyone on that interface). If the remote
station in question has jumpstart on, there's a timewasting
round of "Huh?", "Huh?", "Huh?".... until one or other gets bored
and drops the ax25 connection.
Things I know as facts :-
1. I'm running a very recent version of KA9Q (not JNOS, PA0GRI etc),
with some local mods, they might be the culprit, but I thought
I'd ask.
2. This has been going on for a while now, so the problem existed
with earlier NOS versions I used (PA0GRI based, I believe).
3. It is definately my station that initiates the VC mode, (I send
the SABM).
Observations that may or may not be true :-
1. I run a name server on my ethernet, and accesses by other stations
to the nameserver seem to cause the problem to occur most readily.
From the traces I have noticed that sometimes I will get an "ICMP
code port unreachable" when I issue a DNS reply, could this be that
NOS got bored waiting for my answer, and closed the port ?
2. I've never seen this happen to a TCP connection, only to UDP traffic.
If this sounds familiar to anyone, or if you've got any ideas, send
mail & I'll summarise. I hope to dive into the code this weekend...
--
andyw. N0REN/G1XRL
andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835
------------------------------
Date: Fri, 26 Mar 1993 12:31:34 -0600 (CST)
From: lcz@dptspd.sat.datapoint.com (Lee Ziegenhals)
Subject: Anyone seen this problem before ?
To: tcp-group@ucsd.edu (tcp/ip networking group)
>
>Has anyone seen NOS behave in the following way ?
>
>An interface is set up to work in datagram mode, but sometimes
>NOS decides to start talking in VC mode (to just one or two
Andy,
One thing that would cause this is for someone to send a datagram
with the "reliability" flag set (0x04) in the IP TOS field. JNOS will
send such datagrams in VC mode, regardless of the default "ax25 mode"
setting.
------------------------------
Date: Fri, 26 Mar 93 16:34:58 CST
From: "Erach A. Irani" <irani@cs.umn.edu>
Subject: any System V release 3 ports of NOS/NET (KA9q)/slip
To: tcp-group@ucsd.edu
--- If this is a repeat, please excuse me. I still cannot locate a
working implementation, and that seems highly unlikely to me ---
Hi,
I read that you have agreed to help out by being the
coordinator for the UNIX ports. have you heard of a sys 5 release 3
port of nos/net ka9q slip WHICH can allow me to login to the
originating machine and do UNIX'ish work (rather than talk alone).
A limited number of logins is all I need.
Thanks,
erach
------------------------------
Date: Fri, 26 Mar 93 08:22:10 CST
From: Brian K. Teravskis <brian@smedley.telex.mn.org>
Subject: AX25 and Linux
To: tcp-group@ucsd.edu
Is anyone working on getting AX25 incorporated
into the Linux kernel or is KA9Q the only way
to go for now??
Thanks..
Brian
------------------------------------------------------------------------------
Brian K. Teravskis | Internet: brian@smedley.telex.mn.org
Telex Communications, Inc | brian@hercules.vware.mn.org
Bloomington, MN 55420 | AMPRNET: brian@hercules.wd0efl.tcman.ampr.org
------------------------------------------------------------------------------
------------------------------
Date: Fri, 26 Mar 1993 09:50:10 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: AX25 and Linux
To: "Brian K. Teravskis" <brian@smedley.telex.mn.org>
Right now, you must run a KA9Q variant such as WAMPES under Linux,
because the various people who have been hacking in AX.25 drivers
aren't ready to release them. We're waiting for the SLIP modifications
to the kernel (mostly STREAMS support) to stabilize, as we want to use
some of that to support AX.25. Also, the Linux TCP/IP implementation is
still being debugged - the original developer has left the effort in a
huff due to too much criticism, and others are now posting about one
bug-fix a day.
I find that running KA9Q under Linux is much more comfortable than
running KA9Q on DOS, simply because of the multi-tasking - I can do
something else with the computer while KA9Q is running, and if KA9Q
dies it doesn't crash the system.
It is going to be nice when we can abandon the monolithic structure of
NOS, and break the system into separate processes. I find it much easier
to modify and debug that way.
Bruce Perens KD6OTD
On Fri, 26 Mar 1993, Brian K. Teravskis wrote:
> Is anyone working on getting AX25 incorporated
> into the Linux kernel or is KA9Q the only way
> to go for now??
>
> Thanks..
>
> Brian
>
> ------------------------------------------------------------------------------
> Brian K. Teravskis | Internet: brian@smedley.telex.mn.org
> Telex Communications, Inc | brian@hercules.vware.mn.org
> Bloomington, MN 55420 | AMPRNET: brian@hercules.wd0efl.tcman.ampr.org
> ------------------------------------------------------------------------------
>
>
------------------------------
Date: Fri, 26 Mar 93 14:29:55 PST
From: psm%helios.nosc.mil@nosc.mil (Scot McIntosh)
Subject: LAPB bugs
To: tcp-group@ucsd.edu
Following are some bugs and deficiencies that I've found in the LAPB
code, which a couple of group members have requested that I post.
Excuse the extra-wide format. Hope it doesn't make this unreadable
for some.
------------------------------
Date: Fri, 26 Mar 93 19:04:03 GMT
From: g4klx@g4klx.demon.co.uk (Jonathan Naylor)
Subject: Latest BPQ with IP Router
To: TCP-Group@ucsd.edu
On incoming as ucsd.edu is the latest version of G8BPQs switch software,
BPQ406E.ZIP. In it is included the first release of his IP router software
that operates as an application above the switch. It has been in beta testing
for quite a while in our local packet area with good results. John has added
a protocol for auto routing between his switches.
Could somebody move it from incoming to the g8bpq directory please.
John G8BPQ can now be reached at g8bpq@g4klx.demon.co.uk
73's
Jonathan
------------------------------
Date: Fri, 26 Mar 93 11:02:08 EST
From: Postmaster@alis3.daytonoh.ncr.com
Subject: TCP-Group Digest V93 #78
To: tcp-group@ucsd.edu
Returned Mail: Could not find any To: or Cc: recipients.
*** Returned Mail Message Follows: ***
------------------------------
Date: Fri, 26 Mar 93 04:30:11 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Subject: TCP-Group Digest V93 #78
To: tcp-group-digest@ucsd.edu
TCP-Group Digest Fri, 26 Mar 93 Volume 93 : Issue 78
Today's Topics:
New nos version PA0GRI
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, 26 Mar 93 10:08:02 MET
From: gvdg@tophat.cdh.cdc.com
Subject: New nos version PA0GRI
To: tcp-group@ucsd.edu
Hello All,
Just before going i loaded my latest work on NOS onto ucsd.edu
Main work lately was on tcp and ip access code.
The c command help display now correctly displays the possible commands
for the various compile options of mailbox.c
Now i am all set to get "lost" in the big lands and have a good time.
>>>For all who wrote me a message: I took all notes with me and use them
as time and place comes by. Freq for simplex is 145.520 (i forgot the
30kc channel space.) Thanks all those responded , to nummerous to get back
to individualy (sorry).
Please have funn, i will.
Regards, Gerard.
--
Internet: gvdg@cdc.com | Gerard J van der Grinten
UUCP: gvdgpc!gvdg | Control Data Bv.
Telephone: 0(+31)-15-153123 | Olaf Palmestraat 20
| 2616 LS DELFT Netherlands
------------------------------
End of TCP-Group Digest V93 #78
******************************
------------------------------
Date: (null)
From: (null)
Start
File Line Function Description
lapb.c 168 lapb_input The following code fragment is part of
the processing for
the LAPB_CONNECTED state. 'control'
contains
the complete control field from an
incoming frame, which,
in the case of an RNR, has an N(R)
field. Therefore, the
control == RNR test fails when the N(R)
field of the RNR
contains nonzero. Change 'control' to
'type' to fix this.
case RR:
case RNR:
axp->flags.remotebusy = (control == RNR) ?
YES : NO;
if(poll)
enq_resp(axp);
ackours(axp,nr);
break;
lapb.c 371 ackours The ackours() function returns a -1
value to cause a
FRMR if an acknowledgement is received
for an unsent frame.
None of the routines calling ackours
pays any attention to
the return value. Suggest modifying
ackours to send the FRMR
itself:
static int
ackours(axp,n)
struct ax25_cb *axp;
int16 n;
{
struct mbuf *bp;
int acked = 0; /* Count of frames
acked by this ACK */
int16 oldest; /* Seq number of
oldest unacked I-frame */
int32 rtt,abserr;
/* Free up acknowledged frames by
purging frames from the I-frame
* transmit queue. Start at the
remote end's last reported V(r)
* and keep going until we reach the
new sequence number.
* If we try to free a null pointer,
* then we have a frame reject
condition.
*/
oldest = (axp->vs - axp->unack) &
MMASK;
while(axp->unack != 0 && oldest !=
n){
>> if((bp = dequeue(&axp->txq)) ==
NULLBUF){
>> /* Acking unsent frame */
>> sendfrmr(axp, axp->control,
LAPB_RESPONSE, axp->pf, Z);
>> return -1;
}
Remainder of routine is same. The
arguments to sendfrmr are
the offending packet's control and
pf fields, an indication
that this is a response, and the
reason for the FRMR.
Note: have to add 'control' and
'pf' fields to struct ax25_cb and
fill them with the control
and pf fields of the offending
incoming frame. Also, the X.25
standard specifies that after
sending an FRMR, the DCE enters into
a frame rejection condition and
waits for a SABM, DISC, or DM
from the DTE (this is an
abbreviated description of what the
standard really says). Suggest
adding the LAPB_REJECT state
and the processing for it in the
lapb_input function, and have
the sendfrmr function invoke the
LAPB_REJECT state. Also
suggest adding
sendfrmr(axp, axp->control,
LAPB_RESPONSE, axp->pf, W);
for the cases where an incoming
frame has a control field
containing an unknown type.
lapb.c various lapb_input The code decides whether the local
station is busy by the
enq_resp following means:
if(len_p(axp->rxq) >= axp->window){
/* Too bad he didn't
listen to us; he'll
* have to resend the
frame later. This
* drastic action is
necessary to avoid
* memory deadlock.
*/
sendctl(axp,LAPB_RESPONSE,RNR | pf);
_or_
tmp = len_p(axp->rxq) >=
axp->window ? RNR : RR;
The len_p routine only determines
the length of the
packet at the front of the receive
queue. If multiple
receive packets are queued, they
aren't taken into
account in calculating whether the
window has been
exceeded.
lapbtime.c 95 tx_enq The following code fragment is
from the tx_enq routine:
if(axp->txq != NULLBUF
&& (len_p(axp->txq) <
axp->pthresh || axp->proto == V1)){
/* Retransmit oldest unacked
I-frame */
dup_p(&bp,axp->txq,0,len_p(axp->txq));
ctl = PF | I | (((axp->vs -
axp->unack) & MMASK) << 1)
| (axp->vr << 5);
sendframe(axp,LAPB_COMMAND,ctl,bp);
} else {
ctl = len_p(axp->rxq) >=
axp->window ? RNR|PF : RR|PF;
sendctl(axp,LAPB_COMMAND,ctl);
}
A condition can arise wherein a
transmit packet has been put on
axp->txq, but transmission not
initiated because lapb_output()
found that axp->flags.remotebusy
indicated that the remote station
is busy. In this case, if
tx_enq() is called by recover() or
pollthem(), txq will be non-null,
and the I frame could be transmitted.
This is incorrect behavior when
the remote is busy. If by chance
the remote has become unbusy
between the time of the lapb_output()
failure and the call to tx_enq(),
the tx_enq() transmission of the
I frame doesn't increment
axp->vs, and axp->unack is zero, so an
acknowledgement by the remote
will not be processed properly by
ackours();
------------------------------
End of TCP-Group Digest V93 #79
******************************
------------------------------
End of TCP-Group Digest V93 #80
******************************
------------------------------
End of TCP-Group Digest V93 #82
******************************
******************************