On Fri, Oct 08, 1999 at 12:46:26AM +0200, Andrea Arcangeli wrote:
> On Thu, 7 Oct 1999, Steve Dodd wrote:
> >and serial_cs.o. So I guess the question is hardware problem (modem), software
> >problem (driver), or wetware problem (me configuring something wrong <g>)?
> Just to try to collect some more data. Did you tried to increase the
> txqueuelen to an insane value (50) so that the sched layer won't drop
> packages (but queue them) if they can't be sent to the hardware yet? It
> completly hides the proble here (see my other email).
It doesn't make a significant difference here -- obviously you've got a
slightly different problem :-) I don't believe the hardware layer is actually
refusing packets from the network layer, just corrupting or dropping them.
Setting a ridiculously small mtu (296) makes things more bearable, but it's
not really a long-term solution. Incidentally, I've found at least one
remote site that seems to get completely confused by this -- I don't know
why. It's not the "stupidly blocking ICMP_FRAGNEEDED" wetware problem, 'cos
I'm not altering my mru. I can issue HTTP requests by hand and got the
response fine; when a browser does it, nothing happens. Sending a manual
request with a "X-Pad: ..." (followed by lots of rubbish) header triggers the
problem -- I'm guessing the remote is running some b0rken stack that doesn't
know how to defragment IP packets?
--
"Damn and blast British Telecom!" exclaimed Dirk, the words
coming easily from force of habit.
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
