Whoa a second. Its a lot easier than that, remember we are talking about
*real* digipeating outside of the kernel, therefore we cannot assume
anything about the incoming packets, we may want to retransmit them out
of another AX.25 port etc.
> If the kernel sees a connect request that is either directed to the
> above address or has the address as the next digipeater to use, it will
> signal it to the socket. Hm. Is there a way to get the addressfield of
> the request without accepting the request? Would be bad style to
> accept() while we don't even know if and where to reach the intended
> destination... We are required to pass the
> SABM through, maybe with modified address field (a la FlexNet) and
> accept the incoming request _after_ we received the confirmation from
> the peer.
What you have described here is what I would call pseudo-digipeating. In
this case the kernel is taking a far more active role than I was talking
about. The reason for removing digipeating from the kernel itself was to
allow for the setting up of pseudo-digipeating within the kernel, and
those sad people who want to run a real digipeater would be free to do so
via a small user level program.
The interface to build a real digipeater in user space is very much
simpler than doing a listen() or whatever. The user space digipeater
would listen for packets in the same way that the listen program does,
and transmits them out using a sendto(). Although the interface is
nominally based on BSD sockets, the method is Linux specific and that is
probably where the confusion came from. It does require the user level
digipeater to inspect all the frames callsign by callsign itself as the
kernel would not offer any facilities to help with this task. But of
course you do gain complete flexibility with what you can do. I believe
that Wampes uses this interface to access AX.25 device drivers.
> Hm, seems to be difficult realizing this via BSD-Sockets ;-)
Even pseudo-digipeating raises some interesting questions about the
semantics of it all, however I have left the work in the capable hands of
Frederic F1OAT and the results of his work will be for all to see soon.
> --
> Matthias
Jonathan
-- +----------------------------------+---------------------------------------+ | e-mail: nplufr@fh-merseburg.de | Telephone: +44 (0) 973 695261 | +----------------------------------+---------------------------------------+ | Author of Linux kernel AX.25, NET/ROM and Rose. | +--------------------------------------------------------------------------+