Re: [9fans] ndb/cs

Re: [9fans] ndb/cs

[presotto]

[-- Attachment #1: Type: text/plain, Size: 309 bytes --]

cool, I'ld never noticed that netstat didn't return port names for
il.  Guess I use the -n option too often.

As far as I can see, I have 2 errors here.  One is in csgetval which
should be asking for '!port=566 il=*' which would have kept me from
noticing the other bug, the one that Lucio De Re fixed.

[-- Attachment #2: Type: message/rfc822, Size: 2991 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 626 bytes --]

On Thu, Aug 17, 2000 at 06:55:20PM +0200, Lucio De Re wrote:
> 
> Basically, a csgetval(2) called as follows:
> 	csgetval ("net", "port", "566", "il", buf);
> returns a failure because, apparently, the request to /net/cs stops at
> the first entry (port=566 tcp=guard).  The actual value returned by
> csetval(2) seems to contain _only_ the above entry.
> 
I decided to take the plunge.

In /sys/src/cmd/ndb, I modified cs.c by adding a "count" value in
genquery() instead of terminating after the first match.  I don't
know if the same juggling in necessary elsewhere.  It solved the
netstat(1) problem.

++L

[-- Attachment #2.1.2: cs.c.diff --]
[-- Type: text/plain, Size: 510 bytes --]

diff -n /mnt/wrap/sys/src/cmd/ndb/cs.c /sys/src/cmd/ndb/cs.c
/mnt/wrap/sys/src/cmd/ndb/cs.c:1704 a /sys/src/cmd/ndb/cs.c:1705
> 	int count = 0;
/mnt/wrap/sys/src/cmd/ndb/cs.c:1733,1734 c /sys/src/cmd/ndb/cs.c:1734
< 				ndbfree(t);
< 				return 0;
---
> 				count++;
/mnt/wrap/sys/src/cmd/ndb/cs.c:1747,1748 c /sys/src/cmd/ndb/cs.c:1747
< 			ndbfree(t);
< 			return 0;
---
> 			count++;
/mnt/wrap/sys/src/cmd/ndb/cs.c:1754 c /sys/src/cmd/ndb/cs.c:1753,1754
< 
---
> 	if (count)
> 		return 0;

Re: [9fans] ndb/cs

[Lucio De Re]

[-- Attachment #1: Type: text/plain, Size: 626 bytes --]

On Thu, Aug 17, 2000 at 06:55:20PM +0200, Lucio De Re wrote:
> 
> Basically, a csgetval(2) called as follows:
> 	csgetval ("net", "port", "566", "il", buf);
> returns a failure because, apparently, the request to /net/cs stops at
> the first entry (port=566 tcp=guard).  The actual value returned by
> csetval(2) seems to contain _only_ the above entry.
> 
I decided to take the plunge.

In /sys/src/cmd/ndb, I modified cs.c by adding a "count" value in
genquery() instead of terminating after the first match.  I don't
know if the same juggling in necessary elsewhere.  It solved the
netstat(1) problem.

++L

[-- Attachment #2: cs.c.diff --]
[-- Type: text/plain, Size: 510 bytes --]

diff -n /mnt/wrap/sys/src/cmd/ndb/cs.c /sys/src/cmd/ndb/cs.c
/mnt/wrap/sys/src/cmd/ndb/cs.c:1704 a /sys/src/cmd/ndb/cs.c:1705
> 	int count = 0;
/mnt/wrap/sys/src/cmd/ndb/cs.c:1733,1734 c /sys/src/cmd/ndb/cs.c:1734
< 				ndbfree(t);
< 				return 0;
---
> 				count++;
/mnt/wrap/sys/src/cmd/ndb/cs.c:1747,1748 c /sys/src/cmd/ndb/cs.c:1747
< 			ndbfree(t);
< 			return 0;
---
> 			count++;
/mnt/wrap/sys/src/cmd/ndb/cs.c:1754 c /sys/src/cmd/ndb/cs.c:1753,1754
< 
---
> 	if (count)
> 		return 0;

[9fans] ndb/cs

[Lucio De Re]

I really am too frightened to look at the source, but an educated
guess leads me to believe that an inconsistency in the function of
ndb/cs is responsible for the lack of resolving in the names of the
"il" ports in netstat(1).

I wrote a simple test program, then double checked by using
ndb/csquery (the latter may not be all that indicative).

Basically, a csgetval(2) called as follows:
	csgetval ("net", "port", "566", "il", buf);
returns a failure because, apparently, the request to /net/cs stops at
the first entry (port=566 tcp=guard).  The actual value returned by
csetval(2) seems to contain _only_ the above entry.

I won't insult anyone (or embarrass myself) by posting the 20 lines of
so or code, unless it's the only way to prove my point (or embarrass
myself :-).

++L