pjh@mccc.UUCP (Pete Holsberg) (09/15/88)
I have a Trailblazer on a 3B2/400 running HDB uucp. From time to time,
a caller will get "NO ANSWER" from the system. I suspect that this is
somehow related to what happens when someone calls in and then hangs up
(rather than logging out).
I'm not sure if either problem resides in the modem, the cabling, or the
I/O port, so I'm open to suggestions for experimentation. (I have both
PORTS and EPORTS on the 3B2. Do you think that hardware handshaking
between the 'blazer and an EPORT might help?)
Thanks.
Pete Holsberg UUCP: {...!rutgers!}princeton!mccc!pjh
Technology Division ...!att!jonlab!mccc!pjh
Mercer College CompuServe: 70240,334
1200 Old Trenton Road GEnie: PJHOLSBERG
Trenton, NJ 08690 Voice: 1-609-586-4800lenny@icus.islp.ny.us (Lenny Tropiano) (09/17/88)
In article <822@mccc.UUCP> pjh@mccc.UUCP (Pete Holsberg) writes: |> |>I have a Trailblazer on a 3B2/400 running HDB uucp. From time to time, |>a caller will get "NO ANSWER" from the system. I suspect that this is |>somehow related to what happens when someone calls in and then hangs up |>(rather than logging out). |> |>I'm not sure if either problem resides in the modem, the cabling, or the |>I/O port, so I'm open to suggestions for experimentation. (I have both |>PORTS and EPORTS on the 3B2. Do you think that hardware handshaking |>between the 'blazer and an EPORT might help?) |> I don't know whether the Hardware Flow control will work, but this happens as well on my AT&T 3B1. I've heard the symptoms called the "comatose" mode on the 'Blazer. It's probably the only think that really bothers me about the modem... all in all it's a fine machine. What I've noticed is that it happens with calls terminate abnormally, either hung up or possibly some sort of long BREAK signal. It might also have to do with the XON/XOFF handshaking, the modem getting a XOFF, and never getting the paired XON. For some reason the modem doesn't reset. It will not accept commands, or for that matter incoming calls. My kludge is to kill the uugetty (which drops DTR, therefore resetting the modem) every 1/2 hour. I hope the BA4.01 ROMs fix this problem. I hope the upgrade is free as well... since there are bugs in the ROMS. -Lenny -- Paper-net: Lenny Tropiano | @-net: lenny@icus.islp.ny.us ICUS Software Systems | !-net: ...sbcs \ PO Box 1 | boulder \ Islip Terrace, NY 11752 | talcott !icus!lenny Vocal-net: (516) 582-5525 [work] | pacbell / (516) 968-8576 [home] | hombre / Telex-net: 154232428 ICUS | Another-net: attmail!icus!lenny
lyndon@ncc.Nexus.CA (Lyndon Nerenberg) (09/19/88)
In article <494@icus.islp.ny.us> lenny@icus.islp.ny.us (Lenny Tropiano) writes: >What I've noticed is that it happens with calls terminate abnormally, >either hung up or possibly some sort of long BREAK signal. It might >also have to do with the XON/XOFF handshaking, the modem getting >a XOFF, and never getting the paired XON. For some reason the modem >doesn't reset. It will not accept commands, or for that matter incoming >calls. > >My kludge is to kill the uugetty (which drops DTR, therefore resetting >the modem) every 1/2 hour. I hope the BA4.01 ROMs fix this problem. >I hope the upgrade is free as well... since there are bugs in the ROMS. There will always be bugs in the firmware... This business of free upgrades has been beaten to death before! Our cure to the lockup problem is also to kill the getty on a regular basis. This is best handled by making sure DCD is actually tracking the true carrier state, and adding "-t 120" to the {uu}getty parameter list. In this mode, the getty will recycle 120 seconds after DCD is asserted unless someone has logged in. This will drop DTR which (should) force a modem reset. [ The -t flag may not be documented in your man page, however it exists in every V7 and later getty/uugetty I've seen. BSD uses the "to" entry in gettytab. I'm not sure how 4.3 does it. ] -- VE6BBM {alberta,pyramid,uunet}!ncc!lyndon lyndon@Nexus.CA