panic: ipintr no HDR
>Synopsis: panic: ipintr no HDR >Category: kernel amd64 >Environment: System : OpenBSD 5.7 Details : OpenBSD 5.7-current (GENERIC.MP) #919: Mon Apr 13 21:03:43 MDT 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: I use security/vpnc to connect to my university network via WIFI, using $ dmesg | grep athn0 athn0 at pci2 dev 0 function 0 "Atheros AR5418" rev 0x01: apic 1 int 17 athn0: MAC AR5418 rev 2, RF AR5133 (2T3R), ROM rev 4, address 00:1b:63:02:1c:22 and try to download my mail using mail/offlineimap. With both GENERIC and GENERIC.MP from the April 14 snapshot, running mail/offlineimap triggers the following panic (transcribed by hand below). panic: ipintr no HDR Stopped at Debugger + 0x9: leave RUN AT LEAST ... ddb> trace Debugger() at Debugger + 0x9 panic() at panic + 0xfe ipintr()at ipintr + 0x3f netintr() at netintr + 0x85 softintr_dispatch at softintr_dispatch + 0x7f Xsoftnet() at Xsoftnet + 0x2d --- interrupt --- end trace frame:0x0,count -6 __ALIGN_SIZE + 0x1800 ddb> ps PID PPIDPGRP UID S FLAGS WAITCOMMAND 13743 7862 13743 10003 0x83select python 2.7 15190 7862 13743 10003 0x400083thrsleeppython 2.7 21094 7862 13743 10003 0x400083thrsleeppython 2.7 9340 7862 13743 10003 0x400083thrsleeppython 2.7 24442 7862 13743 10003 0x400083pollpython 2.7 30711 7862 13743 10003 0x400083thrsleeppython 2.7 *22792 1 22792 070x0vpnc 27605 1 27605 773 0x90polldhclient 22932 1 22392 03 0x80polldhclient 11828 1 11828 03 0x83ttyin getty 3636 13636 03 0x83ttyin getty 25678 1 25678 03 0x83ttyin getty 15010 1 15010 03 0x83ttyin getty 7862 17862 10003 0x8bpause zsh 4779 14779 03 0x80pollcron 20988 1 20988 03 0x80select sshd 19340 18093 18093 03 0x80bpf pflogd 18093 1 18093 03 0x80netio pflogd 11198 63946394 733 0x90kqread syslogd 6394 16706394 03 0x80netio syslogd 1670 0 0 030x14200pgzero zerothread 26492 0 0 030x14200aiodonedaiodoned 14706 0 0 030x14200syncer update 26121 0 0 030x14200cleaner cleaner 29431 0 0 030x14200reaper reaper 10920 0 0 030x14200pgdaemon pagedaemon 6007 0 0 030x14200bored srdis 25225 0 0 030x14200bored crypto 17126 0 0 030x14200pftmpfpurge 32558 0 0 030x14200usbtsk usbtask 4497 0 0 030x14200usbatsk usbatsk 18769 0 0 03 0x40014200acpi0 acpi0 17854 0 0 030x14200bored sensors 7148 0 0 030x14200bored softnet 15860 0 0 030x14200bored systqmp 22674 0 0 030x14200bored systq 21836 0 0 03 0x40014200bored idle0 1 0 1 03 0x82waitinit 0 -1 0 030x10200scheduler swapper ddb> boot sync >How-To-Repeat: The panic appears both with GENERIC and GENERIC.MP kernels whenever I to connect my laptop to the WLAN as usual and try to run offlineimap and vpnc as follows: $ cat .offlineimaprc [general] accounts = main [Account main] localrepository = main-local remoterepository = main-remote status_backend = sqlite [Repository main-local] type = Maildir localfolders = /home/theo/.Maildir [Repository main-remote] type = IMAP remotehost = mail.ethz.ch remoteuser = remoteport = 993 ssl = yes cert_fingerp
tcp keep-alives sent without timestamps
>Synopsis: tcp keep-alives sent without timestamps >Category: kernel >Environment: System : OpenBSD 5.7 Details : OpenBSD 5.7-current (GENERIC) #860: Mon Apr 13 20:58:42 MDT 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC Architecture: OpenBSD.amd64 Machine : amd64 >Description: TCP keep-alive messages sent by OpenBSD do not include timestamp options. When using pf tcp normalisation, this breaks eg. ssh(1) from OpenBSD to illumos after transmission of a keep-alive. On (at least) illumos, receiving an empty ACK like this in a connection which was initiated using timestamps in the SYN, the following data packets sent by the illumos host will not include timestamps either (I'm discussing on their mailing lists [0] whether that makes sense). This is a problem if those data packets are scrubbed with reassemble tcp when received by OpenBSD; they will get dropped, because previous data packets *did* include timestamps [pf_norm.c:1252 onwards]. >How-To-Repeat: - set sysctl net.inet.tcp.keepidle to a low value - open a tcp connection with SO_KEEPALIVE to an illumos host, eg. using ssh (TCPKeepAlive=yes is the default) - let the connection idle for half the amount of net.inet.tcp.keepidle - observe that data packets get delivered to the illumos host, but no data packets make it back. With 'pfctl -x notice', observe that pf_norm.c:1283 is reached. >Fix: Include timestamp options in TCP keep-alive ACKs when the connection uses them for other packets. [0]: https://www.listbox.com/member/archive/182193/2015/04/sort/time_rev/page/1/entry/0:1/20150414115040:F678B734-E2BD-11E4-A441-A07D3EA1AED1/ -- Lauri Tirkkonen | lotheac @ IRCnet
Re: tcp keep-alives sent without timestamps
On Tue, Apr 14, 2015 at 19:40 +0300, Lauri Tirkkonen wrote:
> >Synopsis:tcp keep-alives sent without timestamps
> >Category:kernel
> >Environment:
> System : OpenBSD 5.7
> Details : OpenBSD 5.7-current (GENERIC) #860: Mon Apr 13 20:58:42
> MDT 2015
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
>
> Architecture: OpenBSD.amd64
> Machine : amd64
> >Description:
> TCP keep-alive messages sent by OpenBSD do not include timestamp
> options. When using pf tcp normalisation, this breaks eg. ssh(1)
> from OpenBSD to illumos after transmission of a keep-alive.
>
> On (at least) illumos, receiving an empty ACK like this in a
> connection which was initiated using timestamps in the SYN, the
> following data packets sent by the illumos host will not include
> timestamps either (I'm discussing on their mailing lists [0]
> whether that makes sense). This is a problem if those data
> packets are scrubbed with reassemble tcp when received by
> OpenBSD; they will get dropped, because previous data packets
> *did* include timestamps [pf_norm.c:1252 onwards].
> >How-To-Repeat:
> - set sysctl net.inet.tcp.keepidle to a low value
> - open a tcp connection with SO_KEEPALIVE to an illumos host,
> eg. using ssh (TCPKeepAlive=yes is the default)
> - let the connection idle for half the amount of
> net.inet.tcp.keepidle
> - observe that data packets get delivered to the illumos host,
> but no data packets make it back. With 'pfctl -x notice',
> observe that pf_norm.c:1283 is reached.
> >Fix:
> Include timestamp options in TCP keep-alive ACKs when the
> connection uses them for other packets.
>
> [0]:
> https://www.listbox.com/member/archive/182193/2015/04/sort/time_rev/page/1/entry/0:1/20150414115040:F678B734-E2BD-11E4-A441-A07D3EA1AED1/
>
> --
> Lauri Tirkkonen | lotheac @ IRCnet
>
According to 3.2 in RFC 7323:
Once TSopt has been successfully negotiated, that is both and
contain TSopt, the TSopt MUST be sent in every non-
segment for the duration of the connection, and SHOULD be sent in an
segment (see Section 5.2 for details). The TCP SHOULD remember
this state by setting a flag, referred to as Snd.TS.OK, to one. If a
non- segment is received without a TSopt, a TCP SHOULD silently
drop the segment. A TCP MUST NOT abort a TCP connection because any
segment lacks an expected TSopt.
Indeed, we must set timestamps on keep alive packets, except that keep
alive is a bit of a hack and hence specs don't make any mention of it.
FreeBSD and NetBSD both should behave the same way. Which seems to
contradict RFC IMO. But then it begs the question should other options
be also included, e.g. TCP MD5 signatures?
Should in fact tcp_timer_keep call syn_cache_respond (with a patched up
sequence number)?
I had a stab at adding timestamp support to tcp_respond but couldn't
test yet. If you feel like giving it a try, please be my guest.
diff --git sys/netinet/tcp_subr.c sys/netinet/tcp_subr.c
index c8c8e77..9f83bca 100644
--- sys/netinet/tcp_subr.c
+++ sys/netinet/tcp_subr.c
@@ -370,14 +370,10 @@ tcp_respond(struct tcpcb *tp, caddr_t template, struct
tcphdr *th0,
xchg(th->th_dport, th->th_sport, u_int16_t);
else
flags = TH_ACK;
#undef xchg
- m->m_len = tlen;
- m->m_pkthdr.len = tlen;
- m->m_pkthdr.rcvif = (struct ifnet *) 0;
- m->m_pkthdr.csum_flags |= M_TCP_CSUM_OUT;
th->th_seq = htonl(seq);
th->th_ack = htonl(ack);
th->th_x2 = 0;
th->th_off = sizeof (struct tcphdr) >> 2;
th->th_flags = flags;
@@ -386,10 +382,26 @@ tcp_respond(struct tcpcb *tp, caddr_t template, struct
tcphdr *th0,
if (win > TCP_MAXWIN)
win = TCP_MAXWIN;
th->th_win = htons((u_int16_t)win);
th->th_urp = 0;
+ if ((tp->t_flags & (TF_REQ_TSTMP|TF_NOOPT)) == TF_REQ_TSTMP &&
+ (flags & TH_RST) == 0 && (tp->t_flags & TF_RCVD_TSTMP)) {
+ u_int32_t *lp = (u_int32_t *)(th + 1);
+ /* Form timestamp option as shown in appendix A of RFC 1323. */
+ *lp++ = htonl(TCPOPT_TSTAMP_HDR);
+ *lp++ = htonl(tcp_now + tp->ts_modulate);
+ *lp = htonl(tp->ts_recent);
+ tlen += TCPOLEN_TSTAMP_APPA;
+ th->th_off = (sizeof(struct tcphdr) + TCPOLEN_TSTAMP_APPA) >> 2;
+ }
+
+ m->m_len = tlen;
+ m->m_pkthdr.len = tlen;
+ m->m_pkthdr.rcvif = (struct ifnet *) 0;
+ m->m_pkthdr.csum_flags |= M_TCP_CSUM_OUT;
+
/* force routing table */
if (tp)
m->m_pkthdr.ph_rtableid = tp->t_inpcb->inp_rtableid;
else
m->m_pkthdr.ph_rtableid = rtableid;
Re: tcp keep-alives sent without timestamps
On Tue, Apr 14 2015 20:40:58 +0200, Mike Belopuhov wrote: > According to 3.2 in RFC 7323: > >Once TSopt has been successfully negotiated, that is both and > contain TSopt, the TSopt MUST be sent in every non- >segment for the duration of the connection, and SHOULD be sent in an > segment (see Section 5.2 for details). The TCP SHOULD remember >this state by setting a flag, referred to as Snd.TS.OK, to one. If a >non- segment is received without a TSopt, a TCP SHOULD silently >drop the segment. A TCP MUST NOT abort a TCP connection because any >segment lacks an expected TSopt. Thank you, I somehow missed the existence of this RFC. > I had a stab at adding timestamp support to tcp_respond but couldn't > test yet. If you feel like giving it a try, please be my guest. With your patch, I confirm that timestamps are present on keep-alive messages. -- Lauri Tirkkonen | lotheac @ IRCnet
panic when using tun(4) with openvpn on current
>Synopsis: panic when using tun(4) with openvpn on current
>Category: kernel
>Environment:
System : OpenBSD 5.7
Details : OpenBSD 5.7-current (GENERIC.MP) #919: Mon Apr 13
21:03:43 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Architecture: OpenBSD.amd64
Machine : amd64
>Description:
I use openvpn which sets up a tun(4) interface. As soon as I start
using the vpn (eg. with Firefox or lynx) the system panics.
A trace from cpu3 in ddb showed this:
ddb{3}> trace
Debugger() at Debugger+0x9
panic() at panic+0xfe
ipintr() at ipintr+0x3f
netintr() at netintr+0x85
softintr_dispatch() at softintr_dispatch+0x7f
Xsoftnet() at Xsoftnet+0x2d
--- interrupt ---
end trace frame: 0x0, count: -6
__ALLIGN_SIZE+0x1801:
ddb{3}>
Pictures from ddb:
ps (part 1): https://relo.ch/tun-panic-ps1.jpg
ps (part 2): https://relo.ch/tun-panic-ps2.jpg
trace from all 4 cpus: https://relo.ch/tun-panic-trace.jpg
I first noticed it while running the snapshot from April 11.
After I start openvpn the active network configuration looks
like this:
# ifconfig
lo0: flags=8049 mtu 32768
priority: 0
groups: lo
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff00
re0: flags=8802 mtu 1500
lladdr 18:67:b0:3e:b4:8f
priority: 0
media: Ethernet autoselect (none)
status: no carrier
enc0: flags=0<>
priority: 0
groups: enc
status: active
urtwn0: flags=208843 mtu 1500
lladdr 80:1f:02:da:13:e3
priority: 4
groups: wlan egress
media: IEEE802.11 autoselect (OFDM54 mode 11g)
status: active
ieee80211: nwid tsunami chan 6 bssid 4c:9e:ff:90:d8:c0 -82dBm wpakey
wpaprotos wpa1,wpa2 wpaakms psk wpaciphers tkip,ccmp
wpagroupcipher tkip
inet6 fe80::821f:2ff:feda:13e3%urtwn0 prefixlen 64 scopeid 0x4
inet6 2001:470:b70c:0:821f:2ff:feda:13e3 prefixlen 64 autoconf pltime
604778 vltime 2591978
inet6 2001:470:b70c:0:846b:a4cc:8aa:5a1e prefixlen 64 autoconf
autoconfprivacy pltime 85961 vltime 604590
inet 192.168.201.25 netmask 0xff00 broadcast 192.168.201.255
pflog0: flags=141 mtu 33144
priority: 0
groups: pflog
tun1: flags=8051 mtu 1500
priority: 0
groups: tun
status: active
inet 172.19.3.65 --> 172.19.3.66 netmask 0x
# route -n show
Routing tables
Internet:
DestinationGatewayFlags Refs Use Mtu Prio Iface
default192.168.201.1 UGS8 586 -12 urtwn0
127/8 127.0.0.1 UGRS 00 32768 8 lo0
127.0.0.1 127.0.0.1 UHl10 32768 1 lo0
172.16/16 172.19.3.66UGS00 - 8 tun1
172.17/16 172.19.3.66UGS00 - 8 tun1
172.18/16 172.19.3.66UGS00 - 8 tun1
172.19/16 172.19.3.66UGS00 - 8 tun1
172.19.3.65172.19.3.65UHl00 - 1 lo0
172.19.3.66172.19.3.65UH100 - 4 tun1
172.20/16 172.19.3.66UGS00 - 8 tun1
192.168.7/24 172.19.3.66UGS00 - 8 tun1
192.168.26/24 172.19.3.66UGS00 - 8 tun1
192.168.32/24 172.19.3.66UGS00 - 8 tun1
192.168.33/24 172.19.3.66UGS00 - 8 tun1
192.168.101/24 172.19.3.66UGS00 - 8 tun1
192.168.201/24 link#4 UC 20 - 4 urtwn0
192.168.201.1 00:0d:b9:32:fa:18 UHLc 1 28 - 4 urtwn0
192.168.201.20 84:7a:88:07:3f:30 UHLc 0 2295 - 4 urtwn0
192.168.201.25 80:1f:02:da:13:e3 UHLl 00 - 1 lo0
192.168.201.255link#4 UHLb 00 - 1 urtwn0
224/4 127.0.0.1 URS00 32768 8 lo0
Internet6:
DestinationGatewayFlags Refs
Use Mtu Prio Iface
::/104 ::1UGRS 0
0 32768 8 lo0
::/96 ::1UGRS 0
0 32768 8 lo0
defaultfe80::20d:b9ff:fe32:fa18%urtwn0 UG 0
729 -56 urtwn0
::1::1UHl 14
0 32768 1 lo0
::1
