Oddball Routing Issue

What kid of routing equipment is it? All you've said is that there are no firewalls. Are any of them doing NAT? Something else with a dynamic port trigger?

Where are you sniffing, on the network with the server or the network with the controller?

Can you use "show ip packet" on all the routers along the way, to see where the packets are getting lost?

I don't have access to the routers along the route, so can't debug at that level. The sniffer is on the server.

There's no NAT involved. The IPs of the server and controller are in different class C's of the same Class B within a 10 network.

I can't imagine what else would be doing port triggering. I'm told the network is wide open internally.

My next step is to sniff at the controller to see what's actually arriving, although that's going to require some coordination as there's no one on the ground there at the moment.

Mike

Barry Margol> In article

If you can ping the end-point to end-point you do not have a routing problem, you have some other type of problem. Routers don't distinguish between ping packets, TCP packets on port 21 or TCP packets on port 6000. Now if you can ping, but can't establish a connection, you could have an ACL, firewall or NAT issue.

If you have an ACL issue, the server will get back an "ICMP Destination Unreachable" message. To capture this from the server side of the connection, your capture filter must set to include ICMP messages with a destination ip address of the server and ANY source address. The source address of the ICMP message will be the ip address of router interface that drops the packet, not the address of the controller. Of course this is true ONLY if you do NOT have "no icmp destination unreachable" configured on the router that is dropping the packet.

Good info. Thanks. I'll set up the sniffer to capture ICMP messages from all sources for the server and also for the controller when I get that sniffer set up.

In order to have an ACL, firewall or NAT issue, the network would have to have hardware on it that I'm told it doesn't have.

I was hoping it was a common, simple issue, but doesn't appear to be that at this point.

Since the telnet session connects but the controller session doesn't UNTIL the instant after the telnet session connects, is there any parameter in the packet that might be set on one and cleared on the other that might cause the routing hardware to treat them differently? It's not size. Neither packet is over 100 bytes.

Again, there is no problem when the controller is on the local network.

Mike

It's obviously some kind of weird ACL problem. He can connect on port A only immediately after connecting on port B. So something about the first port is opening a hole for the second port.

Maybe there is some kind of virtual telnet or cut-trough proxy device on the path that requires authentication via telnet protocol before any other type of connection is allowed to pass trough. Do you have to authenticate while establishing telnet session or you just open tcp connection with telnet?

Regards, Igor

Not sure what you mean by 'controller.' Is it a router / cisco device ? If so, perhaps there is some form of "dynamic" / "lock and key" access-list involved ?

See:

Thanks.

There's no authentication via telnet. It's just establishing a tcp connection. No login or other credentials are required.

Mike

cijeni:

The controller is an access control system controller. It's responsible for receiving card reads from a proximity reader and sending a door unlock pulse for authorized cards, and for sending event records back to the server. It's a simple device, and it works without a hitch on the local network. The problem only arises when a connection is attempted across the WAN.

This has really got me perplexed. The transport should be fully transparent to the controller itself, which shouldn't see any difference whether the box is local or long-distance, so I don't see how it could be a controller issue. And yet, everything else is just standard hardware.

I'm suspecting it's some misconfiguration of the hardware along the way, possibly with some incorrectly implemented ACL rules. Unfortunately, I don't know enough about advanced router configuration to be able to formulate a hypothesis.

When I get this resolved, I'll post the cause of the issue.

Mike

If you have Cisco routers, you have the hardware to do ACL's, NAT and firewall.

It could be the RTT (round trip-time) is too great. Many years ago we attempted to use STUN to connect two card reader systems. When connected using a TimePlex as a serial connection it worked fine, but when we used STUN (so we could retire the TimePlex) it did not work over the WAN even though it worked fine when we had it setup in our lab. Using STUN over the WAN added too much jitter and increased the RTT to a level that the two controllers kept getting out of sync and it didn't work. You could be having a similar problem and I would contact the controllers vendor. You might need to tweak some parameters on the controller to deal with the increased RTT time.

How does that explain that the connection on the telnet port always succeeds, and then the connection on the controller service port works?

Sorry for the lack of precision in my response. You're right of course, the necessary hardware is present. Meant to say that I'm told there's no hardware configured to utilize that functionality between here and there.

Isn't there some overhead on setting up the initial connection which is reduced if there's already a connection in place between boxes? Just a guess, though -- I don't know a lot about this area.

Total latency is very low, less than 100 ms p> In article ,

See:

See:

To be sure I'm clear on the structure of the controller, there are two components to it:

1. A Lantronics thin server that acts as a Ethernet-to-RS 435 bridge.
2. An access control system controller, which connects to the Lantronics thin server through a serial port.

S> In article ,

See:

Is this the first attempt to install this device on your network or was it working efore ?

What is the Lantronics thin server model number ?

Is it running current firmware ?

This is almost exactly the same configuration we tried with our card reader system. As I stated earlier we also tried STUN using serial ports on two Cisco routers, a Lantronix Ethernet to RS-232, and an ISDN to RS-232 conversion box. None of them worked on the WAN, but they ALL worked locally. After contacting our card reader vendor, they indicated that they two systems poll each other and that the replies must be received within about 70ms. We spent about 6 months working on this problem before finally admitting defeat.

We ended up telling the physical security department that they had two choices: 1) pay for the T1 line that we had in place between the TimePlex's that was in place only to support their card reader system (about $1,000 per month), or 2) purchase a new card reader system. They choose option number

2. This does not answer the question as to why the SYN ACK is not being received, but if you end up getting that problem solved you may run into these same issues. You also might want to stick an RS-232 monitor to track RTS and CTS on both sides. It could be that CTS is not set on the remote Lantronixs device which is why it is not responding to the SYN ACK.

See: