search

Douane / douane-dkms

Kernel module used by Douane firewall
23 stars 15 forks source link

netfilter_hook_version #16

Closed Guimli closed 8 years ago

Guimli commented 8 years ago

This pull request integrates changes in the netfilter hook function in relation to the version of the kernel. Tested successfully on Ubuntu 14.04 with Kernel 3.13.0-85, Ubuntu 15.10 with Kernel 4.2.0-35 and Ubuntu 16.04 with Kernel 4.4.0-22. This fix correct freeze problem for all kernel version.

zedtux commented 8 years ago

Thank you so much @Guimli for this PR. I'll have a look and merge it if all is fine.

bash64 commented 8 years ago 
$ sudo make dkms
Installing Douane Linux kernel module version 0.8.2...

Creating symlink /var/lib/dkms/douane/0.8.2/source ->
                 /usr/src/douane-0.8.2

DKMS: add completed.

Kernel preparation unnecessary for this kernel.  Skipping...

Building module:
cleaning build area....
make KERNELRELEASE=4.4.0-22-generic -C /lib/modules/4.4.0-22-generic/build M=/var/lib/dkms/douane/0.8.2/build.....(bad exit status: 2)
Error! Bad return status for module build on kernel: 4.4.0-22-generic (x86_64)
Consult /var/lib/dkms/douane/0.8.2/build/make.log for more information.
make: *** [dkms] Error 10
bash64 commented 8 years ago 
$ cat /var/lib/dkms/douane/0.8.2/build/make.log
DKMS make.log for douane-0.8.2 for kernel 4.4.0-22-generic (x86_64)
Mon May  9 08:04:06 EDT 2016
make[1]: Entering directory `/usr/src/linux-headers-4.4.0-22-generic'
  LD      /var/lib/dkms/douane/0.8.2/build/built-in.o
  CC [M]  /var/lib/dkms/douane/0.8.2/build/douane.o
/var/lib/dkms/douane/0.8.2/build/douane.c:1115:3: warning: initialization from incompatible pointer type [enabled by default]
   .hook     = netfiler_packet_hook,
   ^
/var/lib/dkms/douane/0.8.2/build/douane.c:1115:3: warning: (near initialization for ‘nfho_outgoing.hook’) [enabled by default]
/var/lib/dkms/douane/0.8.2/build/douane.c:1119:3: error: unknown field ‘owner’ specified in initializer
   .owner    = THIS_MODULE
   ^
/var/lib/dkms/douane/0.8.2/build/douane.c:1120:1: warning: excess elements in struct initializer [enabled by default]
 };
 ^
/var/lib/dkms/douane/0.8.2/build/douane.c:1120:1: warning: (near initialization for ‘nfho_outgoing’) [enabled by default]
make[2]: *** [/var/lib/dkms/douane/0.8.2/build/douane.o] Error 1
make[1]: *** [_module_/var/lib/dkms/douane/0.8.2/build] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-4.4.0-22-generic'
bash64 commented 8 years ago

I removed the .owner line in the structure and it compiled dkms. This works fine for kernel 3.13. However, for linux mint 17.3 64bit kernel 4.4.0.22 is locks up instantly after turning on the configurator. Sorry to say we are back at square one. I see you tested linux mint 17.2 (ubuntu 14.04) but only with kernel 3.13. Please try to get it working with kernel 4. In my configurator (when running kernel 3.13) I do not see any rules. Also there is a warning about dbus.

bash64 commented 8 years ago

P.S. I am using LPFW (Leopard Flower Firewall), but it is not active right now. The rules for it go bad a lot and block everything. Other than that it works. I just have to delete the rule, launch the app, and recreate the rule.

Guimli commented 8 years ago

I think you use the wrong git source to test this PullRequest. Uninstall the dkms module : sudo make cleandkms Delete your douane-dkms local source directory and retry with this Git : git clone https://github.com/Guimli/douane-dkms.git

bash64 commented 8 years ago

I will try again. Any issue with me trying this in vmware? The old Douane corrupted my whole install. Took 3 reformats to get back to normal. I have a frowny face now.

On 05/09/2016 09:49 AM, Nicolas Weill wrote:

I think you use the wrong git source to test this PullRequest. Uninstall the dkms module : sudo make cleandkms Delete your douane-dkms local source directory and retry with this Git : git clone https://github.com/Guimli/douane-dkms.git

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/Douane/douane-dkms/pull/16#issuecomment-217869345

bash64 commented 8 years ago

ok,

I did a sudo make cleandkms I deleted teh entire douane-dkms folder I used git to clone the below folder i did a sudo make dkms I ran the configurator.

Nothing is being blocked. The crashing has stopped. I did previously create a bunch of rules. Maybe they need to be deleted.

On 05/09/2016 09:49 AM, Nicolas Weill wrote:

I think you use the wrong git source to test this PullRequest. Uninstall the dkms module : sudo make cleandkms Delete your douane-dkms local source directory and retry with this Git : git clone https://github.com/Guimli/douane-dkms.git

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/Douane/douane-dkms/pull/16#issuecomment-217869345

bash64 commented 8 years ago

found the issue...please hold on

On 05/09/2016 09:49 AM, Nicolas Weill wrote:

I think you use the wrong git source to test this PullRequest. Uninstall the dkms module : sudo make cleandkms Delete your douane-dkms local source directory and retry with this Git : git clone https://github.com/Guimli/douane-dkms.git

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/Douane/douane-dkms/pull/16#issuecomment-217869345

bash64 commented 8 years ago

After douane borked my system (i used the old code) I reinstalled. I failed to notice that I had not reinstalled all of the dpendencies. After fixing that there is no crashing and it is working fine with kernel 4. Seems to be working better than LPFW. However, in the configurator there are no rules. Where are the rules?

bash64 commented 8 years ago

Never mind. I found the refresh button. I see my rules now.

bash64 commented 8 years ago

I think you have replaced LPFW officially. I will use Douane for a week and if all is fine I will include your product in version #2 of my ebook on linux mint.

bash64 commented 8 years ago

Speak of the devil. Right after the last note my whole system locked up bigger than shit. Is there some sort of log file that will tell me what crashed?

bash64 commented 8 years ago

Here is some of /var/log/douane.log:

10/05/2016 08:29:05 | daemon | DEBUG | [rules_manager.cpp::RulesManager:30]: An allowing rule found for /usr/lib/firefox/firefox
10/05/2016 08:29:06 | daemon | DEBUG | [netlink_message_handler.cpp::NetlinkMessageHandler:7]: [] TCP 192.168.1.130:58220 -> 54.186.241.180:443 with a size of 52 for process /usr/lib/firefox
/firefox
10/05/2016 08:29:06 | daemon | DEBUG | [rules_manager.cpp::RulesManager:30]: An allowing rule found for /usr/lib/firefox/firefox
10/05/2016 08:29:07 | daemon | DEBUG | [netlink_message_handler.cpp::NetlinkMessageHandler:7]: [^FE?^F??z?ki??U??@^F] TCP 192.168.1.130:58220 -> 54.186.241.180:443 with a size of 52 for proc
ess /usr/lib/firefox/firefox
10/05/2016 08:29:07 | daemon | DEBUG | [rules_manager.cpp::RulesManager:30]: An allowing rule found for /usr/lib/firefox/firefox
10/05/2016 08:29:07 | daemon | DEBUG | [netlink_message_handler.cpp::NetlinkMessageHandler:7]: [?3^Bo-?_?^N^O
??b^_?^F] TCP 192.168.1.130:58220 -> 54.186.241.180:443 with a size of 52 for process /usr/lib/firefox/firefox
10/05/2016 08:29:07 | daemon | DEBUG | [rules_manager.cpp::RulesManager:30]: An allowing rule found for /usr/lib/firefox/firefox
10/05/2016 08:29:08 | daemon | DEBUG | [netlink_message_handler.cpp::NetlinkMessageHandler:7]: [!ESC?g????>?A?q?^]^^^F] TCP 192.168.1.130:54588 -> 54.149.8.1:443 with a size of 52 for proces
s /usr/lib/firefox/firefox

...

10/05/2016 08:29:12 | daemon | DEBUG | [rules_manager.cpp::RulesManager:30]: An allowing rule found for /usr/lib/firefox/firefox
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

After a certain point of handling the firefox rule it somehow becomes overloaded and starts dumping junk characters into the log file.

zedtux commented 8 years ago

Thank you @bash64 for your messages (I had a smile :)).

In order to avoid crashing your system, and especially while testing special branches of the DKMS modules, you should use K-Dump (Here is a blog article for Ubuntu: http://blog.zedroot.org/debug-your-linux-kernel-module/). It will handle the kernel panic, boot a new kernel and move your session, saving your machine, and also saving a crash file (readable with the crash command line tool) which would help us to debug.

Just to be sure, here are the instructions in order to test this branch:

The following steps are required in case you already have Douane installed

  1. Stop Douane if is running
  2. Remove the Douane Kernel module
    1. Open a terminal in the douane-dkms folder
    2. Run make cleandkms as root

Now clone the @Guimli's repository and rebuild the kernel module:

  1. In the folder where you've cloned and compiled each Douane parts (Should be ~/Douane/ if you following the compilation instructions) open a terminal
  2. Clone the @Guimli's repository with git clone git@github.com:Guimli/douane-dkms.git douane-dkms-guimli
  3. Go to the folder cd douane-dkms-guimli
  4. Build and install the kernel module with make dkms as root

In the case you haven't followed those instructions, it means you've used the original code which is broken.

Let us know.

Guimli commented 8 years ago

Ok, The "activity->devise_name" is not initilized with >= kernel 4.1.0 in douane-dkms. I will work on this problem. But for now, I do not know how to retrieve the name of the interface with the new implementation of nf_hook ...

bash64 commented 8 years ago

The code for the blog article from Ubuntu does not compile. No way to make KEDR.

zedtux commented 8 years ago

Oops... sorry @bash64, wrong blog article. Here is the right one: http://blog.zedroot.org/linux-kernel-debuging-using-kdump-and-crash/

bash64 commented 8 years ago

kdump is installed. /proc/cmdline show proper crash info. forcing a crash , however, does not result in a reboot into the crash kernel. The system just sits there locked up. kdump=1 set in the config file. not sure what is wrong.

bash64 commented 8 years ago

ok, a sudo reboot is captured by kdump. a sudo coldreboot is needed to bypass kdump. so it is installed and works on a reboot. it however fails to catch the write to sysrq. i am wondering if it will catch douane crashing for me?

zedtux commented 8 years ago

You shouldn't run Douane until you got the hot reboot working.

It was working fine for me when I wrote that blog article and I was using Ubuntu. Today I'm trying to make it working with Debian (I have switched) but I got a similar issue than yours. We need to find a way to this hot reboot working before to continue with Douane.

Guimli commented 8 years ago

I have reproduce the crash on Ubuntu 16.04. But I don't know what to do with this information :

crash 7.1.4 Copyright (C) 2002-2015 Red Hat, Inc. Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation Copyright (C) 1999-2006 Hewlett-Packard Co Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited Copyright (C) 2006, 2007 VA Linux Systems Japan K.K. Copyright (C) 2005, 2011 NEC Corporation Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc. Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc. This program is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Enter "help copying" to see the conditions. This program has absolutely no warranty. Enter "help warranty" for details.

GNU gdb (GDB) 7.6 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu"...

  KERNEL: /usr/lib/debug/boot/vmlinux-4.4.0-22-generic
DUMPFILE: /var/crash/201605121610/dump.201605121610  [PARTIAL DUMP]
    CPUS: 4
    DATE: Thu May 12 16:10:00 2016
  UPTIME: 00:02:13

LOAD AVERAGE: 0.92, 0.38, 0.14 TASKS: 483 NODENAME: douane RELEASE: 4.4.0-22-generic VERSION: #39-Ubuntu SMP Thu May 5 16:53:32 UTC 2016 MACHINE: x86_64 (3399 Mhz) MEMORY: 2 GB PANIC: "BUG: unable to handle kernel NULL pointer dereference at 0000000000000017" PID: 0 COMMAND: "swapper/2" TASK: ffff88007c8e8c80 (1 of 4) [THREAD_INFO: ffff88007c8f4000] CPU: 2 STATE: TASK_RUNNING (PANIC)

crash> bt PID: 0 TASK: ffff88007c8e8c80 CPU: 2 COMMAND: "swapper/2"

0 [ffff88007fd032c8] machine_kexec at ffffffff8105befb

1 [ffff88007fd03328] crash_kexec at ffffffff8110da12

2 [ffff88007fd033f8] oops_end at ffffffff81031c29

3 [ffff88007fd03420] no_context at ffffffff8106ad45

4 [ffff88007fd03480] __bad_area_nosemaphore at ffffffff8106b010

5 [ffff88007fd034c8] bad_area_nosemaphore at ffffffff8106b193

6 [ffff88007fd034d8] __do_page_fault at ffffffff8106b457

7 [ffff88007fd03530] trace_do_page_fault at ffffffff8106b807

8 [ffff88007fd03560] do_async_page_fault at ffffffff81063ed9

9 [ffff88007fd03570] async_page_fault at ffffffff818274a8

[exception RIP: netfiler_packet_hook+381]
RIP: ffffffffc016498d  RSP: ffff88007fd03620  RFLAGS: 00010286
RAX: ffffffffffffffff  RBX: ffff88007b65f4f4  RCX: 0000000000000000
RDX: 0000000000000000  RSI: 000000000000000c  RDI: 0000000000000000
RBP: ffff88007fd037a0   R8: 000000000000ffff   R9: ffff88007b65f508
R10: ffff88007b65f504  R11: ffffffff81cccb00  R12: ffff880076428000
R13: ffff88007b873200  R14: ffff88007b65f508  R15: ffff88007b873200
ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018

10 [ffff88007fd037a8] nf_iterate at ffffffff81752442

11 [ffff88007fd037d8] nf_hook_slow at ffffffff817524d3

12 [ffff88007fd03810] __ip_local_out at ffffffff8175edd1

13 [ffff88007fd03880] ip_local_out at ffffffff8175edfc

14 [ffff88007fd038a8] ip_build_and_send_pkt at ffffffff8175ef6d

15 [ffff88007fd038f8] tcp_v4_send_synack at ffffffff8177ed4a

16 [ffff88007fd03968] tcp_conn_request at ffffffff8176efaa

17 [ffff88007fd03a58] tcp_v4_conn_request at ffffffff8177ceac

18 [ffff88007fd03a68] tcp_rcv_state_process at ffffffff8177430e

19 [ffff88007fd03ae0] tcp_v4_do_rcv at ffffffff8177e532

20 [ffff88007fd03b08] tcp_v4_rcv at ffffffff8177f889

21 [ffff88007fd03b88] ip_local_deliver_finish at ffffffff817596b4

22 [ffff88007fd03bb0] ip_local_deliver at ffffffff817599bf

23 [ffff88007fd03c18] ip_rcv_finish at ffffffff81759392

24 [ffff88007fd03c48] ip_rcv at ffffffff81759cc1

25 [ffff88007fd03cc0] __netif_receive_skb_core at ffffffff8171b314

26 [ffff88007fd03d58] __netif_receive_skb at ffffffff8171b688

27 [ffff88007fd03d78] netif_receive_skb_internal at ffffffff8171b702

28 [ffff88007fd03da8] napi_gro_receive at ffffffff8171c383

29 [ffff88007fd03dd0] virtnet_receive at ffffffff815f3f04

30 [ffff88007fd03e60] virtnet_poll at ffffffff815f436d

31 [ffff88007fd03e88] net_rx_action at ffffffff8171bbce

32 [ffff88007fd03f00] __do_softirq at ffffffff810859f1

33 [ffff88007fd03f68] irq_exit at ffffffff81085cf3

34 [ffff88007fd03f78] do_IRQ at ffffffff81827ce4

--- ---

35 [ffff88007c8f7dc0] ret_from_intr at ffffffff81825dc2

[exception RIP: unknown or invalid address]
RIP: 0000000000000000  RSP: 0000000000000000  RFLAGS: 00000000
RAX: ffffffff81f35140  RBX: ffff88007c8f4000  RCX: ffff88007b37d800
RDX: 00000000ffff5d08  RSI: 0000000000000000  RDI: ffff88007fd0dca0
RBP: 0000000000000087   R8: ffff88007c8f7e90   R9: 0000000000000002
R10: 0000000000000000  R11: 0000000000000000  R12: ffff88007fd0ed40
R13: 000000000000001c  R14: 00000000ffff5d09  R15: 00000000ffff5d08
ORIG_RAX: 0000000000000000  CS: 0000  SS: ffffffffffffff5e

bt: WARNING: possibly bogus exception frame

36 [ffff88007c8f7e68] native_safe_halt at ffffffff810645e6

37 [ffff88007c8f7e98] default_idle at ffffffff81038dfe

38 [ffff88007c8f7eb8] arch_cpu_idle at ffffffff8103960f

39 [ffff88007c8f7ec8] default_idle_call at ffffffff810c3d6a

40 [ffff88007c8f7ed8] cpu_startup_entry at ffffffff810c40d1

41 [ffff88007c8f7f30] start_secondary at ffffffff81051714

crash>

Guimli commented 8 years ago

Ok, I found the problem. skb->sk properties is not initialized and can cause Kernel Panic if state = TCP_TIME_WAITor TCP_NEW_SYN_RECV. @bash64 , can you test with my last commit ?

bash64 commented 8 years ago

I want to try to get kdump working first. I will try kdump again.

On 05/15/2016 06:46 PM, Nicolas Weill wrote:

Ok, I found the problem. skb->sk properties is not initialized and can cause Kernel Panic if state = TCP_TIME_WAITor TCP_NEW_SYN_RECV. @bash64 https://github.com/bash64 , can you test with my last commit ?

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/Douane/douane-dkms/pull/16#issuecomment-219315895

bash64 commented 8 years ago

kdump seems to be working now. Let you all know tomorrow.

On 05/15/2016 06:46 PM, Nicolas Weill wrote:

Ok, I found the problem. skb->sk properties is not initialized and can cause Kernel Panic if state = TCP_TIME_WAITor TCP_NEW_SYN_RECV. @bash64 https://github.com/bash64 , can you test with my last commit ?

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/Douane/douane-dkms/pull/16#issuecomment-219315895

bash64 commented 8 years ago

Question. Nothing runs on boot. I launch the configurator to get the daemon to run. I have to manually launch the douane-dialog also.

On 05/15/2016 06:46 PM, Nicolas Weill wrote:

Ok, I found the problem. skb->sk properties is not initialized and can cause Kernel Panic if state = TCP_TIME_WAITor TCP_NEW_SYN_RECV. @bash64 https://github.com/bash64 , can you test with my last commit ?

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/Douane/douane-dkms/pull/16#issuecomment-219315895

bash64 commented 8 years ago

Marking time: It is 12:21pm EST. Waiting for a crash.

Guimli commented 8 years ago

Indeed, everything has to be started manually. Once the main problems will be solved, I'll try to integrate the automatic start douane-daemon and douane-dialog

bash64 commented 8 years ago

ok, I set douane-daemon to run out of rc.local. I set douane-dialog to run on login. So far so good. I have run a lot of apps and the rules are working. No crashing so far. Will post an update tonight.

bash64 commented 8 years ago

kdump still not working when a crash happens or when triggered with sysreq

bash64 commented 8 years ago

It would be nice to be able to block by appname, ip, or dns name, my choice. A lot of apps use python to get to the net. I cannot block python completely. By ip or dns name would be more appropriate.

Guimli commented 8 years ago

Yes, that would be great ... But it takes a huge rewrite of code and many working day. it's the issues 33

bash64 commented 8 years ago

12:58pm no crashing. Usually crashes within 5 minutes. I think you got it man.

bash64 commented 8 years ago

1:42pm crash. Began playing a youtube video on facebook. Where can I find a log? Total lockup. KDump did not work. Hard force off.

Guimli commented 8 years ago

Are you use my last commit ? If KDump work, the dump can be found in /var/crash/.

bash64 commented 8 years ago

git clone https://github.com/Guimli/douane-dkms.git

Guimli commented 8 years ago

Yes, but i have update code yesterday. I will try to reproduce the crash.

bash64 commented 8 years ago

Nothing in /var/crash. kdump setup properly. I downloaded all code fresh right before 12:21pm.

bash64 commented 8 years ago

kdump-config show DUMP_MODE: kdump USE_KDUMP: 1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR: /var/crash crashkernel addr: 0x2a000000 current state: ready to kdump

kexec command: /sbin/kexec -p --command-line="BOOT_IMAGE=/vmlinuz-4.4.0-22-generic root=/dev/mapper/vg-root ro nouveau.blacklist=1 intel_pstate=disable transparent_hugepage=never quiet splash nomdmonddf nomdmonisw irqpoll maxcpus=1 nousb" --initrd=/boot/initrd.img-4.4.0-22-generic /boot/vmlinuz-4.4.0-22-generic

bash64 commented 8 years ago

ok, this seems to be the answer why kdump fails for me. It has to do with /boot being on a separate partition (I also use LVM), found this on a website:

If /boot is on a separate partition, Kernel Crash Dump on Ubuntu will fail because of a ---> bug which still exists in 14.04 Trusty, can you believe it? At least it is the case for me using LVM and a separate /boot.

The workaround is to

unmount /boot and then mount it to some other mount point, e.g. /mnt
copy the contents over to /boot (the one on the same block device as /). e.g. rsync -axHAX --progress --stats /mnt/ /boot
Trigger a crash by using echo c | sudo tee /proc/sysrq-trigger
If all good, you'll see kernel crash dump in /var/crash in forms of (uname -r)-yyyymmddHHmm.crash and a yyyymmddHHmm directory with dmesg and dump.

If you want to analyze the crash dump, you'll need crash, run it like below: crash /usr/lib/debug/boot/vmlinux-$(uname -r) /var/crash/yyyymmddHHmm/dump.yyyymmddHHmm For more info regarding crash, read the manual. BTW: DO NOT forget to reload the kdump-tools configuration after changing /etc/default/kdump-tools by kdump-config load.

bash64 commented 8 years ago

I copied my /boot folder and made a local copy in / for it. On boot I >umount /boot to unmount the boot partition. Even with /boot being in the / folder kdump still fails. I do: su - echo c > /proc/sysrq-trigger total lockup, no kdump. Hard to test Douane when kdump fails to make a report.

Guimli commented 8 years ago

New version ! Rather than exclude statements do not return a socket, I filter only those who have one. This should be more stable. If it does not work, I could not know or just the problem without your Kdump. Douane does not crash on my test computers ...

@bash64 , thank you for your patience and your help.

bash64 commented 8 years ago

ok, I can try again. I have no working crash dump. Linux Mint 18 will be out soon (ubuntu 16.04). Should fix the issues or at least let me run crash dump.

bash64 commented 8 years ago

Using new code. Compiled at 1am may 22nd. Going let a video stream run all night in Firefox. That will usually lock it up if it is going to.

bash64 commented 8 years ago

The culprit might be /usr/lib/firefox/plugin-container. It almost always happen when playing videos, but not always. Video streams generate a LOT of constant traffic.

bash64 commented 8 years ago

2:21am crashed again. Wrecked my raid. Raid is rebuilding.

Guimli commented 8 years ago

I'm sorry for not being able to find the cause of the crash, and worries that it generates on your computer each test. I will install Douane and Kdump on a maximum computers around me to try to reproduce this bug. Thank you again for your patience.

bash64 commented 8 years ago

Will it help if I install it using vmware? Will kdump work with vmware?

Guimli commented 8 years ago

Yes, Kdump work with VMware. But I can not crash my Linux Mint Vmware computer...

bash64 commented 8 years ago

I run PGL (Peer Guardian for Linux). Could they be conflicting?

Original website: https://launchpad.net/~jre-phoenix/+archive/ubuntu/ppa

Open a terminal and copy and paste each line:

sudo apt-add-repository ppa:jre-phoenix/ppa sudo apt-get update sudo apt-get install pglcmd pgld pglgui