Hi all, Thanks Otto for that link ... looks interesting, even if this might be more interesting for the internals of how we find things.
In general the discovery will be 3 things: 1) Detecting there is something at a given IP/Port 2) Detecting the protocol 3) Getting information about the thing using the protocol we detected Active Scenario: - So for example using TCP/UDP to detect there is something on IP 10.10.64.20 (Could be a ping) - Next to knock on typical ports depending on the protocols (possibly scanning ports) - So as soon as we know on IP 10.10.64.20 there is something and it's got an open port on port 102 - So now the S7 protocol could raise an arm and ask to give it a try as it knows it usually operates on port 102 - It would try to establish a connection and here could find out the type of PLC using the old S7 protocol So in the end we'd know on which device a given protocol is supported and possibly even which type of PLC it is and which software version it is (Does it support S7plus?) Passive scenario: - We start capturing data - A packet is received - Each driver is asked "Here's a tcp packet on port 102 you wanna check it out?" - If the driver says "sure" because he knows the port or simply wants to try to decode every packet, he'll start to decode the packet - If it fails, well then it's probably not that protocol - If it succeeds it will give a positive response possibly containing additional information Unless we happen to intercept a packet where the PLC provides information about itself we can't actively ask for more information Possibly a combination of passive detection of thing and protocol with additional active interrogations would be a good thing to implement. Scanning an IP range and ports is potentially problematic as this does put quite some stress on unhardened devices and will probably let some alarm-bells ring. We could make plc4x limit this scanning to intervals so perhaps such a scan is only done in the night and only once a week on the weekend. Chris Am 01.07.20, 13:55 schrieb "Otto Fowler" <[email protected]>: https://old.zeek.org/development/howtos/dpd.html On June 30, 2020 at 13:32:57, Christofer Dutz ([email protected]) wrote: Just had another idea ... How about giving this driver no real transport at all (think we have the dummy transport ... that works like a charm) and then to provide the means in the subscription addresses? This way I could start discovering serial, passive and active ... and perhaps even multiple instances with just one connection ... Chris Am 30.06.20, 19:09 schrieb "Christofer Dutz" <[email protected]>: Hi folks, for the past weeks I have been thinking about how we could approach the “discovery” topic. I think I just had an idea and would like some feedback from you. So I was thinking about how we could model such a discovery API. In general it would look pretty different to the existing APIs … at least I thought. The Idea I just had, was: How about we create a new “discovery” driver? This can use both the serial transport as well as the passive-mode transport or even tcp transport for protocols that allow active discovery mechanisms. So you would simply create a “connection” to something like “discovery:raw//eh1” or “discovery:serial:///dev/ttyS0” … now this driver would be a little special. It would internally query the list of drivers available on the given system, the same way the DriverManager does it. But it would check each driver if it implements an interface “SupportsDiscovery” (or whatever name we give it) … So it would then initialize an instance of all drivers supporting discovery. So in the end the DiscoveryDriver would simply try to feed each packet to each of the drivers and have them check if they can make sense out of that. If they do, they would start emitting events just the same way a resource subscription does. (Of course we should probably apply some filtering mechanism to avoid too much overload) So a client wanting to use discovery, would use the normal PLC4X API to connect and then would simply subscribe to the datastream produced by that. So in the end we wouldn’t be changing anything with the user-facing API and all could be done internally … and the cool thing we would get all the integrations working with this without modifications for free :-) … so you could start simply streaming the discovery data to StreamPipes or Kafka or log it in IoTDB for intrusion detection or other crazy stuff What do you think? I have to admit I am currently absolutely happy with this idea … so please … bombs away … tear it apart ;-) Chris
