This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ASG v7 always crashes within a day?

Hi guys,

I am quite frustrated with my new ASG v7.005 setup at the moment. I installed it on my new Asus Pundit P1 Barebone (the specifications are in my signature) and there is always a certain point of the day where the ASG hangs so that you cannot login via ssh or webadmin. It is totally dead and needs a hard reboot.

I cannot access web pages as well, the internet is dead to me. I have http proxy running and IPS but I think my system has enough resources to manage. No I shut down the http proxy and will see if the ASG will still run tomorrow. Does anybody have the same problem? Here is a snippet of my kernel.log from the time the ASG crashes:

2007:07:09-07:49:18 (none) kernel: CSLIP: code copyright 1989 Regents of the University of California

2007:07:09-07:49:18 (none) kernel: PPP generic driver version 2.4.2
2007:07:09-07:49:19 (none) kernel: tun: Universal TUN/TAP device driver, 1.6
2007:07:09-07:49:19 (none) kernel: tun: (C) 1999-2004 Max Krasnyansky 
2007:07:09-07:49:20 (none) kernel: MPPE/MPPC encryption/compression module registered
2007:07:09-07:49:20 (none) kernel: PPP BSD Compression module registered
2007:07:09-07:49:20 (none) kernel: PPP Deflate Compression module registered
2007:07:09-07:49:25 (none) kernel: Ebtables v2.0 registered
2007:07:09-07:49:25 (none) kernel: netfilter PSD loaded - (c) astaro AG
2007:07:09-07:49:35 (none) kernel: parport0: PC-style at 0x378 [PCSPP(,...)]
2007:07:09-07:49:35 (none) kernel: parport0: PC-style at 0x378 [PCSPP(,...)]
2007:07:09-07:49:35 (none) kernel: Device not ready. Make sure there is a disc in the drive.
2007:07:09-07:49:35 (none) kernel: Device not ready. Make sure there is a disc in the drive.
2007:07:09-07:49:39 (none) kernel: device eth0 left promiscuous mode
2007:07:09-07:49:39 (none) kernel: eth0: Promiscuous mode enabled.
2007:07:09-07:49:39 (none) kernel: device eth0 entered promiscuous mode
2007:07:09-12:07:35 (none) kernel: Bad pte = 0000a666, process = confd.plx, vm_flags = 100077, vaddr = 8803f28
2007:07:09-12:07:35 (none) kernel: [] __handle_mm_fault+0x942/0x9c0
2007:07:09-12:07:35 (none) kernel: [] work_resched+0x5/0x16
2007:07:09-12:07:35 (none) kernel: [] notifier_call_chain+0x34/0x40
2007:07:09-12:07:35 (none) kernel: [] do_page_fault+0x3b2/0x640
2007:07:09-12:07:35 (none) kernel: [] do_page_fault+0x0/0x640
2007:07:09-12:07:35 (none) kernel: [] error_code+0x4f/0x54
2007:07:09-12:07:35 (none) kernel: VM: killing process confd.plx
2007:07:09-17:54:26 (none) kernel: Netfilter messages via NETLINK v0.30.


You can see that the ASG went down at around 12:07 this morning. At 17:54 I rebootet the device. Can you see anything in this log that logs suspicious? Do you need other logfile excerpts?

Thanks in advance for your help!


This thread was automatically locked due to age.
Parents
  • Forgot to mention that also the up2date service isn't running correctly. Sometimes it works and sometimes not. Here is my version:

    Current pattern version: 3562
    Latest available pattern version: 3571

    This is the pattern I have for over a day now! And I do not have that much traffic here at home, just two Macintosh computers...
  • Radiohead, the kernel stack trace you see at 12:07 is definitely an issue, but doesn't appear to be related to the http proxy at all.

    Given that this is new hardware, I have to wonder if it is flaky and possibly is suffering from bad RAM? Did you test the hardware using memtest or similar tools before installation?

    If it's not bad RAM, it appears to be a bug in the kernel that ships with 7.005.
  • Yeah, that is what I see right now. Actually I have the same problem as shown in the video right now again. What I realised is that the clock on the system now jumped up 2 hours and up again in the matter of seconds....

    See this:

    voldemort:/var/log # date
    Sat Jul 14 19:23:06 CEST 2007
    voldemort:/var/log # date
    Sat Jul 14 21:08:13 CEST 2007
    voldemort:/var/log # date
    Sat Jul 14 21:27:09 CEST 2007
    voldemort:/var/log # date
    Sat Jul 14 21:28:39 CEST 2007
    voldemort:/var/log # date
    Sat Jul 14 21:29:30 CEST 2007
    voldemort:/var/log # date
    Sat Jul 14 21:32:29 CEST 2007
    voldemort:/var/log # 


    I enetered the date commands right behind one another. In a matter of seconds....
  • I have not had good experiences with the Nvidia (N-Force) chipsets with Windows, etc... I'd change to something more mainstream.  Nvidia is good at video chipsets, they should've stuck to that in this case.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • Frankly, I have had reliability issues in certain cases under high DMA with certain Via chipsets as well, so might as well throw those into the "do not use for server class workloads".

    There are a LOT of people using Nvidia chipsets on Linux systems without issues, yes, even under high loads. Just have a look at the Fedora stats project. The #2 most popular IDE chipset is nVidia with 29k systems. #1 is Intel at 52k and #3 is Via with 12.5k. I know for a fact that there are TONs of people running nVidia chipsets on MythTV systems which spend a lot of time pushing a lot of data around.

    With IPS and the http proxy disabled, there really shouldn't be any significant load put on a machine as fast as Radioheads. All it's doing is pushing packets. A paltry single CPU 1GHz machine is probably overkill, even with just 512MB of RAM. Certainly even machines speced lower than that used to work just fine in v6, nevermind a dual-core with 1GB of ram.

    It certainly appears that there is a kernel bug which is triggered by this particular Nvidia system, but given how many other people are seeing system lockups in v7 on all sorts of hardware, I'm more inclined to think that there are real serious bugs in the kernel that Astaro ships.

    The time jumping around problem is an old bug related to the interaction of the kernel and ntp daemon. Someone else brought that up the other day.

    The extremely high load average shown in the video he took indicates that there are some processes getting hung on something. Getting the full process list would be helpful. BTW, is the video shown in real time? The speed at which top is updating is highly unusual and appears as if it is being played back fast forwarded. It would be much more informative if top was set to update once a second.
  •  BTW, is the video shown in real time? The speed at which top is updating is highly unusual and appears as if it is being played back fast forwarded. It would be much more informative if top was set to update once a second.


    Yes, that is what I meant when I said weird [[;)]]

    The video is in realtime. I guess I'll wait till we reach version 7.1 of the ASG. Right now I will back away from ASG and will use my OpenBSD box again. Thanks for your help and support but I want a stable solution for my home environment, since I have to do enough at work and I want to have some time for other things at home [[;)]]
  • Yeah, that's totally weird. Was that with booting with acpi=off and noapic?

    Only other thing I can think of now is to try v6, but not sure if it will run on your hardware or not.
  • Yeah, that's totally weird. Was that with booting with acpi=off and noapic?

    Only other thing I can think of now is to try v6, but not sure if it will run on your hardware or not.


    Yes, I booted with these kernel parameters... Tried to boot V6 but then it came to the point where it said that my HDD has not enough space and the installation stopped before it began...
  • Frankly, I have had reliability issues in certain cases under high DMA with certain Via chipsets as well, so might as well throw those into the "do not use for server class workloads".

    There are a LOT of people using Nvidia chipsets on Linux systems without issues, yes, even under high loads. Just have a look at the Fedora stats project. The #2 most popular IDE chipset is nVidia with 29k systems. #1 is Intel at 52k and #3 is Via with 12.5k. I know for a fact that there are TONs of people running nVidia chipsets on MythTV systems which spend a lot of time pushing a lot of data around.

    With IPS and the http proxy disabled, there really shouldn't be any significant load put on a machine as fast as Radioheads. All it's doing is pushing packets. A paltry single CPU 1GHz machine is probably overkill, even with just 512MB of RAM. Certainly even machines speced lower than that used to work just fine in v6, nevermind a dual-core with 1GB of ram.

    It certainly appears that there is a kernel bug which is triggered by this particular Nvidia system, but given how many other people are seeing system lockups in v7 on all sorts of hardware, I'm more inclined to think that there are real serious bugs in the kernel that Astaro ships.

    The time jumping around problem is an old bug related to the interaction of the kernel and ntp daemon. Someone else brought that up the other day.

    The extremely high load average shown in the video he took indicates that there are some processes getting hung on something. Getting the full process list would be helpful. BTW, is the video shown in real time? The speed at which top is updating is highly unusual and appears as if it is being played back fast forwarded. It would be much more informative if top was set to update once a second.

    I've not had issues with recent(two years) via stuff..but older..most assuredly..[[:)]] nforce excel at multimedia..that's what they are designed for....[[:)]]

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

    Former Sophos SG(Astaro) advocate/researcher/Silver Partner

    PfSense w/Suricata, ntopng, 

    Other addons to follow

  • Hi again,

    I now have installed OpenBSD on this box and I can tell you that it runs really great. No problems at all, so I guess it is the "buggy" Astaro kernel or the Linux kernel in general.

    I just have to setup OpenVPN, a http proxy with av scan and than this box works great.

    Thanks again for your support.
  • Hi again,

    I now have installed OpenBSD on this box and I can tell you that it runs really great. No problems at all, so I guess it is the "buggy" Astaro kernel or the Linux kernel in general.

    I just have to setup OpenVPN, a http proxy with av scan and than this box works great.

    Thanks again for your support.

    it's not Linux in general.  folks that blame all of linux for one distro's problems haven't done their research most times..[:)]

    Try a different linux distro before saying it's Linux-wide(which is highly suspect).

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

    Former Sophos SG(Astaro) advocate/researcher/Silver Partner

    PfSense w/Suricata, ntopng, 

    Other addons to follow

  • it's not Linux in general.  folks that blame all of linux for one distro's problems haven't done their research most times..[:)]

    Try a different linux distro before saying it's Linux-wide(which is highly suspect).


    I just meant the Linux kernel in Astaro. And since I can't change that kernel, I have to leave the ASG behind, even If I really liked the interface...
Reply
  • it's not Linux in general.  folks that blame all of linux for one distro's problems haven't done their research most times..[:)]

    Try a different linux distro before saying it's Linux-wide(which is highly suspect).


    I just meant the Linux kernel in Astaro. And since I can't change that kernel, I have to leave the ASG behind, even If I really liked the interface...
Children
  • I just meant the Linux kernel in Astaro. And since I can't change that kernel, I have to leave the ASG behind, even If I really liked the interface...

    understood there.  try clarkconnect..it's another firewall/server appliance that tracks with centos which tracks with RHEL..

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

    Former Sophos SG(Astaro) advocate/researcher/Silver Partner

    PfSense w/Suricata, ntopng, 

    Other addons to follow

  • Hey. Clarkconnect looks really nice. But I guess that now I'll stick with OpenBSD in the first place. Probably I'll give it a try if I am getting frustrated about not having a nice GUI [;)]
  • My box is getting hit hard by pfilter-reporte. When is Astaro going to address this issue? I have logged several support issues with Astaro Support and they are about as helpful as a hole in the head. I am seriously beating myself up now, as I recommended Astaro for our corporate firewall. My boss is not too please with me at the moment.....
  • if you have ANY ips functions turned on turn them off.  the ips function generates more dropped packets and if there's more than a few a second then pfilter-repote goes nutso.  That means ips off,  im blocking off, anti-portscan off..anything like that.  You have to try to reduce the amount of packets the machine is dropping.

    This IMO is a classic DOS vulnerability:
    https://community.sophos.com/products/unified-threat-management/astaroorg/f/51/t/19797

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

    Former Sophos SG(Astaro) advocate/researcher/Silver Partner

    PfSense w/Suricata, ntopng, 

    Other addons to follow

  • I also had shut down all of the "nice" features but that did not help. At last I only used the packetfilter and it did not improve!

    As I told you the openbsd runs flawlessly now and is known as one of the most secure systems [;)]