Induro BHL1 Ballhead

A couple of years ago I bought the Arca-Swiss Z1 Monoball (with flip-lock) to support my Nikon D300 with several lenses. An excellent ballhead which would last you a life time (that's what I said at the time). And that statement is still valid, IF I was still shooting with (large) DSLR's. In the mean time I sold my DSLR and went for something a bit more compact with the Fujifilm X-T1.

Scaling down on the camera part means that I can also scale down the accessories. A smaller and lighter camera doesn't need a beast like the Arca-Swiss Z1 Monoball for tripod support. Something smaller and lighter (and cheaper) would also suffice.

Induro Ballhead BHL1

Looking around on the Internet I ran into the Induro brand. They make tripods, monopods, and (ball)heads. The one I got is their smallerst BHL ballhead (BHL1).

It's relatively small (compared to the Arca), and about 200grams lighter, while it's still capable of bearing a 20kg load. Not that my current gear comes even near that weight.

It also has the main features of the Arca-Swiss Monoball. Nice bog knobs, with variable friction setting. It also comes with a all-round camera plate (PU60), and a nice bubble-level. The latter is kinda small, so I don't know if it's very usable in the field.

I use the included PU60 plate on my Nikon P7000 P&S camera if necessary. The Wimberley P-5 is my preferred plate under my M9. The Fuji X-T1 is using a Really Right Stuff L-Plate (BXT1). I tested the PU60 on my M9, but even with the rubbery pads on the plate, I could still easily rotate the plate under the camera. This doesn't happen when I use the Wimberley P-5 plate.

This shouldn't be a problem in everyday use, but when you want to do some long-exposures, you don't want the camera to move around the plate itself.

The following photos might give you some idea of the ball head with the included PU60 plate.

The tension on the ball is adjustable (by the 'wheel' in the large knob. It allows you to maintain movement of the ball head, but when you let go of the camera, it stays in the position when you let go. The adjustment can be done with the tip of your finger. If that is hard, you can also use a small coin (or screwdriver) to adjust the friction setting.

It also features a locking mechanism that makes sure that you don't accidentally 'loose' the camera when moving around. This might happen when you loosen the plate. One condition is that the plate attached to the camera has 'stop screws' on the bottom. If these are present, you need to pull and turn the release knob. After that you can safely remove the camera from the ball head.

Posted on August 1, 2014 and filed under Gear, Photography, Review.

Juniper SRX210 Sudden Back-To-Factory Defaults

Earlier this week I configured an Juniper SRX210 for testing. The configuration consisted of several security zones, IDP, UAC (layer3 enforcement) and Application Firewall and Identification. The Junos version I used was JUNOS 12.1X46-D15.3.

This setup worked until today. Today, the SRX was unresponsive. No ICMP reply, no SSH access, nothing. Accessing the SRX via the serial console showed me the Amnesiac login. This means that the configuration is gone. At least the configuration I created was reset to the factory defaults config. A typical WTF!!! moment.

Fortunately, I had configured logging to an external source (Splunk). So I went to investigate. Turned out that the SRX stopped sending syslog messages around 01:30PM. Further investigation showed that the config was actually reset (UI_FACTORY_OPERATION event), and checking the event-codes, it was (probably) done by pressing the reset button on the device.

(the following logging should be read bottom-top)

May 28 13:28:30 10.0.0.1 1 2014-05-28T13:28:30.808+02:00 srx210 mgd 6211 UI_COMMIT_PROGRESS [junos@2636.1.1.1.2.36 message="finished copying juniper.db to juniper.data+"]
May 28 13:28:30 10.0.0.1 1 2014-05-28T13:28:30.369+02:00 srx210 mgd 6211 UI_COMMIT_PROGRESS [junos@2636.1.1.1.2.36 message="copying juniper.db to juniper.data+"]
May 28 13:28:30 10.0.0.1 1 2014-05-28T13:28:30.369+02:00 srx210 mgd 6211 UI_COMMIT_PROGRESS [junos@2636.1.1.1.2.36 message="finished loading commit script changes"]
May 28 13:28:30 10.0.0.1 1 2014-05-28T13:28:30.368+02:00 srx210 mgd 6211 UI_COMMIT_PROGRESS [junos@2636.1.1.1.2.36 message="no transient commit script changes"]
May 28 13:28:30 10.0.0.1 1 2014-05-28T13:28:30.368+02:00 srx210 mgd 6211 UI_COMMIT_PROGRESS [junos@2636.1.1.1.2.36 message="no commit script changes"]
May 28 13:28:30 10.0.0.1 1 2014-05-28T13:28:30.367+02:00 srx210 mgd 6211 UI_COMMIT_PROGRESS [junos@2636.1.1.1.2.36 message="start loading commit script changes"]
May 28 13:28:30 10.0.0.1 1 2014-05-28T13:28:30.133+02:00 srx210 rmopd 1350 PING_TEST_COMPLETED [junos@2636.1.1.1.2.36 test-owner="XS4ALL" test-name="testsvr"]
May 28 13:28:30 10.0.0.1 1 2014-05-28T13:28:30.355+02:00 srx210 mgd 6211 - - auto-snapshot is not configured
May 28 13:28:28 10.0.0.1 1 2014-05-28T13:28:28.814+02:00 srx210 mgd 6211 UI_LOAD_JUNOS_DEFAULT_FILE_EVENT [junos@2636.1.1.1.2.36 pathname="/etc/config//srx210h-defaults.conf"]
May 28 13:28:27 10.0.0.1 1 2014-05-28T13:28:27.823+02:00 srx210 mgd 6211 UI_LOAD_JUNOS_DEFAULT_FILE_EVENT [junos@2636.1.1.1.2.36 pathname="/etc/config//jsrxsme-series-defaults.conf"]  
May 28 13:28:27 10.0.0.1 1 2014-05-28T13:28:27.217+02:00 srx210 mgd 6211 UI_LOAD_JUNOS_DEFAULT_FILE_EVENT [junos@2636.1.1.1.2.36 pathname="/etc/config//junos-defaults.conf"]   
May 28 13:28:26 10.0.0.1 1 2014-05-28T13:28:26.808+02:00 srx210 mgd 6211 - - WARNING: activating factory configuration
May 28 13:28:25 10.0.0.1 1 2014-05-28T13:28:25.378+02:00 srx210 mgd 6211 - - WARNING: removing all configurations
May 28 13:28:25 10.0.0.1 1 2014-05-28T13:28:25.232+02:00 srx210 mgd 6211 UI_FACTORY_OPERATION -
May 28 13:28:25 10.0.0.1 1 2014-05-28T13:27:35.000+02:00 srx210 rmopd 1350 PING_TEST_COMPLETED [junos@2636.1.1.1.2.36 test-owner="XS4ALL" test-name="testsvr"]
May 28 13:27:19 10.0.0.1 1 2014-05-28T13:26:39.941+02:00 srx210 - - - - last message repeated 11 times
May 28 13:17:19 10.0.0.1 1 2014-05-28T13:16:34.309+02:00 srx210 - - - - last message repeated 11 times
May 28 13:07:19 10.0.0.1 1 2014-05-28T13:06:28.346+02:00 srx210 rmopd 1350 PING_TEST_COMPLETED [junos@2636.1.1.1.2.36 test-owner="XS4ALL" test-name="testsvr"]
May 28 13:05:33 10.0.0.1 1 2014-05-28T13:05:33.297+02:00 srx210 rmopd 1350 PING_TEST_COMPLETED [junos@2636.1.1.1.2.36 test-owner="XS4ALL" test-name="testsvr"]
May 28 13:04:38 10.0.0.1 1 2014-05-28T13:04:38.248+02:00 srx210 rmopd 1350 PING_TEST_COMPLETED [junos@2636.1.1.1.2.36 test-owner="XS4ALL" test-name="testsvr"]
May 28 13:04:19 10.0.0.1 1 2014-05-28T13:04:19.548+02:00 srx210 utmd 1380 AV_PATTERN_UPDATED [junos@2636.1.1.1.2.36 version="05/28/2014 12:36 GMT, virus records: 522178" file-size="18635751"]
May 28 13:03:42 10.0.0.1 1 2014-05-28T13:03:42.934+02:00 srx210 rmopd 1350 PING_TEST_COMPLETED [junos@2636.1.1.1.2.36 test-owner="XS4ALL" test-name="testsvr"]

This is strange, since there was no one around at the time. So it must have been some sort of bug that caused this.

Thankfully I had a backup of the config, so the device was up and running again within 10 minutes. So now I have to keep an out out for this. Especially the next couple of days.

UPDATE: There's is definitely something wrong with the hardware. I tried different Junos versions (also stable recommended versions), and different configs, but for some reason the device detect a 'Config button pressed' event and goes back to the default factory config. This happens within 12 hours.

The device keeps going back to the factory default config. Today I changed the behavior of the reset button. The reset button doesn't react to physical interactions when adding the following line to the config:

root@srx210# set chassis config-button no-clear no-rescue

Let's see if that helps. If it does, it means that the hardware reset button (mechanism) is malfunctioning.

UPDATE 2: looks like the config button config did the trick (so far). The device is still up-and-running for nearly 24 hours. -keepingfingerscrossed-

UPDATE 3: and we have a winner. The SRX210 is still operational. Just need to remember to add the command when I reconfigure it. Perhaps a sticker on top as a visual reminder :-)

Posted on May 28, 2014 and filed under Annoying, Junos, Security.

Stephen Colbert On Amazon's Latest Patent

Amazon patented the practice of photographing objects against a white background... Huh? What the F*ck?

Well, that's exactly what Stephen Colbert thought;

I guess that I'm not the only one violating that patent.

Dandelion seed against a white background

Posted on May 18, 2014 and filed under No Way!!!, Fun, Video, Photography.

Continuous Macro Lighting

When shooting macro, you need a lot of light. Normally you would use one or more (off-camera) flashes to facilitate this. The downside of a flash is that you only get the light when you press the shutter button. This can be challenging a relative low-light environment.

A solution for this is continuous lighting.

The traditional continuous lighting setups would get really hot. A couple of hundred Watts of power was nothing, and, in a small workspace, things could get hot (literally).
Thankfully, we have LED lights nowadays. Small (battery powered) devices with a lot of bright LED's, which are very affordable.

I bought a set of video lights on Amazon with 160 LED's (NanGuang CN-160) each. The devices are battery powered and give a lot of light. The video lights have a dimmer, so you can control the amount of light.

NanGuang CN-160 Video Lights

They take several types of batteries. Including 6 AA-type rechargeable batteries. The problem with the AA batteries is that they drain relatively fast, so I got a set of supported batteries, which normally go into a Sony camcorder (NP-F750F). Not the originals, but a cheaper knock-off. Another advantage of the larger batteries over the AA-types is that the amount of light produced is significant higher, and lasts for a longer period of time.

Batteries not included

The lights itself are relatively light, but with the batteries they tend to weigh around half a kilo each. So this is not a practical setup for handheld macro photography in the field.

To give you an idea of how much light they produce: The following photo was made in a dark room with one of the video lights on full power with the included diffuser. The camera (handheld) / lens settings were:

  • Camera: Fujifilm X-T1
  • Lens: Sigma 105mm F/2.8 Macro DG (F-mount with a X-adapter)
  • Shutter: 1/600
  • Aperture: F/8
  • ISO: 400

All I need right now is to create some sort of a flexible (portable) workspace with a way of positioning the lights independently around the subject.

UPDATE: I received my cheap flexible tripods and (even cheaper) ballheads by mail today. This should make the lighting for my macro photography a bit easier.

The total cost of this setup is around €150 (depending on the currency exchange rate).

Note: The setup is sufficient for the (cheap) LED-lights, but I wouldn't trust them with my Leica or Fuji camera.

Posted on April 25, 2014 and filed under Gear, Hardware, Photography, Tips'n Tricks.

Just Apply Pressure

to wreck the SD-card slot cover of the Fujifilm X-T1. An obvious design flaw if you ask me.

Thankfully, I handle my camera with care, but I don't want to think what would happen if I applied a bit more pressure on closing the memory-card compartment.

Posted on April 25, 2014 and filed under Annoying, Gear, Hardware, Photography.

Domain User Membership check via LDAP

When you are using LDAP to determine Windows Active Directory group membership, and the group you are aiming for is the Domain Users group, than you're in for a surprise. It turns out that the LDAP interface doesn't have the Domain Users group listed for a user. It's missing the memberOf attribute for Domain Users. Just compare the following screenshots. The first screenshot shows the Active Directory user interface for the user Administrator, and the second shows the LDAP equivalent of that same user.

Active Directory group memberships

LDAP group memberships

The LDAP output doesn't show a 'memberOf: CN=Domain Users, CN=Users, DC=testdomain, DC=local' attribute.

The reason is that Active Directory has a so-called Primary Group attribute, and this is by default the Domain Users group. With that piece of information you might see a LDAP attribute called 'primaryGroupID' with a number. That number represents the Domain Users group.

So if you need to check for Domain User membership with LDAP, you should check the value of the primaryGroupID attribute. This value is (for as far as I know) always the same (513).

So if you're using Certificate based authentication on a Juniper Pulse Access Gateway or Pulse Access Control Service, and you need to check Windows Domain User group membership the primaryGroupID is the way to go.

B.t.w., if you're looking for a good cross-platform LDAP browser, I can recommend the Apache Directory Studio. It's intuitive, has a good interface and just works (oh... and it's free).

No EAP Protocol Was Agreed On

Having the opportunity to experiment with some Juniper security products at home has its (dis)advantages. Juniper offers a (limited) virtual appliance version for both the Unified Access Control appliance (aka the Infranet Controller or Pulse Access Control Gateway), and the SSL VPN solution (aka Secure Access or Pulse Secure Access Gateway).

The limited parts are:

  • SSL is limited to 3 concurrent users
  • UAC is limited to 5 concurrent users
  • You cannot add additional licenses
  • The UAC has no IF-MAP server capabilities, since that requires at least a 50 user license (and you cannot add additionel licenses).
Max. 3 concurrent SSL VPN users

Max. 3 concurrent SSL VPN users

Max. 5 concurrent UAC users

Max. 5 concurrent UAC users

So yes, it's crippled, but still very nice to play with in a lab or home/study environment.

Anyway, I have both the UAC and the SSL VPN running at home. Both running in  VMWare Fusion on a MAC OSX server (Mac Mini).

A couple of months ago, Juniper released a new major version for the software (v5 for the UAC, and v8 for the SSL VPN), so I wanted to upgrade the VM's to the latstes software (also because of the Heartbleed bug in OpenSSL). This was no problem for the SSL VPN. The upgrade went smooth. However, the UAC was a different story. For some reason, the upgrade package was corrupt or invalid (even though it could be used to do a clean install), so upgrading was out of the question.

So I tried to do a clean install and see if I could import the old config of the existing UAC (v4.4) in the new version 5. Something that didn't work in the older versions of both the SSL VPN and UAC. Importing a software version meant that you needed the correct software version on the device first.

Anyway, importing the system config seemed to work, because all visible settings were correct. The XML import (other configuration settings regarding authentication servers, realms, user roles, etc.) also imported correctly (or so it seemed).
I compared the two configs side by side, and everything checked out. That was until I tried to authenticate on a switch with 802.1x. That didn't work as it should.

The logging of the UAC showed numerous 'No EAP Protocol Was Agreed On' errors. This was weird, because everything worked correctly on the older version.
Since the EAP protocol relies (for a part) on the SSL certificate on the device, I swapped that one for a new certificate from my personal PKI service.

After having checked, and double checked everything (I even tried authenticating against the older UAC version... which still worked), I decided to do a clean install (back to factory settings), and reconfigure the entire UAC by hand instead of the import.

Guess what, everything worked great after I had copied everything by hand.

So I guess that the import of a XML file belonging to a earlier software version still doesn't work. Only difference is that in the old days I got a warning/error.

So if you're getting the 'No EAP Protocol Was Agreed On' error in your events logging, and you did a recent upgrade, you might want to try a fresh install and configure things by hand.

I have no idea if this is applicable to the 'normal' hardware appliances with the software.

Posted on April 13, 2014 and filed under Security, Software, Tips'n Tricks.

Fujifilm X-T1 and Lee Filters

Lee Filter System

Lee Filter System

During the time with my Nikon D300 I always used regular (thread) filters (circular polarizers, and ND filters). Since the release of the Fujifilm X-T1 I wondered if a Lee filter system might be better / more flexible (not cheaper!!!!).

At the moment they offer the normal 100mm filter system and the new 75mm filter system (Seven5). The latter is designed specially for the smaller camera's (MFT, Mirrorless APS-C, etc.).

Fujinon XF 10-24mm f/4 R IOS

The Seven5 series is cheaper since it uses smaller filters (75mm versus 100mm), and since my Fujifilm X-T1 uses relatively small lenses this could be a winner (the kit lens has a 58mm filter thread). Until I found out that the new ultra wide angle Fujinon XF 10-24mm F/4 R OIS has a 72mm filter thread. And as you might guess, I'm really interested in that lens.

Fortunately, Lee has a 75-to-72mm adapter, so technically the Seven5 system can be used with that lens.

Adaptor ring thread sizes:
The holder attaches to the lens via a screw-in adaptor ring. The adaptor ring is available in the following thread sizes: 37, 37.5, 39, 40, 40.5, 43, 46, 49, 52, 55, 58, 60, 62, 67 and 72mm.

But 72mm versus 75mm doesn't leave much room on the vignetting side of it. Chances are that you get serious vignetting on the ultra wide end of the focal range (10-14mm), because of the filter holder attached to the lens.

Just to make sure, I dropped Lee an e-mail, and this is what I got in return:

I tested a pre launch version of this lens last week on my XPro-1 - 10mm is very wide and the lens is the maximum size our 75mm holder can accept. You do get vignetting below about 12mm, which is still good given that is 15mm FF equivalent.

You would have no problems with the bigger system and a wide angle ring at 10mm, but the system is much larger and more expensive.

The s5 system works very well on all other X lenses - you just need to decide whether those last 2mm of focal length are really important to you.

Personally, I will be sticking with the 14mm prime (but upgrading to the X-T1)

I hope this helps.

With regards,

Tech Support - LEE Filters
— - email

Fujinon XF 14mm f/2.8 R

So, there yo got it; Accept additional vignetting on the ultra wide side, or invest in the more expensive 100mm filter system. But before I even invest in a filter system I need to see some independent reviews of that new lens. I might even get the Fujinon XF 14mm f/2.8 R. That lens is available at the moment and is highly recommended by several sites [2] / reviewers / users.

Choices, choices, choices

UPDATE: After much deliberation I bought the Lee 100mm kit with two adapter rings. One for the Fuji 18-55mm (58mm filter thread) and one for the Samyang / Rokinon 12mm f/2 (67mm filter thread). I also added the Big Stopper (10 stops ND) and the Little Stopper (6 stops ND) to my cart.

So in the event I decide to switch camera brand/systems with different lenses (filter threads) I can still use this filter system. I only have to get new/other lens adapters.

Posted on March 28, 2014 and filed under Gear, Photography, Personal, Tips'n Tricks.