Wednesday, August 21, 2013

Blocking Internet at specific times using Netfilter / iptables on OpenWrt Router

From the title, it should already be obvious that this will apply to a very specific case, but I'm sure there are parts of it that will be helpful in other scenarios too.  As is typical with Linux, the power is there, but the lengthy list of vaguely documented pieces and parts make it a challenge to get all the proverbial planets aligned.

What motivated me to sort all this out was a goal of implementing a reasonably cheap, reasonably reliable way to shut off internet access on the tablets my kids have during certain blocks of time each day.  I found a few things like DansGuardian and MIA (Mom's Internet Access) but they were either too complicated to set up, or didn't work on my hardware, or maybe there was some other reason I passed them by... can't remember now.  I also searched for this kind of step by step tutorial that would cover the major points for using iptables (a.k.a. netfilter) firewall rules in Linux to simply shut off traffic from certain devices.  I didn't find anything, so now I'm writing it...  so here goes...

Hardware

* This will probably work on most any wireless access point / router that has been loaded with OpenWRT, but for me it's all set up on a Netgear WNDR3700 v2.
* The rules are set up using the hardware / MAC address on the wireless tablets, which is something all WiFi capable tablets have, so there's nothing special about the devices that are being blocked.

Firmware

On the NetGear router, the stock firmware has been replaced with OpenWrt Barrier Breaker r34054. The version of OpenWrt that would apply to other wireless access points / routers may be different.  See the references below for a link to the OpenWrt compatibility page.  Getting OpenWrt loaded isn't too tough, but I'm not covering that here.

Skills

Most people who get past loading custom firmware on a router will be able to handle the rest of this, but it would help to know your way around an SSH client like PuTTY (ref below), have a basic understanding of networky things like IP addresses, MAC addresses, and understand a little about how timezones and UTC time relate.

Overview

When a wireless device connects to an access point, the network traffic is generally routed (also sometimes called "forwarded") through it to an internet connection.  When the operating system that runs on the access point / router hardware is derived from Linux, as OpenWrt is, there is usually a low level firewall technology built into the core (kernel) of the OS called iptables.  Understanding iptables rules takes a deeper understanding of network protocols and the specifics of packet level data, so there is often a higher level "firewall" product that simplifies how the rules are defined and generates more complicated rules for iptables.  This is also how OpenWrt is set up by default.

Details

iptables "time" module

iptables rules can be defined with -m time --timestart HH:MM:SS --timestop HH:MM:SS to limit the start and end time block within which the rule will be applied.
  • NOTE: The :SS part of the times may be omitted if it is just :00.  Example: --timestart 17:30 --timestop 18:45 is equivalent to --timestart 17:30:00 --timestop 18:45:00
  • WARNING: Somewhere along the way, the default interpretation of HH:MM:SS CHANGED FROM Local-TimeZone TO UTC.  The iptables version distributed with OpenWrt r34054 apparently uses the Local-TimeZone by default.  Documentation on newer versions of iptables says that the default interpretation of HH:MM:SS in iptables is UTC but that may not be the case.  Experiment to see how it actually behaves.
  • WARNING: timestart and timestop cannot cross midnight.  Newer versions of the "time" module for iptables support a --contiguous parameter, but that wasn't supported in the OpenWrt r34054.  If it is supported, it must be specified for a time range like the following to work --timestart 23:00 --timestop 01:00
  • WARNING: If the "Kernel TimeZone" is not in synch with the "Local TimeZone," iptables rules using local times may not behave as you'd expect.  If you have changed the "Local TimeZone" (maybe it was set incorrectly) and you have not rebooted the device (i.e. Linux) since changing it, execute the 'date -k' command to synch things up (or if you're a fan of how M$ Windows works, you could do a full reboot).
  • WARNING: In older versions of iptables, using UTC time requires --utc to be specified in the iptables rule.  The rules operate more clearly based on the UTC time (displayed with 'date -u'), but the tradeoff is that the HH:MM:SS times would not automatically adjust for Daylight Saving Time.
  • WARNING: (...ok this is really a repeat, but...) Older versions of iptables default to LocalTZ, so any documentation referring to the '--localtz' parameter may not apply to an older version of iptables.  Experiment to see how iptables is using the timestart and timestop before concluding that the rule just isn't working.
  • EXAMPLE: 8pm to 7am Mountain Daylight Time (MDT / UTC-6) does not cross midnight in UTC, so it could be specified in one rule:
                  "-m time --utc --timestart 02:00 --timestop 13:00"
  • EXAMPLE: 8pm to 7am Mountain Daylight Time (MDT / UTC-6) does not cross midnight in UTC, so it could be specified in two rules (not sure how you keep packets from squeaking by between 23:59:59 and 00:00, but that one second gap probably won't hurt anything):
                  "-m time --localtz --timestart 20:00 --timestop 23:59:59"
                  "-m time --localtz --timestart 00:00 --timestop 07:00"

iptables "mac" module

Many iptables rule examples you may find use the '-s' parameter to specify a source IP address to match the packets that are to be affected by the rule.  Many access points are set up to use DHCP, which automatically assigns an IP address from a pool of available addresses.  Unless special configuration has been added on the A/P / router, to assign a "static DHCP address lease" to a certain device, the device you're trying to block could end up having a different IP address and iptables rules that use '-s' or '--source' would block the wrong device.  Instead of relying on a dynamically assigned IP address, it is preferable to define rules based on the hardware / MAC address of the device, which will not change.

So, "-m mac --mac-source 9A:BC:DE:F0:12:34" would match packets from a specific hardware device with that MAC address.

NOTE: Some portable devices could have more than one MAC address if they had, for instance, separate radios for different speed WiFi connections (like one MAC address for 802.11B and a different MAC address for 802.11N)  Be sure to make a rule for all possibilities.

iptables "comment" module
Documenting what you've done is always a good idea.  There is a way you can build some commentary right into the rule so you can easily find it when you look at the output of 'iptables --list'  The comment module does the work.
-m comment --comment "This rule blocks Suzy's midnight surfing."

Putting it all Together

This example rule blocks a specific device from accessing the internet between 8pm and 7am MDT (UTC-6).

iptables -I forwarding_rule -m comment --comment "Shut off Georgie's tablet at night" -p tcp -m mac --mac-source 9A:BC:DE:F0:12:34 -m time --utc --timestart 02:00 --timestop 13:00 -j zone_wan_REJECT

NOTE: The target "zone_wan_REJECT" is probably specific to OpenWrt.  It may work in a normal iptables setup to simply specify the "REJECT" target.

Adding the Rule(s)

Using the LuCI web based administrative console for OpenWRT, navigate to the "Network" tab, then within that to the "Firewall" tab, then within that to the "Custom Rules" tab.  Enter the rules here as text and click the "Submit" button.  This just saves the new rules but the firewall must still be restarted to pick up the change.

Restarting the Firewall

There may be a way to do this in LuCI, but I never did find a way.  I found it was easier to SSH into the router using PuTTY and run "/etc/init.d/firewall restart"  An SSH/PuTTY session is also a good place to verify the clock. timezone. etc are set up correctly on the A/P / router.  The "date" command will show many of the clock related things of interest.

An Alternative Way to Generate Firewall Rules

OpenWrt has a higher level firewall configuration tool that generates iptables rules using a config file at /etc/config/firewall.  Some may find it more intuitive to define firewall rules this way so here's the reference page if that's what you prefer.  I abandoned defining my firewall rules this way because I couldn't figure out how to pass through much of what I wanted without just declaring it as "option extra" anyway.
* http://wiki.openwrt.org/doc/uci/firewall

References

Sunday, August 11, 2013

Sony RX100M2 / RX100 II WiFi "Send To Computer" Troubleshooting

This may help if you are attempting to send images to your computer from the Sony DSC-RX100M2 over a WiFi connection, but it is not working.

This deals with troubleshooting the connection from the camera to the computer once the actual WiFi connection is working.  There are numerous guides available to help getting the WiFi access point bit of it set up, so that part isn't covered here.  There may also be troubles getting this to work on a Mac, but I prefer to have some illusion of ownership for the things I've bought, so I don't purchase Apple products any more, and Mac issues aren't covered here either.

As with many consumer electronics products, the connection from Sony's camera to a Windows computer seems to rely on a "plain vanilla" Windows install, with a simple, single WiFi access point, and "plain vanilla" default network settings.  If you have more than one WiFi router, have installed a 3rd party (non Windows/Microsoft) firewall product like Norton or Comodo, or have shut down any of the numerous and vulnerable Windows network services, Sony's arrogant assumptions are probably not valid, and their WiFi function probably fails for one reason or another.

There is a step by step guide for setting up the WiFi connection between the camera and a computer on the PlayMemories Home support site here: http://support.d-imaging.sony.co.jp/www/disoft/int/playmemories-home/operation/import/wi-fi-dslr.html  However, that guide assumes everything in the network and Windows system is set up in simplest possible, all-default settings, "pristine lab" configuration.  Based on the number of posts I found where someone is having issues getting a WiFi connection to work from a Sony device, I'll make my own assumption and say that Sony's software generally doesn't detect or report issues with anything that is set up in a non-standard way.  It just quietly and frustratingly fails to work.

To be clear, this guide covers some troubleshooting to get the "Send to Computer" feature working on the Sony RX100M2 (sometimes called the "RX100 II" or the "RX100 Mark II").  On the camera, in playback mode, when you choose the menu option labeled "Send to Computer", the camera is supposed to connect to the WiFi access point, find a designated computer, and then transfer the media files from the camera to the computer.  If anything doesn't "just work", the instructions include no useful details regarding how to troubleshoot or fix the things that might be causing trouble.  I hope to have most of those issues documented here.  If anyone has sorted out other issues, please add a comment and share what you know.

PlayMemories Home

To start, you must have Sony's "PlayMemories Home" software installed on the Windows computer.  The installer should have been included on a CD packaged with the camera, but (at least as of 8/11/2013) it can be downloaded from Sony's PlayMemories support web site at: http://support.d-imaging.sony.co.jp/www/disoft/int/playmemories-home/  If that link no longer works, try a web search for "Sony PlayMemories Home Download"

  • PMBDeviceInfoProvider.exe - a Windows "NT" service named PMBDeviceInfoProvider gets installed and started when PlayMemories Home is installed.  If that service is not running, it may have been set to "manual" start or it may be failing to start for some reason.  Check in the "Services" control panel and troubleshoot using general techniques for Windows services (e.g. check event log, run the executable from a command prompt and look for errors, etc.)
  • PMBVolumeWatcher.exe - This background process gets set up to start automatically in a registry key HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run (at least that's where it is on a 64bit version of Windows 7).  If it isn't running (maybe because it was too annoying and had to be disabled using msconfig), then nothing will happen on the WiFi "send to computer," even if the RX100M2 connects to WiFi, finds the "target" computer, and is properly recognized as a DSC-RX100M2 device (shown in the Windows Device Manager under "Portable Devices"... more info on that later). 

Setting up the Camera for WiFi connection to a Specific Computer - USB Cable Required

This deserves a mini-rant since it completely ignores advanced users.  I'm sure the reason they chose to force you to connect the camera to a specific computer, with PlayMemories Home installed, is to dumb it down for people who aren't quite sure what the difference is between a computer and a piece of wood, but for most people who would bother to use the WiFi feature, they've taken far too much control over the settings of this feature, and hidden it all inside the PC software.  For instance, it is impossible to switch from one computer to another using the camera menus.  Ironically, the only way to configure the "wireless" connection is to plug in a wire.  LAME Sony!!!!  Ok, mini-rant done.

So, in this step you...
  • Start PlayMemories Home on the computer
  • Plug in the camera using a USB cable
  • Turn the camera on (not sure why it couldn't just listen for a signal from the computer end)
  • Wait for PlayMemories Home to detect the camera
  • Select the camera in the "menu list" along the left side of the PlayMemories window, where it should appear in the "Cameras and media" section.
  • When the camera is selected, then the "WiFi Import Settings" icon shows up on the right side of the PlayMemories Home window.  Click that icon and follow the prompts.
  • Note: The same WiFi Import Settings dialog/wizard may show up when the camera is first plugged into the USB port.

MTP IP Device driver

Sony's WiFi connection apparently depends on loading the camera as an MTP (Microsofts "Media Transfer Protocol") device.  If the device driver fails to load when the camera connects via WiFi, it may help to uninstall the device and let the driver install again.  If this is part of the problem, Windows Device Manager may show a generic "MTP IP Device" instead of the actual camera model, "DSC-RX100M2".  To check and fix this, follow these steps:
  • Open "Device Manager" (Right Click "Computer", select "Properties", then click "Device Manager")
  • With the USB cable disconnected from the camera, attempt to connect the camera to the computer by selecting "Send to Computer" in the Menu.
  • Watch the Device Manager window for the "Portable Devices" section (alphabetically near "Other Devices" and "Ports")
  • If a generic "MTP IP Device" item shows up in either "Other Devices" or "Portable Devices", right click it and select "Uninstall"
  • Click the button on the camera to cancel the connection attempt
  • Attempt to connect the camera to the computer again.
  • If that was part of the problem, the camera should now show up in "Portable Devices" as "DSC-RX100M2"
Note: It isn't clear how the MTP framework gets initialized or installed in Windows 7, but some info on the web suggests that it is related to installing Windows Media Player v10 or v11 on older versions of Windows (e.g. XP).  If the "Windows Media Player" that is bundled with Windows 7 has never been started, it might be necessary to start it once and go through the initial setup dialogs before the MTP stuff will work for the Sony camera.  If anyone tries this and discovers that it actually makes a difference, please comment and confirm that for others.

Using a Firewall Product other than "Windows Firewall"

PlayMemories Home assumes all Windows users are using the built-into-Windows "Windows Firewall" so when it tries to set up the WiFi configuration for a camera, it tries to modify the "Windows Firewall" configuration.  If you're using some other firewall product like Norton or Comodo, PlayMemories Home won't configure it to allow the network traffic.  Another post on Sony's message forum suggested that the ports that needed to be opened were UDP 1900 and TCP 2869 but that information might not be entirely correct.  If I find a definitive answer, I'll update this, but for now, here's what I've found.
  • A quick easy test to see if a firewall is blocking something is to temporarily disable the firewall while you try it.  If things start working, then it might be worthwhile to check the firewall's logs (which may require turning on verbose logging) and find out what got blocked.
  • There is a Windows service named PMBDeviceInfoProvider that gets installed with PlayMemories Home but it doesn't seem to be the process that actually listens for the camera on the network.
  • There is a windows process named WUDFHost.exe that is somehow involved with the transfer of data from the camera to the computer.
  • Port 2869 is normally associated with the Internet Connection Sharing service according to this: http://www.speedguide.net/port.php?port=2869  Also, if the ICS service is started when there is nothing configured to use it, it just stops again immediately with the following message: "The Internet Connection Sharing (ICS) service on Local Computer started and then stopped.  Some services stop automatically if they are not in use by other services or programs."  So, it seems unlikely that the listener on port 2869 has anything to do with the Sony camera or PlayMemories Home.

More Resources and References


Other Posts About Similar Issues

Friday, August 2, 2013

Using HDR/DRO on the Sony DSC-RX100M2

This is intended to be a quick introduction to what the HDR (High Dynamic Range) / DRO (Dynamic Range Optimization) feature does for you on the Sony DSC-RX100M2.  It is also a tip on one thing that it does "to you" instead of "for you."  Here are two shots taken of a scene that demonstrates both the benefit from in-camera dynamic range processing, and a common pitfall.

Click on the image to see full size.
Where the dynamic range settings help is to balance the overall exposure in a scene with both extremely dark areas and extremely bright areas.  The camera takes multiple exposures in quick sequence to capture details in dark areas by over-exposing a frame, capture details in bright areas by under-exposing a frame, and capture a baseline for color, white balance, etc. from a frame taken at the "proper" metered exposure.  Examine the enlarged areas in the first row beneath the two full photos to see the improvement when DRO is enabled.

One area where the high dynamic range feature can degrade a photo is in areas of the scene where the subject actually should have higher contrast.  In the second row, the shadows that add texture detail amongst the leaves of the iceplant nearly disappear into a solid green blob after the dynamic range has been "improved."

LG TV Quirks II - Anamorphic Video Flag

Before getting into the details, readers should know that this post is about the LG TV built in video player (firmware) for streaming DLNA content. Particularly, this is what I have found out so far regarding the LG TV's inability to recognize the "anamorphic" flag in video content that should result in the video player stretching the width of the pixels to fill the screen side-to-side. This really only applies to video content that carries the "anamorphic" flag so it mostly affects people who are attempting to re-code their DVD collection into video files that can be streamed from a DLNA server. I had hoped that sometime during the past year, LG would update the firmware on the TV and fix the DLNA video player, but as of firmware version 5.00.04, it is still not fixed.

Now for some details...

Background

This issue occurs when the LG TV attempts to play HD (16:9 ratio / wide-screen) content which has been recoded (not recorded... recoded) from DVD media to a mkv, m4v or mp4 video file using a tool like Handbrake. DVD content is always stored as a 720:480 picture which was originally intended for the 4:3 aspect ratio typical on tube TV sets that were most common when DVDs were introduced.
    You might be wondering why the picture size is 4:3 when the numeric ratio is 3:2. It doesn't exactly work like that because only the width (720) is a pixel-count resolution. The height or "y" dimension is a scan-line count. Those old tube TVs show scan lines taller than each of the pixel dots across the line, so they're not square... but I digress.
Over the past few years, HD, which is intended to be displayed on a wide screen at a 16:9 aspect ratio has taken over as the standard picture size. HD flat screen TV sets and projectors (e.g. "Full" HD 1080i/p at 1920:1080 or 720i/p HD at 1280:720) have become far more common. Nearly all TV series seasons/collections of recent shows are published on DVDs which are "rigged" to display the 720 pixels in each line wider (instead of narrower). Some older DVDs delivered the wide-screen picture ratio by including actual black bands above and below the viewable picture area. (Some DVDs of movies that have an original aspect ratio that is wider than 16:9 still do this.) Including the black bands in the picture in order to deliver the correct aspect ration diminishes the overall quality because it uses only part of the available height for actual picture data (the black band part) is just discarded.

To improve the picture quality, most recent DVDs, especially those with HD TV content, carry a special flag on the video stream that tells the player how to stretch the picture's width to reproduce the original picture size. This allows the picture to be stored on the DVD at the full height, without the wasted "black band" areas. The stored picture is squeezed from side to side to fit within the 4:3 picture ratio so that when the player stretches it back out to 16:9, it looks right again.

The problem with the LG TV (at least the 5500 / 5600 / 5700 models) is that the video player ignores that flag and DOES NOT STRETCH THE PICTURE AS IT SHOULD. As a result, the picture displayed on the LG TV appears squeezed from side to side.

It looks like LG TV owners are just out of luck on this issue. Samsung TVs seem to handle the anamorphic video flag in content just fine. Set top boxes like the WD TV Live also stretch the video to the proper size. It appears to be a problem that only the LG TV, maybe only the 55LW5700, but probably most of the LG TVs that are ironically marketed under the "SMART TV" logo.

Solution(s)

Since it doesn't look like LG will ever get this fixed, their TV sets just won't correctly display any video content that is originally from a DVD if the content is in HD / wide screen format. In other words, if the video content is encoded such that it depends on the video player recognizing the anamorphic video flag to properly re-size / stretch the picture, LG's built in player isn't up to the job.

Solution 1 is to just abandon the built in player and buy a set-top streaming box like a WD-TV Live. The HDMI output from a box like that will fill the screen as it should without requiring the source video file (m4v, etc.) to be recoded.

Solution 2 is to recode all the content with the anamorphic flag disabled. This requires some investigation of what the proper size ratio of the picture should be for each DVD and requires manually setting the output picture size in the recoding tool (at least in Handbrake). If you already have a large amount of recoded content that would need to be recoded, this isn't a very attractive option. Recoding video including a physical re-sizing of the picture dimensions is time consuming and requires a great deal more computer processing power than a typical straight-through, frame-by-frame picture transcode.

References:

* http://forum.videohelp.com/threads/329912-MKV-Anamorphic-Problem-Encoding-In-Handbrake
* http://en.wikipedia.org/wiki/Anamorphic_widescreen
* http://forum.serviio.org/viewtopic.php?f=12&t=2334
* https://trac.handbrake.fr/wiki/AnamorphicGuide
* http://www.lg.com/us/smart-tvs
* http://www.amazon.com/s/ref=nb_sb_noss_1?field-keywords=wd%20tv%20live
* http://en.wikipedia.org/wiki/Display_resolution
* http://forums.plexapp.com/index.php/topic/26123-supported-file-formatscodecs/

Thursday, August 1, 2013

Dell M6700 Laptop Wacky Window Focus Foreground Background Always-On-Top Issues

The Problem

Running Windows 7 64bit, the window focus on a Dell Laptop goes completely nuts.  Clicking on some windows sends them behind other windows.  Moving the mouse pointer across the title bar of background windows brings them to the front with no click.  Some windows get "stuck" on top of others.

The Tell

In the title bar of each window, just to the left of the minimize, maximize, and close buttons, a small windowpane appears when the mouse pointer is over the title bar of that window.  Also, when the window focus has gone nuts, using alt-tab to cycle through the current set of windows may reveal a transparent ghostly looking window titled: DP_MenuBar_Window

The Villain

A color management utility / driver / manager, or whatever you'd call it supplied by "PremierColor" has a flaky, buggy, shouldn't-have-been-released, was-probably-never-tested, "plugin" named "display splitter".  Dell passes this junkware along to their soon to be previous laptop customers, infuriating them and inspiring many foul things to be said about Dell.

The Hero

Someone posted the question on Dell's own forums, and there's actually an answer (which is a rare thing to find).  However, it isn't easily found because it doesn't match many of the keywords you might use to find it, like focus, hover, hovering, switching windows, title bar, stuck on top, foreground, background, Windows-7 64bit, Dell, laptop, swap, reverse, control, always-on-top, issues, problems bugs, random, front, back, top, bottom, underneath, over, control panel, personalization, "ease of access center", "make the mouse easier to use", "Activate a window by hovering over it with the mouse", and other stuff I'll add if I think of it.

The Happy Ending

You could either read the forum post link below, or you could cut to the chase and disable the buggy "display splitter" plugin, leaving the rest of the PremierColor thing functional.
  1. Find the PremierColor system tray / notification area icon.
  2. Right click it and select "Exit" from the popup menu
  3. Navigate to c:\Program Files (x86)\Common Files\Portrait Displays\Plugins
  4. Rename, move, delete, or do something to hide the "DP" directory
  5. Open the start menu and restart the PremierColor thing
  6. Verify that the "display splitter" part of it is no longer active by checking to be sure the little windowpane icon on each window's title bar is gone.
  7. Enjoy the sanity that comes from knowing your windows will no longer change focus unless you actually click on them... as it is supposed to be.

Reference:  The forum post on Dell's site