On 12/19/09, Stuart Henderson <[email protected]> wrote:
> On 2009-12-17, Denis Doroshenko <[email protected]> wrote:
> > RFC2865 WRT Class field content says the following:
> >
> > The String field is one or more octets.
>
>
> So the RD_STRING is correct,
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
printed as hexadecimal. But it is IMHO.
> and the same problem could occur with other strings. How about running
> them through strvisx() instead?
You are completely correct the same may occur with other strings while
they would be perfectly in accordance with the RFC.
> 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 <[email protected]> */
>
> @@ -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];
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
could print all of it?
> 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);
Do we still need that string and memset/memcpy? Why not removing
variable string and here just doing strvisx(vis, data, len, 0)?
> + fprintf(stdout, " %s", vis);
> }
>
> static void r_print_hex(int code, int len, const u_char *data) {
