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 >
