Date: Mon, 22 May 2006 04:53:37 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Mike Tancsa <mike@sentex.net> Cc: freebsd-net@freebsd.org, Brian Candler <B.Candler@pobox.com> Subject: Re: improving transport over lossy links ? Message-ID: <Pine.BSF.3.96.1060522014929.24481E-100000@gaia.nimnet.asn.au> In-Reply-To: <6.2.3.4.0.20060521104147.081af2d8@64.7.153.2>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 21 May 2006 at 11:09:23 -0400, Mike Tancsa wrote:
> At 05:26 AM 21/05/2006, Brian Candler wrote:
> >On Fri, May 19, 2006 at 12:38:31PM -0400, Mike Tancsa wrote:
> > > Thanks for the reply. Even at 28.8 I am seeing loss with
> > > the connection dropping and seeing dropped packets (e.g.
> > > May 19 12:04:43 soekris4801 ppp[3404]: tun0: Phase: 1: HDLC errors ->
> > > FCS: 1, ADDR: 0, COMD: 0, PROTO: 0)
> >
> >If you have an error-correcting modem, but you are seeing data corruption,
> >then I'd expect the data corruption is occuring on the RS232 link between
> >the PC and the modem at one end or the other. You may have a handshaking
> >problem (i.e. ensure the modem is configured for CTS/RTS handshaking, and
> >the port is configured for this too; with pppd it's "crtscts", I don't know
> >about userland ppp; and ensure the cables are wired properly)
100% great advice Brian, modulo what I said about some modems (three
differently branded V.90s with Cirrus/Ambient chips to be specific) that
very often show 1 FCS error frame early on, that's really a false alarm.
> >If your app could cope with the lack of bandwidth, forcing the modems to
> >2400bps operation can make links over dodgy lines a lot more reliable.
Well yes, but you usually don't need to go to quite that extreme :)
> Its not so much data corruption of packets on the wire, but
> the modem dropping the connection, retraining and
> renegotiating. When the retrains and re negotiations happen, this
> can cause problems for the VPN as keep alives are missed, tx buffers
> can fill up etc. I have tried a number of modems, the current one
> being U.S. Robotics 56K FAX INT V5.22.70. and I am also trying an
> external Intel at the office
Yes that's just the problem alright. Just to be clear, you're referring
here only to various calling-in modems, calling to these fixed terminal
server cards, of maybe Lucent origin, right?
> ati4
> Intel Corporation
>
> OK
> ati5
> Full V.92 Upgradeable
> Present, 32K DSP RAM.000
> Host I/F: Serial
> P. Mem. : 008 Bit 001 W.S.
> D. Mem : 008 Bit 001 W.S.
> DSP loc : INT ROM
Interesting .. that's pretty much the same response as one of these
Cirrus/Ambient chip modems mentioned that shows that one FCS error .. eg
this one is a 'Swann Flash V.90' (pre V.92 upgradeable):
ati1
CD08.55 - 642 (06/30/2000) SERIAL - SPEAKERPHONE 01 - DSP PATCH: 001.65
OK
ati4
AMBIENT TECHNOLOGIES INC. ENGINEERING FIRMWARE DEPARTMENT
OK
ati5
Present, 32K DSP RAM.000
Host I/F: Serial
P. Mem. : 008 Bit 001 W.S.
D. Mem : 008 Bit 001 W.S.
DSP code location = INT ROM
OK
ati22
Cirrus Logic, Inc.
OK
> The internal USR seems to correctly see the carrier drop and PPP
> hence sees it. However, the 2 external Intels I am experimenting
> with on the USB serial ports do not. I suspect thats part of the
> reason the DCD is not working. Perhaps incorrect init string or
> something with the USB-Serial. Note, I only have the internal USRs
> deployed in the field right now
Don't know about USB modems. Do USR still use their own chipsets, or
what? In any case, they're probably highly tunable and well documented.
> Intels
> [vpn2]# stty -f /dev/cuaU0
> speed 115200 baud;
> lflags: -icanon -isig -iexten -echo
> iflags: -icrnl -imaxbel ignbrk -brkint
> oflags: -opost -oxtabs
> cflags: cs8 -parenb clocal crtscts
[..]
> live USR internal
> [Hastings109]# stty -f /dev/cuad4
> speed 115200 baud;
> lflags: -icanon -isig -iexten -echo
> iflags: -icrnl -ixon -imaxbel ignbrk -brkint
> oflags: -opost -oxtabs
> cflags: cs8 -parenb clocal crtscts
Only difference here on present cuaa0 is plus oflags: -onlcr but I doubt
that matters in presumably transparent data mode.
> From the terminal servers perspective it sees
>
> show m12
> Card Type: LU1674 Chipset
> State: ACTIVE
> Active Port: S2
> Transmit Rate: 45333
> Receive Rate: 16800
> Connection Type: LAPM/V42BIS
> Chars Sent: 3166222761
> Chars Received: 2925103984
> Retrains: 1
> Renegotiations: 6
>
> (not sure why, but chats tx/rx are for all calls in the pas 216 days,
Ahah. 16800 rx isn't all that hot either.
> not just this one). This is in the past 4hours. Perhaps with this
> one, I am just better off telling it not to try v.90.
Not V.90 full tilt, anyway. If 45333 is sort of usual for this one,
then I'd probably try telling it to connect no higher than maybe 41333
or 40000; often about 10-15% or so less than 'normal' can make all the
difference. If you can afford the bandwidth, go for slow and solid ..
Our Massive Uplink is a V.90 modem, a WebExcel (Rockwell). While just
giving it its head, it'd connect at 52000 or 50666, but redial at least
twice a day and retrain much more often. Since forcing it to max 49333
- maybe 5 years ago - it holds connections up on average around 10 days,
not so infrequently for 3 weeks, best about 47 days from memory. This
one's only a few hundred metres from its local exchange, too:
ati6
RCV56DPF-PLL L8571A Rev 33.00/33.00
OK
at+ms?
12,1,300,49333,1,0,33600
And here's for one of those Cirrus/Ambient/(Intel?) modems, from 12.5km
out bush to a V.34B modem, usually makes 31200 or 28800, default dialup:
set dial "ABORT BUSY ABORT NO\\sCARRIER ABORT NO\\sANSWER TIMEOUT 10 \
\"\" ATZ OK-ATZ-OK ATE0Q0L1S7=50W3+MS=V34B,1,24000,33600 OK \
\\dATDT\\T TIMEOUT 60 CONNECT \\c \\n"
but after lots of rain - we get 90+"/yr - when the line junctions are
full of water and the lines are shot, I might try one like this, say:
jetstream_24k:
set dial "ABORT BUSY ABORT NO\\sCARRIER ABORT NO\\sANSWER TIMEOUT 10 \
\"\" ATZ OK-ATZ-OK ATE0Q0\\\\N2S7=50+MS=11,1,19200,24000 OK \
\\dATDT\\T TIMEOUT 60 CONNECT \\c \\n"
That's a V.34B Rockwell. Extreme example, another Rockwell as I recall:
gaia_mp: #% from m's very weird phoneline
set dial "ABORT BUSY ABORT NO\\sCARRIER ABORT NO\\sANSWER TIMEOUT 10 \
\"\" ATZ OK-ATZ-OK ATE0Q0S7=45+MS=11,1,7200,19200 OK \
\\dATX3\\\\N3DT\\T TIMEOUT 60 CONNECT \\c \\n"
Modems on poor lines are a necessary evil, but evil nonetheless ..
cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1060522014929.24481E-100000>