6.3 (GENERIC.MP) #3: panic: Data modified on freelist

This happened 36 hours after upgrading to 6.3 and applying syspatch: ddb{0}> dmesg OpenBSD 6.3 (GENERIC.MP) #3: Fri May 18 00:06:26 CEST 2018 r...@syspatch-63-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC. MP real mem = 4264062976 (4066MB) avail mem = 4127744000 (3936MB) mpath0 at

Re: double fault trap at pf_test+0xc on 6.2-STABLE

> Am 22.01.2018 um 14:47 schrieb Alexander Bluhm : > > > Looks like this bug, already fixed in -current. > > https://marc.info/?l=openbsd-cvs=15084109691=2 > Any reason why this was not included in OpenBSD

Re: double fault trap at pf_test+0xc on 6.2-STABLE

> Am 22.01.2018 um 14:47 schrieb Alexander Bluhm <alexander.bl...@gmx.net>: > > On Sat, Jan 20, 2018 at 03:46:36PM +0100, Axel Rau wrote: >> this is a IPsec client, which crashes on reboot of the IPsec master (same >> hardware and software as client). >> T

Re: double fault trap at pf_test+0xc on 6.2-STABLE

> Am 22.01.2018 um 14:47 schrieb Alexander Bluhm : Thanks for answering. > > Looks like this bug, already fixed in -current. > > https://marc.info/?l=openbsd-cvs=15084109691=2 > > > You have configured a

double fault trap at pf_test+0xc on 6.2-STABLE

Hi, this is a IPsec client, which crashes on reboot of the IPsec master (same hardware and software as client). The IPsec tunnel connects some IP6 and IP4 public nets to the internet plus some private nets. kernel: double fault trap, code=0 Stopped at pf_test+0xc:pushq %rbx ddb{0}>

FIXED: --was: Re: em(4) - (I354) responds to wrong MAC on 5.6-STABLE

Am 18.11.2014 um 23:13 schrieb Axel Rau axel@chaos1.de: I tested this on other hardware: It has nothing to do with i354. It’s a bug in the vlan driver which has already been reported here http://marc.info/?l=openbsd-miscm=139903544321689w=2 Reverting Revision 1.162 seems to fix

Re: em(4) - (I354) responds to wrong MAC on 5.6-STABLE

I tested this on other hardware: It has nothing to do with i354. It’s a bug in the vlan driver which has already been reported here http://marc.info/?l=openbsd-miscm=139903544321689w=2 Axel Am 13.11.2014 um 16:01 schrieb Axel Rau axel@chaos1.de: Hi, This is a pppoe-client

em(4) - (I354) responds to wrong MAC on 5.6-STABLE

Hi, This is a pppoe-client on Atom C2000 based Axiomtek NA361 Hardware. pppoe is running via VLAN on device em5, which is I354 based: em5: flags=28843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,NOINET6 mtu 1500 lladdr 00:60:e0:5a:75:39 priority: 0 media: Ethernet autoselect

ntop-1.1 segfaults with OpenBSD 5.2rel

Under load, I see: --- Program received signal SIGSEGV, Segmentation fault. 0x07dd2fce in memcpy () from /usr/lib/libc.so.65.0 (gdb) bt #0 0x07dd2fce in memcpy () from /usr/lib/libc.so.65.0 #1 0x1c0048a1 in queuePacket () #2 0x06bc807d in pcap_read (p=0x835f9000, cnt=-1, callback=0x1c004820

Re: ntop-1.1 segfaults with OpenBSD 5.2rel

Am 18.12.2012 um 23:27 schrieb Philip Guenther: Since it's threaded, can you get the backtraces for all the threads? Voilà: --- Program received signal SIGSEGV, Segmentation fault. TCP UDP ICMP 0x0fceefce in memcpy () from /usr/lib/libc.so.65.0 (gdb) info threads 6 thread

Re: [ipsec routing] IP frame is sent to the wrong IPSEC peer when using srcnat, but should be routed to the network with the most narrow netmask.

Am 07.09.2011 um 19:25 schrieb Markus Friedl: however, i think this could help Pawel. you need to recompile the kernel (and maybe some userland like netstat/route/ipsecctl). Seems to fix the bug. More testing this evening. Axel --- PGP-Key:29E99DD6 b +49 151 2300 9283 b computing @ chaos

Re: [ipsec routing] IP frame is sent to the wrong IPSEC peer when using srcnat, but should be routed to the network with the most narrow netmask.

Am 19.07.2011 um 21:45 schrieb Markus Friedl: All OpenBSD versions should have this problem as it's due to the way how IPsec-flows are encoded in the routing table and I could not find and easy fix. Does this explain, why I can't reach A from B and vice versa?

box freezes immediately after connecting to LAN

This is a follow up to kernel/6556 (http://thread.gmane.org/gmane.os.openbsd.bugs/16632). I have tried to insulate the problem in a virtual environment w/o success. I could reduce it however to a test bed with the original router box, with all network ports un-connected and w/o any CARP devices.

Re: kernel/6556: Memory corruption in ipv6 code with ipv6 traffic via ipsec tunnel

Am 10.02.2011 um 12:48 schrieb Mike Belopuhov: unfortunately i can't spend a lot of time on this atm, but i've tried a simple ipsec over ipv6 setup AFAIK, this is the minimum configuration to trigger the bug: IPSEC is ipv6 ipsec tunnel with ipv4 endpoints. The +---+

Re: kernel/6556: Memory corruption in ipv6 code with ipv6 traffic via ipsec tunnel

Am 10.02.2011 um 12:48 schrieb Mike Belopuhov: lets try to figure out some more details. first of all please remove all tunings (apart from ddb and forwarding) from sysctl.conf. i guess we don't need them to be able to reproduce a bug. I will come back with this tomorrow. then could you

Re: kernel/6556: Memory corruption in ipv6 code with ipv6 traffic via ipsec tunnel

Am 10.02.2011 um 19:00 schrieb Mike Belopuhov: oh man, this is gross. just use a gif(4). On top of a ipsec transport link with daily changing client end point address and isakmpd? gif tunnels and routing comes up without intervention if ipsec transport comes up? using ipv4 endpoints as

Re: kernel/6556: Memory corruption in ipv6 code with ipv6 traffic via ipsec tunnel

Am 10.02.2011 um 21:55 schrieb Mike Belopuhov: On Thu, Feb 10, 2011 at 10:28 AM, Axel Rau axel@chaos1.de wrote: Am 03.02.2011 um 13:15 schrieb Axel Rau: Am 03.02.2011 um 11:03 schrieb Mike Belopuhov: it would be also nice to turn pf, ospf, bgp and friends off. With pf turned off

Re: kernel/6556: Memory corruption in ipv6 code with ipv6 traffic via ipsec tunnel

Am 10.02.2011 um 12:48 schrieb Mike Belopuhov: lets try to figure out some more details. first of all please remove all tunings (apart from ddb and forwarding) from sysctl.conf. Done. your mbuf limits are excessive. please revert all these values to the default ones until the issue is

Re: kernel/6556: Memory corruption in ipv6 code with ipv6 traffic via ipsec tunnel

Am 02.02.2011 um 12:52 schrieb Axel Rau: Currently, boxes immediately lock up on reboot, if ipv6 forwarding enabled and egress and intranet interfaces connected. Anybody any hints/advice to lock down this problem further or to try a workaround? Axel --- axel@chaos1.de PGP-Key:29E99DD6

Re: kernel/6556: Memory corruption in ipv6 code with ipv6 traffic via ipsec tunnel

Am 03.02.2011 um 11:03 schrieb Mike Belopuhov: of course. first of all there's not a single panic message in your mail. also, piling up stack traces doesn't make it easier to follow. could you please follow-up on this with a single panic, show panic, trace and ps outputs. How do I produce a