Oddball Routing Issue

Discussion in 'Cisco' started by secpgmr, Dec 28, 2007.

  1. secpgmr

    secpgmr Guest

    I have an oddball connection issue that appears to be related to the
    routing equipment between the two end points.

    I have a server trying to connect to an access control system
    controller across the country over a WAN. When I sniff the
    connection
    between the server and the controller, I see a sequence of SYN
    packets
    to the controller service port (> 2000 < 4000) on the controller with
    no SYN ACK from
    the controller.

    However, if I open a telnet session to the controller on the port
    where telnet is listening on the controller (> 8000), suddenly the
    server gets
    a SYN ACK on the controller service port and the controller comes
    online.

    If I break the connection on the controller service port and try to
    re-
    establish it, I just get a sequence of SYN packets with no SYN ACK
    until I open another telnet session again.

    Seems the telnet session is establishing some kind of state that is
    needed for the connection to occur that cannot be created on the
    controller service port for some reason.

    The controller connects perfectly on the local network. The problem
    only occurs over the WAN. There are no firewalls between the two end
    points.

    Any thoughts?

    Mike
     
    secpgmr, Dec 28, 2007
    #1
    1. Advertising

  2. In article
    <>,
    secpgmr <> wrote:

    > I have an oddball connection issue that appears to be related to the
    > routing equipment between the two end points.


    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?

    >
    > I have a server trying to connect to an access control system
    > controller across the country over a WAN. When I sniff the
    > connection
    > between the server and the controller, I see a sequence of SYN
    > packets
    > to the controller service port (> 2000 < 4000) on the controller with
    > no SYN ACK from
    > the controller.
    >
    > However, if I open a telnet session to the controller on the port
    > where telnet is listening on the controller (> 8000), suddenly the
    > server gets
    > a SYN ACK on the controller service port and the controller comes
    > online.


    Where are you sniffing, on the network with the server or the network
    with the controller?
    >
    > If I break the connection on the controller service port and try to
    > re-
    > establish it, I just get a sequence of SYN packets with no SYN ACK
    > until I open another telnet session again.
    >
    > Seems the telnet session is establishing some kind of state that is
    > needed for the connection to occur that cannot be created on the
    > controller service port for some reason.
    >
    > The controller connects perfectly on the local network. The problem
    > only occurs over the WAN. There are no firewalls between the two end
    > points.


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

    --
    Barry Margolin,
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***
     
    Barry Margolin, Dec 28, 2007
    #2
    1. Advertising

  3. secpgmr

    secpgmr Guest

    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 Margolin wrote:
    > In article
    > <>,
    > secpgmr <> wrote:
    >
    > > I have an oddball connection issue that appears to be related to the
    > > routing equipment between the two end points.

    >
    > 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?
    >
    > >
    > > I have a server trying to connect to an access control system
    > > controller across the country over a WAN. When I sniff the
    > > connection
    > > between the server and the controller, I see a sequence of SYN
    > > packets
    > > to the controller service port (> 2000 < 4000) on the controller with
    > > no SYN ACK from
    > > the controller.
    > >
    > > However, if I open a telnet session to the controller on the port
    > > where telnet is listening on the controller (> 8000), suddenly the
    > > server gets
    > > a SYN ACK on the controller service port and the controller comes
    > > online.

    >
    > Where are you sniffing, on the network with the server or the network
    > with the controller?
    > >
    > > If I break the connection on the controller service port and try to
    > > re-
    > > establish it, I just get a sequence of SYN packets with no SYN ACK
    > > until I open another telnet session again.
    > >
    > > Seems the telnet session is establishing some kind of state that is
    > > needed for the connection to occur that cannot be created on the
    > > controller service port for some reason.
    > >
    > > The controller connects perfectly on the local network. The problem
    > > only occurs over the WAN. There are no firewalls between the two end
    > > points.

    >
    > Can you use "show ip packet" on all the routers along the way, to see
    > where the packets are getting lost?
    >
    > --
    > Barry Margolin,
    > Arlington, MA
    > *** PLEASE post questions in newsgroups, not directly to me ***
    > *** PLEASE don't copy me on replies, I'll read them in the group ***
     
    secpgmr, Dec 28, 2007
    #3
  4. secpgmr

    Thrill5 Guest

    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.

    "secpgmr" <> wrote in message
    news:...
    >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 Margolin wrote:
    >> In article
    >> <>,
    >> secpgmr <> wrote:
    >>
    >> > I have an oddball connection issue that appears to be related to the
    >> > routing equipment between the two end points.

    >>
    >> 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?
    >>
    >> >
    >> > I have a server trying to connect to an access control system
    >> > controller across the country over a WAN. When I sniff the
    >> > connection
    >> > between the server and the controller, I see a sequence of SYN
    >> > packets
    >> > to the controller service port (> 2000 < 4000) on the controller with
    >> > no SYN ACK from
    >> > the controller.
    >> >
    >> > However, if I open a telnet session to the controller on the port
    >> > where telnet is listening on the controller (> 8000), suddenly the
    >> > server gets
    >> > a SYN ACK on the controller service port and the controller comes
    >> > online.

    >>
    >> Where are you sniffing, on the network with the server or the network
    >> with the controller?
    >> >
    >> > If I break the connection on the controller service port and try to
    >> > re-
    >> > establish it, I just get a sequence of SYN packets with no SYN ACK
    >> > until I open another telnet session again.
    >> >
    >> > Seems the telnet session is establishing some kind of state that is
    >> > needed for the connection to occur that cannot be created on the
    >> > controller service port for some reason.
    >> >
    >> > The controller connects perfectly on the local network. The problem
    >> > only occurs over the WAN. There are no firewalls between the two end
    >> > points.

    >>
    >> Can you use "show ip packet" on all the routers along the way, to see
    >> where the packets are getting lost?
    >>
    >> --
    >> Barry Margolin,
    >> Arlington, MA
    >> *** PLEASE post questions in newsgroups, not directly to me ***
    >> *** PLEASE don't copy me on replies, I'll read them in the group ***
     
    Thrill5, Dec 28, 2007
    #4
  5. secpgmr

    secpgmr Guest

    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

    On Dec 27, 7:36 pm, "Thrill5" <> wrote:
    > 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.
    >
    > "secpgmr" <> wrote in message
    >
    > news:...
    >
    > >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 Margolin wrote:
    > >> In article
    > >> <>,
    > >> secpgmr <> wrote:

    >
    > >> > I have an oddball connection issue that appears to be related to the
    > >> > routing equipment between the two end points.

    >
    > >> 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?

    >
    > >> > I have a server trying to connect to an access control system
    > >> > controller across the country over a WAN. When I sniff the
    > >> > connection
    > >> > between the server and the controller, I see a sequence of SYN
    > >> > packets
    > >> > to the controller service port (> 2000 < 4000) on the controller with
    > >> > no SYN ACK from
    > >> > the controller.

    >
    > >> > However, if I open a telnet session to the controller on the port
    > >> > where telnet is listening on the controller (> 8000), suddenly the
    > >> > server gets
    > >> > a SYN ACK on the controller service port and the controller comes
    > >> > online.

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

    >
    > >> > If I break the connection on the controller service port and try to
    > >> > re-
    > >> > establish it, I just get a sequence of SYN packets with no SYN ACK
    > >> > until I open another telnet session again.

    >
    > >> > Seems the telnet session is establishing some kind of state that is
    > >> > needed for the connection to occur that cannot be created on the
    > >> > controller service port for some reason.

    >
    > >> > The controller connects perfectly on the local network. The problem
    > >> > only occurs over the WAN. There are no firewalls between the two end
    > >> > points.

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

    >
    > >> --
    > >> Barry Margolin,
    > >> Arlington, MA
    > >> *** PLEASE post questions in newsgroups, not directly to me ***
    > >> *** PLEASE don't copy me on replies, I'll read them in the group ***
     
    secpgmr, Dec 28, 2007
    #5
  6. In article <>,
    "Thrill5" <> wrote:

    > 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.


    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.

    --
    Barry Margolin,
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***
     
    Barry Margolin, Dec 29, 2007
    #6
  7. secpgmr

    Pseto Guest

    "secpgmr" <> wrote in message
    news:...
    >I have an oddball connection issue that appears to be related to the
    > routing equipment between the two end points.
    >
    > I have a server trying to connect to an access control system
    > controller across the country over a WAN. When I sniff the
    > connection
    > between the server and the controller, I see a sequence of SYN
    > packets
    > to the controller service port (> 2000 < 4000) on the controller with
    > no SYN ACK from
    > the controller.
    >
    > However, if I open a telnet session to the controller on the port
    > where telnet is listening on the controller (> 8000), suddenly the
    > server gets
    > a SYN ACK on the controller service port and the controller comes
    > online.
    >
    > If I break the connection on the controller service port and try to
    > re-
    > establish it, I just get a sequence of SYN packets with no SYN ACK
    > until I open another telnet session again.
    >
    > Seems the telnet session is establishing some kind of state that is
    > needed for the connection to occur that cannot be created on the
    > controller service port for some reason.
    >
    > The controller connects perfectly on the local network. The problem
    > only occurs over the WAN. There are no firewalls between the two end
    > points.
    >
    > Any thoughts?
    >
    > Mike
    >
    >
    >


    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



    --
    P: Dainese FMX hlace po nepopularnoj cijeni:
    http://www.dainese.com/eng/articolo.asp?cat=6&nome=FMX_PANTS&articolo=3769173
     
    Pseto, Dec 29, 2007
    #7
  8. secpgmr

    John Agosta Guest

    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:
    http://www.cisco.com/en/US/products..._guide_chapter09186a00804fde51.html#wp1000917

    Either way, please let us know what the problem & resolution was!

    Thanks.


    "secpgmr" <> wrote in message
    news:...
    >I have an oddball connection issue that appears to be related to the
    > routing equipment between the two end points.
    >
    > I have a server trying to connect to an access control system
    > controller across the country over a WAN. When I sniff the
    > connection
    > between the server and the controller, I see a sequence of SYN
    > packets
    > to the controller service port (> 2000 < 4000) on the controller with
    > no SYN ACK from
    > the controller.
    >
    > However, if I open a telnet session to the controller on the port
    > where telnet is listening on the controller (> 8000), suddenly the
    > server gets
    > a SYN ACK on the controller service port and the controller comes
    > online.
    >
    > If I break the connection on the controller service port and try to
    > re-
    > establish it, I just get a sequence of SYN packets with no SYN ACK
    > until I open another telnet session again.
    >
    > Seems the telnet session is establishing some kind of state that is
    > needed for the connection to occur that cannot be created on the
    > controller service port for some reason.
    >
    > The controller connects perfectly on the local network. The problem
    > only occurs over the WAN. There are no firewalls between the two end
    > points.
    >
    > Any thoughts?
    >
    > Mike
    >
    >
    >
     
    John Agosta, Dec 29, 2007
    #8
  9. secpgmr

    secpgmr Guest

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

    Mike

    On Dec 29, 10:11 am, "Pseto" <> wrote:
    > "secpgmr" <> wrote in message
    >
    > news:...
    >
    >
    >
    > >I have an oddball connection issue that appears to be related to the
    > > routing equipment between the two end points.

    >
    > > I have a server trying to connect to an access control system
    > > controller across the country over a WAN. When I sniff the
    > > connection
    > > between the server and the controller, I see a sequence of SYN
    > > packets
    > > to the controller service port (> 2000 < 4000) on the controller with
    > > no SYN ACK from
    > > the controller.

    >
    > > However, if I open a telnet session to the controller on the port
    > > where telnet is listening on the controller (> 8000), suddenly the
    > > server gets
    > > a SYN ACK on the controller service port and the controller comes
    > > online.

    >
    > > If I break the connection on the controller service port and try to
    > > re-
    > > establish it, I just get a sequence of SYN packets with no SYN ACK
    > > until I open another telnet session again.

    >
    > > Seems the telnet session is establishing some kind of state that is
    > > needed for the connection to occur that cannot be created on the
    > > controller service port for some reason.

    >
    > > The controller connects perfectly on the local network. The problem
    > > only occurs over the WAN. There are no firewalls between the two end
    > > points.

    >
    > > Any thoughts?

    >
    > > Mike

    >
    > 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
    >
    > --
    > P: Dainese FMX hlace po nepopularnoj cijeni:http://www.dainese.com/eng/articolo.asp?cat=6&nome=FMX_PANTS&articolo...
     
    secpgmr, Dec 30, 2007
    #9
  10. secpgmr

    secpgmr Guest

    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

    On Dec 29, 12:00 pm, "John Agosta" <> wrote:
    > 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:http://www.cisco.com/en/US/products/ps6350/products_configuration_gui...
    >
    > Either way, please let us know what the problem & resolution was!
    >
    > Thanks.
    >
    > "secpgmr" <> wrote in message
    >
    > news:...
    >
    > >I have an oddball connection issue that appears to be related to the
    > > routing equipment between the two end points.

    >
    > > I have a server trying to connect to an access control system
    > > controller across the country over a WAN. When I sniff the
    > > connection
    > > between the server and the controller, I see a sequence of SYN
    > > packets
    > > to the controller service port (> 2000 < 4000) on the controller with
    > > no SYN ACK from
    > > the controller.

    >
    > > However, if I open a telnet session to the controller on the port
    > > where telnet is listening on the controller (> 8000), suddenly the
    > > server gets
    > > a SYN ACK on the controller service port and the controller comes
    > > online.

    >
    > > If I break the connection on the controller service port and try to
    > > re-
    > > establish it, I just get a sequence of SYN packets with no SYN ACK
    > > until I open another telnet session again.

    >
    > > Seems the telnet session is establishing some kind of state that is
    > > needed for the connection to occur that cannot be created on the
    > > controller service port for some reason.

    >
    > > The controller connects perfectly on the local network. The problem
    > > only occurs over the WAN. There are no firewalls between the two end
    > > points.

    >
    > > Any thoughts?

    >
    > > Mike
     
    secpgmr, Dec 30, 2007
    #10
  11. secpgmr

    Thrill5 Guest

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


    "secpgmr" <> wrote in message
    news:...
    > 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
    >
    > On Dec 27, 7:36 pm, "Thrill5" <> wrote:
    >> 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.
    >>
    >> "secpgmr" <> wrote in message
    >>
    >> news:...
    >>
    >> >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 Margolin wrote:
    >> >> In article
    >> >> <>,
    >> >> secpgmr <> wrote:

    >>
    >> >> > I have an oddball connection issue that appears to be related to the
    >> >> > routing equipment between the two end points.

    >>
    >> >> 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?

    >>
    >> >> > I have a server trying to connect to an access control system
    >> >> > controller across the country over a WAN. When I sniff the
    >> >> > connection
    >> >> > between the server and the controller, I see a sequence of SYN
    >> >> > packets
    >> >> > to the controller service port (> 2000 < 4000) on the controller
    >> >> > with
    >> >> > no SYN ACK from
    >> >> > the controller.

    >>
    >> >> > However, if I open a telnet session to the controller on the port
    >> >> > where telnet is listening on the controller (> 8000), suddenly the
    >> >> > server gets
    >> >> > a SYN ACK on the controller service port and the controller comes
    >> >> > online.

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

    >>
    >> >> > If I break the connection on the controller service port and try to
    >> >> > re-
    >> >> > establish it, I just get a sequence of SYN packets with no SYN ACK
    >> >> > until I open another telnet session again.

    >>
    >> >> > Seems the telnet session is establishing some kind of state that is
    >> >> > needed for the connection to occur that cannot be created on the
    >> >> > controller service port for some reason.

    >>
    >> >> > The controller connects perfectly on the local network. The problem
    >> >> > only occurs over the WAN. There are no firewalls between the two
    >> >> > end
    >> >> > points.

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

    >>
    >> >> --
    >> >> Barry Margolin,
    >> >> Arlington, MA
    >> >> *** PLEASE post questions in newsgroups, not directly to me ***
    >> >> *** PLEASE don't copy me on replies, I'll read them in the group ***

    >
     
    Thrill5, Jan 1, 2008
    #11
  12. secpgmr

    Thrill5 Guest

    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.

    "secpgmr" <> wrote in message
    news:...
    > 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
    >
    > On Dec 29, 12:00 pm, "John Agosta" <> wrote:
    >> 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:http://www.cisco.com/en/US/products/ps6350/products_configuration_gui...
    >>
    >> Either way, please let us know what the problem & resolution was!
    >>
    >> Thanks.
    >>
    >> "secpgmr" <> wrote in message
    >>
    >> news:...
    >>
    >> >I have an oddball connection issue that appears to be related to the
    >> > routing equipment between the two end points.

    >>
    >> > I have a server trying to connect to an access control system
    >> > controller across the country over a WAN. When I sniff the
    >> > connection
    >> > between the server and the controller, I see a sequence of SYN
    >> > packets
    >> > to the controller service port (> 2000 < 4000) on the controller with
    >> > no SYN ACK from
    >> > the controller.

    >>
    >> > However, if I open a telnet session to the controller on the port
    >> > where telnet is listening on the controller (> 8000), suddenly the
    >> > server gets
    >> > a SYN ACK on the controller service port and the controller comes
    >> > online.

    >>
    >> > If I break the connection on the controller service port and try to
    >> > re-
    >> > establish it, I just get a sequence of SYN packets with no SYN ACK
    >> > until I open another telnet session again.

    >>
    >> > Seems the telnet session is establishing some kind of state that is
    >> > needed for the connection to occur that cannot be created on the
    >> > controller service port for some reason.

    >>
    >> > The controller connects perfectly on the local network. The problem
    >> > only occurs over the WAN. There are no firewalls between the two end
    >> > points.

    >>
    >> > Any thoughts?

    >>
    >> > Mike

    >
     
    Thrill5, Jan 1, 2008
    #12
  13. In article <>,
    "Thrill5" <> wrote:

    > 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?

    >
    > "secpgmr" <> wrote in message
    > news:...
    > > 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
    > >
    > > On Dec 29, 12:00 pm, "John Agosta" <> wrote:
    > >> 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:http://www.cisco.com/en/US/products/ps6350/products_configuration_gui..
    > >> .
    > >>
    > >> Either way, please let us know what the problem & resolution was!
    > >>
    > >> Thanks.
    > >>
    > >> "secpgmr" <> wrote in message
    > >>
    > >> news:...
    > >>
    > >> >I have an oddball connection issue that appears to be related to the
    > >> > routing equipment between the two end points.
    > >>
    > >> > I have a server trying to connect to an access control system
    > >> > controller across the country over a WAN. When I sniff the
    > >> > connection
    > >> > between the server and the controller, I see a sequence of SYN
    > >> > packets
    > >> > to the controller service port (> 2000 < 4000) on the controller with
    > >> > no SYN ACK from
    > >> > the controller.
    > >>
    > >> > However, if I open a telnet session to the controller on the port
    > >> > where telnet is listening on the controller (> 8000), suddenly the
    > >> > server gets
    > >> > a SYN ACK on the controller service port and the controller comes
    > >> > online.
    > >>
    > >> > If I break the connection on the controller service port and try to
    > >> > re-
    > >> > establish it, I just get a sequence of SYN packets with no SYN ACK
    > >> > until I open another telnet session again.
    > >>
    > >> > Seems the telnet session is establishing some kind of state that is
    > >> > needed for the connection to occur that cannot be created on the
    > >> > controller service port for some reason.
    > >>
    > >> > The controller connects perfectly on the local network. The problem
    > >> > only occurs over the WAN. There are no firewalls between the two end
    > >> > points.
    > >>
    > >> > Any thoughts?
    > >>
    > >> > Mike

    > >


    --
    Barry Margolin,
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***
     
    Barry Margolin, Jan 1, 2008
    #13
  14. secpgmr

    secpgmr Guest

    On Jan 1, 9:06 am, "Thrill5" <> wrote:
    > If you have Cisco routers, you have the hardware to do ACL's, NAT and
    > firewall.
    >
    > "secpgmr" <> wrote in message
    >
    > news:...
    >
    > > 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

    >
    > > On Dec 27, 7:36 pm, "Thrill5" <> wrote:
    > >> 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.

    >
    > >> "secpgmr" <> wrote in message

    >
    > >>news:...

    >
    > >> >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 Margolin wrote:
    > >> >> In article
    > >> >> <>,
    > >> >> secpgmr <> wrote:

    >
    > >> >> > I have an oddball connection issue that appears to be related to the
    > >> >> > routing equipment between the two end points.

    >
    > >> >> 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?

    >
    > >> >> > I have a server trying to connect to an access control system
    > >> >> > controller across the country over a WAN. When I sniff the
    > >> >> > connection
    > >> >> > between the server and the controller, I see a sequence of SYN
    > >> >> > packets
    > >> >> > to the controller service port (> 2000 < 4000) on the controller
    > >> >> > with
    > >> >> > no SYN ACK from
    > >> >> > the controller.

    >
    > >> >> > However, if I open a telnet session to the controller on the port
    > >> >> > where telnet is listening on the controller (> 8000), suddenly the
    > >> >> > server gets
    > >> >> > a SYN ACK on the controller service port and the controller comes
    > >> >> > online.

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

    >
    > >> >> > If I break the connection on the controller service port and try to
    > >> >> > re-
    > >> >> > establish it, I just get a sequence of SYN packets with no SYN ACK
    > >> >> > until I open another telnet session again.

    >
    > >> >> > Seems the telnet session is establishing some kind of state that is
    > >> >> > needed for the connection to occur that cannot be created on the
    > >> >> > controller service port for some reason.

    >
    > >> >> > The controller connects perfectly on the local network. The problem
    > >> >> > only occurs over the WAN. There are no firewalls between the two
    > >> >> > end
    > >> >> > points.

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

    >
    > >> >> --
    > >> >> Barry Margolin,
    > >> >> Arlington, MA
    > >> >> *** PLEASE post questions in newsgroups, not directly to me ***
    > >> >> *** PLEASE don't copy me on replies, I'll read them in the group ***


    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.
     
    secpgmr, Jan 1, 2008
    #14
  15. secpgmr

    secpgmr Guest

    This sounds like the most likely scenario. You may have won yourself
    a cigar. I'll check this out.

    On Jan 1, 9:12 am, "Thrill5" <> wrote:
    > 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.
    >
    > "secpgmr" <> wrote in message
    >
    > news:...
    >
    > > 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

    >
    > > On Dec 29, 12:00 pm, "John Agosta" <> wrote:
    > >> 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:http://www.cisco.com/en/US/products/ps6350/products_configuration_gui...

    >
    > >> Either way, please let us know what the problem & resolution was!

    >
    > >> Thanks.

    >
    > >> "secpgmr" <> wrote in message

    >
    > >>news:...

    >
    > >> >I have an oddball connection issue that appears to be related to the
    > >> > routing equipment between the two end points.

    >
    > >> > I have a server trying to connect to an access control system
    > >> > controller across the country over a WAN. When I sniff the
    > >> > connection
    > >> > between the server and the controller, I see a sequence of SYN
    > >> > packets
    > >> > to the controller service port (> 2000 < 4000) on the controller with
    > >> > no SYN ACK from
    > >> > the controller.

    >
    > >> > However, if I open a telnet session to the controller on the port
    > >> > where telnet is listening on the controller (> 8000), suddenly the
    > >> > server gets
    > >> > a SYN ACK on the controller service port and the controller comes
    > >> > online.

    >
    > >> > If I break the connection on the controller service port and try to
    > >> > re-
    > >> > establish it, I just get a sequence of SYN packets with no SYN ACK
    > >> > until I open another telnet session again.

    >
    > >> > Seems the telnet session is establishing some kind of state that is
    > >> > needed for the connection to occur that cannot be created on the
    > >> > controller service port for some reason.

    >
    > >> > The controller connects perfectly on the local network. The problem
    > >> > only occurs over the WAN. There are no firewalls between the two end
    > >> > points.

    >
    > >> > Any thoughts?

    >
    > >> > Mike
     
    secpgmr, Jan 1, 2008
    #15
  16. secpgmr

    secpgmr Guest

    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 ping to the controller.

    On Jan 1, 9:29 am, Barry Margolin <> wrote:
    > In article <>,
    >
    > "Thrill5" <> wrote:
    > > 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?
    >
    >
    >
    >
    >
    > > "secpgmr" <> wrote in message
    > >news:...
    > > > 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

    >
    > > > On Dec 29, 12:00 pm, "John Agosta" <> wrote:
    > > >> 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:http://www.cisco.com/en/US/products/ps6350/products_configuration_gui..
    > > >> .

    >
    > > >> Either way, please let us know what the problem & resolution was!

    >
    > > >> Thanks.

    >
    > > >> "secpgmr" <> wrote in message

    >
    > > >>news:...

    >
    > > >> >I have an oddball connection issue that appears to be related to the
    > > >> > routing equipment between the two end points.

    >
    > > >> > I have a server trying to connect to an access control system
    > > >> > controller across the country over a WAN. When I sniff the
    > > >> > connection
    > > >> > between the server and the controller, I see a sequence of SYN
    > > >> > packets
    > > >> > to the controller service port (> 2000 < 4000) on the controller with
    > > >> > no SYN ACK from
    > > >> > the controller.

    >
    > > >> > However, if I open a telnet session to the controller on the port
    > > >> > where telnet is listening on the controller (> 8000), suddenly the
    > > >> > server gets
    > > >> > a SYN ACK on the controller service port and the controller comes
    > > >> > online.

    >
    > > >> > If I break the connection on the controller service port and try to
    > > >> > re-
    > > >> > establish it, I just get a sequence of SYN packets with no SYN ACK
    > > >> > until I open another telnet session again.

    >
    > > >> > Seems the telnet session is establishing some kind of state that is
    > > >> > needed for the connection to occur that cannot be created on the
    > > >> > controller service port for some reason.

    >
    > > >> > The controller connects perfectly on the local network. The problem
    > > >> > only occurs over the WAN. There are no firewalls between the two end
    > > >> > points.

    >
    > > >> > Any thoughts?

    >
    > > >> > Mike

    >
    > --
    > Barry Margolin,
    > Arlington, MA
    > *** PLEASE post questions in newsgroups, not directly to me ***
    > *** PLEASE don't copy me on replies, I'll read them in the group ***
     
    secpgmr, Jan 1, 2008
    #16
  17. secpgmr

    secpgmr Guest

    Actually, thinking about this further, since there's not even a SYN
    ACK coming back on the controller service port until the telnet
    session connects, the controller can't be a factor in the problem.
    The issue is a problem at Layer 4, before anything is even sent to the
    controller.

    On Jan 1, 10:17 am, secpgmr <> wrote:
    > This sounds like the most likely scenario. You may have won yourself
    > a cigar. I'll check this out.
    >
    > On Jan 1, 9:12 am, "Thrill5" <> wrote:
    >
    > > 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.

    >
    > > "secpgmr" <> wrote in message

    >
    > >news:...

    >
    > > > 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

    >
    > > > On Dec 29, 12:00 pm, "John Agosta" <> wrote:
    > > >> 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:http://www.cisco.com/en/US/products/ps6350/products_configuration_gui...

    >
    > > >> Either way, please let us know what the problem & resolution was!

    >
    > > >> Thanks.

    >
    > > >> "secpgmr" <> wrote in message

    >
    > > >>news:...

    >
    > > >> >I have an oddball connection issue that appears to be related to the
    > > >> > routing equipment between the two end points.

    >
    > > >> > I have a server trying to connect to an access control system
    > > >> > controller across the country over a WAN. When I sniff the
    > > >> > connection
    > > >> > between the server and the controller, I see a sequence of SYN
    > > >> > packets
    > > >> > to the controller service port (> 2000 < 4000) on the controller with
    > > >> > no SYN ACK from
    > > >> > the controller.

    >
    > > >> > However, if I open a telnet session to the controller on the port
    > > >> > where telnet is listening on the controller (> 8000), suddenly the
    > > >> > server gets
    > > >> > a SYN ACK on the controller service port and the controller comes
    > > >> > online.

    >
    > > >> > If I break the connection on the controller service port and try to
    > > >> > re-
    > > >> > establish it, I just get a sequence of SYN packets with no SYN ACK
    > > >> > until I open another telnet session again.

    >
    > > >> > Seems the telnet session is establishing some kind of state that is
    > > >> > needed for the connection to occur that cannot be created on the
    > > >> > controller service port for some reason.

    >
    > > >> > The controller connects perfectly on the local network. The problem
    > > >> > only occurs over the WAN. There are no firewalls between the two end
    > > >> > points.

    >
    > > >> > Any thoughts?

    >
    > > >> > Mike
     
    secpgmr, Jan 1, 2008
    #17
  18. secpgmr

    secpgmr Guest

    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.

    Since there's no SYN ACK coming back on the port on the Lantronics
    thin server that bridges to the serial interface on the controller,
    the problem never gets off the thin server. The telnet session is
    hosted entirely on the thin server.

    On Jan 1, 9:29 am, Barry Margolin <> wrote:
    > In article <>,
    >
    > "Thrill5" <> wrote:
    > > 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?
    >
    >
    >
    >
    >
    > > "secpgmr" <> wrote in message
    > >news:...
    > > > 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

    >
    > > > On Dec 29, 12:00 pm, "John Agosta" <> wrote:
    > > >> 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:http://www.cisco.com/en/US/products/ps6350/products_configuration_gui..
    > > >> .

    >
    > > >> Either way, please let us know what the problem & resolution was!

    >
    > > >> Thanks.

    >
    > > >> "secpgmr" <> wrote in message

    >
    > > >>news:...

    >
    > > >> >I have an oddball connection issue that appears to be related to the
    > > >> > routing equipment between the two end points.

    >
    > > >> > I have a server trying to connect to an access control system
    > > >> > controller across the country over a WAN. When I sniff the
    > > >> > connection
    > > >> > between the server and the controller, I see a sequence of SYN
    > > >> > packets
    > > >> > to the controller service port (> 2000 < 4000) on the controller with
    > > >> > no SYN ACK from
    > > >> > the controller.

    >
    > > >> > However, if I open a telnet session to the controller on the port
    > > >> > where telnet is listening on the controller (> 8000), suddenly the
    > > >> > server gets
    > > >> > a SYN ACK on the controller service port and the controller comes
    > > >> > online.

    >
    > > >> > If I break the connection on the controller service port and try to
    > > >> > re-
    > > >> > establish it, I just get a sequence of SYN packets with no SYN ACK
    > > >> > until I open another telnet session again.

    >
    > > >> > Seems the telnet session is establishing some kind of state that is
    > > >> > needed for the connection to occur that cannot be created on the
    > > >> > controller service port for some reason.

    >
    > > >> > The controller connects perfectly on the local network. The problem
    > > >> > only occurs over the WAN. There are no firewalls between the two end
    > > >> > points.

    >
    > > >> > Any thoughts?

    >
    > > >> > Mike

    >
    > --
    > Barry Margolin,
    > Arlington, MA
    > *** PLEASE post questions in newsgroups, not directly to me ***
    > *** PLEASE don't copy me on replies, I'll read them in the group ***
     
    secpgmr, Jan 1, 2008
    #18
  19. secpgmr

    Merv Guest

    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 ?
     
    Merv, Jan 1, 2008
    #19
  20. secpgmr

    Thrill5 Guest

    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.


    "secpgmr" <> wrote in message
    news:...
    > 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.
    >
    > Since there's no SYN ACK coming back on the port on the Lantronics
    > thin server that bridges to the serial interface on the controller,
    > the problem never gets off the thin server. The telnet session is
    > hosted entirely on the thin server.
    >
    > On Jan 1, 9:29 am, Barry Margolin <> wrote:
    >> In article <>,
    >>
    >> "Thrill5" <> wrote:
    >> > 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?
    >>
    >>
    >>
    >>
    >>
    >> > "secpgmr" <> wrote in message
    >> >news:...
    >> > > 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

    >>
    >> > > On Dec 29, 12:00 pm, "John Agosta" <> wrote:
    >> > >> 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:http://www.cisco.com/en/US/products/ps6350/products_configuration_gui..
    >> > >> .

    >>
    >> > >> Either way, please let us know what the problem & resolution was!

    >>
    >> > >> Thanks.

    >>
    >> > >> "secpgmr" <> wrote in message

    >>
    >> > >>news:...

    >>
    >> > >> >I have an oddball connection issue that appears to be related to
    >> > >> >the
    >> > >> > routing equipment between the two end points.

    >>
    >> > >> > I have a server trying to connect to an access control system
    >> > >> > controller across the country over a WAN. When I sniff the
    >> > >> > connection
    >> > >> > between the server and the controller, I see a sequence of SYN
    >> > >> > packets
    >> > >> > to the controller service port (> 2000 < 4000) on the controller
    >> > >> > with
    >> > >> > no SYN ACK from
    >> > >> > the controller.

    >>
    >> > >> > However, if I open a telnet session to the controller on the port
    >> > >> > where telnet is listening on the controller (> 8000), suddenly the
    >> > >> > server gets
    >> > >> > a SYN ACK on the controller service port and the controller comes
    >> > >> > online.

    >>
    >> > >> > If I break the connection on the controller service port and try
    >> > >> > to
    >> > >> > re-
    >> > >> > establish it, I just get a sequence of SYN packets with no SYN ACK
    >> > >> > until I open another telnet session again.

    >>
    >> > >> > Seems the telnet session is establishing some kind of state that
    >> > >> > is
    >> > >> > needed for the connection to occur that cannot be created on the
    >> > >> > controller service port for some reason.

    >>
    >> > >> > The controller connects perfectly on the local network. The
    >> > >> > problem
    >> > >> > only occurs over the WAN. There are no firewalls between the two
    >> > >> > end
    >> > >> > points.

    >>
    >> > >> > Any thoughts?

    >>
    >> > >> > Mike

    >>
    >> --
    >> Barry Margolin,
    >> Arlington, MA
    >> *** PLEASE post questions in newsgroups, not directly to me ***
    >> *** PLEASE don't copy me on replies, I'll read them in the group ***

    >
     
    Thrill5, Jan 1, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. richard

    oddball unexpected "you have mail" message

    richard, Dec 9, 2008, in forum: Computer Support
    Replies:
    2
    Views:
    449
    Expert lino fitter
    Dec 9, 2008
  2. richard

    oddball question for catholics

    richard, Mar 14, 2009, in forum: Computer Support
    Replies:
    4
    Views:
    805
    Paul T. Holland
    Mar 15, 2009
  3. richard
    Replies:
    4
    Views:
    572
    Mike Yetto
    Jan 31, 2010
  4. digger odell

    Another oddball translation question

    digger odell, Oct 8, 2010, in forum: Computer Support
    Replies:
    2
    Views:
    453
    Zu Arsschlaark!
    Oct 9, 2010
  5. digger odell

    An oddball language problem with Office 2010

    digger odell, Oct 8, 2010, in forum: Computer Support
    Replies:
    1
    Views:
    479
    John Holmes
    Oct 8, 2010
Loading...

Share This Page