Hi Chris, Hi Sebastian,
I like the idea a lot. In fact, when we started our PLC Communication the first idea was to only listen on the net for the PLC / Sensor communication. Especially with protocols like IOLink this would give richer information than the PLC itself. Ideally, without the need for any setup at all. Thus, this seems really supportable from our side and ideally as protocol agnostic as possible to be able to incorporate not only the PLC-HMI Communication but also all sorts of PLC-Sensor, Sensor-Sensor and whatever communication. Best Julian Am 08.08.18, 18:11 schrieb "Christofer Dutz" <[email protected]>: Hi Sebastian, If this was a cooking show, I would probably say:"I have prepared this for you", but this is not a cooking show ... But I'll still say: "I have prepared this for you" ;-) Just have a look for the raw socket support module in the PLC4X codebase ;-) Ok it's not 100% finished, but most of it is. Promiscuous mode would even make things simpler as I don't have to check if a packet is for me or not and I don't have to manually resolve arp packets and send arp lookups, as I just inspect everything that just happens to come by. Chris Outlook for Android<https://aka.ms/ghei36> herunterladen ________________________________ From: Sebastian Rühl <[email protected]> Sent: Wednesday, August 8, 2018 5:55:09 PM To: [email protected] Subject: Re: How about a "promiscuous" mode? 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 >
