[Bug 276294] net/mpd5: crashes host when configured with PPPoE

2024-05-08 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276294

--- Comment #5 from Gleb Smirnoff  ---
On Wed May  8 20:54:10  2024 UTC, ohartm...@walstatt.org wrote:
> PR 272319 claims to have fixed the problem except for kernels with INVARIANTS
> option.

This is very unlikely related to 272319, which is about problem
in ng_ksocket(4).  When mpd5 runs PPPoE, it doesn't use ng_ksocket.

We need backtrace for the panic to understand what's going on. Please
obtain it and post to the bug. More info on obtaining backtrace:

https://docs.freebsd.org/en/books/developers-handbook/kerneldebug/#kerneldebug-obtain

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 278847] Kernel build errors in the kernel config with the ip17x device

2024-05-08 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278847

--- Comment #3 from Vladyslav V. Prodan  ---
(In reply to Ed Maste from comment #1)

--
>>> Kernel build for test-14-0.1 completed on Wed May  8 08:02:09 EEST 2024
--
>>> Kernel(s)  test-14-0.1 built in 1921 seconds, ncpu: 6
--

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 278847] Kernel build errors in the kernel config with the ip17x device

2024-05-08 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278847

--- Comment #2 from Vladyslav V. Prodan  ---
(In reply to Ed Maste from comment #1)

Similar situation with device ukswitch...
Both of them require INVARIANTS support...

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 276294] net/mpd5: crashes host when configured with PPPoE

2024-05-08 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276294

--- Comment #4 from O. Hartmann  ---
(In reply to Eugene Grosbein from comment #2)

PR 272319 claims to have fixed the problem except for kernels with INVARIANTS
option.

My customized kernel has been stripped off almost every debugging and fancy
reporting facility and NOT being configured with option INVARIANTS - though it
is crashing in the "usual way" as it did more than a year ago ...

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 276294] net/mpd5: crashes host when configured with PPPoE

2024-05-08 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276294

O. Hartmann  changed:

   What|Removed |Added

 Blocks||272319


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272319
[Bug 272319] FreeBSD kernel crash on MPD5 restart with PPP configuration.
-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 276294] net/mpd5: crashes host when configured with PPPoE

2024-05-08 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276294

--- Comment #3 from O. Hartmann  ---
As of today, the appliance has

FreeBSD 14.1-STABLE #2 stable/14-n267607-7e10c2d27a53: Sat May  4 08:33:15 CEST
2024 amd64

The router/FW was up a couple of days/weeks for now. We stopped triggering a
restart of mpd5 via cron every night (to force ISP assigning new IPv4/IPv6 at a
time it is uncritical for the connection, otherwise the iterruption is
performed within business times).

I observe that the longer the router/fw runs, the higher the likelyhood that
the crash appears after the first "service mpd5 restart" performed after boot.

Immediately after boot it takes a couple of attempts to trigger the crash.

--

root@gate:~ # service mpd5 restart
Stopping mpd5.
Waiting for PIDS: 1076.
Starting mpd5.
root@gate:~ #

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x10
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x8097d23a
stack pointer   = 0x28:0xfe00842afaa0
frame pointer   = 0x28:0xfe00842afbd0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume,
IOPL = 0
current process = 1581 (isc-net-0005)
rdi: f80021ebb000 rsi: 001c rdx:
0010
rcx:   r8: 00fd  r9:
7ac356fd
rax:  rbx: f80021ebb000 rbp:
fe00842afbd0
r10: f80007e12698 r11: f800027dc4f0 r12:
fe00842afaa8
r13: f80002831480 r14: fe00842afb70 r15:
fe00842afb70
trap number = 12
panic: page fault
cpuid = 0
time = 1715199106
Uptime: 4d13h8m24s
Automatic reboot in 15 seconds - press a key on the
console to abort

-- 
You are receiving this mail because:
You are the assignee for the bug.


Re: Discarding inbound ICMP REDIRECT by default

2024-05-08 Thread Ed Maste
On Tue, 7 May 2024 at 14:35, Marek Zarychta
 wrote:
>
> But what about IPv6 ? We have "net.inet6.icmp6.rediraccept" knob which
> defaults to 1. Can ICMPv6 redirects be fixed along with the change
> proposed for the legacy IP protocol?

It may make sense to apply the same default change for IPv6, but I
don't think we need to tie the two discussions / investigations
together.



[Bug 278847] Kernel build errors in the kernel config with the ip17x device

2024-05-08 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278847

Ed Maste  changed:

   What|Removed |Added

 CC||ema...@freebsd.org

--- Comment #1 from Ed Maste  ---
Can you give the patch in https://reviews.freebsd.org/D45133 a try?

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 237921] wpi: Memory leak in function wpi_free_tx_ring of sys/dev/wpi/if_wpi.c

2024-05-08 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237921

--- Comment #8 from Yusuf Khan  ---
(In reply to Cheng Cui from comment #7)
I dont have the device to test it either...It looks good to me anyway.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug 256587] tcpreplay not working for if_tun (tun0)

2024-05-08 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256587

--- Comment #3 from commit-h...@freebsd.org ---
A commit in branch stable/14 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=3f6515c20f381d6e136c8c322eadc69fd0e6c4aa

commit 3f6515c20f381d6e136c8c322eadc69fd0e6c4aa
Author: Seth Hoffert 
AuthorDate: 2023-10-22 14:12:45 +
Commit: Mark Johnston 
CommitDate: 2024-05-08 13:06:15 +

bpf: Make BPF interop consistent with if_loop

The pseudo_AF_HDRCMPLT check is already being done in if_loop and
just needed to be ported over to if_ic, if_wg, if_disc, if_gif,
if_gre, if_me, if_tuntap and ng_iface.  This is needed in order to
allow these interfaces to work properly with e.g., tcpreplay.

PR: 256587
Reviewed by:markj
MFC after:  2 weeks
Pull Request:   https://github.com/freebsd/freebsd-src/pull/876

(cherry picked from commit 2cb0fce24d64039090dc9243cdf0715ee80c91b1)

 sys/dev/iicbus/if_ic.c  | 4 ++--
 sys/dev/wg/if_wg.c  | 3 ++-
 sys/net/if_disc.c   | 2 +-
 sys/net/if_gif.c| 3 ++-
 sys/net/if_gre.c| 3 ++-
 sys/net/if_me.c | 3 ++-
 sys/net/if_tuntap.c | 2 +-
 sys/netgraph/ng_iface.c | 2 +-
 8 files changed, 13 insertions(+), 9 deletions(-)

-- 
You are receiving this mail because:
You are the assignee for the bug.