Conference irocz::terminal_servers

  Hi Jim,
  
  First of all, I really appreciate your help!

>     I hate to say it, but many times the answer is RTFM.

  I agree for 100% but I could't (yet) find a solution in there...

>     Why "&E3"?  You should enable *some* sort of flow control...
  
  Sorry for this misunderstanding but in fact, the only working solution
  I have with a DS90M is: flow control disabled on DS90M, flow control
  disabled on both modems and Win95 pc.
  When I tried XON/XOFF flow-control, I did, of course, config both modems
  flow software flow control XON/XOFF (&E5) and  pacing enabled (&E13)...

>     &E12 (pacing disabled): I have no idea what this means.
   
  When Multitech speaks about "flow control", they mean 'controling' data
  flow from computer/terminal to modem.  Possible settings:
  	&E3	flow control disabled
  	&E4	CTS/RTS hardware flow control
  	&E5	XON/XOFF software flow control
  Multitech speaks about "pacing" when they speak about 'controling' data
  flow from modem to computer/terminal.  Possible settings:
  	&E12	pacing disabled
  	&E13  	pacing enabled (kind of flow control depends on setting:
                                if &E4 ==> CTS/RTS, if &E5 ==> XON/XOFF)

>     You should be able to get this brand to work...

  What about the 'readme.txt'-file access-server-manager directory: the
  'problem modems'-list contains just ONE modem: YES it's 'my' MT2834ZDX!!!
  ... but what about the MT932BAI ???
  
  BUT I don't understand why those 2 same modems CAN SUCCESSFULLY be used
  with XON/XOFF flow control (&E5 &E13) for a SLIP-connection between two 
  UCX-hosts (in this case: slip CAN be configured with /FLOWCONTROL which means:
  byte-stuffing e.g. XON & XOFF).  In this case: telnet & ftp works fine!!
  ==> so why nok for PPP???

>     I thought I had already posted some information on modem configuration
>     but I can't seem to find it.  I'll post it as a new topic.
                
  Thanks for note 3413.* this can be useful: I hope someone will add a reply
  with XON/XOFF flow control and Win95 pc
  (with RTS/CTS on DS700 I don't have any problem with ppp-ing to Win95 pc...)

  Patrick    

>   Sorry for this misunderstanding but in fact, the only working solution
>   I have with a DS90M is: flow control disabled on DS90M, flow control
>   disabled on both modems and Win95 pc.

With flow control disabled, if something causes one device to become "busy"
and be unable to keep up with reading data another device is sending it,
some of the data being sent will be lost.  This will result in a number of
symptoms, none of which are desireable.  In the above scenerio, "device"
could be a modem, a PC, or a DECserver.

>  What about the 'readme.txt'-file access-server-manager directory: the
>  'problem modems'-list contains just ONE modem: YES it's 'my' MT2834ZDX!!!
>  ... but what about the MT932BAI ???

We haven't tried the MT932BAI.

>  ==> so why nok for PPP???

Are both ends of the PPP connection byte-stuffing XON/XOFF characters?  Does
the modem *really* not respond to XON/XOFF characters if pacing is disabled?
Do a LIST PORT x LCP and look at the "Character Map:" value.  It should be
"A0000" to guarantee XON/XOFF characters are byte-stuffed by the DECserver.
The PC will have to be similarly configured to not directly pass XON/XOFF...
maybe Win95 always byte-stuffs XON/XOFF??

.0> I can establish a ppp-link between both, a ping command is success-
.0> full but if I try to start a telnet or ftp-session, I can get logged
.0> in on the remote system, but shortly after that, e.g. while doing a
.0> dir-command, this session hangs...

Anytime a session hangs, I'm suspicious of flow control problems.  Have you
done a SHOW PORT STATUS command?  Does it should the DECserver's port is
XOFFed?  If not, something else somewhere along the path might have seen an
XOFF and is waiting for the matching XON that will never come in.

Hi Jim,

I'm really convinced about the need to have flow-control enabled!
That's why I'm still trying to get this up and running (and we thank
you for your help)!

> Are both ends of the PPP connection byte-stuffing XON/XOFF characters?  Does
> the modem *really* not respond to XON/XOFF characters if pacing is disabled?

The LCP character map has always got the value A0000 on the DS90M,
I don't know how this can be set/checked on a Win95 PC, but in the
PPPLOG.TXT -file on the PC I see a "date time LCP : received and accepted ACCM
of A0000": I suppose this means LCP char. map set to A0000???
B.t.w.: if 'you' tested ppp using XON/XOFF flow control, did you do something  
        more than modifying flow-control from hardware (RTS/CTS) to software
        (XON/XOFF) in the 'advanced connection settings' of the modem 'you'	
        selected in dial-up networking??
Yes, when modem is configured for pacing disabled, an XON or XOFF character,
coming form computer/terminal is treated as 'normal' data by the modem...
(info found on Multitech Web-site)
    
> Have you done a SHOW PORT STATUS command?
    
Yes, I was 'continuously' monitoring the state of the DS90M-port but never
saw this one XOFFed when using flow-control XON, even NOT when telnet
'hangs' (as opposed to DS700, configured with RTS/CTS: there I saw the output
 being XOFFed from time to time...)...

Regards,
    
Patrick
    
    
    

 

Hi Jim,

Some more info:

When the PPP-connection is established (flow control XON on whole path),
this is the output of a SHOW PORT x LCP STAT:

Port  6: pvl                           Server: DS7COMMS

LCP Status:

State:                    Opened
Negotiation Time:     0 00:00:09
Since Open:           0 00:02:05
Failure Reason:             None
Authentication:          Initial

LCP Options:              Local:             Remote:

MRU:                        1500                1500
Character Map:             A0000               A0000
Authentication:         Disabled            Disabled
Link Quality:           Disabled            Disabled
Magic Number:           Disabled             Enabled
PF  Compress:           Disabled             Enabled
ACF Compress:           Disabled             Enabled
FCS Size:                 16 Bit              16 Bit
Callback:               Disabled            Disabled


==> Char map on remote is A0000 ==> XON/XOFF byte-stuffed by Win95PC??

I get exactly the same output when modifying Flow-control on
Win95PC + it's modem to RTS/CTS ==> char map on both sides still A0000,
this should be working too?
... but TELNET still 'hangs' after a few seconds, sometimes
I can't even get the hosts-login prompt ...

But what DOES work: on DS700 + its modem: flowcontrol RTS/CTS,
on Win95 + its modem: flowcontrol XON/XOFF...
(SHOW PORT x LCP STAT gives same output: char map: both A0000).

What I noticed too: when telnet session hangs and I 'disconnect' my
Win95 dial-up networking session, the Multitech-modem attached to the
DECserver does NOT hang up immediately but does so after about 30 sec...
==> because comm between 2 modems screwed-up??

Hope this info rings a bell??

Regards,

Patrick

> I don't know how this can be set/checked on a Win95 PC

I don't know for sure, but I suspect if you click on the "Use software flow
control" box in one of the modem setup screens, it'll do the right thing.

> PPPLOG.TXT -file on the PC I see a "date time LCP : received and accepted ACCM
> of A0000": I suppose this means LCP char. map set to A0000???

It means the PC set its *received* character map to that value.  PPP uses
two different maps:  one for the transmitter and one for the receiver.
Most times, the two maps are the same but they don't have to be.

> B.t.w.: if 'you' tested ppp using XON/XOFF flow control, did you do something  
>         more than modifying flow-control from hardware (RTS/CTS) to software
>         (XON/XOFF) in the 'advanced connection settings' of the modem 'you'	
>         selected in dial-up networking??

Yes, much more.

> Yes, I was 'continuously' monitoring the state of the DS90M-port but never
> saw this one XOFFed when using flow-control XON, even NOT when telnet
> 'hangs' (as opposed to DS700, configured with RTS/CTS: there I saw the output
>  being XOFFed from time to time...)...

If you were "using flow-control XON", I would have expected you to occasionally
see the port in the XOFFed state.  If you were using RTS/CTS, you might have
seen the port in the "XOFFed" state even though it was really using hardware
signals instead of XON/XOFF characters....  yeah, the display might be a little
misleading.

Jim

> I get exactly the same output when modifying Flow-control on
> Win95PC + it's modem to RTS/CTS ==> char map on both sides still A0000,
> this should be working too?

Yes.  The character map simply says which characters should be byte-stuffed.
Using RTS/CTS flow control eliminates the need to byte stuff...  but if it's
still done it shouldn't cause a problem.

Different methods of flow control can be used between the DECserver and its
modem vs. the PC and its modem, provided XON/XOFF characters are properly
byte-stuffed.

> What I noticed too: when telnet session hangs and I 'disconnect' my
> Win95 dial-up networking session, the Multitech-modem attached to the
> DECserver does NOT hang up immediately but does so after about 30 sec...
> ==> because comm between 2 modems screwed-up??

The way it's *supposed* to work is that both modems monitor the CD (carrier
detect) signal.  This signal is dropped when one of the modems no longer
"hears" the other modem.  When CD drops, the modem should be set up to drop
the DSR (Data Set Ready) signal.  When the DECserver sees DSR drop, it should
be set up to log out the port ("Local> DEFINE PORT x DSRLOGOUT ENABLED").

I think something isn't properly configured in your setup, or your Multitech
modem is not responding in a way the DECserver expects it to.

Jim

Hi Jim,

Thanks again for your time!

.10> PPPLOG.TXT -file on the PC I see a "date time LCP : received and accepted ACCM
.10> of A0000": I suppose this means LCP char. map set to A0000???

.11>It means the PC set its *received* character map to that value.  PPP uses
.11>two different maps:  one for the transmitter and one for the receiver.
.11>Most times, the two maps are the same but they don't have to be.

LOCAL> SHOW PORT x LCP STAT

LCP Options:              Local:             Remote:

Character Map:             A0000               A0000

==> What do those values mean for Local: and Remote: ?
    Remote means: PPP char map sent by Win95PC??

.12> The way it's *supposed* to work is that both modems monitor the CD (carrier
.12> detect) signal.  This signal is dropped when one of the modems no longer
.12> "hears" the other modem.  When CD drops, the modem should be set up to drop
.12> the DSR (Data Set Ready) signal.  When the DECserver sees DSR drop, it should
.12> be set up to log out the port ("Local> DEFINE PORT x DSRLOGOUT ENABLED").
.12> 

On the Multitech: the "Carrier Loss Disconnect Delay Time, S10-register" is 
set to 700 msec (default value) ==> seems to work in "normal" conditions 
(e.g. when using PPP with RTS/CTS-flow control) but obviously FAILS when 
"session hangs" (using ppp with XON/XOFF) ==> (DSRLOGOUT -setting on DS DOES 
work IF modem drops DSR but Multitech does only so after about 30 sec(!) in
this case (CD-led remains on until then) so some condition (XOFF to DECserver
no handled properly??) prevents Multitech to 'act normally'. 

.12> I think something isn't properly configured in your setup, or your Multitech
.12> modem is not responding in a way the DECserver expects it to.
.11>If you were "using flow-control XON", I would have expected you to occasionally
.11>see the port in the XOFFed state. 

My opinion: when the PC's buffer gets filled, PC sends 'XOFF' to PC_modem, 
PC-modems buffer fills up and signals the DS-modem to stop transmitting
by means of its V42 error correction mechanism ('XOFF"-char. NOT involved
as such, that's how I understand this...).  DS-modem, after having been told
to stop transmitting to PC-modem, must signal DS to stop transmitting and
so place the DS-output in 'XOFFED' state AND THIS DOES NOT HAPPEN accordig to
'Local> show port x status' ...   
As kind of flow-control used between PC & modem doesn't seem to matter,
I guess (too) that XON/XOFF -flow control between DECserver and Multitech
does NOT work as I suppose it should ...
As modem-to-modem flow control seems to work properly when RTS/CTS selected
on whole path and this is done in both cases in the same way b.m.o V42-prot.,
I suppose this is NOT causing 'my' problem...
I'll try another config (no PPP) with XON/XOFF flow control set up on both
DECserver and Multitech to see if this works... I'll try an protocol-anal
to try to see what happens (not much experience with that...)

And we go on...

Regards,

Patrick

==> What do those values mean for Local: and Remote: ?
    Remote means: PPP char map sent by Win95PC??

Basically, they mean both ends are byte-stuffing XON and XOFF characters.
You can find more information about this or any other DECserver display
by reading the DNAS Management Guide.

> this case (CD-led remains on until then) so some condition (XOFF to DECserver
> no handled properly??) prevents Multitech to 'act normally'. 

I doubt it.  Other modems work okay with XON/XOFF.

> I'll try an protocol-anal
> to try to see what happens (not much experience with that...)

If you can get your hands on one, you might want to try using a serial line
analyzer.  You'd insert this device in-line between the DECserver and the
Multitech modem, and it would display the characters actually passed between
those two devices.  However, if the SHOW PORT STATUS display says the port
is not XOFFed, I don't think you're going to see an XOFF character.

Jim

    Its just a SWAG from left field....  Couple of problems I have been
    involved with that *seem* similar turned out to be:
    (1)  insufficent memory in a router causing thrashing
    (2)  bad version of UCX - needed a couple of patches
    
    Bottom line is that the DECserver and DNAS code work great as long as
    the cable, modem, and flow control are all setup correctly.  Many hours
    of engineering and support time have been expended proving this.
    
    Randall Buck
    MCS - Network Support