UNIX to UNIX dialup(hangup) problem

[jlasman]

I am having peculiar dialup difficulties between home and the office. Home is 5.0.5 and the
office is 5.0.0. Specifically the problem is when dialing from home to the office. Both systems
can dial other systems without incident. I can dial from the office to home without incident.
Both of these systems are on 24 hrs.

This is something that has worked fine for several years. Sometime last fall, it started that
when I called the office from home, it would connect OK the the session proceeds normally;
however, when I issue ^D or exit to disconnect, the modem escape would display on the screen
rather than disconnect. A second ^D would cause the escape sequence to display again. It would
usually be a delay of 30-45 seconds after the ^D befor the modem escape delayed. Once in a while,
though, it would disconnect normally. I would eventually force a hangup.

The behavior looks like "stty -hupcl" although stty -a says that "hupcl" is set. Frankly, whatever
is going on, I don't think it is in "devices" or "inittab". About the time this started, maybe
coincidental, maybe not, the kernel was relinked at the office to set up IP address for an ADSL
connection.

Just in the last few days I have discovered that when I leave the office in the evening and all
users are logged out, any subsequent logins from home have difficulting disconnecting. NOW if I
leave a user logged in at the console subsequent logins from home disconnect just fine. BTW the
connections are to /dev/tty2A. No multiport boards on either system. US Robortics sportster modems.
I have swapped serial card and modems between home and office and saw no change.

It doesn't seem to me that the existence of a login should have anything to do with the modem port,
but that is where I stand.

Any thoughts?



Jim Asman
jlasman@telus.net

 

[edfair]

How do you connect? From a user using profile or from command line as user or root?

Ed Fair
Any advice I give is my best judgement based on my interpretation of the facts you supply. Help increase my knowledge by providing some feedback, good or bad, on any advice I have given.

 

[jlasman]

I use JP Radley's XC program from a command line and
login as root when the login prompt appears. Pretty
much a vanilla setup.

BTW, I have the same problem with cu. I even resurrected
an old 3.2.4 box at home to get similar results.

Thanks


Jim Asman
jlasman@telus.net

 

[edfair]

Pins it to the host. Which we both knew anyhow. What gettydef entry?

For some similar problems on 4.2 I ended up modifying gettdef tokens 1, 2, and 3 to point back to themselves rather than rotating and set the baud rate on the one token I used to what I needed. I remember there was some small , otherwise insignificant difference, between the modem entry and the terminal entry. But I can't remember the details.

CU uses the ACU in Devices and that links to an entry in Dialers. What dialer are you using?
For all my USR modems I use the hayes2400 entry from Dialers rather than the compiled HA24 version. But most of my stuff is 4.2 and the 5.0.x I support has other modem equipment.

Have lost contact with JPR since compuserve diddled with the SCO forum. One really smart guy.

Ed Fair
Any advice I give is my best judgement based on my interpretation of the facts you supply. Help increase my knowledge by providing some feedback, good or bad, on any advice I have given.

 

[jlasman]

This is the current gettydef, although I have tried all sorts of variations.

p # B38400 HUPCL # B38400 CS8 SANE HUPCL TAB3 RTSFLOW CTSFLOW -IXON -IXOFF -IXANY #\r\nlogin: # p

I think I am using a dialer I got off CIS Unixforum back
then that was part of a bundle of USR --> uucp etc. stuff.
Again all these files were untouched for 5 years.

A friend floated a theory that it may be some kind of permissions problem on the port. While cron has been directly enabling the port, I am trying tonight to have cron run a script that first opens the permissions before it enables the port.

In 100% of the cases where I had a console tty logged in the modems have disconnected with a ^D. Another variation on this might be that it is only necessary for a login to exist when the port is enabled. I will try that tomorrow night.

JP is still going strong. Your vocabulary will grow if you read his postings, and certainly his opinions are not to be taken lightly. Try

http://www.jpr.com

Jim Asman
jlasman@telus.net

 

[apeasecpc]

I presume you have verified that you are using the modem control device name.

Have you checked the configuration of the modem itself? It is possible to configure a modem to ignore carrier and dtr drops and remain connected. If you have a &C0 or &D0 in your initialization string, or those settings have somehow been saved to your modem's NVRAM that could be the cause of your problem.

Back under 5.0.0 I believed I used "ATE1Q0V1M0S0=0S2=128&U0&N0" to initialize for dialout and "ATE0Q1V0M1S0=1S2=128&U0&N0Y0&W0" for dialin for my US Robotics (3Com) Sportster modems, set up using atdialer.

 

[jlasman]

Yes, it is tty2A. Besides, it hooks up just fine.

It is set &C1 &D2. When this started the relevant
modem and tty files were all dated 1998 so I'm really
expecting that the answer lies in those files.

Further, I swapped the modems & cables between the office
and home and saw no change in behavior. It's quite beyond
me why the existence of a console login would have any affect
on serial comms.

This may be one of those things that I will either fumble my
way to a solution or I will never understand it.

Thanks.

Jim Asman
jlasman@telus.net

 

[jlasman]

I should have said that I'm NOT expecting a solution in
editing the modem & tty files.


Jim Asman
jlasman@telus.net

 

[apeasecpc]

I agree that being logged in on the consol should not effect the modems, which I think that appearance is coincidental. Configuring DSL and relinking the kernel also should not have effected it. Have you done a system and software verification from the software manager? Maybe some of the code that goes through the link process has been corrupted. I assume you have the latest patches installed.

I'm just throwing out ideas because I'm just as confused as you are.

 

[edfair]

Remember one battle with &D2 and needed &D3 but not certain which USR Sportster it was. Some don't have it.
And another battle with a gettydef token that was past some problem in the file. Resolved the problem after I diagnosed it by using a token higher in the chain.
And another that was resolved by putting a sleep 2 at the tail of the inittab file.

I'm also grabbing at the proverbial straw. Not so much for a solution but for a way to diagnose.

Ed Fair
Any advice I give is my best judgement based on my interpretation of the facts you supply. Help increase my knowledge by providing some feedback, good or bad, on any advice I have given.

 

[jlasman]

One thing that I haven't mentioned is that the port is being enabled via cron. I'm going to test this tonight, but I am thinkingg that it is necessary to only have a console user logged in when the modem port is enabled. It's a rather lomg winded affair when you don't have someone sitting at both ends, and you can only really test one thing per evening.

The other thing is that uucp seems to disconnect OK. Maybe
uucp disconnects from the calling end, I don't know. I normally initiate the uucp transfers from home(cron).



Jim Asman
jlasman@telus.net

 

[edfair]

An exit is an exit. And it should work the same logged in from a DOS box and a UNIX box.
If you would set up a user on the office for remote access (to shell only so I could exit) I would be happy to dial in with you present to see what the modem does on exit.
If you're interested I'm unixstuff@bellsouth.net and working in edt zone. And give an office number for voice co-ordination.

Ed Fair
Any advice I give is my best judgement based on my interpretation of the facts you supply. Help increase my knowledge by providing some feedback, good or bad, on any advice I have given.

 

[PHV]

The entries for serial ports in /etc/inittab have been probably rebuilt with the content of the /etc/conf/init.d/sio file when the office kernel was rebuilt.

Hope This Help
PH.

 

[jlasman]

I've been through inittab and the init.d/sio files and they
both are OK, and as I said the session itself is OK, it's
only the hangup hangs.

There is a 100% positive correlation that when a console user is left logged on, the hangup performs perfectly.
It's strange.



Jim Asman
jlasman@telus.net

 

[apeasecpc]

What commands are you using in your cron to enable the port?

Are you using the cron of user "root" or a different user with less permissions?

What about the system/software verification I suggested earlier? If you have missing symbolic links you could be looking at a case where /etc/gettydefs is correct but the system file it is supposed to be linked to isn't.

Can it be any consol user (i.e. root) for the hangup to work, or does it need to be the same user as is trying to connect, or at least someone with the same group memberships?

 

[jlasman]

I ran the software verification. A handful of discrepencies were fixed, but it didn't change the modem hangup issue.

I am using the cron of user "root".

The command is simply ... enable tty2A 1>/dev/null

I have only ever tried it with a "root" login left
running. I will leave another user logged on tonight.

You have given me some ideas of things to experiment with,
and I'll work on them next week.

Thanks,


Jim Asman
jlasman@telus.net

 

[jlasman]

I tried leaving only the user "jim" logged in, and when
I logged in as "jim" the modem would disconnect without
incident, BUT if I logged in a "root" I could NOT disconnect.

The I added a root login on the office machine, leaving jim logged on as well. At that point BOTH jim and root could disconnect normally.

In the mix, I have swapped the office modem with a different third modem. No change.



Jim Asman
jlasman@telus.net