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