Hi Chris,

Im quite keen on this approach as this might be the major use case for plc4x 
anyway.
Regarding the decoding of requests: The ADS implementation is already capable 
of this, on the modbus side im not sure right now.
What comes to my mind thought: Currently netty opens a TCP/Connection to a 
server/peer and reads packages from there. So we might another method to pipe 
these requests into the subsystem. In case for ADS the target IP/Device ID 
would be different too. So this would then be a Wireshark style package 
capturing which even might require root rights. On the top side of plc4x we 
would need a support for „listening“ to traffic. So this might be similar to 
the pub/sub implementation but in my view this would be a separate API (read 
stream etc).
But maybe you have solved all these challenges already in the meantime. :D

Sebastian 

> Am 08.08.2018 um 14:25 schrieb Christofer Dutz <[email protected]>:
> 
> Hi,
> 
> as you probably know I have been talking to a lot of people in the industry 
> lately. While most of them seem to really like what we are doing,
> some are hesitant to what we are doing.
> 
> Mostly these people have the following concerns:
> 
>  *   That more systems querying the controllers would increase the load on 
> these as they have to process these requests.
>  *   Adding more systems to a security relevant network is not possible 
> (mostly heard this from the pharma industry)
> 
> I am currently building a POC for a big pharmaceutical company, which should 
> be able to resolve all of these problems.
> Here we are using a port replication feature of an industrial switch (optical 
> link) to forward all internal traffic in one direction outside the security 
> network.
> Then I am implementing a new driver for that protocol, that runs in 
> promiscuous mode.
> 
> This means the driver just listens for packets coming by and extracts all 
> sorts of information from them without being able to interfere with the 
> normal PLC operation and without increasing any form of load on any of the 
> systems … currently this is a hard-coded poc for a very special protocol, but 
> I think that implementing this form of transport for others does make sense … 
> however it does require us to implement more of the protocols we use. For 
> example in the S7 protocol, I have only implemented the encoding of requests 
> and the decoding of responses … this would require us to also implement the 
> decoding of requests.
> 
> What do you think about this approach?
> 
> Chris
> 

Reply via email to