A brief addendum on a couple of your items...

On Sunday, January 3, 2021 at 8:30:56 PM UTC-6, Grant Taylor wrote:
> On 1/3/21 6:06 PM, John Goerzen wrote:
> > Hello folks,
> > NNCP requires a clean link and doesn't have any special logic
> > for serial port handling.
> I personally feel like requiring an 8-bit clean connection is probably
> fairly safe these days.

Over at https://changelog.complete.org/archives/10042-long-range-radios-a-perfect-match-for-unix-protocols-from-the-70s I wrote about running UUCP over LoRA radios with success. I wrote lorapipe, which can be used as a transport for uucico. I documented some recommendations for it at https://github.com/jgoerzen/lorapipe/blob/master/doc/lorapipe.1.md#uucp

Like several modern radio systems, LoRA is a packetized serial protocol. It offers slightly more promises than UDP: it does not guarantee that every packet will arrive, but it does guarantee that the ones that arrive won't be out-of-order or corrupted.

Another radio system is XBee, and they can offer TCP-like guarantees in hardware. In fact, they have a "serial emulation" mode where they present what looks like a regular serial line with hardware flow control to the system, but internally handle the packetization, collision detection, retransmission, etc. So for XBee, no additional software would be necessary at all to run uucico (or NNCP) over it. For XBee, I wrote xbnet and these instructions for UUCP https://github.com/jgoerzen/xbnet/blob/master/doc/xbnet.1.md#uucp . xbnet allows tunneling IPv4, IPv6, or Ethernet frames across XBee, among other things (also supporting use as a pipe for things like uucico).

> I do think that NNCP is a very interesting idea. I feel like there are
> a LOT of unknowns. Almost as if it's a solution in search of a problem.
> But that may just be observation bias.

I mentioned this thread on the NNCP mailing list. Its author, Sergey Matveev, chimed in with this comment:

"The main difference between UUCP and NNCP, in my opinion, except for
(current) lack of explicit ability to use serial lines, is that NNCP is
a friend-to-friend/darknet network, where each (well, with minor
exceptions of course) participant (on the packet's path) has to be
explicitly known and added to the list of known neighbours. While UUCP
is a greynet, where even "anonymous" (unauthenticated, unidentified)
peers can work.

And no, of course there are no plans for making NNCP opennet, by
automatic fetching of peer's public key via DNS, because... well, it
will simply destroy and ruin the whole network and its resources because
of no trust and control of communicating peers. F2F (darknet)
self-governed networks (FidoNet as an example of global scale world-wide
completely decentralized one) are more complicated to administer and
support, but they are immune to Sybil attacks."

In my opinion, this difference -- while relevant architecturally and for security -- is somewhat less of a practical consideration these days, since the only UUCP installations I am aware of anymore tend to be these small friend-to-friend networks anyhow (due to the demise of the global UUCPNET).

Also there is a new post in my exploration of store-and-forward backups: https://changelog.complete.org/archives/10186-more-topics-on-store-and-forward-possibly-airgapped-zfs-and-non-zfs-backups-with-nncp

- John

On 1/4/21 10:41 AM, John Goerzen wrote:
> A brief addendum on a couple of your items...

*nod*

> Over at
> https://changelog.complete.org/archives/10042-long-range-radios-a-perfect-match-for-unix-protocols-from-the-70s
> I wrote about running UUCP over LoRA radios with success.
> I wrote lorapipe, which can be used as a transport for
> uucico. I documented some recommendations for it at
> https://github.com/jgoerzen/lorapipe/blob/master/doc/lorapipe.1.md#uucp

$ReadingList++

> Like several modern radio systems, LoRA is a packetized serial
> protocol. It offers slightly more promises than UDP: it does not
> guarantee that every packet will arrive, but it does guarantee that
> the ones that arrive won't be out-of-order or corrupted.

Intriguing.

I'm guessing that there is some sort of counter and only newer packets
are relayed from the radio to the other interface.

> Another radio system is XBee, and they can offer TCP-like guarantees
> in hardware. In fact, they have a "serial emulation" mode where they
> present what looks like a regular serial line with hardware flow
> control to the system, but internally handle the packetization,
> collision detection, retransmission, etc. So for XBee, no
> additional software would be necessary at all to run uucico (or NNCP)
> over it. For XBee, I wrote xbnet and these instructions for UUCP
> https://github.com/jgoerzen/xbnet/blob/master/doc/xbnet.1.md#uucp .
> xbnet allows tunneling IPv4, IPv6, or Ethernet frames across XBee,
> among other things (also supporting use as a pipe for things like
> uucico).

Intriguing.

> I mentioned this thread on the NNCP mailing list. Its author, Sergey
> Matveev, chimed in with this comment:
>
> "The main difference between UUCP and NNCP, in my opinion, except for
> (current) lack of explicit ability to use serial lines, is that NNCP
> is a friend-to-friend/darknet network, where each (well, with minor
> exceptions of course) participant (on the packet's path) has to be
> explicitly known and added to the list of known neighbours. While UUCP
> is a greynet, where even "anonymous" (unauthenticated, unidentified)
> peers can work.

I think there needs to be some emphasis on "/can/ work" as the way that
I've configured my UUCP-over-SSH network(s) (a few different ones over
the years) are both closed /and/ only relay packets (?) between
explicitly approved pairs of systems. So, even if someone did manage to
get into the UUCP network (independent of SSH) their packets wouldn't
pass without spoofing the source and / or destination. I think the
sequence number does make this more difficult. Save for injecting files
into UUCP queue directly.

So, I don't think that Sergey's statement is wrong per se, but I don't
think it's 100% accurate either.

> And no, of course there are no plans for making NNCP opennet, by
> automatic fetching of peer's public key via DNS, because... well,
> it will simply destroy and ruin the whole network and its resources
> because of no trust and control of communicating peers.

That doesn't hold any water with me. I am quite certain that I can
configure UUCP nodes to only allow packets from specified sources. As
such, I would expect that NNCP would have such a restriction too. Plus,
seeing as how things are cryptographically verifiable, the source can be
validated. Anything that doesn't pass can be rejected.

Thus, I don't think that having NNCP be open net capable would detract
from it's operation in any way, shape, or form.

> F2F (darknet) self-governed networks (FidoNet as an example of global
> scale world-wide completely decentralized one) are more complicated
> to administer and support, but they are immune to Sybil attacks."

How does a Sybil attack even come into play. The choice to trust an
incoming connection / packet is completely within the receiving
administrator's control. I don't see how any external information can
influence that decision.

> In my opinion, this difference -- while relevant architecturally and
> for security -- is somewhat less of a practical consideration these
> days, since the only UUCP installations I am aware of anymore tend
> to be these small friend-to-friend networks anyhow (due to the demise
> of the global UUCPNET).
>
> Also there is a new post in my
> exploration of store-and-forward backups:
> https://changelog.complete.org/archives/10186-more-topics-on-store-and-forward-possibly-airgapped-zfs-and-non-zfs-backups-with-nncp

$ReadingList++

--
Grant. . . .
unix || die

On Mon, Jan 04 2021, Grant Taylor wrote:

> On 1/4/21 10:41 AM, John Goerzen wrote:
>> Like several modern radio systems, LoRA is a packetized serial protocol. It
>> offers slightly more promises than UDP: it does not guarantee that every
>> packet will arrive, but it does guarantee that the ones that arrive won't be
>> out-of-order or corrupted.
>
> Intriguing.
>
> I'm guessing that there is some sort of counter and only newer packets are
> relayed from the radio to the other interface.

Oh it is more mundane than that :-) If a packet fails to decode correctly, it
is simply dropped on the floor. There is no retransmit in LoRA, there are no
routers, it is just basically a bunch of radios in a single broadcast domain
with iffy collision detection.

That said, LoRA radios can achieve absolutely incredible range with tiny amounts
of power, especially when you get down into the <1000bps range. I mean, 10+
miles with like 70mW! Tradeoffs abound but they are used a lot for remote
sensing and control applications where the batteries last for years.

There is LoRAWAN, a layer atop LoRA that uses synchronized timeslots to minimize
collisions, has limited ARQ, etc. It is not really suitable for many uses
because proper LoRAWAN "gateway" nodes tend to be quite expensive, and they use
widely asymmetric uplink vs. downlink speeds, and would tend to require one to
tunnel UUCP over JSON. I'm willing to tunnel UUCP over a lot of things but that
one is a bridge too far :-)

>> Another radio system is XBee, and they can offer TCP-like guarantees in
>> hardware. In fact, they have a "serial emulation" mode where they present
>> what looks like a regular serial line with hardware flow control to the
>> system, but internally handle the packetization, collision detection,
>> retransmission, etc. So for XBee, no additional software would be necessary

I should also add that the XBee firmware, by default, forms an ad-hoc mesh and
supports encryption over the air. It also runs at higher speeds than LoRA,
maxing out at roughly 50-100Kbps effective bitrate. The range is somewhat less
than LoRA, but I have had success with a 10-mile XBee link at about 50Kbps.
There are a bunch of different XBee modules that use different wire protocols
and frequencies; the longest range are the SX modules. They can also operate
over Zigbee, Wifi, custom 2.4GHz mesh (non-Wifi), which have varying speeds and
such - but with a single serial interface to the controller.

I've not specifically replied to your responses to Sergey, on the grounds that I
didn't write it :-) You make good points but thinking about both perspectives
requires a quantity of thought I haven't had the time for today. Not trying to
ignore it, just being honest here :-)

- John

On 1/4/21 3:55 PM, John Goerzen wrote:
> Oh it is more mundane than that :-) If a packet fails to decode
> correctly, it is simply dropped on the floor. There is no retransmit
> in LoRA, there are no routers, it is just basically a bunch of radios
> in a single broadcast domain with iffy collision detection.

It seems to me like each LoRa radio is in a slightly different broadcast
domain than other LoRa radios simply based off of RF propagation and
what other LoRa radios it is in reception distance of.

> That said, LoRA radios can achieve absolutely incredible range with
> tiny amounts of power, especially when you get down into the <1000bps
> range. I mean, 10+ miles with like 70mW! Tradeoffs abound but they
> are used a lot for remote sensing and control applications where the
> batteries last for years.

*nod*

> There is LoRAWAN, a layer atop LoRA that uses synchronized timeslots to
> minimize collisions, has limited ARQ, etc. It is not really suitable
> for many uses because proper LoRAWAN "gateway" nodes tend to be quite
> expensive, and they use widely asymmetric uplink vs. downlink speeds,
> and would tend to require one to tunnel UUCP over JSON.

More to read about.

> I'm willing to tunnel UUCP over a lot of things but that one is a
> bridge too far :-)

I'm inclined to agree with you.

But I'm also the person that would try to create his own LoRaWAN gateway.

> I should also add that the XBee firmware, by default, forms an ad-hoc
> mesh and supports encryption over the air. It also runs at higher
> speeds than LoRA, maxing out at roughly 50-100Kbps effective bitrate.
> The range is somewhat less than LoRA, but I have had success with a
> 10-mile XBee link at about 50Kbps. There are a bunch of different
> XBee modules that use different wire protocols and frequencies; the
> longest range are the SX modules. They can also operate over Zigbee,
> Wifi, custom 2.4GHz mesh (non-Wifi), which have varying speeds and
> such - but with a single serial interface to the controller.

Interesting.

> I've not specifically replied to your responses to Sergey, on the
> grounds that I didn't write it :-) You make good points but thinking
> about both perspectives requires a quantity of thought I haven't
> had the time for today. Not trying to ignore it, just being honest
> here :-)

Fair enough.

--
Grant. . . .
unix || die