Messages in this thread | | | From | Tony Scholes <> | Subject | RE: 2.2.5 kernel & TCP/IP Terminal Server problem | Date | Fri, 24 Sep 1999 16:36:10 +0200 |
| |
On Friday, September 17, 1999 5:04 PM, Mark Hahn [SMTP:hahn@coffee.psychology.mcmaster.ca] wrote: [snip]
Mark
Thanks for your response, sorry it's taken a few days to get back to you, please excuse me...
> there are inter-operability issues with every pair of network stacks. > in this case, Linux tries agressively to use modern TCP features such > as timestamps and SACK. your symptoms match what you'd expect if the > terminal servers or RH were failing in these features. the simplest > solution is probably to disable them on RH, such as > echo 0 > /proc/sys/net/ipv4/tcp_timestamps >
Tried this, and a few others including disabling SACK, but because I was remote to the site and the tester was not of the highest calibre, the results where not conclusive.... Hope to conduct more accurate tests early next week when I'm onsite at one of the offending networks
> naturally, it would be a welcome contribution to Linux if you would > find which of these helps, if any. >
Of course, and I'll certainly summarise how the problem is resolved to wherever is appropriate (recommendations?) , I've received another response from Alan Cox (gosh!), and replied to the mailing list as well...
> > What should I go looking for here? Default packet sizes? Some clues as to > > possible causes more than welcome... > > well, the standard way to investigate any networking problem is to look > at the packets and find out what's wrong. tcpdump lets you do this, > and would reveal any timestamp/sack problem, potentially as well as > a possible window problem. (the latter is simply the fact that many > tcp stacks, such as those from microsoft, are pathologically slow at > decent window sizes: Linux likes 32K, msft wants 8K.) > > if you capture some tcpdump traces, I'd be happy to look at them, > though I'm not a networking god. >
Thanks very much for the kind offer, I have attached a tcpdump produced by 'tcpdump host thames and host spider1' where 'thames' is the RH 6.0 box and 'spider1' the Shiva Terminal Server... Can'tmake much of it myself, but I'm looking at it now as well, if this is not specific or detailed enough please let me know (if you're still willing to look at it of course)
> regards, mark hahn.
Once again thanks very much for your help so far
-- Tony Scholes Technical Manager ================================================= Beacon Computer Services Tel: +44 (0)1582 478888 The Friars, 82 High Street South Fax: +44 (0)1582 478810 Dunstable, Beds. UK Email: tonys@beacon.co.uk LU6 3HD Compuserve: 72660,207 =================================================
[unhandled content-type:application/octet-stream] | |