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-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-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 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

    • * 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

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