Even though I've had software firewalls in action for years now, I haven't really come across too many instances where I'd need traceroutes. The few times I did, however, I noticed that I only got output like the following:

>tracert example.com

Tracing route to example.com [123.123.123.123]
over a maximum of 30 hops:

  1     *        *        *     Request timed out.
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
 11    50 ms    50 ms    50 ms  example.com [123.123.123.123]

Trace complete.

The number of hops would of course vary for the specific host / IP address.

Today I had to use traceroute in order to analyze a couple of networking problems. That was the incentive I needed to look up why it didn't work.

The fact that not even my router was showing up was a big indicator that something was wrong with my local firewall settings.

After searching the web for a couple of minutes, I found out what I was looking for at this page: http://www.phildev.net/ipf/IPFques.html#ques34

Traceroute is using ICMP packets (plus UDP on Linux systems, but that's outside the scope of this blog entry. You can read more about it on the page I linked above). But even for an outgoing traceroute you need to accept incoming ICMP packets.

Which ones? These:

• ICMP TTL Expired (Type 11, Code 0)
• ICMP Port Unreachable (Type 3, Code 3)

Once you've enabled these types of packets for incoming traffic in your firewall(s), you'll see that your traceroute will now function as it should.

If your firewall does not allow you to configure accepting specific types of ICMP packets, try allowing incoming ICMP packets altogether (if that's not too much of a compromise for you).

Anyway, long-ish story short: It's working now

Thanks to the webmaster of the page I linked above! And thanks to you for reading.

Since the introduction of Firefox 3 or 4 (I don't quite remember) and the removal of the status bar I have liked to use the Add-on bar instead. In the newer versions of Firefox, however, that Add-on bar comes with a closing button, an X on the very left.

Unfortunately, there is no built-in option to disable that particular button. Right-clicking and "Customize ..." doesn't allow moving or removing that button either.

After searching the web for a while, I stumbled upon a Google Groups thread: https://groups.google.com/group/mozilla.support.firefox/browse_thread/thread/d4a77426b84fe2b0

In that thread, Chris Ilias gave a simple solution (thank you!):

1. Go to your Firefox profile directory. For that, just enter about:support in your URL bar (or click on Firefox => Help => Troubleshooting) and click on the "Open Containing Folder" button next to "Profile Directory".
2. Close Firefox. (So maybe it would be better to continue reading these instructions beforehand and/or copy them into a text editor. )
3. Enter the subfolder "chrome" in the profile directory.
4. Open the file "userChrome.css". If it does not exist, copy "userChrome-example.css" and rename the copy to "userChrome.css".
   If you are using Notepad, you won't be able to see line breaks / new lines. Therefore I recommend using a program that can interpret these kinds of line breaks, for example TextPad, Notepad++ or even WordPad, which comes with Windows itself.
5. Add the following line to the file:
   #addonbar-closebutton { display: none }
6. That's it! Save the file, start up Firefox again and enjoy the Add-on bar without a closing button!

These instructions were written for Firefox 11, but they should stay viable for the next couple of versions as well.

I hope this was of any help to you.

Thanks for reading!

After doing a couple of updates on my servers today, I noticed that one of them had syntax highlighting in vim disabled. I double-checked to see that it was still vim that was installed, and not vi. Indeed it was, so I tried entering a couple of vim commands in order to re-enable syntax highlighting.

A couple of minutes of trying and searching the Internet went by till I got the idea to directly compare the vim version info both on one of my servers that had it working properly and the one that didn't. It turned out that even though it was the same version number and build with the same compile time it had a certain difference: one line said "Tiny version without GUI." vs. "Huge version without GUI.". The tiny version was the one that wasn't highlighting correctly.

So I checked out what the package manager thought of this:

# yum list *vim*
[...]
Installed Packages
vim-common.i386                                   2:7.0.109-7.el5                                  installed
vim-enhanced.i386                                 2:7.0.109-7.el5                                  installed
vim-minimal.i386                                  2:7.0.109-7.el5                                  installed
Available Packages
vim-X11.i386                                      2:7.0.109-7.el5                                  base

Somehow during updating it had apparently decided to install the vim-minimal package as well. And of course it wasn't installed on the server on which vim worked as it should.

Fair enough. I thought to myself that removing should fix it, but when I tried to it said the following:

# yum remove vim-minimal
Loaded plugins: fastestmirror
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package vim-minimal.i386 2:7.0.109-7.el5 set to be erased
--> Processing Dependency: vim-minimal for package: sudo
--> Running transaction check
---> Package sudo.i386 0:1.7.2p1-13.el5 set to be erased
--> Finished Dependency Resolution

Dependencies Resolved

============================================================================================================
 Package                   Arch               Version                         Repository               Size
============================================================================================================
Removing:
 vim-minimal               i386               2:7.0.109-7.el5                 installed               581 k
Removing for dependencies:
 sudo                      i386               1.7.2p1-13.el5                  installed               861 k

Transaction Summary
============================================================================================================
Remove        2 Package(s)
Reinstall     0 Package(s)
Downgrade     0 Package(s)

Is this ok [y/N]:

That was weird. It felt the need to remove sudo along with it. Of course that was not okay for me, so I tried looking for a parameter for vim in order to ignore the dependencies, but apparently there are none (any more).

The solution I found after a couple of more minutes of searching the Internet was to remove the package via the actual rpm program. But don't you need the original rpm file for vim-minimal? No, you don't!

First you have to find out the complete package name, however. That can be done like this:

# rpm -qa | grep vim-minimal
vim-minimal-7.0.109-7.el5.i386

And finally just use the following command:

# rpm -e --nodeps vim-minimal-7.0.109-7.el5.i386

whereas the last parameter is of course the proper name of the package in question. --nodeps, as you might have figured already, stands for "no dependencies" and removes the package without any questions asked.

In the end, these simple steps restored the syntax highlighting functionality for my vim.

Let's hope that after the next update it doesn't decide to go monochrome again.

Thanks for reading!

If you have been using the Linux console text editor vim (or: Vi IMproved), you have probably noticed already that at times - especially in files with a large amount of comments - the default color scheme on a black background is less than ideal. Dark blue on black is pretty hard to read and can strain the eyes a lot.

So today I went out to see if somebody had come up with a solution for this particular problem. I saw people who changed console colors by exporting and overwriting certain system variables, and others who edited the default color scheme.

The simplest solution I have found to this problem is just switching the color scheme. You can do that by typing the following in the already open vim session:

:colorscheme desert

where desert is just an example for the scheme of choice. Desert - for me - has just the right color for comments: aquamarine / light blue.

If you are satisfied with the scheme and would like it to be applied each time you launch vim, you can just edit /etc/vim/vimrc (or in my case with CentOS: /etc/vimrc) and add the following line:

colorscheme desert

with desert again, of course, being the chosen color scheme. This would apply this setting automatically for each vim instance that is launched system-wide. If you do not have access to the system-wide preferences or prefer just using it for your own user account, edit the ~/.vimrc instead.

The blog entry I got this tip from (Asher's space) has further instructions on how to edit existing color schemes and even a link to a blog post that explains how to edit the dark blue color for directories in ls listings with color, but I did not feel the need to go that far. If you are interested in that topic I can only encourage you to visit the original post.

Thanks for reading!

Update (2012-01-04):
Okay, looks like pingback isn't working, so here's a direct link to the original blog post:
vi code highlighting: change the default comments color from dark blue to light blue (https://asher2003.wordpress.com/)

Yesterday evening and early today I decided to implement something that has been flying around in my head for quite some while. I enabled SSL for my website - including this blog! - and at the same time moved the blog back to its original URL: http://blog.plee.me/

Now, as some of you might know, that subdomain URL has always continued to work even though I switched the URL to the subdirectory one for a while. However, instead of invalidating one or the other, both will still work. If you visit a link pointing to http://www.plee.me/blog/... you will be redirected to the new subdomain one.

So, with SSL being enabled as well, you can also reach this blog via https://blog.plee.me/, which I would strongly advise you to use over the unencrypted one. It's quite unlikely that I will post highly sensitive content on here to justify SSL encryption, but hey, it's fancy, and who doesn't like fancy stuff, right?

In order to not get any warning due to untrusted certificates, however, I recommend (not only for my site's sake but for a number of other privately or non-commercially run websites throughout the whole web) you visit http://www.cacert.org/ and get the root certificates for your browser so that CAcert will be trusted as a Certificate Authority.

Alright, that's it for now. I think I will have some relevant stuff to write about in 2012, so stay tuned.
Don't hold your breath though

Oh, and in case you haven't noticed, I have actually been active on Twitter again for the last half year or so, and I'm intending on keeping that trend. So swing by there if you like The link/info is on my main website.

Thanks for reading and sorry for any inconvenience.

Just a quick method to (roughly) detect your linux distribution and version:

$ cat /etc/issue
or
$ cat /etc/*release

Cheers

This particular tip was written over at http://www.ohnekontur.de/2011/05/13/adblock-facebook-like-button-blockieren/. Any credit goes to the original author. I am merely posting this on my blog to have a reference for myself in the long run.

You might have heard about the fact that even without clicking on Facebook's Like buttons you might be tracked by Facebook (technically it is absolutely possible for them to see which site it is you visited and had the Like button on it).

So if you are using Firefox and have the Adblock Plus addon installed (which I strongly recommend in the times of annoying flash advertisements) you can just add the following lines under the Adblock Plus preferences => "My Ad Blocking Rules":

||facebook.com^$domain=~facebook.com|~facebook.net|~fbcdn.com|~fbcdn.net
||facebook.net^$domain=~facebook.com|~facebook.net|~fbcdn.com|~fbcdn.net
||fbcdn.com^$domain=~facebook.com|~facebook.net|~fbcdn.com|~fbcdn.net
||fbcdn.net^$domain=~facebook.com|~facebook.net|~fbcdn.com|~fbcdn.net

These rules disable any Facebook scripts that are not used from the Facebook domains (facebook.com, facebook.net, fbcdn.com, fbcdn.net) themselves, including the Like buttons or any other webpage widgets they offer.

Of course, if you are using a different browser or a different kind of ad blocking / script blocking script, the idea is the same: forbid Facebook's scripts to run anywhere but their own website.

As always, I hope to have been of any help to you.

Thanks for reading.

If you have used Adobe Premiere Pro CS5 (or several other CS5 products as I've read), you might have encountered long waiting times during the program launching. In the case of Premiere Pro CS5, the splash screen shows "Loading ExporterQuickTimeHost.prm" and sticks with it for a couple of minutes (yes, minutes). This is not even a one-time thing or a once-per-Windows-session, it happens each and every program launch.

When I researched this, I quickly found the answer in Adobe's forums: Premiere CS5 takes 5 minutes to start up

In fact, what's causing this is not just the Adobe program, but rather the combination of a firewall and the Adobe program. If you are as restrictive in terms of Internet access as I am, you might have forbidden Adobe Premiere Pro.exe outgoing IP connections altogether. However, it is trying to establish a TCP connection to localhost / 127.0.0.1.

The fix is to allow outgoing TCP (I chose IP, which of course includes TCP) to 127.0.0.1 for the following executables:

• <Premiere Directory>\Adobe Premiere Pro.exe
• <Premiere Directory>\32\Adobe QT32 Server.exe
• <Premiere Directory>\32\dynamiclinkmanager.exe

with <Premiere Directory> of course being the path to your Adobe Premiere directory.

Note: Of course you can still stop every other outgoing traffic. Regard the 127.0.0.1 rule as an exception.

If you are trying to apply this fix to other Adobe programs, you are on your own to find out which .exes require 127.0.0.1 TCP connections. With modern firewalls, however, this shouldn't be that big of a problem. Just look at the prompts your firewall pops up and/or determine the .exes via logging.

I hope that helps you enjoy your respective Adobe program(s) all the more.

Good luck and, as always, thanks for reading.

Update (2010-03-28):
I recently found out that with my kind of firewall "Adobe Premiere Pro.exe" would prompt me again for a rule for outgoing traffic to addresses different from the localhost zone. If that happens to you, make sure you don't accidentally replace or override the localhost rule you added above. Rather add an additional rule for all the remaining outgoing traffic and forbid it (or allow it, depending on what you want).

In order to circumvent that problematic, you surely know that you can just open the Start Menu, type the name of the program into the quick search field, wait for it to show up in the results, right-click it and choose "Run as administrator". I found that it was a little to bothersome to use the mouse in addition to typing, especially when you have to elevate quite often in a short period of time.

What is faster is the shortcut I recently found out about. Type the name of the program into the Start Menu's quick search as usual, and instead of right-clicking, just press Ctrl+Shift+Enter. That way, you run the selected program from the list with elevation. You don't even necessarily have to wait for the search results to show up: for example, just type in cmd and press Ctrl+Shift+Enter.

This is a nice and nifty time saver.

Of course, there is also the method to just create a shortcut, go into its properties, click on the "Advanced..." button on the "Shortcut" tab and tick the "Run as administrator" checkbox. This shortcut will then automatically ask for elevation each time. Downside: You have to use another one in order to run it without elevated privileges.

Also note that the key combination Ctrl+Shift+Enter only seems to work in the Start Menu quick search box. I tried Start => Run with it (or: Windows+R), but it had no effect. Too bad.

I hope that was helpful to you and that it will save you as much time and hassle as it did for me.

Thanks for reading.

Since I've recently found out that my new router, the T-Home Speedport W 722V Type B, apparently does not support automatic disconnecting at a specific time (in order to circumvent the 24-hour connectionreset by my ISP), I took a route that my good friend Pool has been using for quite some time.

It is a batch script, so in order to use it, you have to be able to execute it.

On a side note, the Type A model of this router does support automatic disconnecting! Make sure you choose "Other provider" when you're in the internet configuration menu in order to be able to see the setting for that. The "T-Online" option sadly does not show it.

What you need:

• A Windows machine that is running at the given time (has to execute the script)
• cURL for Windows, preferably the win32-ssl-sspi version (download page). win32-ssl should be fine as well.
• Configure a scheduled task for the script, which is not covered in this guide (but quite simple. Just make it execute the script.)

The batch script:

REM Speedport W 722V Type B Internet Reset Script v1.0 - 2010-04-29
REM Written by pl (plee.me)
REM
REM Works with the T-Home Speedport W 722V Type B home router.

REM START CONFIGURATION
REM Adjust these variables to your own ones!
SET PWD=12345678
SET COOKIEFILE="routercookies.txt"
REM END OF CONFIGURATION

@echo off
curl -k https://speedport.ip/cgi-bin/login.cgi -d "pws=%PWD%" -e "https://speedport.ip/hcti_start_passwort.stm" -c "%COOKIEFILE%"
curl -k https://speedport.ip/cgi-bin/status_startseite.cgi -d "connect=0&disconnect=1&block=0&nonblock=0&abc=0" -e "https://speedport.ip/hcti_startseite.stm" -b "%COOKIEFILE%"
curl -k https://speedport.ip/cgi-bin/status_startseite.cgi -d "connect=1&disconnect=0&block=0&nonblock=0&abc=0" -e "https://speedport.ip/hcti_startseite.stm" -b "%COOKIEFILE%"
curl -k https://speedport.ip/cgi-bin/logoutall.cgi -e "https://speedport.ip/hcti_startseite.stm" -b "%COOKIEFILE%"
del "%COOKIEFILE%"

What this script does:

It logs on the web administration interface, uses a hidden option to disconnect the internet connection, then uses a hidden option to connect, and finally logs out again.

Because the cookie is cached in a text file, it is deleted at the end of the script.

Additional information:

The lines beginning with REM are comments, so you might as well leave them out.

If you run the script, make sure that you either have the cURL directory in the PATH environment variable, or that you set its folder as the working directory, so that it can find the curl.exe and actually execute the (central) steps of the script.

I'm sure that this script can be optimized (probably a lot), but for now, it's doing the job.

I hope that was of any help to you, and thanks for reading!