I list a hostname of
  krb5-verify-init-creds-opt-set-ap-req-nofail.krbtest.com
in my .sntoprc.  strace shows that sntop silently trucates this, and
fails, running
["sh", "-c", "fping -r 1 -b 24 -q krb5-verify-init-creds-opt-set-a  2> /dev/null > /dev/null"]

(1) It doesn't complain about the truncation.
(2) yes, I see the note "By default, upto 32 characters will be read,
    per line." Aside from being (a) a bad idea to limit that (b) if
    you're going to have an arbitrary limit, don't use such a *low*
    one (c) while it claims to be "by default", the man page lists no
    option to *change* it.
(3) while they don't necessarily apply here, the GNU Coding Standards
    say that arbitrary limits are evil for a reason...

[Mark W. Eichin 2002-08-06]

I do not know the code, but had a look and suspect the limit is set
using the IN_BUF define.  Here is a proof of concept patch increasing the limit:

diff --git a/sntop.h b/sntop.h
index 173cbdf..e5e35b9 100644
--- a/sntop.h
+++ b/sntop.h
@@ -14,7 +14,7 @@
  */

 #define SNTOP_AUTHORS  "Robert M. Love <rml@tech9.net>, Chris M. Rivera <cmrivera@ufl.edu>"
-#define IN_BUF         33 /* size of our conf data vars and their input */
+#define IN_BUF         128 /* size of our conf data vars and their input */
 #define CONF_BUF       256 /* size of path to conf data */
 #define CONF_UFILE     "/.sntoprc" /* name of user conf file .. we look for this in ~ first */
 #ifndef CONF_SFILE

I agree that dropping the config file line read limit is a good idea,
but that would require a lot more rewriting than this simple oneliner.
As far as I can tell, the rest of sntop do not care about host name
lengths.  Do you see a similar problem when passing the host name on
the command line?  If I understand the code correctly, you should not.
Perhaps this issue can be fixed after 23 years?

For a time-boxed effort, I believe 256 is better than 128 (RFC-1035
defines the limit in terms of wire-encoding of the DNS message rather
than the user-visible values (section 3.1, "To simplify
implementations") - there's also a 63 byte limit for "labels" but that's
just a single name-part and doesn't help here.)

(I don't currently have it installed so I don't have a handy answer to
your command line question.)

[Mark Eichin]

I do not disagree.  Perhaps you can come up with a better patch?  One
without a hardcoded limit would be even greater. :)