Re: [44net] AXUDP spec - 44net

3 Mar 2017

...
  Unfortunately, there are problems with AXIP and AXUDP
ever since the
 revisions of AX.25 were published - the AX.25 frames may get too big
 to encapsulate in unfragmented IP and UDP frames.  Any new document
 would have to discuss the fragmentation issues, and I'll bet they're
 not defined.  (As far as I know, the same issue applies to ROSE, KISS,
 and Net/Rom encapsulation too.) 
Is this an issue?  The AXUDP protocol simply is "put AX.25 frames in UDP
datagrams" and an UDP datagram can be nearly 64KB in size so I would not
think there are any issues.  UDP and IP handle the fragmentation and
reassembly and the receiver gets the original datagram to insert it into
the AX.25 stack.
Of course, AXUDP senders should not set the DF flag, and if they do, they
should not expect more than about 512 bytes maximum frame size.  Which
still is enough for classic AX.25 packet radio.

...
  Do any of the various implementations of AX.25
encompass v2.0 et seq as
 published by TAPR?  Ie, is anyone actually implementing jumbo frames,
 expanded frame sequence numbers, etc?  Or should we just treat it as a
 bad idea that should be buried and go on with the old protocol? 
The actual AX.25 version and extensions like jumbo frames and extended
sequence numbers should not affect AXUDP at all.  The UDP layer only replaces
the HDLC layer normally used to transfer data over radio, and all things
happening in AX.25 should be compatible between the endpoints, as always.

Rob