port question

This topic has 15 replies, 4 voices, and was last updated 15 years, 2 months ago by Gary Atkinson.

Creator

Topic
February 23, 2010 at 9:40 pm #51592
Gary Atkinson
Participant
Hi- I have port question!

I have an inbound tcp/ip thread set-up to listen on port 58013. The vendor is saying the tcp ack is coming to them on a different port (4769). Does the cloverleaf application control this or something else outside the application? We have sniffers on both ends and I need to know who to yell at with this problem 😈

see attachment.

thx,

Gary
Creator

Topic

Viewing 14 reply threads

Author

Replies
- February 24, 2010 at 2:01 pm #70894
  James Cobane
  Participant
  Gary,
  
  I believe the vendor is referring to the local port on their side, which would be different. When a TCP/IP connection is established, the client initiates the request to the server using a random available local port, and connects to the server on the server port specified. Cloverleaf leave is ack’ing back on the connection that the vendor application established with it. This is standard TCP/IP, so I think the vendor is somewhat confused.
  
  Jim Cobane
  
  Henry Ford Health
- February 24, 2010 at 2:30 pm #70895
  Gary Atkinson
  Participant
  That is what I thought, but no one here at the office is listening to me!
  
  Now the vendor wants me to change port on the CL side to 4769. OMG!! 👿 😈 😯
- February 24, 2010 at 8:01 pm #70896
  Chris Williams
  Participant
  Gary,
  
  I think you and the vendor need to decide who is the server (the side that is “listening” and waiting for a connection) and who is the client. It is the server side that determines which port number to use.
  
  The client side will connect to the server at the server’s port number by using one of the client side ephemeral ports (and nobody cares what that port number is, except for the operating system which determines which port it’s going to use).
  
  The port numbers in use for a given TCP connection are not the same on both ends.
  
  Cheers.
- February 24, 2010 at 8:05 pm #70897
  Gary Atkinson
  Participant
  CL is the server. I see the port 58013 in a listening state when I turn the thread on. So, then port 4769 is being provide by client correct?
- February 24, 2010 at 8:51 pm #70898
  Chris Williams
  Participant
  Who came up with 58013 for the port on your side? Is that what you have in the thread configuration? That’s a number one would expect to be in the ephemeral range for a lot of systems.
  
  This is all just speculation until you ask the vendor or your in-house tech support person for that system how they are expecting the two systems to communicate.
  
  I know this can sound really complex, but it’s just like making a phone call. The server is sitting in their house by the phone waiting for someone to call. The server’s phone number is like it’s port number. The client wants to talk with the server so the client dials the server’s phone number. It doesn’t really matter what the client’s phone number is since the client is the one dialing the phone. It won’t work if they both dial the same number, and the client can’t connect to the server if the client doesn’t dial the correct number.
- February 24, 2010 at 8:59 pm #70899
  Gary Atkinson
  Participant
  I came with port 58013 for the thread. I started with 58000 and have been working my way up on each new inbound connection.
  
  The weird part is this integration was working just fine up until a few weeks ago. Now, no one seems to know what is going on. Talk to the network guys; not their problem. Talk to the receiving vendor; not them either. So, it must be the interface guys fault. 😈
  
  I’ve learned more about tcp/ip this week then the semester class I took many moons ago. 😯
- February 24, 2010 at 9:18 pm #70900
  Chris Williams
  Participant
  OK, brute force approach. Try the following CL thread configurations and see which will connect and show as “UP”:
  
  1. Server/port 58013.
  
  2. Server/port 4769
  
  3. Client using the vendor system IP address/port 58013
  
  4. Client using the vendor system IP address/port 4769.
- February 24, 2010 at 9:30 pm #70901
  Gary Atkinson
  Participant
  thx, Chris will get that a try.
  
  iedev:hci> netstat -a | grep 4769
  
  tcp4
- February 25, 2010 at 2:27 pm #70902
  Gary Atkinson
  Participant
  I am really sorry for beating this dead horse, but does anyone have any other thoughts of what I need to check in the CL application? I have about pull out the last of my hair out…
- February 25, 2010 at 3:56 pm #70903
  Robert Kersemakers
  Participant
  Have you tried turning up the noise on CL (EO config)? Or tried a completely different portnumber to see if that works?
  
  Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands
- February 25, 2010 at 4:02 pm #70904
  Gary Atkinson
  Participant
  Yes I tried both of those. The sending vendor was able to route their message feed to a local install of CL on their server. From there to route to hospital CL server. We were able to establish a connection after that. So, the problem seems to occur when communicate between hospital CL and sending vendor application.
  
  The engine noise posts errors like this when when communicating between hospital CL and sending vendor application. :
  
  Code: [icl :tcpi:ERR /0: results_cmd:02/25/2010 09:43:43] write failed: Broken pipe [cmd :cmd :INFO/0: results_cmd:02/25/2010 09:43:43] Since there are some error had occured while attempted to send an Ack back to client [cmd :cmd :INFO/0: results_cmd:02/25/2010 09:43:43] We try to process the command anyway but no further Ack will be send back to Client [cmd :cmd :INFO/0: results_cmd:02/25/2010 09:43:43] Received command: ‘results_xlate xrel_post’ [cmd :cmd :INFO/0:results_xlate:02/25/2010 09:43:43] Doing ‘xrel_post’ command with args ” [cmd :cmd :INFO/0: results_cmd:02/25/2010 09:43:43] Inrecoverable socket error. Closing connection. [cmd :cmd :INFO/0: results_cmd:02/25/2010 09:43:43] Receiving a command [icl :tcpi:ERR /0: results_cmd:02/25/2010 09:43:43] write failed: Broken pipe [cmd :cmd :INFO/0: results_cmd:02/25/2010 09:43:43] Since there are some error had occured while attempted to send an Ack back to client [cmd :cmd :INFO/0: results_cmd:02/25/2010 09:43:43] We try to process the command anyway but no further Ack will be send back to Client [cmd :cmd :INFO/0: results_cmd:02/25/2010 09:43:43] Received command: ”results_xlate’ [cmd :cmd :INFO/0: results_cmd:02/25/2010 09:43:43] Cmd null in ”results_xlate’ [cmd :cmd :INFO/0: results_cmd:02/25/2010 09:43:43] Inrecoverable socket error. Closing connection. Engine idle — 02/25/2010 09:43:53 [pdl :PDL :ERR /0:viewpoint_res:02/25/2010 09:50:18] read returned error 0 (Error 0) [pdl :PDL :ERR /0:viewpoint_res:02/25/2010 09:50:18] PDL signaled exception: code 1, msg device error (remote side probably shut down) Engine idle — 02/25/2010 09:50:33
- February 25, 2010 at 4:14 pm #70905
  Gary Atkinson
  Participant
  Just muddy the waters. The sender vendor is saying they need to receive the tcp ack on the same port they are sending to. This does not make sense to me at all.
- February 25, 2010 at 4:39 pm #70906
  Robert Kersemakers
  Participant
  Hmmm… Really sounds like a networking/firewall problem. Something to do with port forwarding? I’m not a networking expert though.
  
  And when you generate an ack in CL, it is (by default) send over the same port as the port that the original message came over. Strange…
  
  Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands
- February 25, 2010 at 5:02 pm #70907
  Chris Williams
  Participant
  There may, in fact, be a firewall issue, however there is this red flag:
  
  ~~Quote:~~
  
  The vendor said they can’t not input an IP, so I they can’t be the server.
  
  If they have no provision for entering an IP address, THEY ARE THE SERVER. That means that you have to be the client.
- February 25, 2010 at 6:00 pm #70908
  Gary Atkinson
  Participant
  Sorry I mistyped. They can enter IP address.
Author

Replies

Viewing 14 reply threads

The forum ‘Cloverleaf’ is closed to new topics and replies.