I stopped using the particular network probe (an Android app) and now those syslog messages have stopped. It does seem that it was "spraying random bits" as Radosław suggested.
Regards Chris Wilkinson On Thu, 3 Oct 2019, 2:40 p.m. Radosław Korzeniewski, < rados...@korzeniewski.net> wrote: > Hello, > > pon., 30 wrz 2019 o 18:12 David Brodbeck <brodb...@math.ucsb.edu> > napisał(a): > >> >> >> On Fri, Sep 27, 2019 at 1:42 AM Radosław Korzeniewski < >> rados...@korzeniewski.net> wrote: >> >>> Hello, >>> >>> czw., 26 wrz 2019 o 18:57 David Brodbeck <brodb...@math.ucsb.edu> >>> napisał(a): >>> >>>> I deliberately have this set up because I want to know if the director >>>> crashes. Does mean I have to put up with one of those messages every ten >>>> minutes though. ;) >>>> >>> >>> To check if a Director is working you should just use a proper probe. >>> Checking if any service is running by spraying around random bits is >>> insane, IMHO. When you check if HTTP server is working you just perform a >>> proper HTTP GET request and expect a 200 response, right? >>> >> >> It doesn't actually spray random bits, >> > > But at the OP case it is, just take a look: > > Sep 22 11:50:53 HOMESERVER bacula-fd: job.c:508 FD expecting Hello got > bad command from 192.168.1.30. Len=-4. > Sep 22 11:50:53 HOMESERVER bacula-sd: bsock.c:517 Packet > size=121984032 too big from "client:192.168.1.30:46789". Maximum > permitted 1000000. Terminating connection. > > > >> just checks to see if it can connect to the TCP port, then immediately >> disconnects. >> > > I do not know what type of probe you use and I believe that a standard TCP > probe will fire errors too. > > >> It's a basic check to see if the director process has crashed or locked >> up. I set this up because it used to do that pretty regularly, but >> fortunately the more recent versions have been pretty stable. I was >> actually a little surprised that bacula considers it an error (as opposed >> to, say, a debug-level message) when a connection is made without sending >> any commands; most other daemons I'm familiar with ignore that sort of >> thing. >> >> BTW, regardless of what I do the central IT department here runs >> vulnerability scans on my subnet every so often, so this is going to happen >> from time to time anyway. >> >> HTTP is a little different because it's an open protocol. >> > > The same as Bacula. The only difference is that HTTP has RFC but Bacula > doesn't. > > >> Bacula's protocol is proprietary and AFAIK not intended for random >> "unofficial" clients to connect to, >> > > What? Who tell you a such lies? > > >> so writing a more "correct" test would be tricky. >> > > Because on low-level it is a binary protocol and not as plain ascii as > HTTP it doesn't mean it is tricky to write a custom client. It even support > a standard TLS/SSL as an encryption wrapper the same as for HTTPS but > clevier as it is using the same single port for both secured and unsecured > connections. > > Could you, please read the "Bacula Developer’s Guide" manual and > especially chapter 5 - Daemon Protocol. You can check the current > implementation directly in source code. I have no information that this > protocol is patented in some way or another and I modified it when > implementing some new features. > > best regards > -- > Radosław Korzeniewski > rados...@korzeniewski.net > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users >
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
