[bugzilla-daemon@xxxxxxxxxxxxx]

Guy Harris changed bug 11070

What	Removed	Added
Status	UNCONFIRMED	RESOLVED
Resolution	---	NOTOURBUG
Summary	Error capturing/decrypting SSL/TLS traffic: "tshark: Error while capturing packets: SIOCGSTAMPNS: No such file or directory"	tshark: Error while capturing packets: SIOCGSTAMPNS: No such file or directory

Comment # 4 on bug 11070 from Guy Harris

(In reply to Ian V. from comment #1)
> I should say I looked through the source, as well as the kernel source for
> the error message (SIOCGSTAMPNS is a kernel identifier).

Yes, it's an ioctl used by libpcap to fetch nanosecond-resolution time stamps
from a PF_PACKET socket when the memory-mapped capture mechanism isn't be used.

This is a bit surprising, as a recent top-of-trunk libpcap should be using the
memory-mapped capture mechanism unless it's been hacked not to do so.

ENOENT is also a rather surprising error for that ioctl to return.

> The error message in the wireshark source was cryptic though,

The error message from TShark means "libpcap said this failed, and this is all
it had to say about it".

The error message from libpcap means "this really shouldn't be failing, but it
did, and this is all the kernel had to say about it".

In the 3.11.0 kernel, sock_get_timestampns() does:

int sock_get_timestampns(struct sock *sk, struct timespec __user *userstamp)
{
        struct timespec ts;
        if (!sock_flag(sk, SOCK_TIMESTAMP))
                sock_enable_timestamp(sk, SOCK_TIMESTAMP);
        ts = ktime_to_timespec(sk->sk_stamp);
        if (ts.tv_sec == -1)
                return -ENOENT;
        if (ts.tv_sec == 0) {
                sk->sk_stamp = ktime_get_real();
                ts = ktime_to_timespec(sk->sk_stamp);
        }
        return copy_to_user(userstamp, &ts, sizeof(ts)) ? -EFAULT : 0;
}

so ts.tv_sec is presumably getting set to -1 by ktime_to_timespec().

So the kernel is doing something weird here.  That code path is well before any
SSL decryption - it's not even in the same *program* as the SSL decryption, as
the capturing is being done in dumpcap, not TShark/Wireshark - so this is
probably a kernel issue of some sort.

---

      You are receiving this mail because:

• You are watching all bug changes.