[Solved] forum.tinycorelinux.net only reachable from home when using TCL

[GNUser]

I discovered that when I'm on my home network, these two of my favorite websites:

https://forum.tinycorelinux.net
https://www.linguee.com

are only reachable from my laptop while running TCL. If I boot into a Devuan partition on this same laptop (with same local IP, same public IP, same DNS, same browser version, same browser configuration), I cannot reach https://forum.tinycorelinux.net--I get ERR_TIMED_OUT as shown in the attachment.

All other sites I've tried visiting from home work fine regardless of the OS I'm using.

I've never encountered such a strange networking problem before (where ability to visit a website seems OS-dependent). The main/relevant differences between TCL and Devuan running on this laptop are:

1. TCL does not have persistence while Devuan does. I tried totally emptying the cache in Devuan, to no avail.

2. TCL connects to wifi using barebones shell scripts while Devuan uses network-manager

Here are some details when booted into TCL vs. Devuan:

TCL:

Code: [Select]

bruno@x230:~$ sudo ifconfig wlan0
wlan0     Link encap:Ethernet  HWaddr 54:2A:A2:6A:XX:XX 
          inet addr:192.168.10.161  Bcast:192.168.10.255  Mask:255.255.255.0
          inet6 addr: fd11:1111:cafe:cafe:562a:a2ff:fe6a:33fe/64 Scope:Global
          inet6 addr: fe80::562a:a2ff:fe6a:33fe/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:89 errors:0 dropped:0 overruns:0 frame:0
          TX packets:63 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:21503 (20.9 KiB)  TX bytes:8252 (8.0 KiB)

bruno@x230:~$ sudo route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.10.1    0.0.0.0         UG    0      0        0 wlan0
127.0.0.1       *               255.255.255.255 UH    0      0        0 lo
192.168.10.0    *               255.255.255.0   U     0      0        0 wlan0

$ nslookup forum.tinycorelinux.net
Server:    94.140.14.14
Address 1: 94.140.14.14 dns.adguard-dns.com

Name:      forum.tinycorelinux.net
Address 1: 217.160.150.65 mail.tinycorelinux.net

bruno@x230:~$ sudo traceroute forum.tinycorelinux.net
traceroute to forum.tinycorelinux.net (217.160.150.65), 30 hops max, 60 byte packets
 1  192.168.10.1 (192.168.10.1)  1.028 ms  0.968 ms  0.931 ms
 2  10.128.0.1 (10.128.0.1)  17.193 ms  17.144 ms  17.109 ms
 3  static-198-44-159-1.cust.tzulo.com (198.44.159.1)  28.125 ms  28.102 ms  28.050 ms
 4  * * *
 5  * * *
 6  * * *
 7  ae1.cr14-nyc3.ip4.gtt.net (213.254.214.110)  26.024 ms  15.949 ms  15.890 ms
 8  ip4.gtt.net (209.120.131.190)  20.282 ms  24.718 ms  24.690 ms
 9  * * *
10  4.42.171.238 (4.42.171.238)  30.489 ms  26.433 ms  23.465 ms
11  74.208.1.81 (74.208.1.81)  20.368 ms  12.990 ms  20.243 ms
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
Devuan:

Code: [Select]

bruno@x230:~$ sudo busybox ifconfig wlan0
wlan0     Link encap:Ethernet  HWaddr 54:2A:A2:6A:XX:XX 
          inet addr:192.168.10.161  Bcast:192.168.10.255  Mask:255.255.255.0
          inet6 addr: fd11:1111:cafe:cafe:562a:a2ff:fe6a:33fe/64 Scope:Global
          inet6 addr: fe80::562a:a2ff:fe6a:33fe/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:18 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1996 (1.9 KiB)  TX bytes:2659 (2.5 KiB)

bruno@x230:~$ sudo busybox route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.10.1    0.0.0.0         UG    600    0        0 wlan0
192.168.10.0    *               255.255.255.0   U     600    0        0 wlan0

bruno@x230:~$ busybox nslookup forum.tinycorelinux.net
Server:    94.140.14.14
Address 1: 94.140.14.14 dns.adguard-dns.com

Name:      forum.tinycorelinux.net
Address 1: 217.160.150.65 mail.tinycorelinux.net

bruno@x230:~$ sudo traceroute forum.tinycorelinux.net
traceroute to forum.tinycorelinux.net (217.160.150.65), 30 hops max, 60 byte packets
 1  192.168.10.1 (192.168.10.1)  0.724 ms  0.836 ms  1.446 ms
 2  10.128.0.1 (10.128.0.1)  20.226 ms  20.277 ms  20.404 ms
 3  static-198-44-159-1.cust.tzulo.com (198.44.159.1)  20.749 ms  20.739 ms  20.723 ms
 4  * * *
 5  * * *
 6  * * *
 7  ae1.cr14-nyc3.ip4.gtt.net (213.254.214.110)  26.797 ms  18.840 ms  17.476 ms
 8  ip4.gtt.net (209.120.131.190)  17.457 ms  17.447 ms  32.076 ms
 9  * * *
10  4.42.171.238 (4.42.171.238)  31.172 ms  31.148 ms  31.126 ms
11  74.208.1.81 (74.208.1.81)  28.674 ms  21.218 ms  21.192 ms
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
Can anyone think of why forum.tinycorelinux.net is reachable form TCL but not reachable from Devuan, on same hardware with largely identical networking parameters (ip addresses, router, modem, browser, etc)? I'm so perplexed by this

[GNUser]

Maybe it has something to do with ipv6 playing interference? I think network-manager has it on by default but I don't remember explicitly turning it on in TCL. I'll explore that and will report back.

[GNUser]

Maybe it has something to do with ipv6 playing interference? I think network-manager has it on by default but I don't remember explicitly turning it on in TCL. I'll explore that and will report back.

Nope. If I run this in Devuan...

Code: [Select]

sudo sh -c 'echo 1 >/proc/sys/net/ipv6/conf/all/disable_ipv6'
...then try reaching forum.tinycorelinux.net, still no luck. There's some gremlin in my Devuan partition that the TCL forum doesn't like. It's not ipv6.

[GNUser]

It's also not a firewall issue, since neither the TCL nor Devuan partition is running a firewall:

TCL:

Code: [Select]

bruno@x230:~$ sudo iptables -L
sudo: iptables: command not found
bruno@x230:~$ sudo nft list ruleset
bruno@x230:~$
Devuan:

Code: [Select]

$ sudo iptables -L
sudo: iptables: command not found
bruno@x230:~$ sudo nft list ruleset
bruno@x230:~$
P.S. Full disclosure--I do run VPN in my router, which adds complexity. But the router treats the TCL and Devuan partitions identically given that both have the same wireless nic and same local ip. The router doesn't care about the wireless client's OS. I predict that the problem has something to do with the wireless client, nothing to do with the router.

[Rich]

Hi GNUser
I notice the routing table under TCL includes  lo (127.0.0.1)  while
Devuan doesn't include it.

[GNUser]

I figured it out by trial and error.

I remembered that many years ago I had trouble loading yahoo.com and duckduckgo.com when vpn was running in the router. The problem at that time had to do with some websites not dealing well with packet fragmentation.

As I mentioned, vpn is running in the router. I use wireguard and its default MTU is 1420.

I added this rule to router's firewall (table=filter, chain=forward) (note: MTU = maxseg size (mss) + 40)

Code: [Select]

oif tun0 tcp option maxseg size set 1380

Lo and behold, now I can reach forum.tinycorelinux.net (as well as linguee.com) regardless of OS.

There's still something mysterious going on, though: The output of ifconfig wlan0 for both Devuan and TCL shows "MTU:1500"

I know for sure--through extensive testing--that setting maxseg size set 1380 in the router solved my problem. Therefore, I cannot believe that both OS's are really using the same MTU. The MTU's of the two OS's must be different, despite what ifconfig is telling me. (My suspicion is on Devuan's network-manager, which has a tendency to use its own settings and be at odds with other utilities.)

[GNUser]

Thread may be marked as "Solved."

P.S. I'd be interested in measuring the MTU of the packets arriving at the router from my wireless clients, to verify the MTU being reported by the clients. I have a strong suspicion that the reported MTU is not always the actual MTU.

Does anyone know of a relatively painless way to measure MTU of packets arriving at a wireless router? My router is running TCL16 x86_64 so it is very cooperative

[Rich]

Hi GNUser
Google:
tcpdump measure mtu size

[GNUser]

Hi Rich. Thanks for the tip. tcpdump seems to be the tool I need. If I discover anything interesting I'll post it here.

[Rich]

Hi GNUser
I'll be interested to see what you find. I've never used tcpdump, only
wireshark, which is a lot heavier.

[GNUser]

Hi Rich. In retrospect my previous post was not helpful. Please delete it.

In case you are interested, I did some more experiments to try to understand the issue. First I calculated the MTU between my home and 8.8.8.8 (using this as a guide: https://www.comparitech.com/net-admin/determine-mtu-size-using-ping). Here are the final two steps that lead to the answer (ping here is Devuan's more full-featured version):

Code: [Select]

devuan_laptop$ ping -M do -s 1392 -c 5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1392(1420) bytes of data.
1400 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=25.5 ms
1400 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=18.9 ms
1400 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=19.5 ms
1400 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=18.3 ms
1400 bytes from 8.8.8.8: icmp_seq=5 ttl=117 time=36.5 ms

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 18.335/23.739/36.512/6.879 ms

devuan_laptop$ ping -M do -s 1393 -c 5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1393(1421) bytes of data.
ping: sendmsg: Message too long
ping: sendmsg: Message too long
ping: sendmsg: Message too long
ping: sendmsg: Message too long
ping: sendmsg: Message too long

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4102ms

According to the guide at the link, to calculate MTU I should add 28 bytes (for TCP and IP headers) to the maximum packet size that can be sent via ping without fragmentation. So: 1392 + 28 = 1420 bytes. This confirms what I thought: Because of wireguard running in my router, the MTU between my wireless clients at home and WLAN is 1420 bytes.

Next, I went to my workplace where everything is very vanilla (including router and MTU). I just wanted to see if there is any difference in the packet sizes in Devuan <-> forum.tinycorelinux.net traffic compared to TCL <-> forum.tinycorelinux.net traffic:

For Devuan:

Code: [Select]

$ sudo tcpdump -c 500 -i wlan0 dst 217.160.150.65 or src 217.160.150.65 >devuan.txt 2>&1
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:47:10.980391 IP 10.1.72.248.48768 > mail.tinycorelinux.net.https: Flags [S], seq 207632985, win 64240, options [mss 1460,sackOK,TS val 1633752549 ecr 0,nop,wscale 7], length 0
09:47:10.991469 IP mail.tinycorelinux.net.https > 10.1.72.248.48768: Flags [S.], seq 666093319, ack 207632986, win 65160, options [mss 1250,sackOK,TS val 877561695 ecr 1633752549,nop,wscale 7], length 0
09:47:10.991500 IP 10.1.72.248.48768 > mail.tinycorelinux.net.https: Flags [.], ack 1, win 502, options [nop,nop,TS val 1633752560 ecr 877561695], length 0
09:47:10.991782 IP 10.1.72.248.48768 > mail.tinycorelinux.net.https: Flags [P.], seq 1:544, ack 1, win 502, options [nop,nop,TS val 1633752560 ecr 877561695], length 543
09:47:11.002736 IP mail.tinycorelinux.net.https > 10.1.72.248.48768: Flags [.], ack 544, win 505, options [nop,nop,TS val 877561707 ecr 1633752560], length 0
09:47:11.003357 IP mail.tinycorelinux.net.https > 10.1.72.248.48768: Flags [.], seq 1:1239, ack 544, win 505, options [nop,nop,TS val 877561709 ecr 1633752560], length 1238
09:47:11.003376 IP 10.1.72.248.48768 > mail.tinycorelinux.net.https: Flags [.], ack 1239, win 525, options [nop,nop,TS val 1633752572 ecr 877561709], length 0
09:47:11.006151 IP mail.tinycorelinux.net.https > 10.1.72.248.48768: Flags [P.], seq 1239:2477, ack 544, win 505, options [nop,nop,TS val 877561709 ecr 1633752560], length 1238
09:47:11.006151 IP mail.tinycorelinux.net.https > 10.1.72.248.48768: Flags [P.], seq 2477:3141, ack 544, win 505, options [nop,nop,TS val 877561709 ecr 1633752560], length 664
09:47:11.006162 IP 10.1.72.248.48768 > mail.tinycorelinux.net.https: Flags [.], ack 2477, win 539, options [nop,nop,TS val 1633752575 ecr 877561709], length 0
09:47:11.006172 IP 10.1.72.248.48768 > mail.tinycorelinux.net.https: Flags [.], ack 3141, win 534, options [nop,nop,TS val 1633752575 ecr 877561709], length 0
09:47:11.006422 IP 10.1.72.248.48768 > mail.tinycorelinux.net.https: Flags [P.], seq 544:608, ack 3141, win 539, options [nop,nop,TS val 1633752575 ecr 877561709], length 64
09:47:11.006639 IP 10.1.72.248.48768 > mail.tinycorelinux.net.https: Flags [P.], seq 608:700, ack 3141, win 539, options [nop,nop,TS val 1633752575 ecr 877561709], length 92
09:47:11.006801 IP 10.1.72.248.48768 > mail.tinycorelinux.net.https: Flags [P.], seq 700:1188, ack 3141, win 539, options [nop,nop,TS val 1633752575 ecr 877561709], length 488
09:47:11.016612 IP mail.tinycorelinux.net.https > 10.1.72.248.48768: Flags [.], ack 1188, win 500, options [nop,nop,TS val 877561721 ecr 1633752575], length 0
09:47:11.016613 IP mail.tinycorelinux.net.https > 10.1.72.248.48768: Flags [P.], seq 3141:3428, ack 1188, win 500, options [nop,nop,TS val 877561721 ecr 1633752575], length 287
09:47:11.016613 IP mail.tinycorelinux.net.https > 10.1.72.248.48768: Flags [P.], seq 3428:3715, ack 1188, win 500, options [nop,nop,TS val 877561721 ecr 1633752575], length 287
09:47:11.016614 IP mail.tinycorelinux.net.https > 10.1.72.248.48768: Flags [P.], seq 3715:3786, ack 1188, win 500, options [nop,nop,TS val 877561721 ecr 1633752575], length 71
09:47:11.016687 IP 10.1.72.248.48768 > mail.tinycorelinux.net.https: Flags [.], ack 3786, win 541, options [nop,nop,TS val 1633752585 ecr 877561721], length 0
09:47:11.016807 IP 10.1.72.248.48768 > mail.tinycorelinux.net.https: Flags [P.], seq 1188:1219, ack 3786, win 541, options [nop,nop,TS val 1633752585 ecr 877561721], length 31
09:47:11.032936 IP mail.tinycorelinux.net.https > 10.1.72.248.48768: Flags [P.], seq 3786:6262, ack 1219, win 500, options [nop,nop,TS val 877561737 ecr 1633752585], length 2476
09:47:11.032937 IP mail.tinycorelinux.net.https > 10.1.72.248.48768: Flags [P.], seq 6262:7782, ack 1219, win 500, options [nop,nop,TS val 877561737 ecr 1633752585], length 1520
...

Code: [Select]

$ grep -Eo 'length [0-9]+' devuan.txt | sort -rn -k2 | head -n 25
length 262144
length 3714
length 3714
length 3714
length 3714
length 3714
length 3714
length 3714
length 3714
length 3714
length 3714
length 3714
length 3714
length 3714
length 3714
length 2476
length 2476
length 2476
length 2476
length 2476
length 2476
length 2476
length 2476
length 2476
length 2476
For TCL:

Code: [Select]

$ sudo tcpdump -c 500 -i wlan0 dst 217.160.150.65 or src 217.160.150.65 >tcl.txt 2>&1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:54:59.353795 IP 10.1.72.248.37954 > mail.tinycorelinux.net.https: Flags [S], seq 2021830696, win 64240, options [mss 1460,sackOK,TS val 1547205637 ecr 0,nop,wscale 7], length 0
09:54:59.368915 IP mail.tinycorelinux.net.https > 10.1.72.248.37954: Flags [S.], seq 678553525, ack 2021830697, win 65160, options [mss 1250,sackOK,TS val 878031089 ecr 1547205637,nop,wscale 7], length 0
09:54:59.368953 IP 10.1.72.248.37954 > mail.tinycorelinux.net.https: Flags [.], ack 1, win 502, options [nop,nop,TS val 1547205653 ecr 878031089], length 0
09:54:59.369379 IP 10.1.72.248.37954 > mail.tinycorelinux.net.https: Flags [.], seq 1:1239, ack 1, win 502, options [nop,nop,TS val 1547205653 ecr 878031089], length 1238
09:54:59.369382 IP 10.1.72.248.37954 > mail.tinycorelinux.net.https: Flags [P.], seq 1239:2085, ack 1, win 502, options [nop,nop,TS val 1547205653 ecr 878031089], length 846
09:54:59.383984 IP mail.tinycorelinux.net.https > 10.1.72.248.37954: Flags [.], ack 1239, win 500, options [nop,nop,TS val 878031103 ecr 1547205653], length 0
09:54:59.383985 IP mail.tinycorelinux.net.https > 10.1.72.248.37954: Flags [.], ack 2085, win 494, options [nop,nop,TS val 878031103 ecr 1547205653], length 0
09:54:59.383985 IP mail.tinycorelinux.net.https > 10.1.72.248.37954: Flags [P.], seq 1:239, ack 2085, win 494, options [nop,nop,TS val 878031104 ecr 1547205653], length 238
09:54:59.384017 IP 10.1.72.248.37954 > mail.tinycorelinux.net.https: Flags [.], ack 239, win 501, options [nop,nop,TS val 1547205668 ecr 878031104], length 0
09:54:59.386618 IP 10.1.72.248.37954 > mail.tinycorelinux.net.https: Flags [P.], seq 2085:2149, ack 239, win 501, options [nop,nop,TS val 1547205670 ecr 878031104], length 64
09:54:59.386951 IP 10.1.72.248.37954 > mail.tinycorelinux.net.https: Flags [P.], seq 2149:2241, ack 239, win 501, options [nop,nop,TS val 1547205671 ecr 878031104], length 92
09:54:59.387300 IP 10.1.72.248.37954 > mail.tinycorelinux.net.https: Flags [P.], seq 2241:2749, ack 239, win 501, options [nop,nop,TS val 1547205671 ecr 878031104], length 508
09:54:59.398854 IP mail.tinycorelinux.net.https > 10.1.72.248.37954: Flags [.], ack 2749, win 489, options [nop,nop,TS val 878031122 ecr 1547205670], length 0
09:54:59.398857 IP mail.tinycorelinux.net.https > 10.1.72.248.37954: Flags [P.], seq 239:526, ack 2749, win 489, options [nop,nop,TS val 878031122 ecr 1547205670], length 287
09:54:59.398858 IP mail.tinycorelinux.net.https > 10.1.72.248.37954: Flags [P.], seq 526:597, ack 2749, win 489, options [nop,nop,TS val 878031123 ecr 1547205670], length 71
09:54:59.399037 IP 10.1.72.248.37954 > mail.tinycorelinux.net.https: Flags [.], ack 597, win 501, options [nop,nop,TS val 1547205683 ecr 878031122], length 0
09:54:59.399147 IP 10.1.72.248.37954 > mail.tinycorelinux.net.https: Flags [P.], seq 2749:2780, ack 597, win 501, options [nop,nop,TS val 1547205683 ecr 878031122], length 31
09:54:59.420017 IP mail.tinycorelinux.net.https > 10.1.72.248.37954: Flags [P.], seq 597:3073, ack 2780, win 489, options [nop,nop,TS val 878031142 ecr 1547205683], length 2476
09:54:59.420020 IP mail.tinycorelinux.net.https > 10.1.72.248.37954: Flags [P.], seq 3073:4593, ack 2780, win 489, options [nop,nop,TS val 878031142 ecr 1547205683], length 1520
09:54:59.420022 IP mail.tinycorelinux.net.https > 10.1.72.248.37954: Flags [P.], seq 4593:7069, ack 2780, win 489, options [nop,nop,TS val 878031142 ecr 1547205683], length 2476
09:54:59.420023 IP mail.tinycorelinux.net.https > 10.1.72.248.37954: Flags [P.], seq 7069:7606, ack 2780, win 489, options [nop,nop,TS val 878031142 ecr 1547205683], length 537
...

Code: [Select]

$ grep -Eo 'length [0-9]+' tcl.txt | sort -rn -k2 | head -n 25
length 3714
length 2476
length 2476
length 2476
length 2476
length 2476
length 2476
length 2476
length 2476
length 2476
length 2476
length 2476
length 2476
length 2476
length 2476
length 2476
length 2476
length 2476
length 2476
length 2476
length 2476
length 2476
length 2476
length 2476
length 2476
So, to my surprise, there are large packets (>1420 bytes, even >1500 bytes) traveling between my laptop and forum.tinycorelinux.net, regardless of whether I'm running Devuan or TCL.

To summarize, here are the things I know for sure:
1. MTU between my wireless clients at home and 8.8.8.8 (which is presumably representative of WLAN) is 1420 bytes
2. Without a "mss clamp" rule in my router's firewall, I can reach forum.tinycorelinux.net in any browser when using TCL
3. Without a "mss clamp" rule in my router's firewall, I cannot reach forum.tinycorelinux.net when using Devuan or Android (I tested multiple browsers)
4. With a "mss clamp" rule in my router's firewall, I can reach forum.tinycorelinux.net using any device/OS/browser

Based on the result of the tcpdumps above, it seems Devuan's packet sizes are not larger than TCL's packet sizes (rather than one  packet measuring 262144 bytes for which I don't have a good explanation).

Conclusion:
I know that an mss clamp in my router's firewall is what I need for all websites to be reachable from all devices, but I do not have a good explanation for why that's the case. It does not seem to have anything to do with packet sizes--but I'm a total tcpdump newbie so I may be misinterpreting its data. If one of you gurus has an explanation for how/why the mss clamp is needed, please do share.

[gadget42]

^^^@GNUser, re: "one packet measuring 262144 bytes for which I don't have a good explanation"

your "grep" caught the 262144 because devuan tcpdump calls it a "snapshot length" while tcl tcpdump calls it a "capture size"

firewalls/iptables/etc are on my bucket list but i shall wait until i have read Peter N. M. Hansteen's forthcoming awesomeness circa spring 2026(hopefully):

The Book of PF, 4th Edition - A No-Nonsense Guide to the OpenBSD Firewall - Peter N. M. Hansteen

https://nostarch.com/book-of-pf-4th-edition

https://nxdomain.no/~peter/yes_the_book_of_pf_4th_ed_is_coming.html

https://bsdly.blogspot.com/2025/07/yes-book-of-pf-4th-edition-is-coming.html

edited to add: @all, while you're visiting nostarch you could always fall down this rabbithole of a webpage: https://nostarch.com/catalog/security

20250816-0338am-cdt-usa-modified: edited to add content

[Rich]

Hi GNUser
Try running this under TCL and see if anything interesting come back:

Code: [Select]

sudo sysctl -a | grep -iE 'mss|mtu'

[GNUser]

Hi Rich. Thanks for the tip. Nothing jumps out at me as a definitive explanation for why TCL never has a problem but Devuan needs an mss clamp in the router in order to reach some sites (e.g., forum.tinycorelinux.net):

Code: [Select]

TCL16_x86_64$ sudo sysctl -a | grep -iE 'mss|mtu'
net.ipv4.ip_forward_use_pmtu = 0
net.ipv4.ip_no_pmtu_disc = 0
net.ipv4.route.min_adv_mss = 256
net.ipv4.route.min_pmtu = 552
net.ipv4.route.mtu_expires = 600
net.ipv4.tcp_base_mss = 1024
net.ipv4.tcp_min_snd_mss = 48
net.ipv4.tcp_mtu_probe_floor = 48
net.ipv4.tcp_mtu_probing = 0
sysctl: error reading key 'net.ipv6.conf.all.stable_secret': Input/output error
net.ipv6.conf.all.accept_ra_mtu = 1
net.ipv6.conf.all.mtu = 1280
sysctl: error reading key 'net.ipv6.conf.default.stable_secret': Input/output error
net.ipv6.conf.default.accept_ra_mtu = 1
net.ipv6.conf.default.mtu = 1280
sysctl: error reading key 'net.ipv6.conf.dummy0.stable_secret': Input/output error
net.ipv6.conf.dummy0.accept_ra_mtu = 1
net.ipv6.conf.dummy0.mtu = 1500
sysctl: error reading key 'net.ipv6.conf.eth0.stable_secret': Input/output error
net.ipv6.conf.eth0.accept_ra_mtu = 1
net.ipv6.conf.eth0.mtu = 1500
sysctl: error reading key 'net.ipv6.conf.lo.stable_secret': Input/output error
net.ipv6.conf.lo.accept_ra_mtu = 1
net.ipv6.conf.lo.mtu = 65536
sysctl: error reading key 'net.ipv6.conf.tunl0.stable_secret': Input/output error
net.ipv6.conf.tunl0.accept_ra_mtu = 1
net.ipv6.conf.tunl0.mtu = 1480
sysctl: error reading key 'net.ipv6.conf.wlan0.stable_secret': Input/output error
net.ipv6.conf.wlan0.accept_ra_mtu = 1
net.ipv6.conf.wlan0.mtu = 1500
net.ipv6.route.min_adv_mss = 1220
net.ipv6.route.mtu_expires = 600

DevuanExcalibur_64bit$ sudo sysctl -a | grep -iE 'mss|mtu'
net.ipv4.ip_forward_use_pmtu = 0
net.ipv4.ip_no_pmtu_disc = 0
net.ipv4.route.min_adv_mss = 256
net.ipv4.route.min_pmtu = 552
net.ipv4.route.mtu_expires = 600
net.ipv4.tcp_base_mss = 1024
net.ipv4.tcp_min_snd_mss = 48
net.ipv4.tcp_mtu_probe_floor = 48
net.ipv4.tcp_mtu_probing = 0
net.ipv6.conf.all.accept_ra_mtu = 1
net.ipv6.conf.all.mtu = 1280
net.ipv6.conf.default.accept_ra_mtu = 1
net.ipv6.conf.default.mtu = 1280
net.ipv6.conf.eth0.accept_ra_mtu = 1
net.ipv6.conf.eth0.mtu = 1500
net.ipv6.conf.lo.accept_ra_mtu = 1
net.ipv6.conf.lo.mtu = 65536
net.ipv6.conf.wlan0.accept_ra_mtu = 1
net.ipv6.conf.wlan0.mtu = 1500
net.ipv6.route.min_adv_mss = 1220
net.ipv6.route.mtu_expires = 600

[Rich]

Hi GNUser
These settings from Devuan looked interesting, but you're not running IP6, right?:

Code: [Select]

net.ipv6.conf.eth0.mtu = 1500
net.ipv6.conf.wlan0.mtu = 1500