Menu

#437 Provide support for netcat-openbsd

testing_clonezilla
open
nobody
None
5
6 days ago
2025-11-21
No

Hi!

Forwarding this from https://github.com/grml/grml/issues/264

When netcat-openbsd is present instead of netcat-traditional, then clonezilla fails with:

OpenBSD netcat is not supported!
Program terminated!!!

Would be great if netcat-openbsd could be supported as well, as it's very common among powerusers and upstream development seems to be more active.

Thanks for consideration!

PS: sorry, was trying to report this under feature-requests, but only get 403/Forbidden error there.

Discussion

  • Steven Shiau

    Steven Shiau - 2025-11-23

    Thanks for your feedback.
    The netcat from OpenBSD used to have an issue to receive data from stdin in the destination node when the opton "-N" is used.
    I am not sure if the issue has gone or is still there.
    So any reason you have to use netcat from OpenBSD? If so, which function you want to use with Clonezilla?

     
  • Michael Prokop

    Michael Prokop - 2025-11-24

    So any reason you have to use netcat from OpenBSD? If so, which function you want to use with Clonezilla?

    Yes, netcat-openbsd is what's shipped on the Grml live system, so netcat-traditional isn't available there.

    The problem appears when starting clonezilla , choosing remote-dest and going for the restoredisk option there.

    Would be nice if clonezilla wouldn't abort there, otherwise I think we'd have to add an according Conflicts: netcat-openbsd in the Debian package of clonezilla, though this would also prevent clonezilla from being installed on systems where netcat-openbsd is present.

     
  • Steven Shiau

    Steven Shiau - 2025-11-24

    If you are sure the netcat-openbsd (version >= 234) works in the remote-dest function of Clonezilla in your case, definitely we can remove that check.
    Hence please confirm that. Thanks.

     
    • Michael Prokop

      Michael Prokop - 2025-11-24

      I'm not the actual user but forwarding this from https://github.com/grml/grml/issues/264, but I'll try to get this confirmed/verified, will keep you posted

       
      • Michael Prokop

        Michael Prokop - 2026-02-11

        Just checked, netcat-openbsd does not behave/work as expected :(

         
  • Steven Shiau

    Steven Shiau - 2026-02-17

    Thanks for your feedback. In that case, I believe we'd better keep the way it is.

     
    • Michael Prokop

      Michael Prokop - 2026-02-18

      Just thinking further about it, would it be an option to check for the presence of the nc.traditional binary also? This is the one behind the netcat-traditional package, and it can be installed next to netcat-openbsd o Debian. Then nc might point at nc.openbsd, while nc.traditional definitely points at the expected binary from netcat-traditional.

      So within:

        case "$ONTHEFLY_NET_PIPE" in
        netcat)
          # check if command is nc or netcat
          if command -v nc &>/dev/null; then
             NC_CMD="nc"
          elif command -v netcat &>/dev/null; then
             NC_CMD="netcat"
        [...]
      

      ... as first check could be the one for nc.traditional, like:

      if command -v nc.traditional &>/dev/null; then
        NC_CMD="nc.traditional"
      elif command -v nc &>/dev/null; then
        NC_CMD="nc"
      elif command -v netcat &>/dev/null; then
        NC_CMD="netcat"
      [...]
      

      ... and then all should be good to go, and the Debian package of clonezilla could even place a dependency on netcat-traditional package (happy to take care of the according bug report towards Debian also!).

      (And just curious, did anyone report this misbehavior in OpenBSD's netcat towards upstream already?

       

      Last edit: Michael Prokop 2026-02-18
  • Steven Shiau

    Steven Shiau - 2026-02-28

    "as first check could be the one for nc.traditional" -> Sure, will do this.
    "Debian package of clonezilla could even place a dependency on netcat-traditional package (happy to take care of the according bug report towards Debian also!).: -> Please.

    "did anyone report this misbehavior in OpenBSD's netcat towards upstream already?" -> We did not know this issue actually, until you reported this. No one from us reported this.

     
    • Michael Prokop

      Michael Prokop - 7 days ago

      "as first check could be the one for nc.traditional" -> Sure, will do this.

      Thanks! Please let me know once the check is in place so we can also push this towards Debian then :)

      "Debian package of clonezilla could even place a dependency on netcat-traditional package (happy to take care of the according bug report towards Debian also!).:

      -> Please.

      Already took care, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1129523

      "did anyone report this misbehavior in OpenBSD's netcat towards upstream already?"

      We did not know this issue actually, until you reported this. No one from us reported this.

      Ok, FTR - my question was meant with regards to the comment within clonezilla source:

             # netcat.openbsd won't exit if its option -N is not used. However,
             # if it's used, it has an issue to receive from stdin in the destination 
      

      I'd assume that this might be worth a bug report towards OpenBSD's netcat then, given that we know there seems to be a misbehavior? :)

       
      👍
      1
  • Steven Shiau

    Steven Shiau - 6 days ago

    "as first check could be the one for nc.traditional" -> It's in clonezilla package 5.15.5, and used in testing Clonezilla live 3.3.1-37.
    "this might be worth a bug report towards OpenBSD's netcat" -> I believe so.

     
    • Michael Prokop

      Michael Prokop - 6 days ago

      It's in clonezilla package 5.15.5, and used in testing Clonezilla live 3.3.1-37.

      Great, thanks

      "this might be worth a bug report towards OpenBSD's netcat" -> I believe so.

      Alright, this is already a known issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849192#32 (and it looks like we won't see a fix/behavior change there)

       

Log in to post a comment.

MongoDB Logo MongoDB