Subject: kern/28758: ktrace should record socket addresses
To: None <,,>
From: None <>
List: netbsd-bugs
Date: 12/23/2004 03:06:00
>Number:         28758
>Category:       kern
>Synopsis:       ktrace should record socket addreses
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Thu Dec 23 03:06:00 +0000 2004
>Originator:     Ken Raeburn <>
>Release:        NetBSD 2.0
System: NetBSD 2.0 NetBSD 2.0 (THUD) #0: Mon Dec 13 12:23:18 EST 2004 root@thud:/usr/obj/sys/arch/i386/compile/THUD i386
Architecture: i386
Machine: i386

I was trying to monitor the activity of a process.  In various socket
calls, it appears that ktrace does not record the socket addresses
supplied or returned.  So I can see a message is being sent or
received, but can't tell the remote address without also running
tcpdump (or equivalent) and correlating the messages and/or timestamps
from ktrace with those from tcpdump.

   856 host     socket(0x2, 0x2, 0)                = 3
   856 host     connect(0x3, 0x12086dc2c, 0x10)    = 0
   856 host     sendto(0x3, 0x1fffdea48, 0x1f, 0, 0, 0) = 31
   856 host     gettimeofday(0x1fffde2b8, 0)       = 0
   856 host     select(0x4, 0x1fffde338, 0, 0, 0x1fffde2a8) = 1
   856 host     recvfrom(0x3, 0x1fffeea48, 0x10000, 0, 0x1fffde358, 0x1fffde3d8) = 156
   856 host     close(0x3)                         = 0


% ktruss host `hostname`

(assuming the local hostname isn't listed in /etc/hosts, you're using
DNS, etc)


Add a new ktrace record type, I assume; write the data out during
syscalls like connect(), sendto(), recvfrom(), getpeername(),
getsockname(), etc, and update ktruss/kdump to display it.  (Including
AF_UNIX, unless *all* the socket calls would result in NAMEI records
being logged.)

Maybe additional -t options controlling whether to record/display

Ideally, it should provide some helpful information if .sa_len doesn't
match the application-supplied length, or the size of the appropriate
sockaddr_foo for the address family, etc.