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
Bluelog 1.0.3 Status
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.
Well, it’s been awhile since I updated the site. Apologies. Other things have come up, but I do still maintain DigiFAIL.
Today’s update is my customary web-version of a recently published 2600 article. This one is the somewhat embarrassing reconsideration of my opinion on the CR-48 and Chrome OS in the wake of my home being robbed. Who would have thought.
For those following my QR campaign, you may be interested to know that in this issue, 2600’s editorial staff decided to willfully disobey the request that my contact QR code be placed in the head of the article. This if of course after the staff instructed authors to include their own QR if they wanted it to be displayed. I will take this to mean that, as usual, 2600 has decided to be stalwartly archaic and abandon the use of QRs.
Bluelog added to BackTrack 5 RC2
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.
Simultaneous 2600 Articles Accepted
This is a bit strange. I just received emails stating that two separate 2600 articles I wrote and submitted 4 months apart have both been accepted. With the way the submission system usually works, this seems to indicate that both articles will be published in the same issue.
I don’t have a problem with that, as such, but it would be a little odd. I always think it’s strange when I see an author with multiple articles in the same issue, and now it seems like I might be one of those guys. Guess we’ll find out.
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/
