|
List Info
Thread: improving transport over lossy links ?
|
|
| improving transport over lossy links ? |
|
2006-05-19 16:38:31 |
At 12:06 PM 19/05/2006, Ian Smith wrote:
>Assuming that V.42 error correction is working properly
- forced if need
>be - there shouldn't =be= any data loss, however slow
getting through,
>this side of protocol timeouts of course. I can't
guess your mystery
>application, but often slower connections are better
than dropped ones,
>or even ones that spend half their time trying to
retrain at high rates.
Hi,
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)
Error correction is on and negotiated, from the terminal
server's
perspective at least and I imagine the modem too
Testing here at the office
Card Type: LU1674 Chipset
State: ACTIVE
Active Port: S26
Transmit Rate: 28800
Receive Rate: 26400
Connection Type: LAPM/V42BIS
Chars Sent: 215666023
Chars Received: 58090941
Retrains: 0
Renegotiations: 4
The application is TCP based and monitors remote machinery.
(And no,
there is no chance at this point to re-write the
application). The
transport is over a VPN (either IPSEC or OpenVPN) which ever
deals
better with the lossy connection. However, many of the
sites have
dynamic IP addresses which makes it a pain to use with IPSEC
and FreeBSD.
One think I observed with multi-link so far is that if I
kill one of
the connections, the modem does not tell ppp that it has
lost carrier
right away. Instead, I have to wait for the LCP echo
timeout. In the
mean time, I get 50% packet loss for about 20 seconds.
However I can
reduce that by setting the lqrperiod to a lower value.
However, I
dont want that too low, otherwise it spends all its time
chewing up
the link with LCP traffic.
I was going to look at the one2many ng module to see if I
can send
out the same packets on both links at the same time as a
sort of "as
long as one packet gets there strategy" Although the
customer doesnt
use wireless right now, we might have some sites that would
need it
in the fture and this might be an approach. I imagine
satellite users
run into this as well no ?
---Mike
_______________________________________________
freebsd-net freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"
|
|
| improving transport over lossy links ? |
|
2006-05-19 20:11:03 |
On Fri, 19 May 2006 at 12:38:31 -0400, Mike Tancsa wrote:
> At 12:06 PM 19/05/2006, Ian Smith wrote:
>
> >Assuming that V.42 error correction is working
properly - forced if need
> >be - there shouldn't =be= any data loss, however
slow getting through,
> >this side of protocol timeouts of course. I
can't guess your mystery
> >application, but often slower connections are
better than dropped ones,
> >or even ones that spend half their time trying to
retrain at high rates.
>
> Hi,
> 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)
A lot of those, Mike, or just 1 FCS error per connection?
I'm using a
modem right now that often reports just 1 FCS upon linkup,
then works
fine for the day. Ah, 'often' includes this call I'm on
now since:
May 19 22:31:33 paqi ppp[2559]: tun0: Phase: deflink: HDLC
errors ->
FCS: 1, ADDR: 0, COMD: 0, PROTO: 0
.. so on its own that mightn't indicate much but maybe a
chipset HDLC
bug, but bunches of these are most often seen (inbound)
where a caller
negotiates a non-EC connection at 14400 or more; they rarely
last long.
Even then, FCS errors indicate link-level packet retries,
not drops.
Line loss is more likely physical, poor signal to noise over
too long a
time for desired line quality, which factors may well be
tunable, at
either end. I suppose the calling modems are a variety of
types, and
you've really only any control over the inbound modem
config?
> Error correction is on and negotiated, from the
terminal server's
> perspective at least and I imagine the modem too
A lot depends on the calling modems of course .. some do,
some don't.
> Testing here at the office
>
> Card Type: LU1674 Chipset
> State: ACTIVE
> Active Port: S26
> Transmit Rate: 28800
> Receive Rate: 26400
> Connection Type: LAPM/V42BIS
> Chars Sent: 215666023
> Chars Received: 58090941
> Retrains: 0
> Renegotiations: 4
Depends how long a call that represents I guess; it
wouldn't look too
shabby here, but we average less than 1GB/mth with ~3-5
redials/mth.
Retrains 0, Rate renegs 4 over 215Mb doesn't look
problematic.
> The application is TCP based and monitors remote
machinery. (And no,
> there is no chance at this point to re-write the
application). The
> transport is over a VPN (either IPSEC or OpenVPN)
which ever deals
> better with the lossy connection. However, many of
the sites have
> dynamic IP addresses which makes it a pain to use with
IPSEC and FreeBSD.
Well if you redial a lost connection (-ddial etc) and regain
the same IP
address, TCP should chug on fine, ie remain lossless, while
delayed. If
not, open (link) TCP connections are shot, if that's the
lossy you mean?
> One think I observed with multi-link so far is that if
I kill one of
> the connections, the modem does not tell ppp that it
has lost carrier
> right away. Instead, I have to wait for the LCP echo
timeout. In the
> mean time, I get 50% packet loss for about 20 seconds.
However I can
> reduce that by setting the lqrperiod to a lower
value. However, I
> dont want that too low, otherwise it spends all its
time chewing up
> the link with LCP traffic.
Mmm, 50% loss sounds about right for half the link  Sorry,
I've only
a vague idea how multilink PPP works, getting way out of my
depth here.
20 seconds sounds about right for successful redial /
negotiation, but
why isn't modem !DCD telling ppp right away? Is that a
config issue?
> I was going to look at the one2many ng module to see
if I can send
> out the same packets on both links at the same time as
a sort of "as
> long as one packet gets there strategy"
Although the customer doesnt
> use wireless right now, we might have some sites that
would need it
> in the fture and this might be an approach. I imagine
satellite users
> run into this as well no ?
ng_one2many looks great, but there's still its Link Failure
Detection to
satisfy, which still has to come back to noticing modem
!carrier, no?
(Satellite users run into everything at some stage; weather,
sunspots ..
we replaced one with ADSL last year. ssh over sat was
pretty tedious,
even with 128k ISDN back. Outside wifi can get soggy in the
wet, too!)
cheers, Ian
_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"
|
|
| improving transport over lossy links ? |
|
2006-05-21 09:26:02 |
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.
Regards,
Brian.
_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"
|
|
| improving transport over lossy links ? |
|
2006-05-21 15:09:23 |
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-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"
|
|
| improving transport over lossy links ? |
|
2006-05-21 15:49:17 |
Throwing caution to the wind and speaking without thinking
about
what was being said on Sun, May 21, 2006 at 11:09 ,
Mike Tancsa blurted this:
> 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
The best modems I've found are the ones from Multi-tech.
Even their
super-small ones. Before we added a PRI and a Livingston
we were
thinking about using the MT's in the 19" rack mount
box they have.
And when performing fax from email - using sendmail incoming
and
routing to fax [in the early days of the current 'net
before many
people had 'net connections] the MT's were the only ones
that
worked with virtually ever target fax machine.
The MTs are external.
Bill
--
Bill Vermillion - bv wjv . com
_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"
|
|
| improving transport over lossy links ? |
|
2006-05-21 17:15:21 |
On Sun, May 21, 2006 at 11:09:23AM -0400, Mike Tancsa wrote:
> 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.
USB-serial adaptors tend to be very broken, unfortunately. I
don't know
about under Windows, but under FreeBSD/Linux where drivers
seem to be
reverse-engineered, several I've tried don't seem to
handshake properly. I
tried two back-to-back to run a local pppd link and it
failed (haven't had
time to debug that one)
IMO there's no substitute for a real COM port.
> (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.
A pair of analogue modems will never negotiate v90, as for
this one end has
to be digitally connected (typically T1/E1 trunk, although
in theory you
might be able to find a modem which is physically connected
as ISDN BRI but
which supports v90 analogue modulation)
The best you'll get is v34bis (33.6K)
Regards,
Brian.
_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"
|
|
| improving transport over lossy links ? |
|
2006-05-21 18:53:37 |
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-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"
|
|
| improving transport over lossy links ? |
|
2006-05-21 19:32:45 |
At 01:15 PM 21/05/2006, Brian Candler wrote:
>On Sun, May 21, 2006 at 11:09:23AM -0400, Mike Tancsa
wrote:
> > 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.
>
>USB-serial adaptors tend to be very broken,
unfortunately. I don't know
>about under Windows, but under FreeBSD/Linux where
drivers seem to be
>reverse-engineered, several I've tried don't seem to
handshake properly. I
>tried two back-to-back to run a local pppd link and it
failed (haven't had
>time to debug that one)
>
>IMO there's no substitute for a real COM port.
I was hoping to use some of the Soekris 4801s which have
limited
expandability. I need 2 serial ports for the application
and then
the modem of course. Under FreeBSD I have used the uftdi
based
adaptors for OOB console access and they seem to work OK.
>A pair of analogue modems will never negotiate v90,
This is the modem connected to my terminal server which is
connected
via PRI. I dont have any analog modem to analog modem
setups.
---Mike
_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"
|
|
| improving transport over lossy links ? |
|
2006-05-21 19:45:16 |
At 11:49 AM 21/05/2006, Bill Vermillion wrote:
>And when performing fax from email - using sendmail
incoming and
>routing to fax [in the early days of the current 'net
before many
>people had 'net connections] the MT's were the only
ones that
>worked with virtually ever target fax machine.
Thanks, I have used them in the past. They are certainly
quite a bit
more expensive than the USRs (3x) but I might be able to
justify it
if they really do perform a lot better.
---Mike
_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"
|
|
| improving transport over lossy links ? |
|
2006-05-22 09:17:02 |
BC> Date: Sun, 21 May 2006 18:15:21 +0100
BC> From: Brian Candler
BC> [I]n theory you might be able to find a modem which
is physically
BC> connected as ISDN BRI but which supports v90 analogue
modulation)
Ascend MAX 1800 or MAX 3000
Eddy
--
Everquick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network
building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
____________________________________________________________
____________
DO NOT send mail to the following addresses:
davidcbrics.com -*- jfconmaapaqintc.net -*- sameverquick.net
Sending mail to spambait addresses is a great way to get
blocked.
Ditto for broken OOO autoresponders and foolish AV software
backscatter.
_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"
|
|
[1-10]
|
|