Running a DHCP server on WD My Cloud NAS

The WD My Cloud Pro PR2100 has an Intel Pentium N3710 quad-core 1.6 GHz processor and 4GB of DDR3 memory, which is a decent spec on which to run a NAS and some additional services. Having experienced issues with the built-in DHCP server on my Internet access provider’s router, I want to run the DHCP server for my LAN on the NAS instead.

The Busybox installation on the PR2100 includes the udhcpd server package, but the configuration and leases are wiped out each time the appliance is rebooted. To address this I’ve come up with a simple method to maintain persistence across reboots.

First create a new share on your storage which will hold your dhcpd config files, e.g. ‘dhcp’.

Next create your udhcpd.conf in the new share (/shares/dhcp) and specify the runtime options. I have provided an example below:

start 192.168.1.100
end 192.168.1.199
interface bond0
max_leases 100
remaining yes
auto_time 7200
lease_file /shares/dhcp/udhcpd.leases
pidfile /var/run/udhcpd.pid
opt dns 1.1.1.1
opt dns 1.0.0.1
opt domain local
opt router 192.168.1.1
opt subnet 255.255.255.0
opt lease 432000
static_lease 12:34:56:78:90:aa 192.168.1.100 static-host-a
static_lease 12:34:56:78:90:ab 192.168.1.101 static-host-b

To make this configuration persistent across reboots you’ll need to append some commands to the startup script of a system app. For this purpose I added the ‘Internal Backups’ app which is installed to /shares/Volume_1/Nas_Prog/InternalBackups

Edit the startup script for this app (/shares/Volume_1/Nas_Prog/InternalBackups/init.sh) and add these two lines:

touch /shares/dhcp/udhcpd.leases
/usr/sbin/udhcpd /shares/dhcp/udhcpd.conf

This will start udhcpd whenever the device is restarted and DHCP leases will remain persistent across system reboots.

To check the status of your leases you can ssh into your PR2100 (username is ‘sshd’) and use the dumpleases command. I use this command which sorts on IP address:

dumpleases -f /shares/dhcp/udhcpd.leases | tail +2 | sort -k 2

If you update the system app onto which you’ve piggy-backed the udhcpd startup commands then don’t forget to check the init script afterwards as you may need to add them again.

Using a Dell C1760nw printer with macOS Big Sur / Monterey / Ventura / Sonoma

The upgrade to macOS 11 ‘Big Sur’ has been mostly successful for me, except that I can’t install drivers for my trusty old Dell C1760nw printer. After a bit of playing, I’ve found a way around this.

First off, it’s worth knowing that the Dell C1760nw colour laser printer is actually a rebadged version of the Xerox Phaser 6000B printer. The Xerox printer drivers are more recent than Dell’s, but sadly they still don’t support Big Sur. I have a solution however, if you’re comfortable with a bit of command line manipulation.

First download (but don’t install) the latest Phaser 6000 drivers from Xerox.

You should now have the file 6000_6010_Print_Installer_v2_6.dmg in Downloads.

Open a Terminal window and issue these commands:

hdiutil mount ~/Downloads/6000_6010_Print_Installer_v2_6.dmg

cp /Volumes/6010\ 6000\ Print\ Installer/6010\ 6000\ Installer.pkg /tmp

cd /tmp

pkgutil --expand-full 6010\ 6000\ Installer.pkg expanded

cd /tmp/expanded/installationfiles.pkg

sudo cp -a Payload/Library/* /Library

Now open Printers & Scanners in Mac System Preferences.

Add Printer and give the IP address of your Dell printer, selecting Line Printer Daemon (LPD) as the Protocol.

In the ‘Use’ drop-down menu at the bottom choose ‘Select software’ and choose ‘Xerox Phaser 6000B v2.6’

Next you should get an error message saying the printer software was installed incorrectly. Don’t be concerned, this is a good sign!

Select ‘Repair’ to let macOS do its magic and your Dell C1760nw printer will be ready for use.

December 2022 update: I have tested this same installation method on a fresh macOS Ventura build and confirm that it still works.

Gmail style ‘plus’ email aliases in Office365

It’s an often used feature of Gmail to append a ‘+’ (plus) to an email address to create an unlimited number of instant email aliases – see Gmail Blog for an explanation. I gather this is also a feature of Outlook.com, but the same does not apply for hosted domains on Office365. The same can however be achieved with a bit of configuration.

Go to Exchange Admin Centre > mail flow > rules and create a new rule as follows:

Create this rule… The sender is located… Outside the organization

and The recipient address matches… ^yourname\+[\w-]+@yourdomain.com

(For example, if your usual email address is david@yourdomain.com then the rule should match ^David\+[\w-]+@yourdomain.com)

Do the following… Redirect the message to… <select your user>

(The [\w-]+ regular expression will match one or more alphanumeric or hyphen characters).

Next choose the ‘external domains’ tab, select your domain and make sure that the domain type is set as an Internal Relay.

Now that this domain is an internal relay, we’ll need an extra rule to bounce email addressed to unknown recipients more gracefully (instead of looping internally).

Add this as your last mail flow rule:

Create this rule… The sender is located… Outside the organization

Do the following… Reject the message with the explanation… ‘User unknown’

Except if… The recipient is a member of… <select all the valid users>

You will now receive email addressed to david+anything@yourdomain.com in your regular inbox.

Disabling delivery and read receipts in Exchange Online

The default configuration for Office 365’s Exchange server is to automatically respond to requests for mail delivery reports. If like me you don’t want to divulge this information then here is what you need to do.

Follow these steps to block all forms of email delivery and read receipts …

Exchange Admin Centre > mail flow > remote domains > Default 
Untick 'Allow delivery reports' and 'Allow non-delivery reports'
Save
Screenshot 2019-06-07 at 09.38.39.png
 
Next create four separate mail flow rules to remove these mail headers:
 
Disposition-Notification-To
Return-Receipt-To
Receipt-Requested-To
X-Confirm-Reading-To
 
Exchange Admin Centre > mail flow > rules > +
Create a new rule > More options...

Apply this rule if... The Sender is located... Outside the organization
Do the following... Modify the message properties...
Remove a message header (paste a header as above)
Save
You should end up with four rules like these:
 
Screenshot 2019-06-07 at 09.39.06.png
 
Those mail flow rules should strip out the headers and block read receipts before they reach a recipient’s mailbox, but just to be sure:
 
Outlook > Settings > View all Outlook settings > Email
Message handling > Read receipts > Never send a response
Save
Screenshot 2019-06-07 at 10.01.42.png

You have become the new currency

I was alerted to the contents of the privacy policy for Google Payments by an episode of the BBC series – Billion Dollar Deals and How They Changed Your World – in which the presenter Jacques Peretti makes a rather astonishing (for me at least) discovery …

Take Apple Pay, there’s a small amount of money they make in each transaction. But with Android Pay, which is run by Google, they don’t take anything. So what’s going on?

The answer lies in the small print of the terms and conditions: “we may collect information about the transaction, including: Date, time and amount of the transaction, the merchant’s location and description, a description provided by the seller of the goods or services purchased, any photo you choose to associate with the transaction, the names and email addresses of the seller and buyer (or sender and recipient), the type of payment method used, your description of the reason for the transaction, and the offer associated with the transaction, if any.”

Remember that space in the transaction, the space where business makes money? Now that space is about data. You have become the new currency.

This piqued my interest as I have been using Android Pay for a few months. In doing so had I also given my consent for my personal financial transaction data to be harvested by Google?!

For the uninitiated, Apple Pay and Google Pay let you create a digital copy of your payment cards, which are held in a secure virtual wallet on your mobile phone. You can then make contactless payments using your phone instead of the physical cards.

The Apple Pay security and privacy overview states: “Apple Pay doesn’t collect any transaction information that can be tied back to you. Payment transactions are between you, the merchant (or developer for payments made within apps and on the web), and your bank“. That sounds perfectly fair and reasonable, but what about Google?

The current Terms of Service for Android Pay includes the line: “Your use of Android Pay is subject to these Android Pay Terms of Service and the Google ToS (which together, for purposes of these Android Pay Terms of Service, we refer to as the “Terms”), as well as to the Google Privacy Policy.

The Google Privacy Policy includes a link to the specific privacy practices with respect to Payments, which contains the aforementioned small print concerning Google’s collection of payment transaction information.

So yes, by virtue of using their product I did unwittingly give Google permission to ‘spy’ on my spending habits. This financial transaction data has intrinsic value and it’s obvious why Google would like to get their hands on it, but I didn’t expect the banks to be so lax as to allow it to be shared in this way.

This revelation left me wrestling with a dilemma. There is no denying that the simplicity of making small payments with a quick tap of my phone is really handy, but I value my privacy more than the convenience factor.

I just can’t abide my personal data being exploited in this way and so have reluctantly removed my payment and loyalty cards from Android Pay and I won’t be using it again. Sorry Google, but how I choose to spend my hard-earned moolah will be kept between myself, the retailer and my bank from now on.