It’s been a few months since the 1.0.2 release, and figured it would time to toss this one out there. I would consider 1.0.3 somewhat experimental, as it changes a bit of internal code as to how devices are logged and reported. It’s been tested pretty well pre-release, but keep an eye on it just the same. Highlights from the ChangeLog:

• Added -s option for syslog-only logging
• Default log filename now in the format “bluelog-YYYY-MM-DD-HHMM.log”
• Reduced file I/O during logging, should help performance
• Added Pwn Plug CSS theme for Bluelog Live mode
• Better support for Pwn Plug and OpenWRT specific options/features
• General improvements and cleanup for Live HTML 

Version 1.0.3 is in testing now, hopefully to be released in the next week or so. A lot of the changes in this build were under the hood things the normal user won’t encounter, but there at least two big additions:

1. The default log filename is now in the format: “bluelog-YYYY-MM-DD-HHSS.log”. Not only will this make it easier to manage log files, but will prevent Bluelog from continuously appending to the same file as it does currently. Of course, you still have the option of giving your own filename with the “-o” option.

2. For the first time ever, Bluelog has an option to disable the standard log file and instead only record new devices to syslog. This mode was added in part due to reports I got back from people using Bluelog’s syslog output in conjunction with syslog-ng to setup a mesh of Bluelog sensor nodes with one central logging server.

It’s been a long time coming, but as today’s RC 2 release, Bluelog has finally been included in BackTrack. Between this and being added to OpenWRT, pretty soon you won’t actually have to compile Bluelog yourself (where’s the fun in that?).

Well, that was quick.

1.0.2 was released to address a very specific change, namely the inclusion of Bluelog in the official OpenWRT package repositories. This means users will no longer have to build Bluelog themselves, so the Makefiles, scripts, and docs I had written up for setting up and building OpenWRT are no longer necessary.

There were no other major changes aside from the WRT-specific stuff, though I did increase the cache size for Bluelog when running on x86. I don’t think this will cause any kind of problem, but let me know if you have an issue.

I’ve pushed out the first release in the 1.0.x series today, and I’m already loving this extra decimal point. Granularity!

Bluelog 1.0.1 is a bug-related release…but not a bug of mine. This update is intended to help users who might be running Bluelog on a machine that’s still running Linux 3.0.x (Mint 12, Ubuntu 11.10, etc). When Bluelog fails on a machine running a 3.0.x kernel, it will now print a message about the kernel bug and tell users they need to upgrade their kernel. Hopefully this will help clear up some confusion.

The README has also been updated with information relevant to this kernel bug.

My involvement with The Powerbase has been steadily increasing. I’ve now put together an exclusive guide on building OpenWRT from source, which is a culmination of all the work it took to get Bluelog up and running on my OpenWRT device. I think I did a pretty good job explaining everything, and tried to improve upon the murky parts of the official documentation.

http://www.thepowerbase.com/2012/01/openwrt-build-guide-start-to-finish/

After just shy of two years in development, Bluelog 1.0.0 is now ready for release. I want to stress that the “1.0” designation of Bluelog doesn’t mean it is complete (there are still many things I want to do), but that it has proven itself stable enough to call it the first proper release.

Highlights of Bluelog 1.0.0:

• Completed OpenWRT build documentation and Makefiles
• Added Mobile version of Bluelog Live
• Many bug fixes to Bluelog Live
• Fixes for Ubuntu and Mint build environments

All in all, Bluelog 1.0.0 is perhaps not the most exciting of releases, but should be the most reliable and complete I have done yet. Head to the Bluelog page to grab the latest sources and tell me what you think.

Saw an excellent device for further Bluelog development up on DealExtreme today:

TP-LINK WR703N

This looks like a really awesome platform to get Bluelog up and running on; it’s extremely small, can be powered via batteries, and it’s even blue! It’s no Raspberry Pi, but I think it might just hold me over until that drops.

Anyone interested in making a donation for this, please contact me.

I did it more to keep some random cheese purveyors from stealing the name, but Bluelog now has it’s own Google+ Page. Not sure what I’ll really do with it yet, but I suppose it is a good way to attract more users/attention (maybe).

Well, it has been a few months since I cracked open the source for Bluelog, and I am happy to say that it hasn’t taken me long to get back into the swing of things. I already fixed a handful of issues I didn’t notice when working on the 0.9.9 release, and have made extensive improvements to the Live UI. Sometimes it helps to get a fresh look on an issue, I was probably pretty burned out at the end of the 0.9.9 cycle there.

I have also taken the time to greatly improve the OpenWRT build scripts, and as of Bluelog 1.0 they will be included with the source tarball. You will still need to build it on your own (there are way too many OpenWRT build targets for me to provide packages for), at least until I figure out how to submit Bluelog for inclusion in the OpenWRT repos.

Aside from those changes, I also intend to include a few new features. Likely manufacturer OUI lookups, and an improved way of handling “drive-by devices” (devices which only appear once on a partial scan). I am getting the feeling that the new syslog output mode will have to wait until 1.0.0+, when I get a whole new decimal point to screw up with.

More importantly, I wanted to give this opportunity to anyone who might be reading this to recommend their fixes or improvements. It has been very, very, hard to get feedback from the community on Bluelog; I don’t know if that is just par for the course with open source projects, or is a reflection on Bluelog itself…

So anyone who has anything to say about Bluelog, good or bad, please comment here or send me an email directly if you prefer. Any input is greatly appreciated.