OS X Yosemite DHCP Server

This week I re-installed my Mac Mini server at home. It still ran Snow Leopard, and it was time to start with a clean slate. So after a couple of hours of pondering if I had forgotten to backup something, I started with a clean install of OS X Yosemite (10.10).

Everything went smooth, until I started using the DHCP service that comes with the Server App add-on.

My server uses 802.1q (VLAN-tagging) to connect several different VLAN's which I feed into several Virtual Machines. So I also use several DHCP Scopes for those segments.
The IP addresses for these scopes are all in the 192.168-range (class C subnets), so when I created the scopes I had to go through a simple wizard in the Server App. I just had to fill-in the blanks (very user friendly), and OS X did the rest.

Upon testing I ran into the weirdest behaviour on my network. Getting connectivity with a device took a very long time, and when the device got an IP address, it was from a different network (???)> So it couldn't communicate across the network.

At first I began to wonder if I had mixed up the VLAN names and tags, but those were correct. After an hour of troubleshooting (more and more DHCP clients were failing in the network), I found the problem;

When you create a scope Apple will assign a default subnet mask (255.255.0.0). I guess I should have seen it, but I didn't.

After I changed the subnet mask in the DHCP scopes everything went back to normal.

Lesson learned: Don't rely on wizards and other user-friendly stuff.

PlayStation Network Down and How To Get It Working Again

This Christmas (2014), several gaming networks were attacked by a DDoS. One of those networks being the Playstation Network (PSN). This resulted in severe downtime during the holiday season. Sony is/was working hard to resolve this and service is being restored all around the world. Except for me (and probably several thousand other gamers). As of this morning (December 29th, 2014) I was unable to log on to PSN. All I got was one of the much telling error codes:

NW-31456-9

CE-33987-0

Someone on the Interwebs mentioned that a change in the MTU size might help. The MTU size is the maximum transfer unit on a network, which is normally at 1500 (bytes) for regular network clients. In some case it's preferable to adjust this size (I won't get into details).

In the case of PSN being down, an adjustment from 1500 (the default) to 1473 seems to do the trick at the moment. Not sure if it wil hold up in the (near) future, but at least you can get online to play on your new Playstation 4 or with the new game you got for Christmas.

1. Go to the “Settings” menu.
2. Go to “Network” sub-menu.
3. Go to "Set Up Internet Connection".
4. Choose your media (WiFi or LAN).
5. Choose “Custom.”
6. Leave everything as default except MTU (Manual).
7. Change MTU settings to “1473”.
8. Save your changes.
9. Test the Internet connection.

And if you are more of a visual kinda person:

Everything should work now. If not, you may try a reboot.

Lowering the MTU size means that smaller packets are being send over the network (max. 1473 bytes instead of 1500 byte packets) , this is not a bad thing, but might lead to some performance problems in some cases. Just remember that you changed this setting. You want to (or have to) change this back to the default (1500) in the future.

I do not know if this works for other gaming devices. You may try at your own risk (and leave the results in the comments if you'd like).

UPDATE: As of this morning I was able to sign in to PSN with an MTU of 1500 (access the Playstation Store etc.), but I was unable to play online games (Battlefield 4). Changing the MTU back to 1473 fixed that (again).

UPDATE 2: As of this morning (31 december) I can also connect to PSN with an MTU of 1500, so everything is back to normal.

OSX 10.10 (Yosemite) and Audio Out Changes

Yesterday I ran into a new Yosemite feature that annoyed me a bit. After changing the input on my Dell 27" display from DisplayPort to HDMI, the screen turned black on my 27" iMac, and audio stopped. Forcing a reboot (holding the power button for >4 seconds) was needed to get the iMac's display back.

But from that point on, the audio was greyed-out in the menu bar. Changing the volume on the (Apple) keyboard gave a disabled icon on screen. Also, no audio was playing over my external speakers.

My first thoughts were that the earlier crash had corrupted something on my system, so I did an additional reboot. Nothing. After that a PRAM reset (power off, power-on and hold command-option-P-R until you have heard two start-up 'boings'). The start-up sounds were there, so the actual audio hardware was just fine.

When the desktop loaded still no audio control, until I unplugged my DisplayPort connector on the Dell 27" monitor. Audio (controls) came back instantaneous.

So, with DisplayPort connected to the external monitor: no audio (controls), and without the DisplayPort: audio (controls).

Turns out that with Yosemite, the audio is channelled BY DEFAULT over a DisplayPort connection (to a external monitor). In my case, the Dell also has an audio out connector, and I guess that is 'advertised' over the DisplayPort.

Changing the default behaviour is done in the System Preferences -> Sound

The first image shows the default (at least in my case). Changing the settings to the second image gave me back the audio and volume control.

View fullsize

View fullsize

I have no idea if this was also possible with Mavericks (or even earlier versions of OSX), but it's definitely a (default) feature that annoyes the hell out of me.

Even though I tackeled the audio problem, the issue with loosing the display when I change the video input on the external monitor still remains. But only if the desktop is extended to the second screen. It doesn't occur when the screen is mirrored.

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 :-)

Just Apply Pressure

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

View fullsize

View fullsize

View fullsize

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.

Updating to iOS 7.0.5 Turned Ugly

During the update of my iPhone it got stuck in the so-called recovery mode. This means that everything on the iPhone is lost, and that you need to restore everything from a backup. Thankfully, the last backup was made 10 minutes before the upgrade process began. So no worries there.

The panic started to kick in when the actual recovery process terminated with an unknown error (17).

An unknown error occurred (17)

No matter what I tried, the error kept re-occurring

Searching the Interwebs,  I founds several forums mentioning modifying the hosts file on your computer. Any entries referring to the apple.com domain should be removed.

Checking the hosts file out (located @ /etc/hosts on a Mac), I found a reference to a gs.apple.com with a specific IP address. At that point things started to dawn on me....

A couple of years ago I started to experiment with creating your own MobileMe thing (so I would have no need to purchase a MobileMe account back then). In that process you needed to fake some Apple web-servers. One of those servers was gs.apple.com.

After removing the entry from my hosts file and rebooting my iMac, the recovery process went flawlessly.

This 'experience' made me wonder; Did the 'crash' of the iPhone happen because of the hosts file entry? If so, this could be disastrous if someone made these servers unresponsive (e.g. DNS hack, or whatever), since the iPhone would become a brick. At least for as long as these servers are not accessible....