Mike Silbersack wrote: > > On Mon, 26 Nov 2007, Ian FREISLICH wrote: > > > net.inet.tcp.delayed_ack=0 > > net.inet.tcp.rfc1323=1 > > http://www.freislich.nom.za/phone.nodelayedack > > > > net.inet.tcp.delayed_ack=1 > > net.inet.tcp.rfc1323=1 > > http://www.freislich.nom.za/phone.delayedack > > Wow. Wow! WOW! > > The TCP stack on that device amazes me in how poorly it is written. No surprises there. > So it looks like if the phone does not receive an ACK for its data within > .156785-.150649 = .006136 seconds, it gives up on the connection and > closes it! Yet it still manages to send data along with the RST, which is > something that no other TCP stack (in common use) would do. > > My guess is that even coming in from other OSes, you will experience > problems if you go over a link with any noticeable latency. Yet, a colleague managed to configure the phone using his Mac over that very slow link - analog leased line at 28.8kbps. I do occasionally see resets even when not using delayed ack. > Disabling delayed acks when you need to manage this phone looks like the > only option; I don't see anything else that could be changed to better > accomodate this phone. I really hope that the TCP used by this phone is > not used in any other devices. I'm in communication with the vendor, so hopefully this will get fixed. Interestingly, this is one of the few phones that I've been able to interact with web and telnet while it's busy on a call. Guess you win some... and loose some. Thanks for confirming my suspicions. Ian -- Ian FreislichReceived on Mon Nov 26 2007 - 06:48:14 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:23 UTC