01-24-2013 02:46 PM
I repoaced a Linksys business router with a SonicWALL TZ 215 on my network. All is well except for my HP UX server. Users telnet into the HP via ProComm. The login takes as much as 45 seconds to appear and will often fail. This is peer to peer traffic via an IP address - not a name - so I know it's not DNS related.
I have factory reset the SonicWALL and only conifgured Internet access. No firewall. No filtering. SonicWALL support says it's my network not the SonicWALL. He says telnet fails at the application level - which means switches. I do have switches and I have eliminated them by connecting the HP and a laptop directly into the SonicWALL - I have the same problem.
I have even tried a crossover cable directly to the HP box via a laptop and I still get this slow response.
I have replaced my main roeuter in the past with no problems. What could be the issue with the SonicWALL - or is this an entirely different issue?
01-24-2013 03:05 PM
I assume the long login time start after the SonicWall was installed?
Is there any way to take the SonicWall appliance out of the picture? Is it possible to connect the HP-UX server and a PC to some sort of switch so they don't go through the SonicWall?
If you can do that, and the performance improves, then you have your culprit. However, if it is still slow, then you have other issues.
01-24-2013 03:10 PM
01-24-2013 03:29 PM - edited 01-24-2013 03:32 PM
Looks like dns problem,
typically telnet is slow when dns is not responding.
so try a nslookup ipaddrofthepc
Else only tusc may help you to identify what telnetd is doing ( attached to inetd )
and may be a network trace taken on hpux ( nettl -tn all -e all -f somefile ; reproduce; nettl -tf -e all ) then read the file with wireshark.
Other common cause for such symptoms: duplicate IP, router not answering to ping done by the dead gateway detection, ....
01-24-2013 10:02 PM
The HP-UX system may be trying to do a reverse DNS lookup on the incoming connection, to map a source IP address into a DNS name in order to log where the incoming connection is coming from.
Another possibility is identd: the HP-UX system may be trying to contact the source host and query its identd for the username associated with the connection. (This is especially likely if you have tcpwrappers installed and configured in a certain way.) If there is no firewall and the source host has no identd running (e.g. because it's a Windows workstation), the HP-UX system would normally receive a TCP Reset from the source host, which would be a clue that identd is not available. Then the login would proceed normally with an imperceptibly short delay.
But with a firewall, an unexpected connection to the identd port is likely to be dropped, causing no response to the identd request at all. An identd request is a TCP connection, so it would observe the normal TCP timeouts. It follows that if the HP-UX systems leaves an incoming telnet connection hanging while it waits for response for its identd connection, by the time the identd connection times out, the telnet connection is close to timing out too.
(I once had this exact problem with a FTP service in an old HP-UX, maybe version 11.00 or 10.20. The FTP daemon insisted on making ident queries and I could not find a way to disable that feature at that time.)
Most firewalls are set up to DROP (i.e. ignore without any response at all) any connections that are not listed as allowed in the firewall rules. But for the specific case of the ident protocol (port 113/TCP), it might be beneficial to set up a REJECT rule instead (i.e. for a TCP connection, send a TCP Reset packet back to the source of the connection; for anything else, use an appropriate ICMP error packet to inform the source that the requested service is not available). If you're afraid that someone will use the REJECT rule as a vector for a denial-of-service attack, you can combine the REJECT rule with a rate-limiter rule, so that the first few connections per second will be rejected as normal, and any more will be dropped without a response.
01-25-2013 10:39 AM
The problem goes away when I connect the old Linksys router. The problem comes back when I install the SonicWALL. Even though I haven't configured it. It's pretty frustrating. I've replaced the router a couple of times before without a hitch. It may have nothing to do with the SonicWALL, but it the symptom occurs when the SonicWALL is connected - or when I connect directly to the HP UX system with a crossover or simple switch. It doesn't make any sense to me, either.
01-29-2013 01:35 PM
I have to admit I'm more of a Windows guy. What commands can I use at the telnet prompt that will give me my HP's network info - especially the DNS server setting. I put in a new DNS server last month. Possibly this is an issue?
When I do an nslookup with the HP's IP address, I get a "non-existent domain" error. I looked in my DNS server and I see no listing for the HP server. But I doubt I had one in my old DNS server, either.
02-08-2013 06:16 AM
to check if it is a dns problem in nsswitch.conf remove dns
# An example file that could be copied over to /etc/nsswitch.conf; it
# does not use any name services.
else next step use tusc -f -T "" on inetd, then reproduce,