Using C.H.I.P. as a Repetier-Server

My wife got me a 3D Printer (the MonoPrice Maker Select V2) for Christmas, and while I initially had it connected directly to my PC, when I rearranged things it was no longer close enough to be practical to connect with a USB cable.

I backed the C.H.I.P. kickstarter a while back, and had a $9 computer I had played with for a while and then not gone back to, so it seemed like a great opportunity to put it to use. I had been using Repetier-Host on my PC with its embedded Repetier-Server, so I really wanted to keep using the software as it was my favorite of the 3D printing apps I’ve tried so far.

A Small Note

If you are an experienced Linux user, this is a very straightforward process. When I went looking to see if Repetier-Server would run on the C.H.I.P. pretty much the only thing I found was “it should” and some references to running it on the Raspberry Pi. Besides the instructions themselves, another major intent of this article is just to say that yes, it works, and it doesn’t require a lot of convoluted process to set up.

Flashing your Chip

I had flashed my C.H.I.P. right after I got it so I could use the VGA adapter I got with it, but when I tried to set it up (monitor, keyboard, and all) connected to the 3D printer, I ran into some issues. It wasn’t connecting to the printer, and when I installed Repetier-Server it couldn’t find the printer. After some searching around (most of the stuff out there is for the Raspberry Pi, which is a very similar device) it seems like the first builds of the C.H.I.P. firmware didn’t include the USB Serial drivers in the kernel. Apparently, /dev/ttyUSB0 should have been a choice, and it wasn’t there.

I also hadn’t used the device in quite a while, so I figured it was a good idea to reflash my C.H.I.P. to get the latest and greatest image for the device and hope this was resolved. As it turns out, in the 4.4 firmware at least, it is!

In order to perform a flash, you will need to put your C.H.I.P. into “FEL Mode”. This is a bit of an odd step, as you will need to unfold a paperclip and plug it into a couple of the pins on your C.H.I.P. Here is my C.H.I.P. all ready for flashing:

After that is done, head over to and follow the wizard to flash your device. I choose the “Headless Kernel 4.4” image since I was going to set this up as a server without a monitor and keyboard. You might want a different image if you intend to make the repetier server a side-job for your C.H.I.P.

Updating C.H.I.P.

After flashing, I needed to set up my C.H.I.P. so it would connect to my wireless network. There are some excellent directions here: on doing just that. Just remember to be patient after plugging in your C.H.I.P. it takes a few seconds for the computer to boot up and be available via the COM port.

Once you’ve connected to your network and can connect to your C.H.I.P. via SSH over wireless (use the same putty application you used to set up the network), it is time to perform some updates. If you logged in as root, you can follow the commands below directly. If you are using one of the desktop firmware version, you will need to preface these commands with “sudo” and provide the “chip” when the system asks for a password.

To update your installation sources and package information, run:

apt-get update

after the completes, go ahead and let the C.H.I.P. update the packages installed on the system:

apt-get upgrade

This will likely take a few minutes, as there are a lot of packages to update from the base firmware. Just let it run, and pick back up when it finishes.

Downloading Repetier-Server

Head over to and click on the Download link under Repetier-Server. There will be a number of options here, but the one we want is for “armhf“, since the C.H.I.P. is a 32-bit ARM processor. The easiest thing to do here is to right click on the download button and copy the link to the clipboard. Then pop back over to your putty session and download the file with wget. From the command line, type “wget ” and right click to paste the URL into the putty window. Hit enter, and the file will download. In my case:


After downloading, we need to install the package:

dpkg -i Repetier-Server-0.80.3-Linux.deb

Finally, we just need to start the service:

service RepetierServer start

Troubleshooting note: I had an issue where the RepetierServer service did not start when I restarted my C.H.I.P. After connecting with putty and experimenting, I found that, for some reason, the repetierserver user had disappeared from /etc/passwd. I just reran the dpkg command above and reinstalled and didn’t have an issue after that.

Server Setup

For the rest of the setup, we need to switch to a web browser. Once the service is started, your C.H.I.P. will be running a web server on port 3344. In your browser, navigate to http://chip.local:3344 and you should see the Repetier-Server interface:

From here, click on “Add new Printer” and follow the wizard. When asked about the port to use, my server determined it automatically:

Follow through the rest of the wizard (the details will be dependent on your particular printer), and you should now have a printer now available on your server.

Connecting with Repetier-Host

Now that the server is set up, head over to and download the most recent Repetier-Host for your OS. I’m using Windows, but I suspect the Mac and Linux versions are not very different.

Once you have Repetier-Host installed (you can install without the local repetier-server), we need to configure the program to connect to the server we just set up. Open up Repetier-Host and click on the “Connect” button. It should fail and ask you if you want to open the printer settings dialog (alternatively, you can select Config -> Printer Settings from the menu bar).

 On the Connection tab, select Repetier-Server as the Connector, and enter chip.local for the IP address. Now, we need to enter our API key to allow us to connect to the server. Click on the “Show” button next to the API key field and your default browser will open to the Repetier server’s connectivity screen. Copy the API key (a long hex value) and past it into the API Key field in the dialog box above and click “Connect to Continue”.

Your printer should be automatically selected. If not, click the dropdown for Printer and select it. Click on “Copy Server Config Settings” to transfer information about your printer (size, heated bed, etc) to Repetier-Host. You can review the other tabs in this dialog if you like. Again, these details will depend on your printer model. Click “Ok” when done, and you are ready to print!


Windows 10 Fall Update (1511) APC_INDEX_MISMATCH

TL;DR: This page is getting a lot of views as the Win 10 deadline approaches. If you have a Dell machine, boot in safe mode or remote in via remote desktop and rename the file “C:\Program Files\Realtek\Audio\HDA\RtkNGUI64.exe”. This should allow you to boot without the blue screen.

So we rolled out the Windows 10 Fall Update (1511) to a couple of PCs at the office that were running Windows 10 RTM. Every machine appeared to upgrade fine, but once any user logged into the PC, it would throw up a frowny-face blue screen stating that “Your computer experienced a problem and needs to restart”. The “if you want to know more” reference was listed as “APC_INDEX_MISMATCH”. Searching around for this points to a driver issue, though there wasn’t really an indication of what exactly it might be.

There wasn’t enough time between the login and the blue screen to do any troubleshooting, but there were a few interesting notes:

  • The PCs could stay at the lock screen or the login screen indefinitely. The blue screen only occurred AFTER logging in. This would indicate that the issue is unlikely to be a driver, as drivers would load prior to logging in.
  • The blue screen appeared after login regardless of network connectivity. Wire plugged in or not, right after hitting the desktop the system would crash. The implication here is that the problem is something already on the PC as opposed to something running in the network logon script.
  • All of the machines were Dell Optiplex desktops, but several different models.

Taking these items together, it would seem to point to a startup program. To test that, we could boot into safe mode (which doesn’t run startup items) and disable them. Microsoft has made it quite a bit harder to get into Safe Mode on Windows 8/10 (especially since this blue screen isn’t happening during startup, so it doesn’t trigger the repair mode automatically), but that is where we needed to turn to solve the problem.

If you aren’t familiar with getting into safe mode on Windows 10 (when you can’t get to the desktop to do it through the menu, anyway), power up the machine and wait for the Windows Logo to appear and the “busy” circle to start spinning at the bottom of the screen. Hold down the power button and shut the machine off before it boots up. Repeat this process a couple of times, and instead of the spinning busy circle, the text “Starting Automatic Repair” will appear. Let this run and you will be presented with a couple of tiles on the screen. Click on the Advanced options tile, and click on Startup Options. You will be asked to reboot again. Do so, and a startup options menu will appear. Select Safe Mode (or safe mode with networking, etc).

To solve this particular problem on our Dell machines, after booting into Safe Mode, open Task Manager, click on Details, and click on the Startup tab. We started by disabling all of the startup programs and rebooting into normal mode. This allowed us to log in without the blue screen.

After that, it was just a matter of starting each of the startup items until we hit a blue screen. The culprit for us turned out to be “Realtek HD Audio Manager”. The executable is located at “C:\Program Files\Realtek\Audio\HDA\RtkNGUI64.exe”. Running this .exe file immediately blue screens every PC we have tried it on that has the fall update installed.

I’m sure there will be an update for this eventually, but since you can’t even run updates while this error persists, it can be a real pain to get your PC back in working order. You can avoid the whole problem by disabling this startup executable prior to updating to the Windows 10 Fall Update.

Email Clutter in Office 365

I have a personal Office 365 account, and have managed O365 in an enterprise environment for about a year now. Several months ago, Microsoft quietly introduced a feature called “Clutter” – it showed up on day as a folder in my mailbox with a single message which explained what Clutter in Office 365 is and a link to turn it on. Last week, Microsoft announced that they will be enabling the Clutter feature by default on all Office 365 mailboxes if users haven’t already specifically turned it off.

What does it do?

Clutter pays attention to how you interact with messages in your mailbox and determines what messages you are likely to ignore. As similar messages arrive in the future, it redirects them from your Inbox to the Clutter folder where you can browse through them at your leisure. If you move particular messages out of clutter and back to your inbox, it will learn that you don’t want those items to be classified as clutter and avoid doing so in the future.

How is this different from Junk E-Mail or Spam Filtering?

In a couple of ways, actually. Spam filtering usually uses pattern matching against known spam e-mail or message analysis that determines the likelihood that the message is spam. Messages that get filtered out at this point never hit your mailbox at all.

Those that make it past, but are still of questionable value may get directed to the Junk E-Mail folder. Items in this folder are restricted – they won’t download images, and you can’t click on links in an e-mail in your Junk folder. You have to move it out of Junk before you can interact with it.

Clutter works a bit differently. Items in the Clutter folder are still interactive. You can work with them just like you can with items in your Inbox.

On by Default?

Clutter is actually a pretty nice feature – I have been using it since it was released, and it tends to catch all of the automated status messages from system monitors, along with near-spam messages that make it past the various filters in place. In about two weeks, it will be enabled by default on existing O365 accounts as well as new ones. I can see this initially being a source of confusion to users, since they may not see messages they are expecting to see.

According to the announcement above, when the on-by-default goes live it will include periodic messages indicating what kinds of things are being directed to Clutter, which will be good – right now there is no indication other than the unread count number next to the Clutter field increasing.

There is a PowerShell command included in the announcement above to disable Clutter for your existing user accounts, but as you create new accounts you will have to return to PowerShell if you want to disable Clutter for them – it will be on for newly created accounts with no way to make “off” the default setting for your tenant.

The other good option, of course, is to just let your users know it is coming. This can be especially important considering they will begin receiving e-mail messages with links in them that they are not expecting to receive otherwise – and how many times have we urged users to never click on links in e-mails they weren’t expecting to get 🙂

Shellshock Bug : How to Patch bash Manually

I have a number of Linux system, including several virtual machines with various distributions running everything from test web servers to a Minecraft server for my daughter, and a Raspberry Pi that gets its SD card swapped out all the time depending on what I need it to do. While most of these systems can be automatically updated via yum or apt-get to install new versions of packages, a few are running distributions for which update packages are not readily available.

This doesn’t mean that I can’t secure them against the recently discovered Shellshock vulnerability. I just needed to compile the bash software from the source code, including the Shellshock patches, and install it. That is actually not nearly as complicated as it might sound. Here’s how to do it:

Continue reading

Resolving Windows Update error code 80246002

I don’t know exactly what sequence of updates caused the proliferation of the 80246002 errors when attempting to run Windows Updates, but it appears to be a fairly wide-spread problem on Windows 7 machines.

The problem manifests itself as an inability to manually search for Windows Updates. If you are on a domain that uses a Software Update Server, this check is done by selecting the “Check Online for Updates from Microsoft Update” link at the bottom of the Windows Updates window. Typically the manual check will quickly fail with the error code 80246002.

Searching the net for a solution comes up with a few suggestions, most commonly to change your DNS server to (Google’s DNS) and try again. This does seem work to allow for updates to be downloaded immediately, but it doesn’t solve the problem going forward (you will have to do it again the next time you want to check for updates), and you can’t access any of your local domain resources until you switch it back.

A co-worker and I discussed this problem yesterday, and she worked out a procedure that has corrected the problem on all of the PCs we have tried it on so far:

  • Open Windows Update from the Control Panel
  • Click on “Change Settings” on the left hand side of the screen
  • Uncheck “Give me updates for Microsoft products and check for new optional Microsoft software when I update windows”
  • Restart the PC
  • Optional – I suggest completing the rest of this process and seeing if it works before you do this step, as this will eliminate your Windows Update history. If after completing the procedure you still receive errors when attempting to check for updates, try the following to remove the directory Windows Update uses to store the items it downloads (It will get recreated when the WUAUSERV service is restarted):
    • Open a command prompt as administrator (Click Start, type CMD, right click on the “cmd” entry at the top of the start menu and select “Run As Administrator”)
    • Run the command “net stop wuauserv”
    • Run the command “CD %WINDIR%”
    • Run the command “RENAME SoftwareDistribution SoftwareDistribution_Old”
    • Run the command “net start wuauserv”
  • Open Windows Update and check for updates. Install any updates other than the language packs.
  • When prompted, restart the PC
  • Open Windows Update again and click on the “Find Out More” link which talks about getting updates for other Microsoft products. This will take you to the Microsoft Update page.
  • Install the Microsoft Update client and check for updates.

After that, manually checking for updates seems to work normally on the machines we have tested. It seems that reverting back to Windows Update and then opting back in to Microsoft Update repairs the problem with the update client on the PC.

Some extra keywords for searches : 0x80246002, Microsoft Update, Windows Update, errorcode, fails, Windows 7, Win7, Win 7, search for updates, check for updates, manual update, manually update, wus, wsus, software update services

Active Directory Authoritative Restore

One of the things I hope to do with this blog is post tidbits of information that I come up with after resolving an IT-related problem. Things that were not immediately obvious when searching around the internet to research the issue. Hopefully if other people run into the same problem, they will be able to benefit from these posts. Of course, all of the standard disclaimers apply – this worked in the environment I was in. Your environment might be different. Always backup first, your mileage may vary, etc 🙂

Over the weekend, I was asked to assist with a problem. About 500 user accounts had been accidentally deleted from an organization’s Active Directory. Their AD domain is a child domain of a larger forest, and the deletion had come from a user in the domain above them.

The network in question was running Windows 2008 R2 for some of their domain controllers, but several were still Windows 2003, so the functional level was still at 2003. This means that the Active Directory recycle bin feature was not available. Given the size of the deletion, it was necessary to perform a restore from backup.

Once we had done the tape-based restore, blocked incoming sync traffic, and marked the objects on the restored domain controller as authoritative, we attempted to use repadmin to push the changes out from the restored DC with:


repadmin /syncall (dc name) /e /A /P /d /q


and monitor the replication with


repadmin /showreps (neighbor dc name)


But we kept receiving an error message from /showreps stating that:


Last attempt @ YYYY-MM-DD HH:MM:SS failed, result 8418 (0x20e2):
"The replication operation failed because of a schema mismatch between the servers involved."


Upon investigation, it turned out that the admins in the parent domain had issued a schema update related to a custom AD attribute on the same day as the deletion took place, meaning that the NTDS backup from the night before did not contain that schema update, but did contain the user accounts and group membership that needed to be restored.

The solution turned out to be ensuring that the objects in the restored DC were authoritative and then enabling incoming replication traffic on the DC:


repadmin /options (ServerName) -DISABLE_INBOUND_REPL


This allowed the schema update to complete, which enabled replication between the restored DC and the rest of the domain. After this was done, the /syncall replication performed normally. We then performed a second push to ensure group memberships were updated. When doing an authoritative restore it is possible that group membership lists will be pushed before user accounts are created, so when the group is replicated the users that don’t yet exist won’t be in the replicated group. Pushing the groups a second time (after all of the user accounts are replicated) resolves this problem.

All in all, it took a few hours, but the problem was resolved without any major disruption.

  • Advertisement