Re: #2 Extended sequence numbers for AX.25
- To: firstname.lastname@example.org
- Subject: Re: #2 Extended sequence numbers for AX.25
- From: email@example.com (Alan Cox)
- Date: Mon, 6 Mar 1995 10:26:21 +0000 (GMT)
- Cc: firstname.lastname@example.org, email@example.com
- In-reply-to: <9503051540.AA05924@sys3.pe1chl.ampr.org> from "Rob Janssen" at Mar 5, 95 04:40:17 pm
> Addition of XID capability to AX.25 is completely independent of my
> extended sequence number proposal, and I think it should not be mixed.
> It will not solve the compatability issues described in the document, as
> implementations that don't react to SABME(P) will probably ignore XID(P)
> as well.
Tiny2's frequently get upset by a variant of the SABM alternatives used by
the PK88 for HF which squashes callsigns into identifiers. The longer SABM
causes the TNC to crash and start broadcasting UI frames with the responses.
rather than run the connection correctly.
How many different TNC's have you fired a SABME at as a test.
> (howcome that so many AX.25 implementations still send a full MAXFRAME-
> sized window of packets after they received an REJ? this usually is a
> waste... look at some station with a bad link connected to the local BBS
> and you know what I mean)
Because thats what LAPB implementations do in general. Linus for example
picks up that behaviour from the LAPB I used to build the AX.25 LLC.
IMHO a better approach is to concentrate on getting things like TCP/IP stacks
working efficiently over amateur radio using UI frames, fast retransmit and
other options, rather than fixing a fundamentally less useful setup that would
lose its primary advantage (runs in stupidly small amounts of memory) using