[patch] netstat: got bogus unix line...

[Denys Vlasenko]

On Thursday 27 December 2007 12:07, Cristian Ionescu-Idbohrn wrote:
> On Wed, 26 Dec 2007, Denys Vlasenko wrote:
> > On Wednesday 26 December 2007 20:42, Cristian Ionescu-Idbohrn wrote:
> > > As log as _no attempt_ to display the bogus lines is made all should
> > > be good.  None of the other 3 warnings make any attempts to display
> > > the bogus lines.
> >
> > ...leaving users puzzled *what exactly* is a problem.
>
> Well, maybe.  netstat from net-tools (which bb-netstat copied code from)
> does exactly that.
>
> > > 'bogus unix line' _should not_ do that either.  This is the "fix"
> > > I'd like to see in bb.
> >
> > Like attached?
>
> Looks like the code now completely hides the problem :(

I don't know what do you want then.

> Looked through using gdb.  The ugly line, up to the first '\n' character,
> is:
>
>   f7ab6280: 00000002 00000000 00000000 0002 01 14954 @^@^@^@.^R^@^@x*
>
> It continues with 97 NUL characters and ends with the 2nd '\n'.
>
> xmalloc_fgets_internal reads (passed the NUL characters) up to the 1st
> '\n' character and returns a 62 characters linebuf with embedded NUL
> characters, ignoring the rest of the corrupted string which continues up
> to the 2nd '\n'.  My guess is that it will be that string (97 NUL
> characters) xmalloc_fgets_internal will return next time it's called.
>
> The bb-netstat output will eventually _look correct_ just because a NUL
> character follows the '@'.  The buffer is actually 62 bytes but only 52 of
> them are displayed.

How do you want it to be displayed? As soon as we see '@' as the first
char in unix domain socket name, we cannot know what will follow.

Right now, on this notebook, I see:

f6ee1740: 00000003 00000000 00000000 0001 03 13802 @/tmp/fam-vda-^@^@^@^@^@^@...
f75aee40: 00000003 00000000 00000000 0001 03 12026 @/tmp/hald-local/dbus-hk8b0CGGAI

So, it can be *either* "normal" newline terminated name,
*or* 108-byte verbatim copy of struct sockaddr_un's sun_path member,
with possible embedded NULs, newlines and whatnot.

I don't see how this can be cleanly handled.

Yes, now we just stop at first NUL, ignore strings of NULs,
and complain on complex cases. Better ideas?



> I guess what I'm trying to say is that:
>
> * if bogus lines detection is important, buffer sizes need to be used

Why? memchr(line, '\n') would do.

> * bogus lines should not be displayed as then will cause console
>   corruption

Yes.

> * we may or may not display the message "warning, got bogus <stuff> line"
>   (net-tools netstat cares about that warning)

We definitely have only those two options :)
--
vda