and the same problem could occur with other strings. How about running
them through strvisx() instead?

Index: print-radius.c
===================================================================
RCS file: /cvs/src/usr.sbin/tcpdump/print-radius.c,v
retrieving revision 1.8
diff -u -p -r1.8 print-radius.c
--- print-radius.c	23 May 2006 21:57:15 -0000	1.8
+++ print-radius.c	19 Dec 2009 13:04:46 -0000
@@ -32,7 +32,9 @@
 #include <arpa/inet.h>
 
 #include <stdio.h>
+#include <stdlib.h>
 #include <string.h>
+#include <vis.h>
 
 /* RADIUS support for tcpdump, Thomas Ptacek <tqbf@enteract.com> */
 
@@ -206,6 +208,7 @@ static void r_print_address(int code, in
 
 static void r_print_string(int code, int len, const u_char *data) {
 	char string[128];
+	char vis[128*4];
 
 	if(!len) {
 		fputs(" ?", stdout);
@@ -218,7 +221,8 @@ static void r_print_string(int code, int
 	memset(string, 0, 128);
 	memcpy(string, data, len);
 
-	fprintf(stdout, " %s", string);
+	strvisx(vis, string, len, 0);
+	fprintf(stdout, " %s", vis);
 }
 
 static void r_print_hex(int code, int len, const u_char *data) {

[ message continues ]

I think this can be simplified further. The memset() and memcpy() can be


[ message continues ]

If you take "STRING" in RD_STRING points to "string" in the RFC, then
that may be the case. The RFC defines the following types:

      text      1-253 octets containing UTF-8 encoded 10646 [7]
                characters.  Text of length zero (0) MUST NOT be sent;
                omit the entire attribute instead.

      string    1-253 octets containing binary data (values 0 through
                255 decimal, inclusive).  Strings of length zero (0)
                MUST NOT be sent; omit the entire attribute instead.

      address   32 bit value, most significant octet first.

      integer   32 bit unsigned value, most significant octet first.

      time      32 bit unsigned value, most significant octet first --
                seconds since 00:00:00 UTC, January 1, 1970.  The
                standard Attributes do not use this data type but it is
                presented here for possible use in future attributes.

So there's no type that is straight printable. For me, when and
attribute type described as "octets containing binary data", better be

You are completely correct the same may occur with other strings while

Just curious here, why128*4? Do you try to align stack here? As per
vis(3) the buffer should be 127*4+1, isn;t it a task of a compiler to
place the variables in the stack no matter what their sizes are?

Then again, the RFC defines maximum length of the string type is 253.
Is it okay to print 127 first octets of it? May be for -v mode we

Do we still need that string and memset/memcpy? Why not removing

[ message continues ]