Modbus utility

[laszlo]

Ok, thanks TomW.

Out of the box,  it seems one could use haproxy for this proxy/arbiter function.  At the house I don't have a Linux box but I provide config example below  for haproxy to have single backend tcp connection to port 502 on the CLassic from haproxy backend, and have various clients connect to the haproxy frontend.

frontend modbus-proxy- to-classic 0.0.0.0:502
mode tcp
maxconn 5
default_backend classic

backend classic
mode tcp
server my-classic <clsssic-IP>:502 maxconn  1

[RossW]

Out of the box,  it seems one could use haproxy for this proxy/arbiter function.

I'd be surprised if it worked properly. Modbus isn't entirely stateless, if you have more than one device communicating at a time, there is a mechanism to ensure overlapped reads and writes don't mess things up, and a proxy/arbiter without specific modbus awareness is unlikely to function properly.

There are also other issues which probably won't affect most (possibly all) midnite users, that is that a session once opened and unlocked will hold the device in read/write mode until the connection is closed. With a proxy that maintains the connection open, this layer of protection would be defeated.

That's not to say there isn't a modbus proxy out there, but it would need to be an application specific to the task.

[boB]

Out of the box,  it seems one could use haproxy for this proxy/arbiter function.

I'd be surprised if it worked properly. Modbus isn't entirely stateless, if you have more than one device communicating at a time, there is a mechanism to ensure overlapped reads and writes don't mess things up, and a proxy/arbiter without specific modbus awareness is unlikely to function properly.

There are also other issues which probably won't affect most (possibly all) midnite users, that is that a session once opened and unlocked will hold the device in read/write mode until the connection is closed. With a proxy that maintains the connection open, this layer of protection would be defeated.

That's not to say there isn't a modbus proxy out there, but it would need to be an application specific to the task.

I like the idea of a proxy.  Something that reads the registers of the Classic once every so often (programmable how often and what it reads maybe ?)  and then any number of other applications could work through that proxy.  That would leave the Classic to do what it really needs to do (charge batteries) and let the other multi comm. stuff to the external (to the classic) proxy software.

boB

[zoneblue]

Well amost 24 hours exactly later newmodus stopped connecting again. And stays that way for, well a half hour so far. Havent rebooted the classic yet. Want to see what happens. Last time newmodus returned "connection refused" this time its just hanging there waiting. Local app gets "device not available".

The dump for about 3 minutes is below, ie three 1 minute cron job intervals:

Code Select Expand


root@cubie#contrab -lu peter
* 6-18 * * *  /usr/bin/php-cgi -f /home/tasks/classic.php  >/dev/null 2>&1
0 19-5 * * *  /usr/bin/php-cgi -f /home/tasks/classic.php  >/dev/null 2>&1


Code Select Expand


root@cubie:# tcpdump -nS host 192.168.0.223
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:21:02.669924 IP 192.168.0.3.56008 > 192.168.0.223.502: Flags [S], seq 4584834   81, win 14600, options [mss 1460,sackOK,TS val 18644196 ecr 0,nop,wscale 7], len   gth 0
11:21:02.670085 IP 192.168.0.223.502 > 192.168.0.3.56008: Flags [S.], seq 668100   , ack 458483482, win 546, options [mss 546], length 0
11:21:02.670831 IP 192.168.0.3.56008 > 192.168.0.223.502: Flags [.], ack 668101,    win 14600, length 0
11:21:02.671187 IP 192.168.0.3.56008 > 192.168.0.223.502: Flags [P.], seq 458483   482:458483494, ack 668101, win 14600, length 12
11:21:02.671350 IP 192.168.0.223.502 > 192.168.0.3.56008: Flags [.], ack 4584834   94, win 0, length 0
11:21:07.677543 ARP, Request who-has 192.168.0.223 tell 192.168.0.3, length 28
11:21:07.677639 ARP, Reply 192.168.0.223 is-at 60:1d:0f:00:1b:95, length 46
11:21:34.500531 IP 192.168.0.223.502 > 192.168.0.3.56008: Flags [F.], seq 668101, ack 458483494, win 546, length 0
11:21:34.505536 IP 192.168.0.3.56008 > 192.168.0.223.502: Flags [F.], seq 458483494, ack 668102, win 14600, length 0
11:21:34.506094 IP 192.168.0.223.502 > 192.168.0.3.56008: Flags [.], ack 458483495, win 546, length 0
11:21:39.507932 ARP, Request who-has 192.168.0.223 tell 192.168.0.3, length 28
11:21:39.508473 ARP, Reply 192.168.0.223 is-at 60:1d:0f:00:1b:95, length 46
11:22:03.934420 IP 192.168.0.3.56009 > 192.168.0.223.502: Flags [S], seq 1658402901, win 14600, options [mss 1460,sackOK,TS val 18650322 ecr 0,nop,wscale 7], length 0
11:22:03.935021 IP 192.168.0.223.502 > 192.168.0.3.56009: Flags [S.], seq 668588, ack 1658402902, win 546, options [mss 546], length 0
11:22:03.941634 IP 192.168.0.3.56009 > 192.168.0.223.502: Flags [.], ack 668589, win 14600, length 0
11:22:03.942589 IP 192.168.0.3.56009 > 192.168.0.223.502: Flags [P.], seq 1658402902:1658402914, ack 668589, win 14600, length 12
11:22:03.943082 IP 192.168.0.223.502 > 192.168.0.3.56009: Flags [.], ack 1658402914, win 0, length 0
11:22:35.534570 IP 192.168.0.223.502 > 192.168.0.3.56009: Flags [F.], seq 668589, ack 1658402914, win 546, length 0
11:22:35.538119 IP 192.168.0.3.56009 > 192.168.0.223.502: Flags [.], ack 668590, win 14600, length 0
11:22:35.545204 IP 192.168.0.3.56009 > 192.168.0.223.502: Flags [F.], seq 1658402914, ack 668590, win 14600, length 0
11:22:35.545739 IP 192.168.0.223.502 > 192.168.0.3.56009: Flags [.], ack 1658402915, win 546, length 0
11:23:03.689447 IP 192.168.0.3.56010 > 192.168.0.223.502: Flags [S], seq 2520130533, win 14600, options [mss 1460,sackOK,TS val 18656298 ecr 0,nop,wscale 7], length 0
11:23:03.690156 IP 192.168.0.223.502 > 192.168.0.3.56010: Flags [S.], seq 669068, ack 2520130534, win 546, options [mss 546], length 0
11:23:03.696109 IP 192.168.0.3.56010 > 192.168.0.223.502: Flags [.], ack 669069, win 14600, length 0
11:23:03.700622 IP 192.168.0.3.56010 > 192.168.0.223.502: Flags [P.], seq 2520130534:2520130546, ack 669069, win 14600, length 12
11:23:03.701075 IP 192.168.0.223.502 > 192.168.0.3.56010: Flags [.], ack 2520130546, win 0, length 0
11:23:35.568166 IP 192.168.0.223.502 > 192.168.0.3.56010: Flags [F.], seq 669069, ack 2520130546, win 546, length 0
11:23:35.573236 IP 192.168.0.3.56010 > 192.168.0.223.502: Flags [F.], seq 2520130546, ack 669070, win 14600, length 0
11:23:35.573789 IP 192.168.0.223.502 > 192.168.0.3.56010: Flags [.], ack 2520130547, win 546, length 0
11:23:40.577989 ARP, Request who-has 192.168.0.223 tell 192.168.0.3, length 28
11:23:40.578594 ARP, Reply 192.168.0.223 is-at 60:1d:0f:00:1b:95, length 46
11:24:03.009132 IP 192.168.0.3.56011 > 192.168.0.223.502: Flags [S], seq 36759640, win 14600, options [mss 1460,sackOK,TS val 18662230 ecr 0,nop,wscale 7], length 0
11:24:03.009742 IP 192.168.0.223.502 > 192.168.0.3.56011: Flags [S.], seq 669540, ack 36759641, win 546, options [mss 546], length 0
11:24:03.015692 IP 192.168.0.3.56011 > 192.168.0.223.502: Flags [.], ack 669541, win 14600, length 0
11:24:03.018925 IP 192.168.0.3.56011 > 192.168.0.223.502: Flags [P.], seq 36759641:36759653, ack 669541, win 14600, length 12
11:24:03.019428 IP 192.168.0.223.502 > 192.168.0.3.56011: Flags [.], ack 36759653, win 0, length 0
11:24:34.600835 IP 192.168.0.223.502 > 192.168.0.3.56011: Flags [F.], seq 669541, ack 36759653, win 546, length 0
11:24:34.601333 IP 192.168.0.3.56011 > 192.168.0.223.502: Flags [F.], seq 36759653, ack 669542, win 14600, length 0
11:24:34.601475 IP 192.168.0.223.502 > 192.168.0.3.56011: Flags [.], ack 36759654, win 546, length 0
11:25:03.613372 IP 192.168.0.3.56012 > 192.168.0.223.502: Flags [S], seq 746372578, win 14600, options [mss 1460,sackOK,TS val 18668290 ecr 0,nop,wscale 7], length 0
11:25:03.613979 IP 192.168.0.223.502 > 192.168.0.3.56012: Flags [S.], seq 670024, ack 746372579, win 546, options [mss 546], length 0
11:25:03.618790 IP 192.168.0.3.56012 > 192.168.0.223.502: Flags [.], ack 670025, win 14600, length 0
11:25:03.621126 IP 192.168.0.3.56012 > 192.168.0.223.502: Flags [P.], seq 746372579:746372591, ack 670025, win 14600, length 12
11:25:03.621711 IP 192.168.0.223.502 > 192.168.0.3.56012: Flags [.], ack 746372591, win 0, length 0
^C
44 packets captured
44 packets received by filter
0 packets dropped by kernel


[laszlo]

From systems  availability perspective, proxy makes a lot of sense. If you or RossW wanted to pursue writing a modbus proxy, I would still suggest to use  a well-established proxy platform and contribute the module to them.  This would cut down on having to manage various OS platforms and to navigate the quirks of tcp/ip client/server stuff.

Out of the box,  it seems one could use haproxy for this proxy/arbiter function.

I'd be surprised if it worked properly. Modbus isn't entirely stateless, if you have more than one device communicating at a time, there is a mechanism to ensure overlapped reads and writes don't mess things up, and a proxy/arbiter without specific modbus awareness is unlikely to function properly.

There are also other issues which probably won't affect most (possibly all) midnite users, that is that a session once opened and unlocked will hold the device in read/write mode until the connection is closed. With a proxy that maintains the connection open, this layer of protection would be defeated.

That's not to say there isn't a modbus proxy out there, but it would need to be an application specific to the task.

I like the idea of a proxy.  Something that reads the registers of the Classic once every so often (programmable how often and what it reads maybe ?)  and then any number of other applications could work through that proxy.  That would leave the Classic to do what it really needs to do (charge batteries) and let the other multi comm. stuff to the external (to the classic) proxy software.

boB