Openserver 5.0.6 ping floods router - SCO

This is a discussion on Openserver 5.0.6 ping floods router - SCO ; wrote: > > One is: capture those ping packets with your sniffer; then deliberately > > issue a similar ping request > > We're not using a sniffer -- just watching the CPU Utilization graph > on the router's web ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 27 of 27

Thread: Openserver 5.0.6 ping floods router

  1. Re: Openserver 5.0.6 ping floods router

    wrote:

    > > One is: capture those ping packets with your sniffer; then deliberately
    > > issue a similar ping request

    >
    > We're not using a sniffer -- just watching the CPU Utilization graph
    > on the router's web interface, and viewing the log file.


    Fix that! Sniffers are readily available these days (e.g. wireshark,
    runs on Win & Lin). You're really fumbling around in the dark if you
    haven't even seen the contents of these mystery packets.

    > > Another tack also relates to your observation of a 1-minute delay before
    > > the pings start. That implies that some user-level process is
    > > initiating them. ...[snip]...

    >
    > How about I build a little script file, stick it on /stand, and put a
    > reference to it in /etc/rc1? Or would a better trick be to create a
    > script called something like /etc/rc1.d/S00TryToCatchAPinger so it'll
    > be run first thing when rc1.d gets processed?


    /stand is irrelevant (OSR5 mounts / before /stand -- /stand is
    _accessed_ first, but that's by the BIOS and boot programs that are all
    done long before your script could possibly run).

    There's no rc1.d directory; /etc/rc1 doesn't even try to look for one.

    > I was digging around in the /etc/rc1 script yesterday, but was a tad
    > hesitant to stick anything in there -- I don't want to "brick" the SCO
    > box by putting something in rc1 that won't let it get to the "Type
    > D to continue..." message.


    If your script is going to "brick" the system it doesn't really matter
    where you execute it from, does it?

    I thought I understood from your description that the system did get all
    the way to single-user mode, and even a minute past that, before the
    pings started. If so, just put the accton script in /tmp or something.
    Boot up, go to single-user mode, run it. Then there's zero chance of
    mistakenly bricking the system. Anyway, even if you did, you'd just
    boot from install or backup/recovery media and fix your mistake.

    If there isn't really a minute's gap between SU mode and the pings
    starting, I'd say, put it as the first command in /etc/bcheckrc. (Just
    `/usr/lib/acct/accton /usr/adm/pacct`; `acctcom` just reads the data
    collected, you can run it at any time once process accounting data
    collection has started.)

    >Bela<


  2. Re: Openserver 5.0.6 ping floods router

    On Jul 16, 9:42*pm, Bela Lubkin wrote:
    > wrote:
    > > We're not using a sniffer -- just watching the CPU Utilization graph
    > > on the router's web interface, and viewing the log file.

    >
    > Fix that! *Sniffers are readily available these days (e.g. wireshark,
    > runs on Win & Lin). *You're really fumbling around in the dark if you
    > haven't even seen the contents of these mystery packets.


    You're absolutely correct, had I been using a sniffer, I would have
    solved the problem long ago. By the way, I solved the problem.

    It was NOT the SCO box, but the router that was instigating the ping
    flood. A couple of months ago, we were having problems with one of
    the VPN tunnels from this router. It worked fine for 50 minutes, then
    dropped for 5 minutes, then worked fine for another 50... ... ad
    nauseum.

    So, being the idiot I am, I turned on the DLinks syslog logger, and
    pointed it to the SCO box, thinking I could capture some logging data
    that corresponds with the drop outs. Also, being a busy idiot, I got
    tied up with other projects and completely forgot about enabling that.

    Two days ago, I was wracking my brain, trying to think of things that
    had changed since this problem started, and I remembered turning on
    the syslog logger. I logged into the router, turned off the
    syslogger, and the router's CPU utilization dropped to 2% and stayed
    there. The ping messages in the log also stopped.

    What threw me was the way the logfile showed the message:

    SRCIP: 192.168.1.10 (SCO box) -> DESTIP: 192.168.1.3 (router)

    That stuck in my brain as the SCO box being the source (funny how that
    works!)

    Anyway, the problem is solved. Sorry for inflicting MY stupidity on
    the group, but very appreciative of all of the suggestions and help.

    Note to Bela -- Sorry also for not knowing the root cause of the
    problem, such as "Why is the SCO box ping flooding the router when the
    router is trying to use it for syslog?". My guess is it's a bug in
    the DLink DFL200 firmware -- I've never enabled that on any of the
    other DFL200s my clients have, and DLink end-of-lifes old equipment
    faster than most people throw out underwear. There's no chance of
    getting any troubleshooting help from them. Thanks again for all your
    suggestions, and I'm gonna get me a packet sniffer ASAP (I'm
    downloading WireShark as I type this)....

    RLW

  3. Re: Openserver 5.0.6 ping floods router



    On Fri, 18 Jul 2008, RLW wrote:

    > On Jul 16, 9:42*pm, Bela Lubkin wrote:
    >> wrote:
    >>> We're not using a sniffer -- just watching the CPU Utilization graph
    >>> on the router's web interface, and viewing the log file.

    >>
    >> Fix that! *Sniffers are readily available these days (e.g. wireshark,
    >> runs on Win & Lin). *You're really fumbling around in the dark if you
    >> haven't even seen the contents of these mystery packets.

    >
    > You're absolutely correct, had I been using a sniffer, I would have
    > solved the problem long ago. By the way, I solved the problem.
    >
    > It was NOT the SCO box, but the router that was instigating the ping
    > flood. A couple of months ago, we were having problems with one of
    > the VPN tunnels from this router. It worked fine for 50 minutes, then
    > dropped for 5 minutes, then worked fine for another 50... ... ad
    > nauseum.
    >
    > So, being the idiot I am, I turned on the DLinks syslog logger, and
    > pointed it to the SCO box, thinking I could capture some logging data
    > that corresponds with the drop outs. Also, being a busy idiot, I got
    > tied up with other projects and completely forgot about enabling that.


    Were the packets actually ping packets (icmp type 8) or were they
    "destination unreachable" packets (icmp type 3)?


  4. Re: Openserver 5.0.6 ping floods router

    On Jul 18, 5:07*pm, JD wrote:

    > Were the packets actually ping packets (icmp type 8) or were they
    > "destination unreachable" packets (icmp type 3)?


    They were "destination unreachable" packets.

    RLW

  5. Re: Openserver 5.0.6 ping floods router



    On Sat, 19 Jul 2008, RLW wrote:

    > On Jul 18, 5:07*pm, JD wrote:
    >
    >> Were the packets actually ping packets (icmp type 8) or were they
    >> "destination unreachable" packets (icmp type 3)?

    >
    > They were "destination unreachable" packets.


    Had you posted this early on in the thread, your would probably have got
    to a solution far earlier.

  6. Re: Openserver 5.0.6 ping floods router

    On Jul 20, 2:41*am, JD wrote:
    > On Sat, 19 Jul 2008, RLW wrote:
    > > They were "destination unreachable" packets.

    >
    > Had you posted this early on in the thread, your would probably have got
    > to a solution far earlier.


    JD,

    Had I realized the significance, I would have. Do you have any
    explanation why they were there in the first place?

    RLW

  7. Re: Openserver 5.0.6 ping floods router



    On Sun, 20 Jul 2008, RLW wrote:

    > On Jul 20, 2:41*am, JD wrote:
    >> On Sat, 19 Jul 2008, RLW wrote:
    >>> They were "destination unreachable" packets.

    >>
    >> Had you posted this early on in the thread, your would probably have got
    >> to a solution far earlier.

    >
    > JD,
    >
    > Had I realized the significance, I would have. Do you have any
    > explanation why they were there in the first place?


    I thought that you had understood this already. Your router was sending
    UDP packets to port 514 on your SCO box. I would guess that you did not
    have syslog listening on this address/port on your SCO box (perhaps syslog
    was configured to listen on only the loopback interface, or was not
    running), your SCO box sent back a "destination unreachable" control
    packet.

    Had you known the details of the "destination unreachable" packets, it
    would have been obvious what was happening.

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2