ava TCP Socket Connection Issue — handshake failure while connecting to legacy equipm

**NOTE** Make the title "Java" not "ava". Copy/paste error FTW.

I am attempting to write a Java program that will replace an old DOS-based program that my company currently uses. When I attempt to simply open a socket to communicate with the piece of equipment the program is being written for, the TCP handshake never completes. I have a fairly decent idea of what the problem may be, but I am truly a novice network programmer and I'm not totally sure (nor am I sure how to resolve the issue). I'll try to make this explanation both brief and useful.

The equipment that I'm attempting to connect with is OLD -- like 20+ years old. The device is typically controlled by either a GPIB connection or over a network. Historically, all the programs that have connected to this device over a network have been run on Solaris system. The GPIB port has been the only option available for PC-based connections.

Now, one downside is that I don't have access to any of the source code from either the "client" accessing the machine nor the "server" on the machine. All the information I have has been gleaned by intercepting the IP traffic between a Solaris box and the equipment. I do believe that the equipment is utilizing a UNIX-like embedded system. And if you want proof of how old these things are, check out the MAC address below that starts with "00:80:12:00".

The bottom line of my problem is this -- it seems that there is enough difference between the packets that my system and JVM (Win7 with Java 7) send and the packets that the equipment produce to cause a TCP connection to not function. I have a feeling that Java doesn't have any built-in methods or classes to functionally modify a TCP packet. I ran into a similar limitation when I was writing a RARP server and found out that I couldn't easily send a ping from a Java program.

I'm including some basic packet information that I've intercepted off the network. The first set of six packets are the first packets exchanged between the Solaris system and the equipment. The second set of six packets are the only six packets sent between my Windows 7-based Java program and the equipment. Key items that I've noticed already about the difference between these two sets of packets:

1) The port being used by this equipment is 2112 (AKA idonix-metanet). The extremely limited information I've found about this port/protocol just shows how utterly old this equipment and protocol are.
2) The working packets from the Solaris system do not contain any entry involving "WS=XXX". I'd imagine this is because that particular aspect of TCP didn't exist way-back-when.
3) It seems to me that my PC/program is the entity deciding to close the attempted TCP connection. When I open the socket in Java, it sends a SYN packet, receives a SYN, ACK packet, sends an ACK packet, then instantly sends a FIN, ACK packet which then starts the process of terminating the connection. To me and my limited experience, this tells me that something in the single SYN,ACK packet that was sent from the equipment made my program(or OS) decide that this connection was not working properly.
4) I also noticed that the value for "Win" was drastically different between the two. In the functional Solaris packets, Win starts off with a value of 24820. This value changes in later packets. I did manually modify my program to have a fixed Win value of 24820, but this had no effect.
5) The length of the first packet is four greater (66) in my Java-based communications than it is in the Solaris-based communications. This is probably due to the additional WS field.

I am not including any Java code since all I am doing at this point is opening a Socket to the equipment's IP and port.

First -- the working Solaris packets:


No. Time Source Destination Protocol Length Info<br>
1 0.000000 192.168.1.135 192.168.1.23 TCP 62 33384 > idonix-metanet [SYN] Seq=0 Win=24820 Len=0 SACK_PERM=1 MSS=1460
<pre>
0000 00 80 12 00 03 33 00 03 ba 13 6b ec 08 00 45 00 <t> .....3....k...E.
0010 00 30 48 37 40 00 40 06 6e a2 c0 a8 01 87 c0 a8 <t> .0H7@.@.n.......
0020 01 17 82 68 08 40 cf f8 45 a0 00 00 00 00 70 02 <t> ...h.@..E.....p.
0030 60 f4 fd fa 00 00 01 01 04 02 02 04 05 b4 <t> `.............</pre>

No. Time Source Destination Protocol Length Info<br>
2 0.000970 192.168.1.23 192.168.1.135 TCP 60 idonix-metanet > 33384 [SYN, ACK] Seq=0 Ack=1 Win=4096 Len=0 MSS=1024
<pre>
0000 00 03 ba 13 6b ec 00 80 12 00 03 33 08 00 45 00 ....k......3..E.
0010 00 2c 00 05 00 00 64 06 d2 d8 c0 a8 01 17 c0 a8 .,....d.........
0020 01 87 08 40 82 68 00 39 c0 00 cf f8 45 a1 60 12 ...@.h.9....E.`.
0030 10 00 a5 5f 00 00 02 04 04 00 00 00 ..._........</pre>

No. Time Source Destination Protocol Length Info<br>
3 0.000975 192.168.1.135 192.168.1.23 TCP 60 33384 > idonix-metanet [ACK] Seq=1 Ack=1 Win=25600 Len=0
<pre>
0000 00 80 12 00 03 33 00 03 ba 13 6b ec 08 00 45 00 .....3....k...E.
0010 00 28 48 38 40 00 40 06 6e a9 c0 a8 01 87 c0 a8 .(H8@.@.n.......
0020 01 17 82 68 08 40 cf f8 45 a1 00 39 c0 01 50 10 ...h.@..E..9..P.
0030 64 00 67 68 00 00 55 55 55 55 55 55 d.gh..UUUUUU</pre>

No. Time Source Destination Protocol Length Info<br>
4 0.001235 192.168.1.135 192.168.1.23 TCP 62 33384 > idonix-metanet [PSH, ACK] Seq=1 Ack=1 Win=25600 Len=8
<pre>
0000 00 80 12 00 03 33 00 03 ba 13 6b ec 08 00 45 00 .....3....k...E.
0010 00 30 48 39 40 00 40 06 6e a0 c0 a8 01 87 c0 a8 .0H9@.@.n.......
0020 01 17 82 68 08 40 cf f8 45 a1 00 39 c0 01 50 18 ...h.@..E..9..P.
0030 64 00 26 55 00 00 41 03 00 00 00 00 00 00 d.&U..A.......</pre>

No. Time Source Destination Protocol Length Info<br>
5 0.002694 192.168.1.23 192.168.1.135 TCP 60 idonix-metanet > 33384 [ACK] Seq=1 Ack=9 Win=4088 Len=0
<pre>
0000 00 03 ba 13 6b ec 00 80 12 00 03 33 08 00 45 00 ....k......3..E.
0010 00 28 00 06 00 00 64 06 d2 db c0 a8 01 17 c0 a8 .(....d.........
0020 01 87 08 40 82 68 00 39 c0 01 cf f8 45 a9 50 10 ...@.h.9....E.P.
0030 0f f8 bb 68 00 00 00 00 00 00 00 00 ...h........</pre>

No. Time Source Destination Protocol Length Info<br>
6 0.019280 192.168.1.23 192.168.1.135 TCP 62 idonix-metanet > 33384 [PSH, ACK] Seq=1 Ack=9 Win=4096 Len=8
<pre>
0000 00 03 ba 13 6b ec 00 80 12 00 03 33 08 00 45 00 ....k......3..E.
0010 00 30 00 07 00 00 64 06 d2 d2 c0 a8 01 17 c0 a8 .0....d.........
0020 01 87 08 40 82 68 00 39 c0 01 cf f8 45 a9 50 18 ...@.h.9....E.P.
0030 10 00 79 fb 00 00 41 03 00 00 00 00 00 52 ..y...A......R</pre>

<br><br>

Now, the non-functional Java-based packets (packets 1 and 2 were removed since they were just broadcasts looking for the equipment's MAC address):

No. Time Source Destination Protocol Length Info<br>
3 0.001154 192.168.1.79 192.168.1.23 TCP 66 49931 > idonix-metanet [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
<pre>
0000 00 80 12 00 03 33 14 da e9 1a c9 c4 08 00 45 00 .....3........E.
0010 00 34 01 9a 40 00 80 06 75 73 c0 a8 01 4f c0 a8 .4..@...us...O..
0020 01 17 c3 0b 08 40 22 6f b1 8d 00 00 00 00 80 02 .....@"o........
0030 20 00 2c 11 00 00 02 04 05 b4 01 03 03 08 01 01 .,.............
0040 04 02 ..</pre>

No. Time Source Destination Protocol Length Info<br>
4 0.002375 192.168.1.23 192.168.1.79 TCP 60 idonix-metanet > 49931 [SYN, ACK] Seq=0 Ack=1 Win=4096 Len=0 MSS=1024
<pre>
0000 14 da e9 1a c9 c4 00 80 12 00 03 33 08 00 45 00 ...........3..E.
0010 00 2c 00 05 00 00 64 06 d3 10 c0 a8 01 17 c0 a8 .,....d.........
0020 01 4f 08 40 c3 0b 00 3a 70 00 22 6f b1 8e 60 12 .O.@...:p."o..`.
0030 10 00 f6 8f 00 00 02 04 04 00 00 00 ............</pre>

No. Time Source Destination Protocol Length Info<br>
5 0.002379 192.168.1.79 192.168.1.23 TCP 60 49931 > idonix-metanet [ACK] Seq=1 Ack=1 Win=64512 Len=0
<pre>
0000 00 80 12 00 03 33 14 da e9 1a c9 c4 08 00 45 00 .....3........E.
0010 00 28 01 9b 40 00 80 06 75 7e c0 a8 01 4f c0 a8 .(..@...u~...O..
0020 01 17 c3 0b 08 40 22 6f b1 8e 00 3a 70 01 50 10 .....@"o...:p.P.
0030 fc 00 20 98 00 00 00 00 00 00 00 00 .. .........</pre>

No. Time Source Destination Protocol Length Info<br>
6 0.003002 192.168.1.79 192.168.1.23 TCP 60 49931 > idonix-metanet [FIN, ACK] Seq=1 Ack=1 Win=64512 Len=0
<pre>
0000 00 80 12 00 03 33 14 da e9 1a c9 c4 08 00 45 00 .....3........E.
0010 00 28 01 9c 40 00 80 06 75 7d c0 a8 01 4f c0 a8 .(..@...u}...O..
0020 01 17 c3 0b 08 40 22 6f b1 8e 00 3a 70 01 50 11 .....@"o...:p.P.
0030 fc 00 20 97 00 00 00 00 00 00 00 00 .. .........</pre>

No. Time Source Destination Protocol Length Info<br>
7 0.004242 192.168.1.23 192.168.1.79 TCP 60 idonix-metanet > 49931 [FIN, ACK] Seq=1 Ack=2 Win=4096 Len=0
<pre>
0000 14 da e9 1a c9 c4 00 80 12 00 03 33 08 00 45 00 ...........3..E.
0010 00 28 00 06 00 00 64 06 d3 13 c0 a8 01 17 c0 a8 .(....d.........
0020 01 4f 08 40 c3 0b 00 3a 70 01 22 6f b1 8f 50 11 .O.@...:p."o..P.
0030 10 00 0c 97 00 00 02 04 04 00 00 00 ............</pre>

No. Time Source Destination Protocol Length Info<br>
8 0.004246 192.168.1.79 192.168.1.23 TCP 60 49931 > idonix-metanet [ACK] Seq=2 Ack=2 Win=64512 Len=0
<pre>
0000 00 80 12 00 03 33 14 da e9 1a c9 c4 08 00 45 00 .....3........E.
0010 00 28 01 9d 40 00 80 06 75 7c c0 a8 01 4f c0 a8 .(..@...u|...O..
0020 01 17 c3 0b 08 40 22 6f b1 8f 00 3a 70 02 50 10 .....@"o...:p.P.
0030 fc 00 20 96 00 00 00 00 00 00 00 00 .. .........</pre>
<br><br>


So, now to my main question -- how in the world do I make this connection function properly in Java? My GUESS is that I'll need some C/C++ code to act as an intermediary between my program and my OS/hardware, but I really hope there is another way. I don't have the slightest clue how to do that.

Also, I do have all the Solaris-based header and compiled class files (C/C++) that are needed to access this equipment, but I don't know how useful compiled classes would be.

Many many thanks in advance for any help. Please let me know if there is any additional information that would help.

Jonathan

Quote:

---

OLD -- like 20+ years old

---

GET OFF MY ... nvm

Can you run the DOS client in something like VirtualBox to act as a proxy? Or how about a GPIB proxy - a PC with a GPIB card (amazon has to-USB cables for not small amounts of money) connected to your mystery equipment?

Attempting to reverse-engineer the protocol sounds like the path of pain. Only well-known public-facing services are really likely to be found on the same ports consistently, I'm not convinced you could reliably discover the protocol from the port number. Your only hope of being able to communicate with that thing via TCP is if you get a reliable clue as to what the protocol should be. Is there anything that does automatic protocol discovery?

20-years-old is old for continuously operational electronic equipment! Can you image using a 20-year-old computer?

I've considered that sort of solution, but I really want to improve the program as well as running it on a Windows 7 system. I have GPIB captures that show that all the commands to the equipment are sent in plain-text, and additional IP captures I've done between the Solaris computer and the equipment show that it also uses plain-text (as translated by the packet sniffer).

From what I know about this equipment, it seems fairly unlikely that the protocol that they used was anything but a standard protocol... just perhaps using a non-standard port. To me, it just seems like there is a fairly minor disconnect between the way packets are formed with my Java program and the existing Solaris program.

Is there any additional information that I could provide from the packet sniffer that might help? Perhaps packets displaying a functional exchange between the Solaris system and the equipment?

Thanks for your reply. I appreciate all input, especially since this doesn't seem to be a cut-and-dry issue.

I doubt packet inspection will help much for a Java solution - there's not much you could do with that level of detail from within Java. If it's a very simple text protocol as you say, have you tried connecting to the port on the equipment using telnet from your PC and telnet from the host the client software usually runs on? You can specify the port number on the command line.

edit: just to rule out the obvious, have you tried connecting your Java program to an HTTP or SMTP server to check that it doesn't just close it's port and die as a feature?

Yeah... that's the basic feeling I've gotten from my experience with Java and networking. Would it be theoretically possible to utilize C/C++ code to interface between Java and the network interface?

I'm going to attempt a telnet connection tomorrow. I'm also going to try to run my Java code on the same Solaris box that is currently able to connect to my equipment... perhaps Solaris will be properly able to handle the packets. If so, at least I'll know that the Windows implementation of Java's Socket class is at fault. Perhaps the Linux JVM would also work.

It could be something more trivial, like a kludgey 'security' feature on the equipment that restricts communication to a specified IP address, or something in the protocol that's sensitive to the timing of messages. Those sorts of things might be much easier gleaned from the original supplier than they would by trial-and-error.

Are you at liberty to say what the piece of equipment is? Is it an off-the-shelf product or custom-made?

I've considered that, but it seems from the packets I've captured that my computer is the one that starts the FIN sequence to terminate the connection. That certainly doesn't mean that my computer isn't responding to something strange that was sent to it.

I haven't named the equipment because it's extremely unlikely that anybody online would have even heard about it, and my company is the only company in the world that provides service and support for it... so we're pretty much the experts (at least with most aspects of this equipment). The equipment was created by a company named Integrated Measurement Systems and they're digital IC testers. They do have two CPUs in them, so they really do function as a stand-alone computer system that receives instructions from what is essentially a dumb terminal. The manufacture created an extensive API for network control using Solaris and C/C++, but didn't bother with the same infrastructure for PC-based communications.

I'm going to try a bunch of different things today to try to learn a bit more.

I've made some slight progress. I found that I was being an idiot before. When I was observing the packets in Wireshark, I saw what looked like the command "A......." being sent to the equipment to initialize it. I didn't bother to notice that all non-printable characters are displayed as periods. So I properly formed the data to perfectly match the packets from the Solaris box. For example, the first message that was displayed as "A......." was actually "A\u0003\u0000\u0000\u0000\u0000\u0000\u0000" or, in hex, 41 03 00 00 00 00 00 00. So that little issue was just purely my stupidity.

I am now able to (mostly) properly carry out the first two data exchanges, the first of which is the packet I just detailed. The second exchange involves the same packet just with a 'C' or 0x43. That communication also works. The third one, however, does not work. I imitate the data exactly as it is in the packets I pulled from the Solaris box ("\u0036\u0003\u0000\u0000\u0000\u0000\u0000\u0000 ") but I get no response.

I have noticed that the "Data Offset" differ between the packets I've sent with my Java program and the ones I've sent with the Solaris-based program, but they never vary between different runs on the same platform. I've captured the packets from both the Solaris box and my PC multiple times in a row using identical methods to determine which information is relevant and which information is only concerned with the specifics of that single packet during that single usage.

My conclusion so far (be they right or wrong) is that the first three lines (or first 12 octets) don't seem to be terribly important in that they're all either consistent across different platforms or always different even when run multiple times on the same platform. The data offset/Reserved/control flags (octets 13 and 14) seem important in that they're consistent between runs on the same platform but different between the platforms. Octets 15 and 16 are for the window and they don't seem important. The rest of the octets seem pretty important as well (Checksum, Urgent Pointer, Options, and Padding).

I'm fairly sure that I can change the use of Urgent Pointers from Java... but what about the rest?

I'm fairly sure that I can do this with Jpcap... it just seems like it's going to be brutally difficult to do.

The TCPPacket class of Jpcap has fields such as:

_ipOffset, TCP_ACK_LEN, TCP_ACK_MASK, TCP_ACK_POS, TCP_CSUM_LEN, TCP_CSUM_POS, TCP_DP_POS, TCP_FIN_MASK, TCP_FLAG_LEN, TCP_FLAG_POS, TCP_HEADER_LEN, TCP_PORT_LEN, TCP_PSH_MASK, TCP_RST_MASK, TCP_SEQ_LEN, TCP_SEQ_POS, TCP_SP_POS, TCP_SYN_MASK, TCP_URG_LEN, TCP_URG_MASK, TCP_URG_POS, TCP_WIN_LEN, TCP_WIN_POS

Does anybody think that it would be practical to use this class to format many many many packets?

I doubt your difficulties lie with TCP. If your first two commands work, you probably ought to concede that the problem lies with your third command. How else can you tackle this? Can you simulate the equipment in Java but configure the Solaris box to send traffic to your simulator instead of the equipment? Reading the InputStream on your PC should give you a direct copy of what you should be sending to the equipment from your new Java control application.

Yes, I think that I could probably write a simulator since I'm able to capture all the traffic using a packet sniffer. Could this show me something different than what the packet sniffer tells me?

Seeing that the vast majority of all the packets I'm trying to emulate is TCP overhead, I do have a hard time seeing how the "simple" commands I'm sending for the first two interactions work, but the third "simple" command (that only varies data wise in that it has a '6' in the first position rather than an 'A' or 'C'. Also, I know that I'm matching the data section (as far as I know) exactly in the same way with the third communication as I am in the first two.


I have noticed one thing that I'm not (easily) able to modify. If you look at packet 3 above from the first set of packets, you'll see that the data portion of the ACK packet has a bunch of 'U' values (as converted from 0x55 hex values). The "same" ACK packet from my windows box has only null or 0x00 (packet 5 of the second set). This seems like a fairly drastic difference between a non-data carrying ACK packet. Could this have anything to do with it?

A simulator would give you exactly the bytes you need to send from a Java control application - that would be the immediate benefit. You could save them as a list of commands and 'replay' them with very little effort. There would be no need to translate / transcribe them. In fact, what you could also do to rule out networking platform issues is to write a proxy, so that you accept commands from the Solaris box, relay them to the equipment, and send back to the Solaris box whatever the equipment responds. That might be your fastest route to a working Java control application.

That's a really good idea! I like it. If I capture and serialize the packets, I could just store them and use 'em again. Not bad at all. Thanks!