telnet: connection refused only from HP-UX; windoze works!

[Brad Marks]

I am trying to establish a telnet connection to a phone switch (mitel 3300 icp) on port 1752. I am able to ping it from HP-UX and, in fact, am able to telnet to it from the command prompt of my windows box. But when I try from HP-UX 11.i on my rp5470, I get a connection refused error.
Why would it work for windows but not for HP-UX? Our phone switch var can't answer this question and want us to revert to pulling data from the rs-232 printer port which, I think, is ludicrous.
Any help will result in a big 'THANKS!' and points to boot!
Thanks,
Brad

[Tim Nelson]

Not that this would be an HPUX issue but...

Is there a firewall between the HPUX server(s) and the phone equipment ?

Does the phone equipment have any security settings ( i.e. restrict connectivity from IP ranges ) ?

[Brad Marks]

Tim,
No there is no firewall and, since I'm able to telnet to the phone equipment from my PC, which is in the same subnet as my HP box, IP restriction cannot be an issue.
Nonetheless, thanks for the effort!
Brad

[Tim Nelson]

how about...

Does the phone equipment do reverse lookup or ident security that could be successfull for the PC but not the HPUX server(s)

[Eric SAUBIGNAC]

Bonsoir,

"I get a connection refused error" ... This error message clearly means that a box somewhere refuses the connection. Some silly ideas ... :

HP-UX itself ? I have a very little knowledge with IPFilter (B9901AA) but is there any possibility that it could be configured on the HP-UX box itself to prevent some TCP connections ?

Routing ? Ok, you are in the same subnet : HP-UX, phone switch and windoze PC. So what about ARP ? Could you check from PC and from HP-UX that the IP of the switch resolves to the same mac address (arp -a) ? Is it possible to take a look at arp cache of the switch ?

Firewall ? "... and, since I'm able to telnet to the phone equipment from my PC, which is in the same subnet as my HP box, IP restriction cannot be an issue." IMHO it cans if the switch itself provides some basic firewalling. Your answer to Tim on this point is not clear enough.

And yes, reverse lookup is often missconfigured bye windoze dns admins ... Is you switch a DNS client ?

Hope this will help

Regards

Eric

[Brad Marks]

Guys,
The problem is that the var for the phone equipment knows no Unix and little networking. The manufacturer, who will deal *only* with the var, doesn't know Unix and doesn't care. They say "It works with Windows OS and that's good enough for us".
I am going to forward this thread to the var, but don't actually expect much forthcoming, but one never knows....
Thanks for your salient questions. I will post any resolution.
Best regards,
Brad

[Steven Schweda]

> But when I try from HP-UX 11.i on my
> rp5470, I get a connection refused error.

When you try _what_, exactly? Normally,
"connection refused" means that you've
reached the remote system, but that you're
trying to talk to a port where no one is
listening. A sufficiently clever intervening
firewall can cause the same effect.

From your detail-free description, it's hard
to say whether you're talking to the right
system on the right port. Have you tried it
by address instead of by name? How sure are
you that you're specifying the right port?

[Brad Marks]

Steven,
The command I'm using is:
telnet 172.20.131.3 1752
I am able to ping the IP and also am able to execute this exact command from my PC with success. Further, I am able to establish a telnet connection from my HP Unix server on port 23; I get a 'login:' prompt.
My PC and HP server are both on the same subnet, and I've been told by our network administrator that there is no firewall involved.

I think I should also mention that while the HP server's IP address is 139.64.100.1 and the phone equipment's IP address is 172.20.131.3, I have attached the routing table entries for both my HP box and my PC.

Thanks,
Brad

[Brad Marks]

All,
I seem to have given some misleading information: The error is not 'Connection Refused' but is 'Unable to connect to remote host: Connection timed out'

Sorry about that, I've been dealing with a different problem involving refused connections.

I'm sure this makes a difference. Again, sorry 'bout that!

Brad

[Steven Schweda]

> I seem to have given some misleading
> information [...]

This is what makes copy+paste so useful.
(And you needed a 40KB Word document for a
smidge of text?)

> I am able to ping the IP and also am able
> to execute this exact command from my PC
> with success.

Ok. And what is the PC's IP address?

> Further, I am able to establish a telnet
> connection from my HP Unix server on port
> 23; I get a 'login:' prompt.

That's port 23 of the Mitel gizmo, right?

If you can connect to one port on the device,
then it would seem that the routing and DNS
stuff can't be too bad. Not knowing all the
IP addresses involved, I can only guess that
the Windows system is on a different subnet,
and that the Mitel gizmo restricts access to
its port 1752 in some way (unknown to me).

"Connection timed out" could mean many
things, but we seem to have eliminated
routing, and all other generic comm problems,
so I'm left suspecting an uncooperative
attitude at the Mitel end.

[Brad Marks]

Steve,
The PCs IP address is 139.64.104.9. Yeah, on the same subnet!

>I'm left suspecting an uncooperative
>attitude at the Mitel end.

Unfortunately, no truer words spoken.

I guess I'm just gonna bite the bullet and get what info I need via an rs-232 connection to the Mitel's printer port. This seems an arcane means of getting data from a device with an Ethernet card, but I can't say I (and we, thanks) didn't try.

Thanks to all,
Brad

[Steven E. Protter]

Shalom,

Of importance here to see if HP-UX is he problem is whether there is any evidence of a connection in the logs of the HP-UX system.

tail -f /var/adm/syslog/syslog.log

Try a connect. You should see something there.

If not, the problem is outside the HP-UX system.

SEP

[Steven Schweda]

Of course, I know nothing, but, according to:

http://www.vocaletraining.com/mitel/attachments/MitelPortsDoc.htm

regarding port 1752:

Provides view of SMDR records as they
generated. This connection is not
interactive and no username/password is
required Access to this port could be
restricted to the management VLAN.


So, what, exactly, happens when you do
whatever you do from the Windows system? I
don't use exotic Telnet commands from
Windows. Is it really talking to port 1752?

[Brad Marks]

SEP: Nothing is going to the syslog. I'm feeling awfully certain that the problem lies in the Mitel device. -- Thanks!

Steven,
Good find. I will look into finding out what the 'management VLAN' is.

What happens when I issue the not-so-exotic telnet command "telnet 172.20.131.3 1752" on my PC, is phone call data spews by on the screen. I want to capture this data.

In the past, I have gotten this data from our old (read non-Ethernet) Mitel device by having my application establish an connection to its rs-232 printer port via a DTC. Our phone switch VAR stated that the same data comes out of port 1752 and I *should* be able to get it form there, thus eliminating the need for a DTC. Just in case, a DTC is a terminal server (Ethernet to rs-232).

Thanks,
Brad

[Steven Schweda]

> What happens when I issue the not-so-exotic
> telnet command "telnet 172.20.131.3 1752"
> on my PC, is phone call data spews by on
> the screen. [...]

That sure sounds like what's supposed to
happen. It's not obvious to me why the HP-UX
system would not be able to achieve the same
result. You did claim that you could Telnet
to the thing on port 23 from the HP-UX
system, right? You're not trying to connect
a second time to a port which may be able to
handle only one connection, I trust. (That
is, the session from the Windows system is
closed when you're trying to connect from the
HP-UX system, right?)

The Telnet protocol does include some fine
print involving flow control and the like,
but I'd assume that you'd need some unusual
stty settings to get into trouble that way.

Sounds like a mystery.

[Brad Marks]

A mystery it is.
Oh well, on to more important tasks!
-Brad