🚀 go-pugleaf

In article <3kMmQBA0$fmwoA0O@turnpike.com>, David English
<DavidE@turnpike.com> writes
>In article <ALgZzMAULVmwEAJr@heaven.demon.co.uk>, Jason Crouch
><jason@heaven.demon.co.uk> writes
[Active profile of the modem]
>
>/V1 will enable protocol result code

Actually I guess you mean \V1 (pedants-are-us); however, this only does
anything if the modem hasn't already been sent to give out extended
result codes with W1 in the init string, which is the way I currently
have it set :(

However, looking at the format, it may be worthwhile to set normal
result codes (i.e. just CONNECT with the appropriate DCE or DTE speed)
with ATW0 or ATW2, then append a \V1 to get an "extended" string.
Although you'd think it would be sensible of the modem manufacturers to
make ATW1\V0 == ATW0\V1 (both of which are explained in the manual as
"extended result codes") ... oh, but silly me, I just wrote a sentence
with "sensible" and "modem manufacturers" in it.

Moving swiftly on, after a suggestion from Jim Segrave (jes), I
attempted dialing the local (manchester) vPoP using a normal terminal
app earlier today, and watched what the connection returned.

at&f     <- surprise, surprise factory default.
OK
atw1     <- turn ON extended result codes (bit like \V1 but not quite :)
OK
atdt3859666
CARRIER 28800 V.34

PROTOCOL: LAP-M

COMPRESSION: V.42bis

CONNECT 115200

a.demon.co.uk (ttyc4a):
demon login:

The interesting thing here is; when compared with the same logon via the
Microsoft Dial-up networking, with the same INIT string (and, yes, I
have tried both methods with a variety of INIT strings), gives the
response I posted yesterday, viz:

Send: ATDT#######<cr>
Recv: ATDT3859666<cr>
Recv: <cr>
Interpreted response: Informative
Recv: <lf>
Interpreted response: Informative
Recv: CARRIER 28800
Interpreted response: Informative
Recv:  V.34<cr><lf><cr><lf>PROTOCOL: LAP-M<cr><lf><cr>
WARNING: Unrecognized response.  Retrying...
Connection established at 28800bps.
Error-control off or unknown.
Data compression off or unknown.

i.e. it gets the "PROTOCOL: LAP-M" line, which it fails to recognise,
then appears to accept the CONNECT 115200 modem response, whilst either
failing to log the other extended response codes, or simply ignoring
them. Oh bum. 

Still, can't expect Microsoft to get any^H^H^Heverything right.
 
>Good luck

Thanks.

j.
-- 
heaven - mFifteen
http://www.gabriel.co.uk/heaven/

I feel a really sharp knife solves most problems - D.S.