I suspect this bug to be triggered by 'ets0' network interface
(synchronous HDLC support) from et.o module supplied with ET5025
synchronous card. I contacted with ET support and they said it's linux's
fault. Maybe it's true, maybe it's not - I suppose some kind of
interaction between ET driver and derfagmenting code in kernel, because I
did some tests and:
When i run EXACTLY the same kernel image on other machine and use 'sl0'
(async SLIP) interface instead of 'ets0' everything is OK.
This suggests that bug is in ET driver.
BUT, on the other hand, i used this driver for several months with no
problems at all. It all started when i compiled in kernel option
IP ALWAYS DEFRAGMENT - what I need for my firewall and masquerading.
That suggests that bug is in linux kernel in defragmenting code
Is there anybody responsible for this code fragment, who would be so kind
to answer my question:
Is it possible that network interface is good for "regular" kernel but
"lacks some features" or "don't behave correctly" with kernel compiled
with defragmentation ???
Should any "external" network driver expect different interaction while
this feature is active in kernel ?
Or maybe this new feature sends something strange that ET driver will not
accept and nobody knows about it because Ethernet and SLIP drivers are
"more tolerant" for buggy packets/data/code ?
If you are interested in details, I can send my kernel/network
configuration.
I suppose it would be difficult for kernel maintainers to test this bug
because of lack of such a card in his/her system - if this is the case,
send me detailed description of tests I should do on my machine.
P.S. Please reply to my private e-mail because i'm not subscribed to this
list!!!!
*----------------------------------------------------------------------------*
Leszek Gerwatowski
bigl@alpha.im.pw.edu.pl
*----------------------------------------------------------------------------*