summaryrefslogtreecommitdiffstats
path: root/sys/netinet/tcp_debug.c
diff options
context:
space:
mode:
authoritojun <itojun@openbsd.org>2000-04-14 04:20:57 +0000
committeritojun <itojun@openbsd.org>2000-04-14 04:20:57 +0000
commit362a1c190f49f64acac485f876fd85750b31a0f6 (patch)
treef56072c2e4e91c17694b9c54da66b734025e1130 /sys/netinet/tcp_debug.c
parentSome documentation for future generations of maintainers (diff)
downloadwireguard-openbsd-362a1c190f49f64acac485f876fd85750b31a0f6.tar.xz
wireguard-openbsd-362a1c190f49f64acac485f876fd85750b31a0f6.zip
for layer 3 protocols that does not support path MTU discovery
(I mean, IPv4) do not try to use rmx_mtu on routing table. this symptom was introduced by rmx_mtu initialization (necessary for IPv6 path MTU discovery) in net/route.c. now prior behavior is recovered. From: Hugh Graham <hugh@openbsd.org> there are several question about mssdflt semantics, though: Question 1: with the current code, mssdflt does not override rmx_mtu value (mssdflt overrides interface mtu only). should we override rmx_mtu by mssdflt as well? Question 2: with the current code, mssdflt overrides mss computed from if mtu, only when the destination is IPv4 non-local. is it safe enough? we may want to use mssdflt, whenever we are uncertain. mss = if mtu - hdrsiz; if (IPv4 non-local destination) mss = min(mss, mssdflt);
Diffstat (limited to 'sys/netinet/tcp_debug.c')
0 files changed, 0 insertions, 0 deletions