Re: Could this be a sign of break-in
From: Tim Haynes (usenet-20031202_at_stirfried.vegetable.org.uk)
Date: 12/02/03
- Previous message: Tim Haynes: "Re: Serious Vulnerability in Linux Kernel"
- In reply to: Newsbox: "Re: Could this be a sign of break-in"
- Next in thread: Newsbox: "Re: Could this be a sign of break-in"
- Reply: Newsbox: "Re: Could this be a sign of break-in"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 02 Dec 2003 09:46:32 +0000
Newsbox <newsbox@MAPS_ON_customers-of-adelphia.org> writes:
>> The `transmit timed out' normally means you have an inferior network
>> card and/or driver - in practice, via-rhine and some 3com chipsets have
>> been known to give that, worse under intense UDP and high temperatures.
>> IMNSHO you should get an intel etherpro100 in there if you're relying on
>> it for anything slightly serious.
>
> I'd like to pick your brain for whatever details you can give me on the
> via-rhine drivers and/or the chipsets they run on, with respect to
> specific or reproducible flaws. I have looked into this before, and I'm
> not saying that your advice to the OP is anything less than the best, at
> least in the short term. And I know that it's not a big expense or a big
> deal to replace a NIC (if needed). I have several D-Link DFE-530TX+ cards
> running, and would rather not replace them without knowing a reason to do
> so, or seeing if D-Link will underwrite the repair.
Always stress-test (CPU, file-system / disk access, network throughput, use
all the RAM), before you run a box live.
> I was new to *nix when I bought my first D-Link NIC, and got it after
> researching and finding recommendations that this was standards compliant
> and worked with *nix, whereas some others were not and did not.
The drivers exist. I don't claim to be able to establish whether it's
quality of driver or card hardware, but the net result is DFE530TX is
banished from my networks.
> I have thoroughly load tested these cards on my LANs and found no errors,
> problems or dropped packets whatsoever, on my LANs, with D-Link cards
> talking to D-Link cards. Under light and intermittent loads, my tests
> show approximately a couple of dozen dropped packets at irregular
> intervals during any 24 hour day, while connected to the ISP's Cisco
> router. ... Minor, perhaps.
Hmmm. How'd you test them?
>> The `transmit timed out' normally means you have an inferior network
>> card and/or driver - in practice, via-rhine and some 3com chipsets have
>> been known to give that,
>
> I haven't encountered anything of this type. But if you or others can
> give me references, I will take it to the manufacturer for credits.
It's a bunch of experience here dating from late kernel 2.2.x through
2.4.16 or later. If you've somehow managed to avoid problems with the
cards, cool.
>> worse under intense UDP and high temperatures.
>
> Sorry for gaps in fundamental knowledge. But, if you would please: UDP
> (User Datagram Protocol?)
The very same.
> Is there some particular way to simulate the problem(s) on my (or
> D-Link's) test LANs by creating "intense UDP"? How would I intentionally
> create "intense UDP" on a test LAN? What specific conditions might be
> needed or expected to occur on a public network to create problems for a
> connected D-Link card? Are you talking about an intentional DDOS attack?
Try running a 4-box MOSIX cluster - that uses a shed-load of UDP. ;8)
As a quicker solution, set up two boxes with a hub between them, try
something like
boxA nc -l -p 1234 > /dev/null
boxB nc boxA 1234 < /dev/zero
boxA ping -f boxB
boxB ping -f boxA
boxB ping boxA
boxA ping boxB
either box: iptraf (detailed mode)
and then do the netcat things with `-u' on both ends. Try all the above
separately & simultaneously.
Note: this is very network-intensive, but at low CPU cost on either end.
You should be able to sustain 10-11Mb/s with the first pair of commands
overnight.
> Many transistors exhibit higher leakage currents and lower breakdown
> voltages, as well as higher (and sometimes destructive) power
> dissipation, at increased temperatures. This is probably true (AFAIK) for
> all semiconductors. Defective power supplies and even unfiltered power
> line transients can probably, in most cases, produce almost any kind of
> similar failures. Would you think an intel card would be more resistant
> to common external sources of circuit breakdowns?
I don't have to think that ;)
I've experienced sticking a 4-node mosix cluster in a confined *warm* space
(under an exhibition stand) and the boxes survived, but the dfx530tx cards
got swapped-out very quickly; exact same symptoms as the above, `TX
transmit timed-out, resetting..' - and then after a few, the reset starts
failling too and that's it dead. No such problems with intels in there.
> pps. That's a neat approach to the return e-mail address ! Very clever.
Pity it seems to be necessary. Blame Swen.
~Tim
-- And the wind / And the rain |piglet@stirfried.vegetable.org.uk Falls around |http://spodzone.org.uk/
- Previous message: Tim Haynes: "Re: Serious Vulnerability in Linux Kernel"
- In reply to: Newsbox: "Re: Could this be a sign of break-in"
- Next in thread: Newsbox: "Re: Could this be a sign of break-in"
- Reply: Newsbox: "Re: Could this be a sign of break-in"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
