Android Tip: More detailed stack traces

I noticed that stack traces generated by my app does not show any source file information next to the method names in the stack. This was really annoying as it would make it more difficult to narrow down the line causing the exception. I suspected this was due to debug information not being generated by the compiler and with a little hunting around in settings found the way to enable it:

Right click the project and select "Properties" -> "Java Compiler" -> check the "Add source file name to generated class file" checkbox.

You will likely need to check the "Enable project specific settings" checkbox first enable changing this setting.

Now it prints prints the source file and the line number making it much easier to figure out the source of the exception without having to attach the debugger.

Nexus 4

I put in a order for the Nexus 4 on December 4th when Google Play site was reporting 4-5 weeks delivery estimates, fully expecting to not get one till January 2013. Imagine my surprise when I received a email saying my Nexus 4 was shipped on the 6th, and lo behold I got it delivered on 7th :).


Was somewhat disappointed to find out that it did not support USB OTG though. Hopefully there would be some hack to make it work. Possibly in Cyanogenmod.

File share requests

I keep getting requests to share the files that I have posted in my earlier posts.

Just to clear the confusion, there is no need for this. All the files are shared as public and should be downloadable to anyone. You don't even need a Google account. Just click the Download option in the File 'menu' of Google Docs to download the file.

I did however found that the links for the NMUtils were broken in my previous post. These should be working now.

Altogether I'm not very happy with using Google Docs as a file sharing platform. In the future I think I'll use a account on GitHub or Google Code to publish any projects.

Wireless packet capture utilities for NetMonitor

Windows Vista introduced the long awaited feature of Monitor mode for normal everyday wireless adapters. While you still can't do packet injection without resorting to expensive solutions like AirPCap TX, it's still a very useful feature to have when testing wireless security.

However tools like airodump-ng doesn't support this method as of yet, and most of the good tools for working with this are in Linux anyway, so I was looking for a way to convert NetMonitor packet captures to tcpdump/pcap format when I came across the nm2lp utility by Josh Wright which does exactly that.

Unfortunately it seems to be incompatible with x64 Windows (At least not without recompiling as 64 bit binary) and crashed on my laptop. So in good opensource tradition I decided to reinvent the wheel, this time in C# and called it nm2pcap. Afterwards I also built a airserve-ng compatible server NMServe which uses NetMonitor API to capture packets and serve them to any airodump-ng client.

NMServe enables you to use a non USB wireless adapter with a airodump-ng instance running on a VMWare BackTrack 4 installation which you otherwise can't do since VMWare doesnt support non usb devices to be attached to the guest os. You could even use it with the windows airodump-ng binaries though that seems a bit flaky. The only snag is that it cannot put the adapter into Monitor mode automatically. You will need to do it manually using the nmwifi.exe which comes with NetMonitor before running NMServe. I'd probably fix this later.

The NMUtils binaries and the source code are available under LGPL v2 license.

Wiimote Whiteboard with Windows x64 support.

I updated Johnny Chung Lee's original Wiimote Whiteboard with a couple of new features and bug fixes including:
  • Compatibility with 64 bit Windows (Tested on Windows 7)
  • Automatic bluetooth pairing on MS Bluetooth stack
  • Minor ui updates


I'm calling it version 1.2 for no particular reason:

Wiimote newbie tips

Having recently come across the Wiimote whiteboard by Johnny Chung Lee, I bought a Wii controller to test it. I learned a few things which were not obvious on most blogs and wikis which might help out a new user:
  1. Wiimote Whiteboard v0.3 software on Johnny's blog does not work with Windows 7 64 bit.
  2. After pairing the Wiimote with the PC, the lights on the Wiimote keeps on blinking till it's turned off by software. I kept thinking that it was not paired properly when infact it was. I found the WPF wii data visualizer tool to be the best application to test that the controller is working properly.
  3. After every session you must pair the Wiimote anew. That is you should delete any existing paring with the wiimote from the bluetooth device manager and pair it again as if it was the first time.
  4. Sometimes even though the device is paired successfully the applications does not detect it's presence or does not receive any data from it. In these cases I found that you need to take out one of the batteries for a few seconds and then put it back again to reset it. Trying to sync it by holding down 1 & 2 or the red sync button did not seem to work.
  5. GlovePIE does work however you might have to disable the automatic connect (Click the "No Auto-Bluetooth Connect" option) and manually do the sync yourself, because sometimes it does not work.
  6. Most automatic connect software only work if you have a Microsoft bluetooth stack. If you have a Widcomm driver (my Dell Studio 1557 does) they usually do not work and you should pair the controller manually. Even software which does support the Widcomm driver like the Java Whiteboard did not work for me with the latest Widcomm driver. The only exception to this for me was GlovePIE though even that gave me trouble sometimes.
Of course all of the above is from my own experience with the Wii controller. Your milage will vary. You probably want to read the connection guide at WiimoteProject forum