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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to