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

[Cristian Ionescu-Idbohrn]

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 :(

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.

I guess what I'm trying to say is that:

* if bogus lines detection is important, buffer sizes need to be used
* bogus lines should not be displayed as then will cause console
  corruption
* we may or may not display the message "warning, got bogus <stuff> line"
  (net-tools netstat cares about that warning)

What do you think?


Cheers,

-- 
Cristian