Thanks for the input about uClinux+RTLinux 0.9j. I have obtained the
RTlinux patch and got it work successfully. Yet the problem remains.
RTLinux provides a mechanism to execute certain tasks at hard realtime
scheduled intervals while the linux kernel becomes a soft scheduled realtime
task. This leaves the CS8900 code in the same state as before which is good
for data acquisition but truly bad for a someone trying to access the
uSimm's web server, for example, at the time a ping flood occurs.
Sebastion suggested to write the CS8900 driver as a polled driver -
unfortunately I don't have enough kernel programming know-how to get this
accomplished. What mechanism would call some code x to poll the card?
Perhaps the hard realtime side? How about if the RTLinux was not used.
I have to ask this question again. If someone uses the CS8900 chip on an
ISA PC card and a ping flood occurs then how can the system to anything but
receive packets? The CS8900 pdf file clearly states that once the
interrupts occurs all data must be read the matter what.
Here is another interesting observation. I have ping flooded the uCsimm.
It appears, using tcpdump, that the ICMP echo requests are sent to the
uCsimm. The ICMP echo replies occur only *after* I stop the ping flood.
Perhaps the polled method would be better for the CS8900 chip, since in
interrupted mode it can only receive the flood of packets.
> -----Original Message-----
> From: Steffen Plotner [SMTP:firstname.lastname@example.org]
> Sent: Monday, August 28, 2000 10:31 PM
> To: 'ucsimm@uClinux.com'
> Subject: [uCsimm] CS8900 Chip Selection
> I have a simple question about the choice of the CS8900 LAN chip: the
> software driver has to process any and all incoming packets once it
> an interrupt. If you don't process all packets, you will not get
> interrupted again.
> So in English that means, if someone does a ping -f (ping flood) the
> SIMM device will have no choice but to deal with the ping flood - it does
> remarkably well at that - except that NO other process can do anything
> because the flood has taken over the system. Try the following, connect
> using the serial port, and perform the ping flood against the device.
> the ping flood occurs, attempt to do anything with the serial connection.
> How exactly can CS8900 chip set be used in an embedded device, when it
> possible to perform such a simple DoS (Denial of Service) attach?
> Here is the snippet of source code reference of the CS8900.c file which I
> found, proving my points above
> /* we MUST read all the events out of the ISQ, otherwise we'll never
> get interrupted again. As a consequence, we can't have any
> on the number of times we loop in the interrupt handler. The
> hardware guarantees that eventually we'll run out of events.
> course, if you're on a slow machine, and packets are arriving
> faster than you can read them off, you're screwed. Hasta la
> vista, baby! */
> This message resent by the email@example.com list server
This message resent by the firstname.lastname@example.org list server http://www.uClinux.com/
This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:37 EST