Responding to multiple IP addresses

[mhoneywill]

Hi Mark,

I am thinking of using the uTasker simulator to help me build an application that will simulate a number of modbus TCPIP slaves, on one ethernet connection. I need to support about 30 modbus slaves. To do this I need to modify the stack to repond to multiple IP addresses, this could easily be done on a block basis so utasker would respond to any IP in the range 192.168.1.1 to 192.168.1.32 for instance.

How difficult would this be to do? I'm envisioning this just being a simulator project it would never run on real hardware.

I could just run 30 instances of an application all configured to run with different IP addresses but this seems a bit heavy.

I found this post http://www.utasker.com/forum/index.php?topic=261.0 which gives me some clues,  I think I need to do the following things

1. Handle ARP requests from external devices for any IP in the range, I presume it would be ok to respond with the same MAC address

2. If a UDP or TCP request came through for an IP request in the range then respond to it, accordingly. I.e. respond to a Ping or Http request etc. In most cases I don't care that the uTasker simulator will not know to which IP destination address the request was directed, just that it replies to the request from the same IP address. Thinking about it I may have to duplicate the structures for each IP address as different IP addresses may be in different states

3. In the case of ModbusTCP I will want the higher level application to Know which IP address the request was sent to as I will want to respond with different information. The Modbus stack can already handle multiple TCPIP connections on different ports, its just a case of extending this mechanism to support multiple IP addresses.

Is it worth me trying to do this or is uTasker quite tightly tied into working with single IP addresses?

Cheers

Martin

 

[mark]

Hi Martin

The filtering of IP addresses takes place at the IP level so it is simple to enable it to accept not just its present IP address but all, or a range of addresses.

It would be possible to have multiple MODBUS slaves listening on the same TCP port but this may be complicated due to the fact that they would all  respond with the local IP address unless each transmission is matched to a particular session reception.

It may be easiest to add a TCP port number translation as follows:

1) Activate a number of MODBUS slaves on the TCP ports 502 (standard), 503, 504, 505 etc.

2) Filter IP reception addresses in the range 192.168.0.10 to 192.168.0.29 (example, for 20 slaves). In the case of 192.168.0.10 nothing is done. In the case of 192.168.0.11 the TCP port number in the received frame is changed to (502 + 1). In the case of 192.168.0.12 the TCP port number in the received frame is changed to (502 + 2)....In the case of 192.168.0.29 the TCP port number in the received frame is changed to (502 + 19).

This means that 20 different MODBUS slaves can be reached in the IP address range (each with one session) on the external TCP port 502, but each will internally work with a different TCP port number so each connection is easily recognisable (eg. one know that the MODBUS slave on port 504 receives only traffic on the external IP address 192.168.0.12).

3) When transmissions are sent by the MODBUS slaves they will also have the TCP port numbers 502... (502 + 19). At the IP transmission level, monitor the TCP port number being sent and  perform the reverse translation. That is, when TCP port 502 is being sent there is nothing to do since it is the local IP address. If TCP port 503 is being sent, decrement it to 502 and increment the IP to 192.168.0.11....If TCP port (502 + 19) is being sent, decrement it to 502 (that is by 19) and increment the IP to 192.168.0.29 (that is by 19).

The reception case should be easy since the TCP check sum is not checked by the simulator (the reason being that WireShark simulations often contain incorrect TCP check sums - no idea why - and so the check has been removed when simulating [can also be removed if this is to run on a real board]). Modifying the IP and port number in the transmission frame will however require new IP and and TCP check sums to be calculated (old ones replaced). This is not difficult to do by using the existing calculation routines.

I could imaging that this technique would enable quite a simple implementation.

Regards

Mark