Date: Sun, 21 May 2006 11:09:23 -0400 From: Mike Tancsa <mike@sentex.net> To: Brian Candler <B.Candler@pobox.com> Cc: freebsd-net@freebsd.org, Ian Smith <smithi@nimnet.asn.au> Subject: Re: improving transport over lossy links ? Message-ID: <6.2.3.4.0.20060521104147.081af2d8@64.7.153.2> In-Reply-To: <20060521092602.GB20262@uk.tiscali.com> References: <6.2.3.4.0.20060519110026.05820230@64.7.153.2> <Pine.BSF.3.96.1060520014045.15967A-100000@gaia.nimnet.asn.au> <6.2.3.4.0.20060519121104.1126b480@64.7.153.2> <20060521092602.GB20262@uk.tiscali.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
>
>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.
Hi,
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
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
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
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
[vpn2]# stty -f /dev/cuaU1
speed 115200 baud;
lflags: -icanon -isig -iexten -echo
iflags: -icrnl -imaxbel ignbrk -brkint
oflags: -opost -oxtabs
cflags: cs8 -parenb clocal crtscts
[vpn2]#
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
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,
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.
---Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6.2.3.4.0.20060521104147.081af2d8>