🚀 go-pugleaf

>Is there something which would handle X.25 Reset Requests correctly?

None of the present "X.25" protocols actually know anything at all about the
underlying packet-level protocol. Generally, host-based X.25 implementations
return an error when a Reset is received; uucico considers that a failure,
and hangs up. PADs either toss the Reset, or insert a "reset" service signal.
Both will cause uucico to detect a transmission error, and retry either the
packet ('g' protocol) or the whole file ('f' protocol). PADs that barf on the
Reset or that drop into command mode will cause uucico to time out.

You *could* write something that detected Reset packets properly, and did a
real layer-4 style resynchronization. But it would not be portable; there is
no standard X.25 PLP applications interface. (If you have something like CONS,
you are probably going through a higher-layer protocol anyway, so uucico does
not need to care.)

One alternative would be a generalization of 'g' or 'f' to recognize certain
types of errors (like EL3RST, for you System V fans) as a temporary condition,
and try to recover from there. With 'f' that is much harder, since the present
implementations of 'f' provide no way for the receiver to notify the sender of
a problem until end of file.

>Or is that what AT&T did with their UUCP over X.25 protocol, which hasn't
>become very popular?

You mean 'x' protocol? It isn't popular because it doesn't work. It requires
8-bit transparency, has no error checking, no flow control, and requires that
a zero-length data packet be able to be passed end-to-end to mark the end of
file. Not only is this impossible with a PAD, some PDNs don't even recognize
it as legal.

<csg>