Date: Wed, 06 May 2020 06:42:51 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 246247] Caddy webserver stops listening on port 80; port 443 continues to serve Message-ID: <bug-246247-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246247 Bug ID: 246247 Summary: Caddy webserver stops listening on port 80; port 443 continues to serve Product: Ports & Packages Version: Latest Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: Individual Port(s) Assignee: ports-bugs@FreeBSD.org Reporter: gac@tutanota.com Created attachment 214188 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D214188&action= =3Dedit pcap that generated the sample log entry in the bug description I have a VPS webserver running FreeBSD 12.1-RELEASE-p4, and the caddy-1.0.4 package from the FreeBSD repository. I'm having an intermittent issue; ever= y so often the webserver stops listening on port 80 which serves up HTTP->HTTPS redirects. Port 443 still works so Caddy is still running and the website is still available as long as you manually enter 'https://' So far, all I've worked out is that whenever this happens, a log entry is generated reading: May 6 03:46:26 server caddy[32009]: 2020/05/06 03:46:26 set tcp my.ip:80->remote.ip:52024: setsockopt: connection reset by peer After this point, `lsof -nni` shows no process listening on port 80 anymore= and trying to access this port from an HTTP client results in 'connection refus= ed' as expected when no process is bound to a port. I've had a rolling tcpdump capture running to try and figure out if there's a particular traffic patte= rn that triggers this, and so far only one pattern seems to stand out. At the point this happens, my server sees roughly the following: In: SYN + <1ms Out: SYN/ACK + ~150ms In: ACK + <1ms In: RST/ACK So the boxes triggering this appear to be roughly a 150ms round trip away in all cases and it seems to me like immediately after they send their regular= ACK to me, they also send a RST/ACK without waiting for any response to the reg= ular ACK. This is happening from multiple source IP addresses (some registered to AWS, some registered to a company called Dedipath, possibly others but I haven't checked every IP that has one of those log entries) and it's very intermittent. Sometimes it won't happen for months, sometimes it happens multiple times in a day. I've tried using Scapy to replicate this exact tra= ffic but have been unable to so far (either I'm doing it wrong, or there's somet= hing different about Scapy-generated traffic that means it's not a valid reproduction) I've brought this up with the Caddy project on GitHub but they haven't real= ly been able to offer any solid suggestions so I'm opening a bug here to try a= nd ascertain if it's a FreeBSD issue rather than a problem with Caddy. A coupl= e of other GitHub users suggested they've seen the same behaviour so I intend to= put the link for this bug on the Caddy issue tracker to see if they can provide= any further information. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-246247-7788>