Re: improving transport over lossy links ?

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

_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Again about gprs
    ... DO NOT USE ATZ. ... AT&F is the standard for ordinary modems. ... >ABORT 'NO CARRIER' ... >I connected the phone to the computer and started the connection with: ...
    (comp.protocols.ppp)
  • Re: Two 56K modems connect at different rates
    ... I worked very closely with USRobotics (as they were before the 3Com ... that the standard doesn't just define one connection speed (eg you might ... methods that allow the modems to shift the rates that the channels are ... I'd imagine the Pace modem may be able to do the same. ...
    (uk.telecom)
  • Re: dual modem for dial-up
    ... > I read an article that indicated this person was using two 56k modems ... Multilink is enabled automatically in Windows XP Home Edition and Windows XP ... increases your connection bandwidth. ... Click the General tab, and then click each device that you want to use ...
    (microsoft.public.windowsxp.general)
  • Re: NDIS Miniport Serial Driver
    ... i currently have two modems attached on serial ports which i would ... > Although i can get one machine to accept a connection and one to dial ... > serial port driver which emulates the responses of a Hayes AT modem. ... > One of my thoughts is to have the modem appear as a network device ...
    (microsoft.public.development.device.drivers)
  • Re: Connecting to the Internet
    ... > Are "locally attached modems" different from modems connected to a PC ... > using a serial connection at one end and a plain old telephone at the ... I have no idea what's being sold in your ... I think mayayana has understood. ...
    (microsoft.public.vb.winapi)