Since I upgraded my gateway / filter to an APU1D running 5.8-stable,
I've been getting "connection refused" every time I try to access
www.openbsd.org or ftp.openbsd.org.
- the gateway gets its connection from a ONT, via a switch which does
some vlan splitting (VoIP and IPTV vlans are sent elsewhere). The
problem persists if the gateway is connected straight to the ONT, with
no switch involved.
- this behaviour hasn't been seen with any other website, and
connections to "neighbouring" IPs (e.g. 188.8.131.52 and .193) work.
- pings and traceroutes are ok (see below)
- if I connect a MacBook to the ONT everything works fine there
- Everything worked fine with the previous setup (Soekris net4801
running 5.7-stable) with a pf ruleset that is essentially the same
(minor changes to ifnames).
- pf doesn't seem to be the culprit, as the problem persists even if
"pfctl -d" briefly (see below). Also, all block rules are logged and
nothing shows up on pflog0
Can anyone help me debug this further? What am I missing?
All following commands were ran on the gateway:
# ping -c 2 www.openbsd.org
PING www.openbsd.org (184.108.40.206): 56 data bytes
64 bytes from 220.127.116.11: icmp_seq=0 ttl=237 time=161.053 ms
64 bytes from 18.104.22.168: icmp_seq=1 ttl=237 time=156.808 ms
--- www.openbsd.org ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 156.808/158.930/161.053/2.159 ms
$ traceroute -n www.openbsd.org
traceroute to www.openbsd.org (22.214.171.124), 64 hops max, 40 byte packets
1 * * *
2 126.96.36.199 2.734 ms 7.096 ms 2.708 ms
3 188.8.131.52 2.38 ms 2.513 ms 2.232 ms
4 184.108.40.206 107.715 ms 113.575 ms 106.362 ms
5 220.127.116.11 104.771 ms 106.121 ms 106.139 ms
6 18.104.22.168 34.062 ms 34.054 ms 35.029 ms
7 22.214.171.124 106.025 ms 105.684 ms 107.137 ms
8 126.96.36.199 108.458 ms 109.071 ms 106.873 ms
9 188.8.131.52 109.272 ms 109.033 ms 110.187 ms
10 184.108.40.206 120.601 ms 120.061 ms 119.916 ms
11 220.127.116.11 139.284 ms 142.777 ms 138.417 ms
12 18.104.22.168 140.142 ms 141.428 ms 139.363 ms
13 22.214.171.124 155.431 ms 155.313 ms 156.591 ms
14 126.96.36.199 154.882 ms 154.304 ms 154.325 ms
15 188.8.131.52 158.266 ms 156.794 ms 157.025 ms
16 184.108.40.206 157.345 ms 157.001 ms 157.51 ms
17 220.127.116.11 158.45 ms 156.856 ms 156.796 ms
18 18.104.22.168 156.129 ms 156.31 ms 158.011 ms
On 2015-11-06 12:08, Zé Loff wrote:
> Since I upgraded my gateway / filter to an APU1D running 5.8-stable,
> I've been getting "connection refused" every time I try to access
> www.openbsd.org or ftp.openbsd.org.
(For some reason my Thunderbird refused to quote your debug dump output.
Probably because it is preceeded by "-- " alone on a new line, which
tricks it into thinking it is the start of the mail signature.)
FWIW, I'm seeing the same bad ip checksum errors on my development
computer running -current (as of sometime last week). This is regardless
of what site I try to connect to (well, I tried two, www.openbsd.org and
one not running OpenBSD).
On a stock 5.7 server (haven't got any 5.8-stable around) I don't see
the checksum errors.
However, unlike your scenario, regardless of checksum errors my -current
box seems to connect fine everywhere, and it receives what appears to be
> FWIW, I'm seeing the same bad ip checksum errors on my development
> computer running -current (as of sometime last week). This is regardless
> of what site I try to connect to (well, I tried two, www.openbsd.org and
> one not running OpenBSD).
> On a stock 5.7 server (haven't got any 5.8-stable around) I don't see
> the checksum errors.
> However, unlike your scenario, regardless of checksum errors my -current
> box seems to connect fine everywhere, and it receives what appears to be
> correct data.
If I'm not mistaken, machines that do hardware checksumming will show an
incorrect checksum in tcpdump.
On 11/6/15, Raul Miller <[hidden email]> wrote:
> On Fri, Nov 6, 2015 at 10:26 AM, Ted Unangst <[hidden email]> wrote:
>> If I'm not mistaken, machines that do hardware checksumming will show an
>> incorrect checksum in tcpdump.
> That sounds like it should be a problem with some specific machines,
> rather than a protocol issue.
What Ted means, is the software driver for the NIC does not
calculate the checksum for the packet if the hardware is capable*
of taking on that task. Therefore, in those cases, tcpdump will
show "bad checksum". This is expected as the HW hasn't seen
the packet yet; once it does, the packet will be sent out with
* This assumes the HW is capable of checksum offloading and the
driver is enabling said feature (hence, not calculating the checksum
itself, in software).
> Do you recall which machines exhibited this problem?