Ok ... picking up the ball on this again :-)
So yesterday I added 4 empty interfaces to the SPI. All are in the
"org.apache.plc4x.java.spi.discovery" package.
I guess I could probably omit the "SupportsDiscovery" interface which all
others extend, but I'll leave it for now.
In general there seem to be 3 types of discovery mechanisms (regarding network
technology):
1) Actively connect to a device
2) Passively listen to traffic
3) Send some broadcast packets (Not 100% sure about the name)
If I missed one, please tell us about it.
I guess the broadcast has to be differentiated a little as I have seen
broadcasts events being sent out and the other members respond by a broadcast
themselves or they send a direct packet to the source of the broadcast.
I also added a "discovery" driver in the sandbox, but that's just a work
proposal for now ... if we decide to do it that way, if we want to extend the
PLC4X API directly or even do both, I guess that's up to us. For now I'd like
to concentrate on getting first discoveries working somehow.
So my first steps would be to propose some methods in the corresponding
Discovery interfaces. As soon as that's done I would take a driver and try to
implement the discovery for that.
So ... my friends ... I really need your input on this ... I do know some of
you already have thought about discovery and I would like to channel these
thoughts into something productive :-)
Looking forward to some feedback.
Chris
Am 01.07.20, 16:00 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
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" <ottobackwa...@gmail.com>:
https://old.zeek.org/development/howtos/dpd.html
On June 30, 2020 at 13:32:57, Christofer Dutz
(christofer.d...@c-ware.de)
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"
<christofer.d...@c-ware.de>:
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
