public inbox for nncp-devel@lists.stargrave.org
Atom feed
* Greetings
@ 2026-03-12 23:30 Rafael Diniz
2026-03-13 1:13 ` Greetings John Goerzen
2026-03-15 8:23 ` HF modem support Sergey Matveev
0 siblings, 2 replies; 14+ messages in thread
From: Rafael Diniz @ 2026-03-12 23:30 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1.1: Type: text/plain, Size: 1566 bytes --]
Hello all,
I'm Rafael Diniz (PU2UIT/CR7BYQ), working at Rhizomatica [1]. We've been
using UUCP for almost a decade in our HF networks, and we always knew
the time to move to NNCP would come.
We'd like to have at least a working test network up this year
(hopefully). I'm still studying NNCP, understanding on how to provide
NNCP to the communities that use HERMES [2], that are UUCP-based. There
are always questions about security, but one huge advantage to me is
bundle broadcast (using fountain codes [3]), together with our modem [4].
I did a very early draft (without broadcast support, without many
things, untested, ai generated) on how we could connect NNCP to a
VARA-compatible modem (like our Mercury modem), just to start the
conversation:
https://github.com/Rhizomatica/nncp/pull/1
(I want to get out of github asap, but for now, that is where I placed
the code)
I have some test setups with radio on dummy loads in my table, and over
the air also, stations some hundreds of kilometers apart, which I can do
tests. My focus will be the Mercury modem in the next weeks, in order to
stabilize the over-the-air protocol and connectivity to standard VARA
[5] (Mercury is compatible VARA client tcp interface) clients, but I
want to fire up already the NNCP torch inside our project.
NNCP GO!
Cheers,
Rafael
[1] https://www.rhizomatica.org/
[2] https://hermes.radio/
[3] https://github.com/Rhizomatica/hermes-broadcast
[4] https://github.com/Rhizomatica/mercury
[5] https://rosmodem.wordpress.com/
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Greetings
2026-03-12 23:30 Greetings Rafael Diniz
@ 2026-03-13 1:13 ` John Goerzen
2026-03-13 1:51 ` Greetings Rafael Diniz
2026-03-15 8:23 ` HF modem support Sergey Matveev
1 sibling, 1 reply; 14+ messages in thread
From: John Goerzen @ 2026-03-13 1:13 UTC (permalink / raw)
To: Rafael Diniz; +Cc: nncp-devel
Hi Rafael,
Wow! This is right in line with many of my interests. That looks like
a fascinating project.
Sergey can chime in on your patch.
I have a few thoughts in case it is helpful.
I don't know how you're using UUCP, but since it was built in an era of
slow, error-prone, half-duplex links, it is probably ideally suited to
HF radio. nncp-daemon assumes a low-latency, error-free link, so may be
hard to adapt to HF conditions. You may find that a convenient option
would be to use nncp-bundle to generate a file (essentially a tar file)
containing NNCP packets for a given destination. You can then transport
that over UUCP to the remote, and inject it to NNCP using nncp-bundle
there.
You could also use nncp-bundle without a UUCP wrapper, as you alluded
to. nncp-bundle -rx will simply drop packets not destined for the local
node, so you can certainly broadcast bundles to everyone. A problem
arises, though, that this doesn't permit retransmit requests if parts of
it aren't received correctly. My approach at
https://www.complete.org/dead-usb-drives-are-fine-building-a-reliable-sneakernet/
may help you work around that by using end-to-end ACK packets.
If you do use nncp-daemon and nncp-call(er), you will want to set the
NNCPDEADLINE environment variable, as well as the maxonlinetime and
onlinedeadline to high values.
Along those lines, nncp-daemon and nncp-call(er) support a -ucspi
option, which means they communicate over stdin/stdout. If you have a
generic wrapper for your TNC software, that may be useful. You might
also use TCP over AX.25 over KISS, but the high packet overhead of that
at HF speeds would likely be unfavorable.
I see you are aware of various regulations on use of encryption on
amateur radio bands. Unfortunately, since encryption is prohibited on
amateur radio bands in the US, NNCP won't ever run over ham radio here.
If your target countries permit it, then that's great!
- John
On Thu, Mar 12 2026, Rafael Diniz wrote:
> Hello all,
>
> I'm Rafael Diniz (PU2UIT/CR7BYQ), working at Rhizomatica [1]. We've been using
> UUCP for almost a decade in our HF networks, and we always knew the time to move
> to NNCP would come.
>
> We'd like to have at least a working test network up this year (hopefully). I'm
> still studying NNCP, understanding on how to provide NNCP to the communities
> that use HERMES [2], that are UUCP-based. There are always questions about
> security, but one huge advantage to me is bundle broadcast (using fountain codes
> [3]), together with our modem [4].
>
> I did a very early draft (without broadcast support, without many things,
> untested, ai generated) on how we could connect NNCP to a VARA-compatible modem
> (like our Mercury modem), just to start the conversation:
> https://github.com/Rhizomatica/nncp/pull/1
>
> (I want to get out of github asap, but for now, that is where I placed the code)
>
> I have some test setups with radio on dummy loads in my table, and over the air
> also, stations some hundreds of kilometers apart, which I can do tests. My focus
> will be the Mercury modem in the next weeks, in order to stabilize the
> over-the-air protocol and connectivity to standard VARA [5] (Mercury is
> compatible VARA client tcp interface) clients, but I want to fire up already the
> NNCP torch inside our project.
>
> NNCP GO!
>
> Cheers,
> Rafael
>
> [1] https://www.rhizomatica.org/
> [2] https://hermes.radio/
> [3] https://github.com/Rhizomatica/hermes-broadcast
> [4] https://github.com/Rhizomatica/mercury
> [5] https://rosmodem.wordpress.com/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Greetings
2026-03-13 1:13 ` Greetings John Goerzen
@ 2026-03-13 1:51 ` Rafael Diniz
2026-03-13 2:25 ` Greetings John Goerzen
0 siblings, 1 reply; 14+ messages in thread
From: Rafael Diniz @ 2026-03-13 1:51 UTC (permalink / raw)
To: John Goerzen; +Cc: nncp-devel
[-- Attachment #1.1: Type: text/plain, Size: 4831 bytes --]
Hi John! Nice to talk to you!
I'll comment inline.
On 3/13/26 1:13 AM, John Goerzen wrote:
> Hi Rafael,
>
> Wow! This is right in line with many of my interests. That looks like
> a fascinating project.
>
> Sergey can chime in on your patch.
>
> I have a few thoughts in case it is helpful.
>
> I don't know how you're using UUCP, but since it was built in an era of
> slow, error-prone, half-duplex links, it is probably ideally suited to
> HF radio. nncp-daemon assumes a low-latency, error-free link, so may be
> hard to adapt to HF conditions. You may find that a convenient option
> would be to use nncp-bundle to generate a file (essentially a tar file)
> containing NNCP packets for a given destination. You can then transport
> that over UUCP to the remote, and inject it to NNCP using nncp-bundle
> there.
In HF we don't have low-latency, but the modem guarantees an error-free
link. Need to dive in the timeouts.
> You could also use nncp-bundle without a UUCP wrapper, as you alluded
> to. nncp-bundle -rx will simply drop packets not destined for the local
> node, so you can certainly broadcast bundles to everyone. A problem
> arises, though, that this doesn't permit retransmit requests if parts of
> it aren't received correctly. My approach at
> https://www.complete.org/dead-usb-drives-are-fine-building-a-reliable-sneakernet/
> may help you work around that by using end-to-end ACK packets.
Your website is pretty cool, thanks a lot, I know it for quite some time.
Using RaptorQ (hermes-broadcast), no need of per-(modem)-packet ACK,
fountain codes take care, stations can just ask the broadcast to keep
going till the receive the bundle. This is the part of the system with
clearer view for me. The async NNCP ACKs could be useful for informing
the gateway which stuff arrived to each station.
> If you do use nncp-daemon and nncp-call(er), you will want to set the
> NNCPDEADLINE environment variable, as well as the maxonlinetime and
> onlinedeadline to high values.
Perfect - these are the details I needed to know, to start testing.
> Along those lines, nncp-daemon and nncp-call(er) support a -ucspi
> option, which means they communicate over stdin/stdout. If you have a
> generic wrapper for your TNC software, that may be useful. You might
> also use TCP over AX.25 over KISS, but the high packet overhead of that
> at HF speeds would likely be unfavorable.
I already use a wrapper [1] for the UUCP<->HF Modem connection now. For
NNCP, I wanted something more elegant, with proper support.
> I see you are aware of various regulations on use of encryption on
> amateur radio bands. Unfortunately, since encryption is prohibited on
> amateur radio bands in the US, NNCP won't ever run over ham radio here.
> If your target countries permit it, then that's great!
We don't use amateur radio bands in HERMES project.
This is not really meant for amateur radio use, at least until this
encryption prohibition holds.
[1] https://github.com/Rhizomatica/hermes-net/tree/main/uucpd
- Rafael
> - John
>
> On Thu, Mar 12 2026, Rafael Diniz wrote:
>
>> Hello all,
>>
>> I'm Rafael Diniz (PU2UIT/CR7BYQ), working at Rhizomatica [1]. We've been using
>> UUCP for almost a decade in our HF networks, and we always knew the time to move
>> to NNCP would come.
>>
>> We'd like to have at least a working test network up this year (hopefully). I'm
>> still studying NNCP, understanding on how to provide NNCP to the communities
>> that use HERMES [2], that are UUCP-based. There are always questions about
>> security, but one huge advantage to me is bundle broadcast (using fountain codes
>> [3]), together with our modem [4].
>>
>> I did a very early draft (without broadcast support, without many things,
>> untested, ai generated) on how we could connect NNCP to a VARA-compatible modem
>> (like our Mercury modem), just to start the conversation:
>> https://github.com/Rhizomatica/nncp/pull/1
>>
>> (I want to get out of github asap, but for now, that is where I placed the code)
>>
>> I have some test setups with radio on dummy loads in my table, and over the air
>> also, stations some hundreds of kilometers apart, which I can do tests. My focus
>> will be the Mercury modem in the next weeks, in order to stabilize the
>> over-the-air protocol and connectivity to standard VARA [5] (Mercury is
>> compatible VARA client tcp interface) clients, but I want to fire up already the
>> NNCP torch inside our project.
>>
>> NNCP GO!
>>
>> Cheers,
>> Rafael
>>
>> [1] https://www.rhizomatica.org/
>> [2] https://hermes.radio/
>> [3] https://github.com/Rhizomatica/hermes-broadcast
>> [4] https://github.com/Rhizomatica/mercury
>> [5] https://rosmodem.wordpress.com/
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Greetings
2026-03-13 1:51 ` Greetings Rafael Diniz
@ 2026-03-13 2:25 ` John Goerzen
2026-03-13 10:58 ` Greetings Rafael Diniz
0 siblings, 1 reply; 14+ messages in thread
From: John Goerzen @ 2026-03-13 2:25 UTC (permalink / raw)
To: Rafael Diniz; +Cc: nncp-devel
On Fri, Mar 13 2026, Rafael Diniz wrote:
[ some snips ]
>> If you do use nncp-daemon and nncp-call(er), you will want to set the
>> NNCPDEADLINE environment variable, as well as the maxonlinetime and
>> onlinedeadline to high values.
>
> Perfect - these are the details I needed to know, to start testing.
Looks like you've got a pretty nice protocol stack there. Having a
reliable stack underneath NNCP makes this all so much easier.
I thought I'd just send you a few more direct links on this:
https://nncp.mirrors.quux.org/Sync.html#index-NNCPDEADLINE talks about
NNCPDEADLINE
https://nncp.mirrors.quux.org/CfgNeigh.html#CfgMaxOnlineTime covers the
onlinedeadline and maxonlinetime settings.
I am curious what over-the-air codec you're using. Amateur packet radio
over HF tends to use 300bps Bell 103. This goes all the way back to
1963 and is pretty bad by modern standards, so I imagine you're using
something better :-)
I'm also interested in what non-amateur bands you're using.
- John
(KR0L)
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Greetings
2026-03-13 2:25 ` Greetings John Goerzen
@ 2026-03-13 10:58 ` Rafael Diniz
0 siblings, 0 replies; 14+ messages in thread
From: Rafael Diniz @ 2026-03-13 10:58 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1.1: Type: text/plain, Size: 2566 bytes --]
Hi John,
On 3/13/26 2:25 AM, John Goerzen wrote:
>
> On Fri, Mar 13 2026, Rafael Diniz wrote:
>
> [ some snips ]
>
>>> If you do use nncp-daemon and nncp-call(er), you will want to set the
>>> NNCPDEADLINE environment variable, as well as the maxonlinetime and
>>> onlinedeadline to high values.
>>
>> Perfect - these are the details I needed to know, to start testing.
>
> Looks like you've got a pretty nice protocol stack there. Having a
> reliable stack underneath NNCP makes this all so much easier.
>
> I thought I'd just send you a few more direct links on this:
>
> https://nncp.mirrors.quux.org/Sync.html#index-NNCPDEADLINE talks about
> NNCPDEADLINE
>
> https://nncp.mirrors.quux.org/CfgNeigh.html#CfgMaxOnlineTime covers the
> onlinedeadline and maxonlinetime settings.
Thanks, I'll read and try to set the configuration in two radio boxes on
dummies next week.
> I am curious what over-the-air codec you're using. Amateur packet radio
> over HF tends to use 300bps Bell 103. This goes all the way back to
> 1963 and is pretty bad by modern standards, so I imagine you're using
> something better :-)
I hope it is better!
: )
At this point we are using these (de/)modulators from freedv:
| FreeDV Mode | RF bandwidth (Hz) | Payload data rate bits/s | Payload
bytes/frame | FEC | Duration (sec) | MPP test | Use case |
| :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: |
| DATAC0 | 500 | 291 | 14 | (256,128) | 0.44 | 70/100 at 0dB | Reverse
link ACK packets |
| DATAC1 | 1700 | 980 | 510 | (8192,4096) | 4.18 | 92/100 at 5dB |
Forward link data (medium SNR) |
| DATAC3 | 500 | 321 | 126 | (2048,1024) | 3.19 | 74/100 at 0dB |
Forward link data (low SNR) |
| DATAC4 | 250 | 87 | 56 | (1472,448) | 5.17 | 90/100 at -4dB | Forward
link data (low SNR) |
| DATAC13 | 200 | 64 | 14 | (384,128) | 2.0 | 90/100 at -4dB | Reverse
link ACK packets (low SNR) |
| DATAC14 | 250 | 58 | 3 | (112,56) | 0.69 | 90/100 at -2dB | Reverse
link ACK packets (low SNR) |
Right now, DATAC13 for control plane, and DATAC4, DATAC3 and DATAC1 for
the data plane, to be used by the gear-shift logic:
https://github.com/Rhizomatica/mercury/
> I'm also interested in what non-amateur bands you're using.
We always ask license channels in bands for fixed and mobile stations in
HF, there are much more bands for fixed/mobile HF station for private
use licensing than for Ham radio (the ITU frequency attribution have all
the top-level details, and each country some specifics).
- Rafael
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: HF modem support
2026-03-12 23:30 Greetings Rafael Diniz
2026-03-13 1:13 ` Greetings John Goerzen
@ 2026-03-15 8:23 ` Sergey Matveev
2026-03-16 2:13 ` Rafael Diniz
1 sibling, 1 reply; 14+ messages in thread
From: Sergey Matveev @ 2026-03-15 8:23 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 563 bytes --]
Greetings!
*** Rafael Diniz [2026-03-12 23:30]:
>I did a very early draft (without broadcast support, without many things,
>untested, ai generated) on how we could connect NNCP to a VARA-compatible
>modem (like our Mercury modem), just to start the conversation: [...]
Code looks good, should not break anything. Merged it into "develop"
branch. Unfortunately can not check anything from that, too far from
those topics. Cool. Thank you!
--
Sergey Matveev (http://www.stargrave.org/)
LibrePGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: HF modem support
2026-03-15 8:23 ` HF modem support Sergey Matveev
@ 2026-03-16 2:13 ` Rafael Diniz
2026-03-17 23:53 ` Rafael Diniz
2026-03-18 10:26 ` Sergey Matveev
0 siblings, 2 replies; 14+ messages in thread
From: Rafael Diniz @ 2026-03-16 2:13 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1.1: Type: text/plain, Size: 1558 bytes --]
Yay! Thanks Sergey!
NNCP rocks!
As I'm just starting with real testing, with radios on dummy loads for
now, I expect fixes / improvements to come. It is not really working yet.
nncp-call -autotoss estacao2
vara.go:246: hfmodem: ctrl: OK
vara.go:246: hfmodem: ctrl: OK
vara.go:246: hfmodem: ctrl: OK
vara.go:246: hfmodem: ctrl: OK
vara.go:246: hfmodem: ctrl: OK
vara.go:246: hfmodem: ctrl: OK
2026-03-16T02:02:21Z ERROR Calling estacao2
(mercury://127.0.0.1:8300/PU2UIT-2?mycall=PU2UIT-3&bw=2300&ptt=hermes):
connection to PU2UIT-2 failed
Modem calls, I see signal on air, not that bad for a first try of the
code. I'll start working on it this week.
Sergey, Can I just keep doing what I'm doing to send commits?
I'll maintain some debian builds of this, as I need arm64 and amd64
packages to test (John, these are hackish debian packages, I'm build
with go own cross-compilation capabilities, nothing to do with your
great official upstream ones):
https://debian.hermes.radio/
Cheers!
Rafael
On 3/15/26 8:23 AM, Sergey Matveev wrote:
> Greetings!
>
> *** Rafael Diniz [2026-03-12 23:30]:
>> I did a very early draft (without broadcast support, without many things,
>> untested, ai generated) on how we could connect NNCP to a VARA-compatible
>> modem (like our Mercury modem), just to start the conversation: [...]
>
> Code looks good, should not break anything. Merged it into "develop"
> branch. Unfortunately can not check anything from that, too far from
> those topics. Cool. Thank you!
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: HF modem support
2026-03-16 2:13 ` Rafael Diniz
@ 2026-03-17 23:53 ` Rafael Diniz
2026-03-18 0:32 ` Rafael Diniz
2026-03-18 10:42 ` Sergey Matveev
2026-03-18 10:26 ` Sergey Matveev
1 sibling, 2 replies; 14+ messages in thread
From: Rafael Diniz @ 2026-03-17 23:53 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1.1: Type: text/plain, Size: 2281 bytes --]
I hit a road block here.
The first package of NNCP protocol will take 65280 bytes? I can see
there is some padding involved. 64 kB will never be feasible in HF for a
handshake (most of our payloads are at most 10 kB, for "large" files,
like pictures). Is there any sensible approach to reduce this, without
completely breaking the security (we're using UUCP, so anything better
than nothing is better already).
I'm hammering a bit the code, but better I understand a bit the protocol
before I do something very wrong. Which is a good reference to start with?
- Rafael
On 3/16/26 2:13 AM, Rafael Diniz wrote:
> Yay! Thanks Sergey!
>
> NNCP rocks!
>
> As I'm just starting with real testing, with radios on dummy loads for
> now, I expect fixes / improvements to come. It is not really working yet.
>
> nncp-call -autotoss estacao2
> vara.go:246: hfmodem: ctrl: OK
> vara.go:246: hfmodem: ctrl: OK
> vara.go:246: hfmodem: ctrl: OK
> vara.go:246: hfmodem: ctrl: OK
> vara.go:246: hfmodem: ctrl: OK
> vara.go:246: hfmodem: ctrl: OK
> 2026-03-16T02:02:21Z ERROR Calling estacao2 (mercury://127.0.0.1:8300/
> PU2UIT-2?mycall=PU2UIT-3&bw=2300&ptt=hermes): connection to PU2UIT-2 failed
>
> Modem calls, I see signal on air, not that bad for a first try of the
> code. I'll start working on it this week.
>
> Sergey, Can I just keep doing what I'm doing to send commits?
>
> I'll maintain some debian builds of this, as I need arm64 and amd64
> packages to test (John, these are hackish debian packages, I'm build
> with go own cross-compilation capabilities, nothing to do with your
> great official upstream ones):
> https://debian.hermes.radio/
>
> Cheers!
> Rafael
>
> On 3/15/26 8:23 AM, Sergey Matveev wrote:
>> Greetings!
>>
>> *** Rafael Diniz [2026-03-12 23:30]:
>>> I did a very early draft (without broadcast support, without many
>>> things,
>>> untested, ai generated) on how we could connect NNCP to a VARA-
>>> compatible
>>> modem (like our Mercury modem), just to start the conversation: [...]
>>
>> Code looks good, should not break anything. Merged it into "develop"
>> branch. Unfortunately can not check anything from that, too far from
>> those topics. Cool. Thank you!
>>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: HF modem support
2026-03-17 23:53 ` Rafael Diniz
@ 2026-03-18 0:32 ` Rafael Diniz
2026-03-18 10:45 ` Sergey Matveev
2026-03-18 10:42 ` Sergey Matveev
1 sibling, 1 reply; 14+ messages in thread
From: Rafael Diniz @ 2026-03-18 0:32 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1.1: Type: text/plain, Size: 3807 bytes --]
So, I hammered a bit, I got my first successful nncp transmission over
the air!
NNCPDEADLINE=600 nncp-call -autotoss estacao2
proxy.go:188: hfmodem: proxy: connected to PU2UIT-2 via daemon
2026-03-18T00:21:02Z We have got for estacao2: 1 packets, 1.8 KiB
2026-03-18T00:21:52Z Packet
GVMJ7SXOCAKJAFTLIPEXUYJ6FNX352EQIRX7ZNVY4J2WC5WDCPPA (1.6 KiB) (nice B): 0%
2026-03-18T00:21:52Z estacao2 has got for us: 1 packets, 1.6 KiB
2026-03-18T00:21:52Z Connection to estacao2
(mercury://127.0.0.1:8300/PU2UIT-2?mycall=PU2UIT-3&bw=2300&ptt=hermes)
2026-03-18T00:21:52Z Tx H3D4TV2AUYXYOYII..5ISMP4EOR3NOHUDQ 1.8 KiB/1.8
KiB 100% (0 B/sec)
2026-03-18T00:23:31Z Rx GVMJ7SXOCAKJAFTL..ZNVY4J2WC5WDCPPA 1.6 KiB/1.6
KiB 100% (0 B/sec)
2026-03-18T00:23:31Z Got packet
GVMJ7SXOCAKJAFTLIPEXUYJ6FNX352EQIRX7ZNVY4J2WC5WDCPPA 100% (1.6 KiB / 1.6
KiB): done
2026-03-18T00:23:32Z Rx file GVMJ7SXOCAKJAFTL..ZNVY4J2WC5WDCPPA 1.2
KiB/1.2 KiB 100% (0 B/sec)
2026-03-18T00:23:32Z Got file common.sh (1.2 KiB) from estacao2
2026-03-18T00:24:05Z Packet
H3D4TV2AUYXYOYIIHSCBIXT7RKKEKJUXS6UZ5ISMP4EOR3NOHUDQ is sent
There are still some rough edges to fix, but more importantly, could
anyone give me a feedback on the removal of padding of the first frame?
Here is the diff:
https://github.com/Rhizomatica/nncp/commit/07c5cf5b244140fe4960f210b45017d449f17719
Поехали!
Cheers,
Rafael
On 3/17/26 11:53 PM, Rafael Diniz wrote:
> I hit a road block here.
>
> The first package of NNCP protocol will take 65280 bytes? I can see
> there is some padding involved. 64 kB will never be feasible in HF for a
> handshake (most of our payloads are at most 10 kB, for "large" files,
> like pictures). Is there any sensible approach to reduce this, without
> completely breaking the security (we're using UUCP, so anything better
> than nothing is better already).
>
> I'm hammering a bit the code, but better I understand a bit the protocol
> before I do something very wrong. Which is a good reference to start with?
>
> - Rafael
>
>
> On 3/16/26 2:13 AM, Rafael Diniz wrote:
>> Yay! Thanks Sergey!
>>
>> NNCP rocks!
>>
>> As I'm just starting with real testing, with radios on dummy loads for
>> now, I expect fixes / improvements to come. It is not really working yet.
>>
>> nncp-call -autotoss estacao2
>> vara.go:246: hfmodem: ctrl: OK
>> vara.go:246: hfmodem: ctrl: OK
>> vara.go:246: hfmodem: ctrl: OK
>> vara.go:246: hfmodem: ctrl: OK
>> vara.go:246: hfmodem: ctrl: OK
>> vara.go:246: hfmodem: ctrl: OK
>> 2026-03-16T02:02:21Z ERROR Calling estacao2 (mercury://127.0.0.1:8300/
>> PU2UIT-2?mycall=PU2UIT-3&bw=2300&ptt=hermes): connection to PU2UIT-2
>> failed
>>
>> Modem calls, I see signal on air, not that bad for a first try of the
>> code. I'll start working on it this week.
>>
>> Sergey, Can I just keep doing what I'm doing to send commits?
>>
>> I'll maintain some debian builds of this, as I need arm64 and amd64
>> packages to test (John, these are hackish debian packages, I'm build
>> with go own cross-compilation capabilities, nothing to do with your
>> great official upstream ones):
>> https://debian.hermes.radio/
>>
>> Cheers!
>> Rafael
>>
>> On 3/15/26 8:23 AM, Sergey Matveev wrote:
>>> Greetings!
>>>
>>> *** Rafael Diniz [2026-03-12 23:30]:
>>>> I did a very early draft (without broadcast support, without many
>>>> things,
>>>> untested, ai generated) on how we could connect NNCP to a VARA-
>>>> compatible
>>>> modem (like our Mercury modem), just to start the conversation: [...]
>>>
>>> Code looks good, should not break anything. Merged it into "develop"
>>> branch. Unfortunately can not check anything from that, too far from
>>> those topics. Cool. Thank you!
>>>
>>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: HF modem support
2026-03-16 2:13 ` Rafael Diniz
2026-03-17 23:53 ` Rafael Diniz
@ 2026-03-18 10:26 ` Sergey Matveev
1 sibling, 0 replies; 14+ messages in thread
From: Sergey Matveev @ 2026-03-18 10:26 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 295 bytes --]
Greetings!
*** Rafael Diniz [2026-03-16 02:13]:
>Sergey, Can I just keep doing what I'm doing to send commits?
If they give workability for those new features, then why not.
--
Sergey Matveev (http://www.stargrave.org/)
LibrePGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: HF modem support
2026-03-17 23:53 ` Rafael Diniz
2026-03-18 0:32 ` Rafael Diniz
@ 2026-03-18 10:42 ` Sergey Matveev
2026-03-18 12:56 ` Rafael Diniz
1 sibling, 1 reply; 14+ messages in thread
From: Sergey Matveev @ 2026-03-18 10:42 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 1379 bytes --]
*** Rafael Diniz [2026-03-17 23:53]:
>The first package of NNCP protocol will take 65280 bytes? I can see there is
>some padding involved.
Yes, it pads it, to hide amount of packets available in queue.
>Is there any sensible approach to reduce this, without completely breaking
>the security (we're using UUCP, so anything better than nothing is better
>already).
In general it is just a *relatively* easy way to give at least some
privacy (metadata security). I think it is ok to optionally disable it,
if we deal with links where even 64KiB is too much. Only the number of
packets in a queue is revealed, that I guess is acceptable for most users.
Actually NNCP packets in general are not very lightweight. Each packet
contains "path" field that always consumes 255 bytes. Not too friendly
to very low-bandwidth links. NNCP initially was created even without
online connections support at all: completely aimed for floppynet-like
use-cases.
>I'm hammering a bit the code, but better I understand a bit the protocol
>before I do something very wrong. Which is a good reference to start with?
The whole documentation is available in doc/nncp.info, doc/nncp.html
(the same as website). No additional materials about its details exist.
--
Sergey Matveev (http://www.stargrave.org/)
LibrePGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: HF modem support
2026-03-18 0:32 ` Rafael Diniz
@ 2026-03-18 10:45 ` Sergey Matveev
2026-03-18 12:52 ` Rafael Diniz
0 siblings, 1 reply; 14+ messages in thread
From: Sergey Matveev @ 2026-03-18 10:45 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 696 bytes --]
*** Rafael Diniz [2026-03-18 00:32]:
>So, I hammered a bit, I got my first successful nncp transmission over the air!
Cool!
>There are still some rough edges to fix, but more importantly, could anyone
>give me a feedback on the removal of padding of the first frame?
>Here is the diff:
>https://github.com/Rhizomatica/nncp/commit/07c5cf5b244140fe4960f210b45017d449f17719
Personally I would prefer to add an option to configuration file to
disable padding, but automatically setting it depending on "hf" link
will also work of course. I think this is ok, should work.
--
Sergey Matveev (http://www.stargrave.org/)
LibrePGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: HF modem support
2026-03-18 10:45 ` Sergey Matveev
@ 2026-03-18 12:52 ` Rafael Diniz
0 siblings, 0 replies; 14+ messages in thread
From: Rafael Diniz @ 2026-03-18 12:52 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1.1: Type: text/plain, Size: 796 bytes --]
Hi Sergey,
Thanks for everything! I agree adding a configuration file parameter
makes more sense. Let me work on it.
- Rafael
On 3/18/26 10:45 AM, Sergey Matveev wrote:
> *** Rafael Diniz [2026-03-18 00:32]:
>> So, I hammered a bit, I got my first successful nncp transmission over the air!
>
> Cool!
>
>> There are still some rough edges to fix, but more importantly, could anyone
>> give me a feedback on the removal of padding of the first frame?
>> Here is the diff:
>> https://github.com/Rhizomatica/nncp/commit/07c5cf5b244140fe4960f210b45017d449f17719
>
> Personally I would prefer to add an option to configuration file to
> disable padding, but automatically setting it depending on "hf" link
> will also work of course. I think this is ok, should work.
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: HF modem support
2026-03-18 10:42 ` Sergey Matveev
@ 2026-03-18 12:56 ` Rafael Diniz
0 siblings, 0 replies; 14+ messages in thread
From: Rafael Diniz @ 2026-03-18 12:56 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1.1: Type: text/plain, Size: 1365 bytes --]
Comments inline:
>> Is there any sensible approach to reduce this, without completely breaking
>> the security (we're using UUCP, so anything better than nothing is better
>> already).
>
> In general it is just a *relatively* easy way to give at least some
> privacy (metadata security). I think it is ok to optionally disable it,
> if we deal with links where even 64KiB is too much. Only the number of
> packets in a queue is revealed, that I guess is acceptable for most users.
Cool!
> Actually NNCP packets in general are not very lightweight. Each packet
> contains "path" field that always consumes 255 bytes. Not too friendly
> to very low-bandwidth links. NNCP initially was created even without
> online connections support at all: completely aimed for floppynet-like
> use-cases.
Got it. I think for now we can live with the 255 bytes, as this size of
payload we can indeed pipe over HF. Of course having a null-terminated
path would save some bytes, but this is not critical IMO.
>> I'm hammering a bit the code, but better I understand a bit the protocol
>> before I do something very wrong. Which is a good reference to start with?
>
> The whole documentation is available in doc/nncp.info, doc/nncp.html
> (the same as website). No additional materials about its details exist.
Perfect, thanks.
- Rafael
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2026-03-18 12:56 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-03-12 23:30 Greetings Rafael Diniz
2026-03-13 1:13 ` Greetings John Goerzen
2026-03-13 1:51 ` Greetings Rafael Diniz
2026-03-13 2:25 ` Greetings John Goerzen
2026-03-13 10:58 ` Greetings Rafael Diniz
2026-03-15 8:23 ` HF modem support Sergey Matveev
2026-03-16 2:13 ` Rafael Diniz
2026-03-17 23:53 ` Rafael Diniz
2026-03-18 0:32 ` Rafael Diniz
2026-03-18 10:45 ` Sergey Matveev
2026-03-18 12:52 ` Rafael Diniz
2026-03-18 10:42 ` Sergey Matveev
2026-03-18 12:56 ` Rafael Diniz
2026-03-18 10:26 ` Sergey Matveev