From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=JpQu5E9X; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id C8EEA5A004E for ; Mon, 03 Feb 2025 09:35:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1738571739; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=w6BSJwpHm64JdXkNSDAN8VYBt2YdC5c4j38XW9Kqvaw=; b=JpQu5E9Xsk5OVnfCVPXoePL+bCUInHgh0DRMgZLLDlUOGJNe0WbbAlh8rhzmVHztUvS44h vL4J8Mv+g3QrU2d/TkoXVmAsbDCD8zd9CkUo6rMWbDsDnKQ1H6ke2aR1qc4xGT+pgdw+mb baZ1akisI7KDGCuKea8vPgEYwUDEsZI= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-526-FJjRdSvJNlqtVNMfYnutUQ-1; Mon, 03 Feb 2025 03:35:38 -0500 X-MC-Unique: FJjRdSvJNlqtVNMfYnutUQ-1 X-Mimecast-MFC-AGG-ID: FJjRdSvJNlqtVNMfYnutUQ Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-386333ea577so1688397f8f.1 for ; Mon, 03 Feb 2025 00:35:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738571735; x=1739176535; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=w6BSJwpHm64JdXkNSDAN8VYBt2YdC5c4j38XW9Kqvaw=; b=DKdGtBthVl06D5BFZkXJcBXPZb3KwSx2pzNsXy9KXcfrjh7oF90ka+rt++qRryKQ3Y 8KhQPcVOpzfak41Bu4QFTuhSQ5N4Jo3xuZmyqsghMx8ihTtYPbLFCuT44ZDj6Nq+0cuV TkjDcWEICzvL6qiC78p8BeW9uuu85O40PKSE4DC/1zC1yksxLcUVx0iJ1S6IZw/0nPxo xFpy8e8yAhkphvc7E+gMBQqq9YbhRrLys4bX92SDCJ+F/K1f2wE2xbtxlPZOEL+v5+M0 z0BAbGOn7pFeZHNiMQvQPmxwWW7HwUUQvc5FBm8fiJJiih2CSbdNclWgyUfld4/+bga3 CtCg== X-Gm-Message-State: AOJu0YxLMhuCJScO2D9Udsn0nq5FSYh+2smAVSicC0/5qixdSqHnwDIW lI3u4XT6egLHXlR1vVLWqhTlkHZba/Ztgqj/xPLZe1NYwytwDICS7UnNA81jp0mhUy8xbEZLAkZ EIZnPSH+F/bJ+OlRWfg5usv4UZhmvpQVfuz82MCQOwHY0AwitTewcKMyVuU5OFEn25VHbr/wvX5 czML83lLv/MhnlK6MS7yvGSxe5UV7KnAZU X-Gm-Gg: ASbGnctWNc0A+9KIp+/3xObPm5JujSQlW2ubbAf9fIuJBMAV8n3DEYR8nFa36EZv6HE OaSBgB+Y76/Nut9pbtIXJnRH43o730HSy4wi2oWvrkirTW5sIouUc6VNA4hWHYt/6lLHdlzQ5hi eLpq5RKtAZAzZZx07woXtqW8VT+UgxGnncOPjkA6Z/M3hLwRWcW0Hdu7pzN4WxTs/1a4482g9OS 7YclEM7T7SUQnENtWtvff0Xy0ti7KVj9wLjp7KbptIKNO9KveiTzXYJeafxAGYlJyYaOQ7zJofb kzu3yv8MAf75wmjPDnya8m6lfZBotp4K3Q== X-Received: by 2002:a5d:50c2:0:b0:38b:d7d2:12f2 with SMTP id ffacd0b85a97d-38c520bf925mr12078581f8f.54.1738571735317; Mon, 03 Feb 2025 00:35:35 -0800 (PST) X-Google-Smtp-Source: AGHT+IG/sMrEpiMsWavVazaLRqVRXnywXxHfFnBGYUvjhF1RqaB9acszB4lKJVNL3SEFn7TqRoVUmg== X-Received: by 2002:a5d:50c2:0:b0:38b:d7d2:12f2 with SMTP id ffacd0b85a97d-38c520bf925mr12078553f8f.54.1738571734770; Mon, 03 Feb 2025 00:35:34 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38c5c122539sm12061150f8f.46.2025.02.03.00.35.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Feb 2025 00:35:33 -0800 (PST) Date: Mon, 3 Feb 2025 09:35:31 +0100 From: Stefano Brivio To: Prafulla Giri Subject: Re: Apparmor (and other) Issues Message-ID: <20250203093531.6a71cc81@elisabeth> In-Reply-To: References: <20250129104112.0756df5c@elisabeth> <20250129194854.6b67fbfe@elisabeth> <3mWvqHbG0sGUhoq9ersir5eXDcFpZkAm8BGfuhs3YOBV36rlbJ82aj27diLMkSjg8YQnrQajsHKkcVh3kXG9gc-o2HZF2rQXo9DnqkqbwNQ=@protonmail.com> <20250131212024.34733b6d@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 3TRViBpY3jgSPiaiJtY4bNsS5CLE-1AVsB8Requ8o-o_1738571737 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: QMVF6GX6L6P7WYFUAIJVJVYPJ7Q7FVGR X-Message-ID-Hash: QMVF6GX6L6P7WYFUAIJVJVYPJ7Q7FVGR X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "passt-dev@passt.top" , Andrea Bolognani X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Sun, 02 Feb 2025 14:21:49 +0000 Prafulla Giri wrote: > On Saturday, February 1st, 2025 at 2:05 AM, Stefano Brivio wrote: >=20 > > On Thu, 30 Jan 2025 10:05:14 +0000 > > Prafulla Giri prafulla.giri@protonmail.com wrote: > > =20 > > > I didn't have auditd installed on Debian and installed it, and > > > running everything with the default auditd config (with my Apparmor > > > disabled for passt, as mentioned previously) does not result in > > > anything. Do I have to configure auditd manually? Any pointers on > > > that, please? =20 > >=20 > >=20 > > No, the default configuration is just fine. But you should re-enable > > AppArmor for passt so that we can see meaningful messages in the logs. > > =20 > The following is the output of grep-ping 'passt' after re-enforcing the a= pparmor config and trying to start a VM: > $ grep passt /var/log/audit/audit.log # Debian Trixie > type=3DAVC msg=3Daudit(1738501259.829:124): apparmor=3D"STATUS" operation= =3D"profile_load" profile=3D"unconfined" name=3D"passt" pid=3D1935 comm=3D"= apparmor_parser" > type=3DAVC msg=3Daudit(1738501309.118:135): apparmor=3D"DENIED" operation= =3D"file_mmap" class=3D"file" profile=3D"passt" name=3D"/usr/bin/passt" pid= =3D2030 comm=3D"passt" requested_mask=3D"r" denied_mask=3D"r" fsuid=3D1000 = ouid=3D0=1DFSUID=3D"larryboy" OUID=3D"root" > type=3DSYSCALL msg=3Daudit(1738501309.118:135): arch=3Dc000003e syscall= =3D59 success=3Dno exit=3D-13 a0=3D7faf24035fc0 a1=3D7faf24035210 a2=3D7ffc= 063280d0 a3=3D0 items=3D0 ppid=3D1964 pid=3D2030 auid=3D1000 uid=3D1000 gid= =3D1000 euid=3D1000 suid=3D1000 fsuid=3D1000 egid=3D1000 sgid=3D1000 fsgid= =3D1000 tty=3D(none) ses=3D1 comm=3D"passt" exe=3D"/usr/bin/passt" subj=3Dp= asst key=3D(null)=1DARCH=3Dx86_64 SYSCALL=3Dexecve AUID=3D"larryboy" UID=3D= "larryboy" GID=3D"larryboy" EUID=3D"larryboy" SUID=3D"larryboy" FSUID=3D"la= rryboy" EGID=3D"larryboy" SGID=3D"larryboy" FSGID=3D"larryboy" > type=3DANOM_ABEND msg=3Daudit(1738501309.118:136): auid=3D1000 uid=3D1000= gid=3D1000 ses=3D1 subj=3Dpasst pid=3D2030 comm=3D"passt" exe=3D"/usr/bin/= passt" sig=3D11 res=3D1=1DAUID=3D"larryboy" UID=3D"larryboy" GID=3D"larrybo= y" System call number 59 (this seems to be x86_64) is "execve": $ ausyscall 59 execve and this seems to be libvirt failing to execute passt itself, but: https://gitlab.com/libvirt/libvirt/-/blob/0264a7704ada52f686cafe8f6402d5b= 60f9f0fc4/src/security/apparmor/libvirt-qemu.in#L195 Do you see the libvirtd profile loaded if you run 'aa-status'? Do you have this line: /usr/bin/passt Cx -> passt, in /etc/apparmor.d/abstractions/libvirt-qemu? I wonder if something bad happened during installation. Can you perhaps grep a bit before and after those messages (say, grep -A5 -B5) to see if we spot something else related to libvirt? > type=3DAVC msg=3Daudit(1738501923.727:148): apparmor=3D"DENIED" operation= =3D"file_mmap" class=3D"file" profile=3D"passt" name=3D"/usr/bin/passt" pid= =3D2088 comm=3D"passt" requested_mask=3D"r" denied_mask=3D"r" fsuid=3D1000 = ouid=3D0=1DFSUID=3D"larryboy" OUID=3D"root" > type=3DSYSCALL msg=3Daudit(1738501923.727:148): arch=3Dc000003e syscall= =3D59 success=3Dno exit=3D-13 a0=3D7ff564035d40 a1=3D7ff564039d00 a2=3D7fff= e9aa1de0 a3=3D0 items=3D0 ppid=3D2060 pid=3D2088 auid=3D1000 uid=3D1000 gid= =3D1000 euid=3D1000 suid=3D1000 fsuid=3D1000 egid=3D1000 sgid=3D1000 fsgid= =3D1000 tty=3D(none) ses=3D1 comm=3D"passt" exe=3D"/usr/bin/passt" subj=3Dp= asst key=3D(null)=1DARCH=3Dx86_64 SYSCALL=3Dexecve AUID=3D"larryboy" UID=3D= "larryboy" GID=3D"larryboy" EUID=3D"larryboy" SUID=3D"larryboy" FSUID=3D"la= rryboy" EGID=3D"larryboy" SGID=3D"larryboy" FSGID=3D"larryboy" > type=3DANOM_ABEND msg=3Daudit(1738501923.727:149): auid=3D1000 uid=3D1000= gid=3D1000 ses=3D1 subj=3Dpasst pid=3D2088 comm=3D"passt" exe=3D"/usr/bin/= passt" sig=3D11 res=3D1=1DAUID=3D"larryboy" UID=3D"larryboy" GID=3D"larrybo= y" > type=3DAVC msg=3Daudit(1738502301.651:174): apparmor=3D"DENIED" operation= =3D"file_mmap" class=3D"file" profile=3D"passt" name=3D"/usr/bin/passt" pid= =3D2145 comm=3D"passt" requested_mask=3D"r" denied_mask=3D"r" fsuid=3D1000 = ouid=3D0=1DFSUID=3D"larryboy" OUID=3D"root" > type=3DSYSCALL msg=3Daudit(1738502301.651:174): arch=3Dc000003e syscall= =3D59 success=3Dno exit=3D-13 a0=3D7fe208034ce0 a1=3D7fe208034350 a2=3D7fff= d2e60120 a3=3D0 items=3D0 ppid=3D2117 pid=3D2145 auid=3D1000 uid=3D1000 gid= =3D1000 euid=3D1000 suid=3D1000 fsuid=3D1000 egid=3D1000 sgid=3D1000 fsgid= =3D1000 tty=3D(none) ses=3D1 comm=3D"passt" exe=3D"/usr/bin/passt" subj=3Dp= asst key=3D(null)=1DARCH=3Dx86_64 SYSCALL=3Dexecve AUID=3D"larryboy" UID=3D= "larryboy" GID=3D"larryboy" EUID=3D"larryboy" SUID=3D"larryboy" FSUID=3D"la= rryboy" EGID=3D"larryboy" SGID=3D"larryboy" FSGID=3D"larryboy" > type=3DANOM_ABEND msg=3Daudit(1738502301.651:175): auid=3D1000 uid=3D1000= gid=3D1000 ses=3D1 subj=3Dpasst pid=3D2145 comm=3D"passt" exe=3D"/usr/bin/= passt" sig=3D11 res=3D1=1DAUID=3D"larryboy" UID=3D"larryboy" GID=3D"larrybo= y" >=20 > > > $ passt -f -d # on Debian Testing/Trixie > > > 0.0016: No interfaces with usable IPv6 routes > > > 0.0017: Failed to detect external interface for IPv6 > > > 0.0028: UNIX domain socket bound at /tmp/passt_1.socket > > > 0.0029: Template interface: enp1s0 (IPv4) > > > 0.0029: MAC: > > > 0.0029: host: 9a:55:9a:55:9a:55 > > > 0.0029: NAT to host 127.0.0.1: 192.168.100.1 > > > 0.0029: DHCP: > > > 0.0029: assign: 192.168.100.157 > > > 0.0029: mask: 255.255.255.0 > > > 0.0029: router: 192.168.100.1 > > > 0.0029: DNS: > > > 0.0029: 192.168.100.1 =20 > >=20 > >=20 > > So, judging from this configuration, it looks like we advertise to > > the guest (via DHCP) 192.168.100.1 as resolver (copied from the host), > > and when we receive packets from the guest for 192.168.100.1, we'll > > re-map them to the host. > >=20 > > Nothing strange so far, systemd-resolved is running on the host, it > > should get our queries and reply to them. > > =20 > > > $ cat /etc/resolv.conf # On Debian Trixie > > > # This is /run/systemd/resolve/resolv.conf managed by > > > man:systemd-resolved(8). [...] > > > nameserver 192.168.100.1 > > > search . > > > $ cat /etc/resolv.conf # On a Debian 11 OS > > > # Generated by NetworkManager > > > nameserver 192.168.100.1 > > >=20 > > > Also the output of `resolvectl status` for good measure: > > > # On Fedora 41 > > > Global > > > Protocols: LLMNR=3Dresolve -mDNS -DNSOverTLS > > > DNSSEC=3Dno/unsupported resolv.conf mode: stub > > >=20 > > > Link 2 (wlp0s20f3) > > > Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 > > > Protocols: +DefaultRoute LLMNR=3Dresolve -mDNS -DNSOverTLS > > > DNSSEC=3Dno/unsupported Current DNS Server: 192.168.100.1 > > > DNS Servers: 192.168.100.1 > > >=20 > > > # On Debian Trixie > > > Global > > > Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=3Dno/unsupported > > > resolv.conf mode: uplink > > >=20 > > > Link 2 (enp1s0) > > > Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 > > > Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS > > > DNSSEC=3Dno/unsupported DNS Servers: 192.168.100.1 > > > Default Route: yes =20 > >=20 > >=20 > > Everything as expected here, I don't see any obvious reason why > > systemd-resolved should discard our queries. > > =20 > > > The log from Debian Trixie host for VM1: > > > passt 0.0~git20250121.4f2c8e7-1: /usr/bin/passt.avx2 (6428) > > > 0.0017: info: No interfaces with usable IPv6 routes > > > 0.0029: info: UNIX domain socket bound at > > > /run/user/1000/libvirt/qemu/run/passt/2-vm1-net0.socket 0.0030: info: > > > Template interface: enp1s0 (IPv4) 0.0030: info: MAC: > > > 0.0030: info: host: 9a:55:9a:55:9a:55 > > > 0.0030: info: NAT to host 127.0.0.1: 192.168.100.1 > > > 0.0030: info: DHCP: > > > 0.0031: info: assign: 192.168.100.157 > > > 0.0031: info: mask: 255.255.255.0 > > > 0.0031: info: router: 192.168.100.1 > > > 0.0031: info: DNS: > > > 0.0031: info: 192.168.100.1 > > > 0.0031: info: DNS search list: > > > 0.0031: info: . > > > 0.0066: info: > > > You can now start qemu (>=3D 7.2, with commit 13c6be96618c): > > > 0.0066: info: kvm ... -device virtio-net-pci,netdev=3Ds -netdev > > > stream,id=3Ds,server=3Doff,addr.type=3Dunix,addr.path=3D/run/user/100= 0/libvirt/qemu/run/passt/2-vm1-net0.socket > > > 0.0066: info: or qrap, for earlier qemu versions: 0.0066: info: > > > ./qrap 5 kvm ... -net socket,fd=3D5 -net nic,model=3Dvirtio 0.0617: > > > info: accepted connection from PID 0 38.6257: info: DHCP: offer > > > to discover 38.6257: info: from 52:54:00:a0:e1:7c > > > 38.6471: info: DHCP: ack to request > > > 38.6471: info: from 52:54:00:a0:e1:7c > > > 451.4989: info: Client connection closed, exiting =20 > >=20 > >=20 > > Unfortunately libvirt doesn't let us enable more verbose logging. I > > hoped to see DNS queries there, but without --debug given to passt, > > that won't work. > >=20 > > Another idea: pasta(1) does the same job as passt(1) (it's the same > > code and same binary) and it's intended for containers, but it has a > > stand-alone mode that can probably help us to debug this, because it's > > a network namespace that will look like your guest, and it can also > > take packet captures. > >=20 > > What happens if you run: > >=20 > > pasta --config-net --trace --pcap /tmp/dns.pcap -- nslookup fsf.org > >=20 > > ? =20 > This one errors out. dns.pcap is attached. > $ pasta --config-net --trace --pcap /tmp/dns.pcap -- nslookup fsf.org # D= ebian Trixie/Testing > 0.0015: No interfaces with usable IPv6 routes > 0.0015: Failed to detect external interface for IPv6 > 0.0073: Template interface: enp1s0 (IPv4) > 0.0073: Namespace interface: enp1s0 > 0.0074: MAC: > 0.0074: host: 9a:55:9a:55:9a:55 > 0.0074: NAT to host 127.0.0.1: 192.168.100.1 > 0.0074: DHCP: > 0.0074: assign: 192.168.100.157 > 0.0074: mask: 255.255.255.0 > 0.0075: router: 192.168.100.1 > 0.0075: DNS: > 0.0075: 192.168.100.1 > 0.0076: DNS search list: > 0.0076: . > 0.0146: SO_PEEK_OFF supported > 0.0146: TCP_INFO tcpi_snd_wnd field supported > 0.0146: TCP_INFO tcpi_bytes_acked field supported > 0.0146: TCP_INFO tcpi_min_rtt field supported > 0.0147: Saving packet capture to /tmp/dns.pcap > 0.0197: pasta: epoll event on /dev/net/tun device 16 (events: 0x00000001) > 0.0371: pasta: epoll event on /dev/net/tun device 16 (events: 0x00000001) > 0.0372: pasta: epoll event on /dev/net/tun device 16 (events: 0x00000001) > 0.0372: tap: protocol 17, 192.168.100.157:41892 -> 192.168.100.1:53 (1 pa= cket) > 0.0372: Flow 0 (NEW): FREE -> NEW > 0.0372: Flow 0 (INI): NEW -> INI > 0.0372: Flow 0 (INI): TAP [192.168.100.157]:41892 -> [192.168.100.1]:53 = =3D> ? > 0.0372: Flow 0 (TGT): INI -> TGT > 0.0373: Flow 0 (TGT): TAP [192.168.100.157]:41892 -> [192.168.100.1]:53 = =3D> HOST [0.0.0.0]:41892 -> [127.0.0.1]:53 > 0.0373: Flow 0 (UDP flow): TGT -> TYPED > 0.0373: Flow 0 (UDP flow): TAP [192.168.100.157]:41892 -> [192.168.100.1]= :53 =3D> HOST [0.0.0.0]:41892 -> [127.0.0.1]:53 > 0.0373: Flow 0 (UDP flow): Side 0 hash table insert: bucket: 31049 > 0.0374: Flow 0 (UDP flow): TYPED -> ACTIVE > 0.0374: Flow 0 (UDP flow): TAP [192.168.100.157]:41892 -> [192.168.100.1]= :53 =3D> HOST [0.0.0.0]:41892 -> [127.0.0.1]:53 > 0.0374: pasta: epoll event on UDP reply socket 95 (events: 0x00000008) > 0.0374: ICMP error on UDP socket 95: Connection refused Ouch. I just sent a patch for this, you can test it by checking out passt locally: git clone git://passt.top/passt; cd passt applying it (you might need to install 'b4'): b4 shazam https://archives.passt.top/passt-dev/20250203082210.2114348-1-sbrivio@red= hat.com/ then: make and ./pasta --config-net --trace --pcap /tmp/dns.pcap -- nslookup fsf.org You can also install it to /usr/local with 'make install', it's just a couple of files and will uninstall cleanly with 'make uninstall' if needed. Note that AppArmor profiles don't apply to binaries under /usr/local/bin. > [...] > > This is rather strange: from the shell I successfully managed to `ping fs= f.org` and `ping gnu.org`. That's because they were already cached on your host at this point (I suppose by systemd-resolved) and ping didn't need to resolve anything, just call getaddrinfo() and get the addresses back. There's no UDP at all in the output below: > I went back and ran > $ pasta --config-net --trace --pcap /tmp/ping.pcap -- ping -c 5 fsf.org #= and the following output followed (ping.pcap is also attached) >=20 > 0.0013: No interfaces with usable IPv6 routes > 0.0013: Failed to detect external interface for IPv6 > 0.0091: Template interface: enp1s0 (IPv4) > 0.0091: Namespace interface: enp1s0 > 0.0092: MAC: > 0.0092: host: 9a:55:9a:55:9a:55 > 0.0092: NAT to host 127.0.0.1: 192.168.100.1 > 0.0092: DHCP: > 0.0092: assign: 192.168.100.157 > 0.0093: mask: 255.255.255.0 > 0.0093: router: 192.168.100.1 > 0.0093: DNS: > 0.0093: 192.168.100.1 > 0.0093: DNS search list: > 0.0094: . > 0.0161: SO_PEEK_OFF supported > 0.0161: TCP_INFO tcpi_snd_wnd field supported > 0.0161: TCP_INFO tcpi_bytes_acked field supported > 0.0161: TCP_INFO tcpi_min_rtt field supported > 0.0162: Saving packet capture to /tmp/ping.pcap > PING fsf.org (209.51.188.174) 56(84) bytes of data. > 0.0181: pasta: epoll event on /dev/net/tun device 16 (events: 0x00000001) > 0.0181: pasta: epoll event on /dev/net/tun device 16 (events: 0x00000001) > 0.0182: tap: protocol 1, 192.168.100.157 -> 209.51.188.174 (1 packet) --=20 Stefano