pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162024-01-11T18:46:05ZpfSense bugtracker
Redmine pfSense - Bug #15156 (Feedback): Fragmented packets delayed by limiters are losthttps://redmine.pfsense.org/issues/151562024-01-11T18:46:05ZGeorgiy Tyutyunnik
<p>Client is having issues with outgoing SIP calls on XG-1537 23.09.1 specifically. KVM host with the same config works correctly.<br />Possible fragmentation handling issue.<br />pre-NAT there are 1514-sized packet followed by 87-sized packet of SIP invite, marked as "fragmented/ reassembled in x+1". and post-NAT I only see 1514-sized packets. captures attached<br />scrub enabling/disabling doesn't have any effect on the issue</p> pfSense - Regression #14431 (Feedback): Sending IPv6 traffic on a disabled interface can trigger ...https://redmine.pfsense.org/issues/144312023-05-29T14:41:52ZSteve Wheeler
<p>This issue was hidden by <a class="external" href="https://redmine.pfsense.org/issues/14164">https://redmine.pfsense.org/issues/14164</a> but now that is solved in 23.05 is being seen.</p>
<pre>
db:1:pfs> bt
Tracing pid 93402 tid 103857 td 0xfffffe00cf7cac80
kdb_enter() at kdb_enter+0x32/frame 0xfffffe00cf8a0800
vpanic() at vpanic+0x183/frame 0xfffffe00cf8a0850
panic() at panic+0x43/frame 0xfffffe00cf8a08b0
trap_fatal() at trap_fatal+0x409/frame 0xfffffe00cf8a0910
trap_pfault() at trap_pfault+0x4f/frame 0xfffffe00cf8a0970
calltrap() at calltrap+0x8/frame 0xfffffe00cf8a0970
--- trap 0xc, rip = 0xffffffff80f5a036, rsp = 0xfffffe00cf8a0a40, rbp = 0xfffffe00cf8a0a70 ---
in6_selecthlim() at in6_selecthlim+0x96/frame 0xfffffe00cf8a0a70
tcp_default_output() at tcp_default_output+0x1ded/frame 0xfffffe00cf8a0c60
tcp_output() at tcp_output+0x14/frame 0xfffffe00cf8a0c80
tcp6_usr_connect() at tcp6_usr_connect+0x2f4/frame 0xfffffe00cf8a0d10
soconnectat() at soconnectat+0x9e/frame 0xfffffe00cf8a0d60
kern_connectat() at kern_connectat+0xc9/frame 0xfffffe00cf8a0dc0
sys_connect() at sys_connect+0x75/frame 0xfffffe00cf8a0e00
amd64_syscall() at amd64_syscall+0x109/frame 0xfffffe00cf8a0f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe00cf8a0f30
--- syscall (98, FreeBSD ELF64, connect), rip = 0x800fddc8a, rsp = 0x7fffdf5f8c98, rbp = 0x7fffdf5f8cd0 ---
</pre>
<pre>
db:1:pfs> bt
Tracing pid 68614 tid 100330 td 0xfffffe00cf325720
kdb_enter() at kdb_enter+0x32/frame 0xfffffe00c7d955f0
vpanic() at vpanic+0x183/frame 0xfffffe00c7d95640
panic() at panic+0x43/frame 0xfffffe00c7d956a0
trap_fatal() at trap_fatal+0x409/frame 0xfffffe00c7d95700
trap_pfault() at trap_pfault+0x4f/frame 0xfffffe00c7d95760
calltrap() at calltrap+0x8/frame 0xfffffe00c7d95760
--- trap 0xc, rip = 0xffffffff80f63aa4, rsp = 0xfffffe00c7d95830, rbp = 0xfffffe00c7d95a50 ---
ip6_output() at ip6_output+0xb74/frame 0xfffffe00c7d95a50
udp6_send() at udp6_send+0x78e/frame 0xfffffe00c7d95c10
sosend_dgram() at sosend_dgram+0x357/frame 0xfffffe00c7d95c70
sousrsend() at sousrsend+0x5f/frame 0xfffffe00c7d95cd0
kern_sendit() at kern_sendit+0x132/frame 0xfffffe00c7d95d60
sendit() at sendit+0xb7/frame 0xfffffe00c7d95db0
sys_sendto() at sys_sendto+0x4d/frame 0xfffffe00c7d95e00
amd64_syscall() at amd64_syscall+0x109/frame 0xfffffe00c7d95f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe00c7d95f30
--- syscall (133, FreeBSD ELF64, sendto), rip = 0x823f95f2a, rsp = 0x8202cea88, rbp = 0x8202cead0 ---
</pre>
<pre>
db:1:pfs> bt
Tracing pid 2 tid 100041 td 0xfffffe0085264560
kdb_enter() at kdb_enter+0x32/frame 0xfffffe00850ad910
vpanic() at vpanic+0x183/frame 0xfffffe00850ad960
panic() at panic+0x43/frame 0xfffffe00850ad9c0
trap_fatal() at trap_fatal+0x409/frame 0xfffffe00850ada20
trap_pfault() at trap_pfault+0x4f/frame 0xfffffe00850ada80
calltrap() at calltrap+0x8/frame 0xfffffe00850ada80
--- trap 0xc, rip = 0xffffffff80f5a036, rsp = 0xfffffe00850adb50, rbp = 0xfffffe00850adb80 ---
in6_selecthlim() at in6_selecthlim+0x96/frame 0xfffffe00850adb80
tcp_default_output() at tcp_default_output+0x1ded/frame 0xfffffe00850add70
tcp_timer_rexmt() at tcp_timer_rexmt+0x514/frame 0xfffffe00850addd0
tcp_timer_enter() at tcp_timer_enter+0x102/frame 0xfffffe00850ade10
softclock_call_cc() at softclock_call_cc+0x13c/frame 0xfffffe00850adec0
softclock_thread() at softclock_thread+0xe9/frame 0xfffffe00850adef0
fork_exit() at fork_exit+0x7d/frame 0xfffffe00850adf30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00850adf30
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
db:1:pfs>
</pre> pfSense - Bug #14290 (Feedback): ICMPv6 Path MTU Discovery breaks with NPThttps://redmine.pfsense.org/issues/142902023-04-20T06:14:28ZPhilip S
<p>I have the following setup:</p>
<p>Tunnel via HE.net<br />Internal Prefix on LAN: 2001:db8:1::1/64<br />Routed /48 from HE: 2001:db8:2::/48</p>
<p>NPt is setup on GIF interface like this:<br />Internal Prefix: 2001:db8:1::/48<br />External Prefix: 2001:db8:2::/48<br />MTU Set to 1452 on HE and local tunnel interface, LAN interface set to 1500</p>
<p>I check test-ipv6.com and see it complains about MTU issues, I then test pmtu with tracepath from a linux machine while watching tcpdump for icmp6 I see no packet to large messages<br />when I disable NPt I immediately get the correct ICMPv6 too large replies, same when I have tracepath running while changing config on the tunnel interface and hit apply</p>
<p>but as soon as NPt is enabled, no more ICMPv6 too large messages</p>
<p>pfSense 23.01-RELEASE (arm) on SG-3100</p>