Re: a question on the nncp workflow

Hi Ethan,

My apologies for the slow reply; it's been a hectic week.

Replies inline:

On 2025-04-12, Ethan Carter <ec1828@somewhere.edu> wrote:

I have not understood the workflow yet.  This is going to be long
because it's my education on the subject that's the problem and it takes
many lines to expose my thought process.
>
I have two machines---an OpenBSD and a FreeBSD.  The OpenBSD is called
home and the FreeBSD is called fbsd.  The machine fbsd is 24/7 on the
Internet, but home is behind (at least one) NAT router.  Their relevant
configuration is shown below---I don't show the entire file because
there are private keys in that file.
>
The two pages that I've been trying to get help from are
>
  https://nncp.mirrors.quux.org/Workflow.html
>
and John Goerzen's NNCP concepts page at
>
  https://www.complete.org/nncp-concepts/
>
which is the one I've been as a guide.  At first I tried file
transmissions, but I failed to see the arrival of files, even though I
think I might have transferred a text file properly.  I then decided to
try command execution thinking it would be something easier to get
right: so I choose the program /uname/ to execute on the fbsd machine.
(I show the configuration of both machines at the end of this post.)
>
My attempt is to issue a uname execution on node fbsd but requested from
node home and I expect to see the answer on node home (somehow).

This is maybe different than UUCP; nncp-toss doesn't do anything special with
the output of a command requested by nncp-exec.  It will continue to retry if it
exits in error, but that's it.  If you want to get the output sent back to you,
you need to do something; for instance, send it to you via the regular mail
system, or send it to you via nncp-file.

[ snip ]

2025-04-11T23:49:59Z Exec is sent to fbsd@uname (291 B)
b#
>
The reason you see three Tx lines is because I didn't know the command
was reading my stdin---so I pressed ENTER (IIRC) a few times and then I
must have pressed ^D to give the program the EOF byte.  The program
finished.

Correct.

So I thought---okay, the request has been added to a queue at node home.

Yes.  You can verify this with nncp-stat or by looking at your log file.

[ snip ]

Looks good.  Now I'd think the request has been added to a queue at node
fbsd.  In other words, I believe the uname program has not been ran yet.

Right.

I would now think that I must somehow process that queue on node fbsd.
The section ``[c]ommands to process packets'' on John Goerzen's guide
seems promising: it seems to say that I must run nncp-toss on the fbsd
node.  So I did and I got:
>
# nncp-toss
2025-04-12T00:25:29Z Got exec from home to uname (15 B)

Yes.  It ran uname, piped your input to it, and exited.

Makes perfect sense.  Now I don't know how I at node home could get the
output of the command.  I suppose that a new packet has been added to

Here's where you need to do a little more work to make that happen (see above).

the outgoing queue at node fbsd and should be transferred to node home.
(A packet containing the uname output, I mean.)  But how could I
transfer something to node home from node fbsd?  Node home has no
Internet address.  So I'm thinking that node home must request that
transfer itself.  What would be the command?  It looks like nncp-freq is
only for a file request, not for receiving the output from a command
execution.  So I'm stuck here.

The network connection set up via nncp-call(er) and nncp-daemon is
bidirectional.  So packets destined to node home will still flow to it whenever
it calls node fbsd.  This is similar to UUCP.

This is also how the public quux gateway can work.  quux has a static IP, most
callers don't, but that's fine because packets will flow in both directions when
quux is called.

I tried running nncp-stat just to see what I could see on both machines,
but that told me not much:
>
(*) At node home
>
b# nncp-stat -cfg /etc/nncp.hjson                                             
fbsd
self

This is correct; nothing for fbsd after you sent the packet.

>
(*) At node fbsd
>
# nncp-stat
home
self
>
(*) Trying to make sense of the queues at node fbsd

And also correct, after the packet was received and tossed, there's nothing left
in the queue (due to the need for more specific action to return the output of
uname).

I also looked at /var/spool/nncp at node fbsd to see if I could identify
a possible packet lingering on a queue.  My hope was that I could spot a
hash of some sort that would identify the packet that I'm expecting to
get at node home (with the output of uname), but I see no match between
the file names below and the ``hashes'' I see above---I'm not sure
they're really hashes.

Pretty much hashes, etc.

By the way, I'm hiding my correct Internet address due to this post
being sent to the USENET.

Feel free to drop me an email also if you like.  Even if it's to say "look for
my post in comp.mail.uucp".

Hope this helps!

- John