[cobalt-security] promisc and Cobalt kernel

["David Thacker" <Cobalt@xxxxxxxxxxxxxx>]

> Message: 4
> Date: Wed, 23 May 2001 09:32:29 +0200 (CEST)
> From: ProServe - Peter Batenburg <peter@xxxxxxxxxxx>
> To: Cobalt Security Mailing List <cobalt-security@xxxxxxxxxxxxxxx>
> Subject: Re: [cobalt-security] promisc and Cobalt kernel
> Reply-To: cobalt-security@xxxxxxxxxxxxxxx
>
> Hi Gossi,
>
> About 6 months ago i tried to recompile 2.2.14C10 on a raq3 with openwall
> & stealth patches. The kernel compiled, and i installed it sucessfully.
> The only problem i had was when i started trafshow (promisc) or added a
> new ip with ifconfig, was that the network seems to freeze. The box still
> runs, but all network activity stops. Completely the same as in your
> story. And no, it had nothing to do with the stealth patch. I stil haven't
> found out what the problem was.
>
> With kind regards,
>
> Peter Batenburg
>
> ProServe
> Prisma 100
> 3364 DJ Sliedrecht
> Tel.: 0184 - 423 815
> Fax: 0184 - 417 160
> http://www.proserve.nl
>
> On Wed, 23 May 2001, Gossi The Dog wrote:
>
> >
> > Hi,
> >
> > I've got a bizzare problem on owned.lab6.com.  We run snort as our IDS.
> > Since installing the RPM for the kernel to the fix the latest security
> > problems, if I run something else which tries to put the NIC into
promisc
> > mode (for example, another sniffer), all networking drops out on the box
> > completely.  It sits logging stuff in syslog and is alive, but I can't
> > print/traceroute or get any kind of response from it.  I'm thinking its
a
> > kernel problem - can anybody else test?
> >
> > Regards,
> > Gossi.
> >


Greetings,

I experienced the same "networking goes to sleep" problem with a RaQ3 using
the standard unmodified kernel, and this problem has been reported now and
then by others as well.  To my knowledge there has never been a solid answer
or solution from Cobalt about this one.

This was an intermittent problem from day one on this box.  All networking
would quit and then restart itself at some indeterminate later time (15
minutes to an hour).  Active monitor queries inside the box would continue
to work okay.  If I pinged the box from another machine on the same subnet,
that would usually wake it up and away it would go servicing outside
requests again until the next doze event.

The only reliable way I could get this box to keep its networking working
was to start a background task to ping the gateway every 75 seconds:

nohup ping -i 75 -n 207.167.12.2 >> /dev/null &

My colocation provider was convinced it was a problem with the stock Intel
NIC driver compiled into the kernel, and we provided some supporting URLs to
Cobalt detailing problems with the driver, but nothing ever came of it.

David Thacker