Modbus TCP Slave Request Rejected

I have a genset controller as slave for Modbus TCP/IP. Simply attempt to communicate from my laptop. All client software (Modbus Poll, Modscan32, SimplyModbus) fails. Settings are as follows:

Slave device: Woodward EazyGen 3100XT
IP: 172.0.113.219
Subnet Mask: 255.255.0.0
Default Gateway: 172.0.113.1
Slave ID: 1
Port: not programmable in device, assumed to be 502
Modbus Protocol: 5010

Master device: Dell laptop Windows 7
TCP Client software: Modscan64
IP: 172.0.113.220
Subnet Mask: 255.255.0.0
Default Gateway: 172.0.113.1

Software is setup to read the device at the assigned IP and slave ID. The following is the results:
[11/21 10:56:25.553](3,2756) CModReadPacket::_Send() ModReadPacket 04846AB0 is sending - RegType=3 Start=10776 End=10776 Retries=4
[11/21 10:56:25.653](3,2756) CModReadPacket::_Send() Sending 12 bytes at 4846B14:
[11/21 10:56:25.653](3,2756) CModReadPacket::_Send() 01 ED 00 00 00 06 01 04 2A 17 00 01

The above packet is sent to 172.0.113.219 (end device). Filtering the Wireshark capture to only show frames including that IP address, we see the following behavior:
TCP connect handshake (frames 47-49)
Modbus request (frame 229)
ACK for Modbus request (frame 230)
FIN-ACK from Modbus device (frame 231)
ACK responding to FIN-ACK from Modbus device (frame 232)
RST-ACK from Modbus device (frame 233)
RST from Modbus device (frame 234)
Unrelated UDP stuff (frames 247, 569)
What we see is the device rejecting the Modbus request. Looking closer at the frames, we see some very strange behavior from the device

In frame 229, we're sending Modbus/TCP data, which has a 7-byte Modbus Application Protocol (MBAP) Header and the Modbus command. In this case, the packet is as follows:

01 ed 00 00 00 06 01 04 2a 17 00 01
01 ed = Transaction number 493
00 00 = Protocol identifier Modbus
00 06 = 6 bytes of Modbus command (including the Modbus Unit address byte)
01 = Modbus Unit 1
04 = Read Input Registers
2a 17 = Start at register 10775
00 01 = Read 1 register

Now if we check frames 231 and 233, they all have 6 bytes of "padding" that are as follows:

01 ed 00 00 00 06

This matches the first 6 bytes of the MBAP header. A proper Modbus response should look as follows:

01 ee 00 00 00 05 01 04 02 xx xx
01 ee = Transaction number 494
00 00 = Protocol identifier Modbus
00 05 = 5 bytes of Modbus command
01 = Modbus Unit 1
04 = Read Input Registers
02 = 2 bytes of return
xx xx = Contents of register 3:10775"

I didn't read the entirety of the post, but I had a similar thing happen to a DGC-2020 genset controller. Had to make sure that the "user permissions" were set to allow Modbus connections, and also had to power down/restart the controller.

Did you save the Wireshark file? I wouldn't mind seeing it.

If your Firewall is enabled, you will be unable to connect a Modbus TCP device. Disable the firewall or include Modbus port no. 502 in the Firewall Exceptions List.

also, you can find Modbus protocol tester (master application) free to download from here: http://www.colwaysolutions.com/modbus-protocol-tester.php.