Marc Torres writes:
> I have had ssh sessions running for hours and launched nslookups,
> traceroutes, etc. Everything is rock solid. It just happens with http
> traffic. So my guess is that there might be a bug somewhere in the
> driver usbsacm or in the networking stack that breaks the connection
> when using the 3G network of T-mobile.
My guess would be that there's a problem much lower down. Have you
tried transferring large files back and forth without http? I suspect
that it's stress-related, and that the problem is either a flow
control configuration error or something related to packet size.
> This is the cat'ed output of /etc/ppp/peers/t-mobile:
In general: you want to configure as _little_ as possible when using
pppd (and perhaps just about any software). The defaults are
intentionally chosen to be useful, and generally conform to
standards-specified protocol requirements.
Some comments:
> mtu 8192
That's an awfully large MTU, and likely exposes you to lower
performance due to the large of relatively large amounts of data when
transmission errors occur. It doesn't make sense for something as
slow as async I/O or a cell phone.
Are you absolutely sure that's the right thing to do here?
> 460800
That's fairly fast for ordinary async serial I/O, but should work.
(How fast is the underlying link supposed to be?)
> modem
That's the default and shouldn't be necessary to specify.
> password "pass"
I recommend using the appropriate /etc/ppp/pap-secrets or
/etc/ppp/chap-secrets file for this, but placing it here is also ok.
> nobsdcomp
This doesn't do anything -- you've already specified noccp.
> pap-max-authreq 32
> pap-restart 16
> pap-timeout 0
Those (and the other negotiation tuning tweaks) certainly shouldn't be
needed on any properly-functioning link. Is the device you're using
unusually slow or bug-ridden?
> #kdebug 4
> #proxyarp
I know you have those commented out, but just for reference: kdebug is
useful mostly for those hacking on the kernel itself. It's usually
not useful for debugging a failed link. The proxyarp option only
really makes sense for some dial-in servers, and is almost never the
right thing to do on dial-out.
> Could somebody shed some ideas as to what the cause of this might be?
> What should I trace and how should I trace it to give developers more
> of an idea as to what is failing?
I'll need:
- debug logs from syslog; make sure that daemon.debug is
directed to a file.
- output from "netstat -ni" after the failure.
- output from "kstat sppp\*" after failure.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]
