DispatchBuddyversion 0.85 - May 8th, 2010
|Subscribe to Blue Labs Software|
|Browse Archives at groups.google.com|
What is DispatchBuddy?
DispatchBuddy captures LPR and AppSocket printer data from a sniffed or spanned ethernet, groks the embedded message, reformats it, fills in the applicable template file(s) then sends it out by various means such as emails and SQL storage.
DispatchBuddy was written for the South Meriden VFD to increase the reliability of receiving emergency dispatches. I started it in 2003 due to our frustration at the very unreliable Minitor II pagers we have. We currently use three forms of notification; the siren which is located on the firehouse, our portable pagers - which use 46Mhz and are very susceptible to location blackouts, and now our cellphones.
DispatchBuddy is free software, as in Open Source. It is released under the GNU GPL v3 license. In a nutshell that means you can have it for free, free as in speech and free as in beer. If you redistibute it with or without changes, you must freely provide the source. No warranty is offered or implied. Naturally I'd love to hear if you use it and I would enjoy reading over any patches sent to me.
- Smart recipient selection
- Embedded HTTP server for status
- Template based messages
- Various media used for message delivery (email, cellular, IRC, AIM)
What do I need to run DispatchBuddy?
- Receipt of fire/EMS dispatches via LPR or AppSocket on an ethernet
interface that you can promiscuously monitor. These messages should
be easily grokked with standard
- A Linux, BSD, or similar machine
- [option] A means to send emails to the internet at large via port 25/SMTP
- [option] (planned) A GSM modem (cellular account) for sending directly
- [option] IRC, AIM, or other IM account
What libraries and external tools do I need?
- PCAP library
- SSL (if you use an SSL psql session)
- sHTTPd, libshttpd.a is included in the source and linked in at compile time. (shttpd is going away and will be replaced by another embedded HTTP server)
- PDFlib-Lite (pdflib.org)
- May 8th, 2010 - Version 0.85
- Rewrote the parsing language yet again to handle another printer format with CAD 7
- rewrite most regex parsing using PCRE (libpcre)
- started adding cURL support, added twitter feed updates (not functional again as twitter migrated to OAUTH API)
- added support for libgooglevoice
- cleaned up more packet handling, made more robust
- finished the rcache handling
- valgrind cleanups
- printer wedge detection had to be tweaked due to CAD7 sending megabyte sized payloads (sends ~12 full pages, only prints 2 or 3..why?)
- config verbs updated
- started support on a gsmd module
- January 8th, 2009 - Version 0.80
- fixed the spurious abnormal PG termination
- IRC module got more work
- valgrind cleanups
- added --no-pdfs
- changed --loglevel to the more common --verbosity
- start using 8bit data streams
- removed TZ from SQL INSERT
- added code to detect wedged printer (stuck, out of paper, offline, etc)
- July 2nd, 2008 - Version 0.76
- add tools/glyph-boxer.c, this takes an xpm and finds all the glyphs in it. the glyphs get boxed and saved to a glyph file for human editing. once edited, the up and coming ocr code i'm writing can do 100% accurate image to text translation preserving layout. integration started
- added --source to the libpcap regex so you can have other print jobs sent to this printer from another IP and DB will ignore them
- PDF cleanups
- new GB ocr code put in place, nearly all glyphs found so the alphabet set should be entirely usable
- June 20th, 2008 - Version 0.73
- Added PDF printout capability, currently only used in the QA feedback report
- Added TCP reassembly, sorting, and duplicate packet handling
- Fixed up handling of Okidata divergence from Epson manual
- Added some tools from the gutenprint package and my own decoder
- Made --http more easy to disable, added truth values for representing "off"
- Started adding GOCR output for layout decoding
- Restructuring *incident
- Started being more semantically correct about protocol references
- Much of the protocol specific code has been sorted and better organized
- June 16th, 2008 - Version 0.69
- Reintegrated SQL storage
- Improved case number accuracy with hueristics
- Made more fault tolerant
- Event handling more streamlined with specific functions broken into separate handlers
- Improved SQL (re)connection and status handling
- make copy of TCP packets and decoded printer image to files
- June 4th, 2008 - Version 0.67
- Uptown dispatch converted from using LPR to using AppSocket without warning. Spent a week figuring out the new data stream, then hastily putting together a working skeleton. Eventually the code has been updated to bring it back to production design.
- July 4th, 2007 - Version 0.61
- Rewrote the SQL [re]connection routines and implemented server tickling to send a keep-alive query periodically. Cleaned up some more features (bugs), added the forking and pidfile and cleaned up some of the template handling.
- June 2nd, 2007 - Version 0.57
- More asynchronous SQL conversions. Updated status html template. Implemented more global stats.
- Started code to detect printer wedging by analyzing time periods between attempted print jobs that fail to be ACKed, needs to be tested. (I.e. someone left the printer offline or paper has jammed in it.)
- May 18th, 2007 - Version 0.52
- Added the external shttpd library to package. This is a prerequisite that should be installed per your distribution or by installing the library yourself. Get the library from sourceforge. be sure to get 1.37 or higher. CVS is also good because a lot of changes are going in (i.e. http://shttpd.sf.net/, for http://superb-west.dl.sourceforge.net/sourceforge/shttpd/shttpd-1.37.tar.gz)
- May 13th, 2007 - Version 0.51
- Added template support for messages. Three message types are supported right now, text/html, text/plain, and cellular. Added and updated man pages to match.
Where can I get it?
Please use SVN, it's more up to date, featureful, and of course has
newer bugs to replace older bugs. If you want a tarball, generate one via the websvn repository
browser. The last packaged source is for 0.61 at DispatchBuddy-0.61.src.tbz2
and the ascii
If you use Gentoo
Linux, there is an ebuild for
DispatchBuddy. The SVN commit messages are announced via my
Blue Labs Google Group.
SVN checkout instructions:
- cd /parent/directory/of/your/choice/ i.e. /home/david/svn
- svn co https://blue-labs.org/svn/BlueLabs/DispatchBuddy
This will add the subdirectory /home/david/svn/BlueLabs/DispatchBuddy and check out all the files into it.
Frequently Asked Questions
- Q. What License is DispatchBuddy released as?
- A. GPLv3
- Q. How does it work?
- A. DispatchBuddy does the following:
- Starts up, reads the /etc/dispatchbuddy/dispatchbuddy.conf file
- Listens to ethernet interface in promiscuous mode
- Captures all packets on LPR or AppSocket port (default is 9100 and it's configurable)
Uses a simple match to find the start of a specific pattern for a dispatch messageNow decodes the full LPR conversation and correctly grabs the files sent to the printer's LPD server. It then searches the dispatch message for specific patterns. If the inbound message is in a bitmap format (currently only ESCP2 supported), OCR is run against the image to extract the text.
- Upon match of those patterns, uses regexes to further match on the lines of text in the message
- Arranges all the matched data into a structure and does sanitiing on the text (cleans it up)
- Runs several SQL queries to build lists of recipients based on the type of message, time of day/week for recipient preferences.
- Creates N types of emails, i.e a rich message and a plain text message, for delivery to the appropriate recipients
- Sends the emails to respective destinations, i.e. plain text to cell phones, rich messages to regular mailboxes, but the destination and type is a preference set entirely by the recipient
- Stores the data in an SQL table
- Idles waiting for another packet
- Q. What future plans are there for DispatchBuddy?
- A. Adding the completed ability to send instant messages to clients on AIM, Yahoo, ICQ, MSN, and IRC (more possibly if there is an interest). I also plan to eventually add a direct SMS server like Kannel using an SMSC. This will allow for immediate delivery to all cellphones within seconds instead of a couple minutes total due to sequential delivery.
- Q. How do I configure it?
- A. Copy the example /etc/dispatchbuddy/dispatchbuddy.conf.example file and make your appropriate changes. Options are easily discovered by running dispatchbuddy -h
- Q. Are the regexes configurable?
- A. No, at present they are hard coded for the particular message body that SMVFD receives. You can see the POSIX regexes in the source code. They are easily adapted to your particular needs. In the future they will definitely be configurable. Each data item will have it's own regex specified in the /etc/dispatchbuddy/dispatchbuddy.conf file.
- Q. How is the server at SMVFD set up?
- A. The server has a primary ethernet interface connected to a cable modem. Another ethernet interface is plugged into a Foundry switch with VLAN tags for different networks. The printer port is mirrored into the server port. DispatchBuddy now interprets VLANs too.
- Q. Who writes this software?
- A. David Ford, of South Meriden VFD, is the author of this software. Development, site hosting, and server management, are done under the name of Blue Labs Software (website).