Date: Sat, 27 Mar 93 04:30:06 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 #79
To: tcp-group-digest
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
******************************
******************************