Set WIFI in Freebsd

Let's say we have a TP-Link USB Wifi adapter (TL-WN321G 54Mbps) and we want to configure it to work in FreeBSD 9.x.

After attaching to one our USB port we will get:

  dmesg
...
run0: <1 .0=".0"> on usbus4
run0: MAC/BBP RT3070 (rev 0x0201), RF RT2020 (MIMO 1T1R), address 54:e6:fc:94:6e:0f
run0: firmware RT2870 loaded
wlan0: Ethernet address: 54:e6:fc:94:6e:0f

So we notice is detected as run0 device.

To configure we wil first create a wlan interface:

  ifconfig wlan0 create wlandev run0

Then we can scan for Access Points:

  ifconfig wlan0 up scan

If is already up we can just scan for an Access Point:

  ifconfig wlan0 scan

Now, we will use WPA-PSK which is configured for our Access Point. In order to do that create a file called /etc/wpa_supplicant.conf with the following content:

  network={
    ssid="ourwifi_ssid"
    psk="our_password"
  }

Next we will add the following lines to /etc/rc.conf:

  wlans_run0="wlan0"
  ifconfig_wlan0="WPA DHCP"

Note: our password should be at least 8 characters long.

Now we will try to connect to the A.P.:

  wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf

If you do not want to run wpa_supplicant command you could restart your network:

  /etc/rc.d/netif

Still if you have a second network connection and you do not want to lose that when restarting then use wpa_supplicant command instead of running netif script.

If the connection is succesfully, then you should see associated status for your wlan0 when you run ifconfig.

Refer to:
http://www.freebsdonline.com/content/view/936/506/

How to split a APE or FLAC lossless audio file into several wave files using CUE

When we download a lossless audio file from the Internet, what we really want to do is definitely not to listen the whole long file from the beginning to the end of dozen songs. Usually, we need to split the whole file into several pieces with each song into one piece. And then listen them in some kinds of Media player such as iTune and so on.

Actually, I have done the same operation several times, but I need to search for the whole Internet for the method each time. (Seems that my memory is bad enough). I decide to record the most common method here for my next usage. Maybe it also works for you, if you are interested in this simple instructions. I don't mean to make an complete survey of the methods that can be used to complete this conversion task. At least, the method I presented here works smoothly for me on my computer (Windows 7/Windows series). 

Software should be available on your system:

1. foobar2000:  http://www.foobar2000.org/

2. a foobar2000 extra component: http://www.foobar2000.org/components/view/foo_input_monkey

foobar2000 is the basic working platform and the monkey component is used to add the APE file format into the foobar2000 because the base installation of foobar2000 cannot recognize APE format. Without monkey component would cause the Unknown Format error messages pop out during the process of the conversion. If you are converting a FLAC file, you don't need to border with this component's installation.

Here is the steps: 

1. drag the CUE file into the main view of the foobar2000 (the big blank space at the centre of the foobar2000 main view)

2. select all of the entries in the main view (it should be automatically chosen after import the CUE file), choose the convert option from the right click's menu. 

3. choose the directory to place the converted files.

4. Here we go, conversion would be running soon. 

Mac OS X new installed applications shown "* is an application downloaded from the Internet"

In the quite normal situation, after a new application is downloaded from the Internet and is run for the first time, a warning message is shown: " * is an application downloaded from the Internet. Are you sure you want to open it?".  Actually, after you answer it with a yes. this message shouldn't appear anymore in the following starting up the application. This is the normal case!!!

Let's start a strange one: the warm warning message consistently appear in every times' start up process of some specific application. I believe that this is caused by an inappropriate installation of the application. The main point is that how to get ride of the message!!!

xattr -d -r com.apple.quarantine /Path/to/application/

this should be run in a super user mode.


reference: osxdaily.com/2010/09/12/disable-application-download-from-the-internet-message-in-mac-os-x/

New LInux System installed problem

I just installed a new version of Linux (Fedora 15) to take over the works of the old Fedora 14. A problem happened when I was trying to migrate all of the experiment files from the old system's file system. Basically, I have no chance to go through the old system's file system. As far as I remember, at least I was able to access the old system's file system last time after I completed the installation of the new Fedora 15. How comes I failed this time?

After some diggings into the huge Internet, what I found is that the root reason is the duplicated Volume Group names between the old one and the new one. I assumed that I kept the old hard drive installed last time. In this case, the install process change the old system's Volume Group automatically. However, this time I uninstalled all of the hard drive except the new 1T hard drive. The installation has no chance to change them.

 OK, here is the problem analysis. Then, the solution is:

Firstly, I need to check the old system's Volume Group's UID. This is able to complete by checking the directory: /dev/disk/by-id. The currently using Volume Group's ID will be presented there:

ls -l /dev/disk/by-id

Then type the command "lvdisplay ", a WARNING message will be given. The first one UID is the currently using Volume Group's. The later one should be the old system's Volume Group's UID:

lvdisplay /dev/VolumeGroup

After the old system's Volume Group's UID is obtained, using the "vgrename" command to change its name.

vgrename

After this process, all of three Volume Group (two old and one new) are able to be recognized by the new system.

Great!!!

Here is some useful reference: (no promise the availability)

http://linuxers.org/howto/how-mount-linux-lvm-volume-partitions-linux

Using Alternate Compilers

Using Alternate Compilers

Tuesday, November 15th, 2005 ~ 10:49 pm

Users of Fedora Core 4, SuSE 10.0 and other distributions with GCC v4 may have found some open source softwares may not compile properly. Using alternate compilers may resolve the problem. FC4 also ships with GCC v3.2. There are many ways to specify alternate compilers during the build process, below are some ways.
Environment Variables
Most softwares support the CC and CXX environment variables. First assign them, then run configure or make. Example:

# export CC=gcc32
# export CXX=g++32
# ./configure

A good example can be found on the Redhat Mailing List.
Configure Support
If the software is using the standard GNU automake and configure, then there is a chance it supports other compilers by passing in a setting to the configure script. First run configure --help to see if it mentions anything. The following example is from MPlayer:

# ./configure --help
# ./configure --cc=gcc32

Makefile Support
Sometimes the software may just come with a Makefile. Open the Makefile and look inside to see if there are variables that specify the compiler. You can either edit those variables or set them at compile time. For example:

(in Makefile)
 
C_COMPILER = cc
CPLUSPLUS_COMPILER = c++

Then using the makefile, you can run:

# make CPLUSPLUS_COMPILER=g++32

Although the above examples are not exhaustive they should provide some ideas for using alternate compilers in Fedora Core and other Linux distributions.
I am also providing some notes from my FC4 Guide on GCC and GCC Compatability Libraries.

1. Aaron Says:
   January 26th, 2006 at 11:28 pm # export CC=gcc32
   # export CPP=g++32
   # ./configure
   Please note, it only worked for me when I used CXX (C++ compiler) instead of CPP (pre-processor).
   
   
   Reference: http://www.mjmwired.net/linux/2005/11/15/using-alternate-compilers/
   

Linux / Unix find command

Quick links

About find
Syntax
ExamplesRelated commandsLinux / Unix main page

About find

Finds one or more files assuming that you know their approximate filenames.

Syntax

find path expressions

path	A path name of a starting point in the directory hierarchy.
-atime n	True if the file was accessed n days ago. The access time of directories in path is changed by find itself.
-cpio device	Always true; write the current file on device in cpio format (5120-byte records).
-ctime n	True if the file's status was changed n days ago.
-depth	Always true; causes descent of the directory hierarchy to be done so that all entries in a directory are acted on before the directory itself. This can be useful when find is used with cpio to transfer files that are contain edin directories without write permission.
-exec command	True if the executed command returns a zero value as exit status. The end of command must be punctuated by an escaped semicolon. A command argument {} is replaced by the current path name.
-follow	Always true; causes symbolic links to be followed. When following symbolic links, find keeps track of the directories visited so that it can detect infinite loops; for example, such a loop would occur if a symbolic link pointed to an ancestor. This expression should not be used with the -type l expression.
-fstype type	True if the filesystem to which the file belongs is of type type .
-group gname	True if the file belongs to the group gname. If gname is numeric and does not appear in the /etc/group file, it is taken as a group ID.
-inum n	True if the file has inode number n.
-links	True if the file has n links.
-local	True if the file system type is not a remote file system type as defined in the /etc/dfs/fstypes file. nfsis used as the default remote filesystem type if the/etc/dfs/fstypes file is not present.
-ls	Always true; prints current path name together with its associated statistics. These include (respectively): inode number  size in kilobytes (1024 bytes)  protection mode number of hard links user group size in bytes modification time. If the file is a special file the size field will instead contain the major and minor device numbers. If the file is a symbolic link the pathname of the linked-to file is printed preceded by `->'. The format is identical to that of ls -gilds ls Note: Formatting is done internally, without executing the ls program.
-mount	Always true; restricts the search to the file system containing the directory specified. Does not list mount points to other file systems.
-mtime n	True if the file's data was modified n days ago.
-name pattern	True if pattern matches the current file name.  Normal shell file name generation characters (see sh) may be used. A backslash (\) is used as an escape character within the pattern. The pattern should be escaped or quoted when find is invoked from the shell.
-ncpio device	Always true; write the current file on device in cpio -c format (5120 byte records).
-newer file	True if the current file has been modified more recently than the argument file.
-nogroup	True if the file belongs to a group not in the /etc/group file.
-nouser	True if the file belongs to a user not in the /etc/passwd file.
-ok command	Like -exec except that the generated command line is printed with a question mark first, and is executed only if the user responds by typing y.
-perm [-]mode	The mode argument is used to represent file mode bits. It will be identical in format to the operand described in chmod, and will be interpreted as follows. To start, a template will be assumed with all file mode bits cleared. An op symbol of: + will set the appropriate mode bits in the template; - will clear the appropriate bits; = will set the appropriate mode bits, without regard to the contents of process' file mode creation mask. The op symbol of - cannot be the first character of mode; this avoids ambiguity with the optional leading hyphen. Since the initial mode is all bits off, there are not any symbolic modes that need to use - as the first character. If the hyphen is omitted, the primary will evaluate as true when the file permission bits exactly match the value of the resulting template. Otherwise, if mode is prefixed by a hyphen, the primary will evaluate as true if at least all the bits in the resulting template are set in the file permission bits.
-perm [-]onum	True if the file permission flags exactly match the octal number onum see chmod). If onum is prefixed by a minus sign (-), only the bits that are set in onum are compared with the file permission flags, and the expression evaluates true if they match.
-print	Always true; causes the current path name to be printed.
-prune	Always yields true. Do not examine any directories or files in the directory structure below the pattern just matched. If -depth is specified, -prune will have no effect.
-size n[c]	True if the file is n blocks long (512 bytes per block). If n is followed by a c, the size is in bytes.
-type c	True if the type of the file is c, where c is b, c, d, D, f, l, p, or s for block special file, character special file, directory, door, plain file, symbolic link, fifo (named pipe), or socket, respectively.
-user uname	True if the file belongs to the user uname . If uname is numeric and does not appear as a login name in the /etc/passwd file, it is taken as a user ID.
-xdev	Same as the -mount primary.

When using find to determine files modified within a range of time, one must use the ?time argument before the -print argument; otherwise, find will give all files.

Examples

find -name 'mypage.htm'

In the above command the system would search for any file named mypage.htm in the current directory and any subdirectory.

find / -name 'mypage.htm'

In the above example the system would search for any file named mypage.htm on the root and all subdirectories from the root.

find -name 'file*'

In the above example the system would search for any file beginning with file in the current directory and any subdirectory.

find -name '*' -size +1000k

In the above example the system would search for any file that is larger then 1000k.

find . -size +500000 -print

Next, similar to the above example, just formatted differently this command would find anything above 500MB.

Reference: http://www.computerhope.com/unix/ufind.htm

Using Traceroute

<>

Traceroute is the program that shows you the route over the network between two systems, listing all the intermediate routers a connection must pass through to get to its destination. It can help you determine why your connections to a given server might be poor, and can often help you figure out where exactly the problem is. It also shows you how systems are connected to each other, letting you see how your ISP connects to the Internet as well as how the target system is connected.

This tutorial was written for users of premium Usenet services, but can be useful for anyone wanting to learn to use traceroute.

1. Running a traceroute
2. Reading the output
3. The reverse route
4. Tracing from elsewhere
5. Finding the problem: timeouts
6. Finding the problem: long routes
7. Finding the problem: high round-trip times
8. Finding the problem: routing weirdness
9. Finding the problem: using ping
10. Under the hood

Running a traceroute

The traceroute program is available on most computers which support networking, including most Unix systems, Mac OS X, and Windows 95 and later.

On a Unix system, including Mac OS X, run a traceroute at the command line like this:

traceroute server.name

If the traceroute command is not found, it may be present but not in your shell's search path. On some systems, traceroute can be found in /usr/sbin, which is often not in the default user path. In this case, run it with the full path:

/usr/sbin/traceroute server.name

On Mac OS X, if you would rather not open a terminal and use the command line, a GUI front-end for traceroute (and several other utilities) called Network Utility can be found in the Utilities folder within the Applications folder. Run it, click the “Traceroute” tab, and enter an address to run a trace to.

MTR is an alternate implementation of traceroute for Unix. It combines a trace with continuing pings of each hop to provide a more complete report all at once. It is available here.

If you're stuck with Windows, the command is called tracert. Open a DOS window and enter the command:

tracert server.name

You can also download VisualRoute, a graphical traceroute program available for Windows, Sparc Solaris, and Linux. VisualRoute helps you analyze the traceroute, and provides a nifty world map showing you where your packets are going (it's not always geographically accurate). View a screenshot (I have obscured my local addresses).

Reading the output

Here is some example traceroute output, from a Unix system:

traceroute to library.airnews.net (206.66.12.202), 30 hops max, 40 byte packets
 1  rbrt3 (208.225.64.50)  4.867 ms  4.893 ms  3.449 ms
 2  519.Hssi2-0-0.GW1.EWR1.ALTER.NET (157.130.0.17)  6.918 ms  8.721 ms  16.476 ms
 3  113.ATM3-0.XR2.EWR1.ALTER.NET (146.188.176.38)  6.323 ms  6.123 ms  7.011 ms
 4  192.ATM2-0.TR2.EWR1.ALTER.NET (146.188.176.82)  6.955 ms  15.400 ms  6.684 ms
 5  105.ATM6-0.TR2.DFW4.ALTER.NET (146.188.136.245)  49.105 ms  49.921 ms  47.371 ms
 6  298.ATM7-0.XR2.DFW4.ALTER.NET (146.188.240.77)  48.162 ms  48.052 ms  47.565 ms
 7  194.ATM9-0-0.GW1.DFW1.ALTER.NET (146.188.240.45)  47.886 ms  47.380 ms  50.690 ms
 8  iadfw3-gw.customer.ALTER.NET (137.39.138.74)  69.827 ms  68.112 ms  66.859 ms
 9  library.airnews.net (206.66.12.202)  174.853 ms  163.945 ms  147.501 ms

Here, I am tracing the route to library.airnews.net, the news server name at Airnews. The first line of output is information about what I'm doing; it shows the target system, that system's IP address, the maximum number of hops that will be allowed, and the size of the packets being sent.

Then we have one line for each system or router in the path between me and the target system. Each line shows the name of the system (as determined from DNS), the system's IP address, and three round trip times in milliseconds. The round trip times (or RTTs) tell us how long it took a packet to get from me to that system and back again, called the latency between the two systems. By default, three packets are sent to each system along the route, so we get three RTTs.

Sometimes, a line in the output may have one or two of the times missing, with an asterisk where it should be:

 9  host230-142.uuweb.com (208.229.230.142)  12.619 ms * *

In this case, the machine is up and responding, but for whatever reason it did not respond to the second and third packets. This does not necessarily indicate a problem; in fact, it is usually normal, and just means that the system discarded the packet for some reason. Many systems do this normally. These are most often computers, rather than dedicated routers. Systems running Solaris routinely show an asterisk instead of the second RTT.

It's important to remember that timeouts are not necessarily an indication of packet loss. This is a common misconception, but since there are only three probes, dropping one response is no big deal.

Sometimes you will see an entry with just an IP address and no name:

 1  207.126.101.2 (207.126.101.2)  0.858 ms  1.003 ms  1.152 ms

This simply means that a reverse DNS lookup on the address failed, so the name of the system could not be determined.

If your trace ends in all timeouts, like this:

12  al-fa3-0-0.austtx.ixcis.net (216.140.128.242)  84.585 ms  92.399 ms  87.805 ms
13  * * *
14  * * *
15  * * *

This means that the target system could not be reached. More accurately, it means that the packets could not make it there and back; they may actually be reaching the target system but encountering problems on the return trip (more on this later). This is possibly due to some kind of problem, but it may also be an intentional block due to a firewall or other security measures, and the block may affect traceroute but not actual server connections.

A trace can end with one of several error indications indicating why the trace cannot proceed. In this example, the router is indicating that it has no route to the target host:

 4  rbrt3.exit109.com (208.225.64.50)  35.931 ms !H *  39.970 ms !H

The !H is a “host unreachable” error message (it indicates that an ICMP error message was received). The trace will stop at this point. Possible ICMP error messages of this nature include:

!H

Host unreachable. The router has no route to the target system.

!N

Network unreachable.

!P

Protocol unreachable.

!S

Source route failed. You tried to use source routing, but the router is configured to block source-routed packets.

!F

Fragmentation needed. This indicates that the router is misconfigured.

!X

Communication administratively prohibited. The network administrator has blocked traceroute at this router.

Sometimes, with some versions of traceroute, you will see TTL warnings after the times:

 6  qwest-nyc-oc12.above.net (208.185.156.26)  90.0 ms (ttl=251!)  90.0 ms (ttl=251!)  90.0 ms (ttl=251!)

This merely indicates that the TTL (time-to-live) value on the reply packet was different from what was expected. This probably means that your route is asymmetric (see below). This is not shown by all versions of traceroute, and can be safely ignored.

The output of the Windows version of traceroute is slightly different from the Unix examples (I have censored my router's name and IP address from the listing):

Tracing route to news-east.usenetserver.com [63.211.125.90]
over a maximum of 30 hops:

  1     3 ms     3 ms     2 ms  my.router [xxx.xxx.xx.xxx]
  2    35 ms    36 ms    35 ms  rbtserv5.exit109.com [208.225.64.56]
  3    36 ms    37 ms    36 ms  rbrt3.exit109.com [208.225.64.50]
  4    41 ms    40 ms    41 ms  571.Hssi5-0.GW1.EWR1.ALTER.NET [157.130.3.205]
  5    42 ms    44 ms    52 ms  113.ATM2-0.XR1.EWR1.ALTER.NET [146.188.176.34]
  6    43 ms    41 ms    41 ms  193.at-1-0-0.XR1.NYC9.ALTER.NET [152.63.17.218]
  7    61 ms    41 ms    41 ms  181.ATM6-0.BR2.NYC9.ALTER.NET [152.63.22.225]
  8    41 ms    42 ms    47 ms  137.39.52.10
  9    47 ms    42 ms    42 ms  so-6-0-0.mp2.NewYork1.level3.net [209.247.10.45]
 10    65 ms    63 ms    68 ms  loopback0.hsipaccess1.Atlanta1.Level3.net [209.244.3.2]
 11   104 ms    68 ms    80 ms  news-east.usenetserver.com [63.211.125.90]

Trace complete.

The Windows version does not show ICMP error messages in the manner described above. Errors are shown as (possibly ambiguous or confusing) text. For example, a “host unreachable” error will be shown as “Destination net unreachable” on Windows.

The rest of the examples will be in Unix format.

The reverse route

Any connection over the Internet actually depends on two routes: the route from your system to the server, and the route from that server back to your system. These routes may be (and often are) completely different (asymmetric). If they differ, a problem in your connection could be a problem with either the route to the server, or with the route back from the server. A problem reflected in a traceroute output may actually not lie with the obvious system in your trace; it may rather be with some other system on the reverse route back from the system that looks, from the trace, to be the cause of the problem.

So a traceroute from you to the server is only showing you half of the picture. The other half is the return route or reverse route. So how can you see that route?

In the good old days, you could use source routing with traceroute to see the reverse trace back to you from a host. The idea is to specify what is called a loose source route, which specifies a system your packets should pass through before proceeding on to their destination.

The ability to use loose source routing to see the reverse route could be pretty handy. Unfortunately, source routing has a great potential for abuse, and therefore most network administrators block all source-routed packets at their border routers. So, in practice, loose source routes aren't going to work.

These days, the only hope you likely have of running a reverse traceroute is if the system you want to trace from has a traceroute facility on their web site. Many systems, and Usenet providers in particular, have a web page where you can run a traceroute from their system back to yours. In combination with your trace to their system, this can give you the other half of the picture. I have a list of Usenet provider traceroute pages here.

Tracing from elsewhere

It can also be useful to see the result of a traceroute from somewhere else on the net. There are many public traceroute pages available which let you trace from those systems to other systems or back to your own system. There is an exhaustive list at www.traceroute.org.

Since many systems are multi-homed (have more than one connection to the Internet), you may have to run traces to a system from multiple locations in order to “see” all of its connections. In addition to diagnosing technical problems, this can be useful to determine what kind of connections a system has to the Internet.

Finding the problem: timeouts

If your trace to a system ends in timeouts, and never completes, there could be a problem. (The other explanation is that a system is blocking traceroute attempts, either by filtering all ICMP messages or by other means.) Your next step is to figure out where the problem is.

Well, obviously, if the trace stops at a particular system and can't go any further, then that system is where the problem lies, right? Possibly, but not necessarily.

If your traceroute ends in timeouts at a certain system, it's likely that either the connection between that system and the next system on the route, or the next system itself, is the source of the problem. The system may be down, or the network connecting them may be down. You may just have to wait for the problem to be fixed, especially if the problem system is not at your ISP and thus you aren't a paying customer of that network.

The problem could, however, not be with that system. Recall that the packets must travel from your system to the router and back again before you can see the results, and that the return route may be different from the forward route. Thus, the problem could lie somewhere on the return route between the system giving the timeouts and your own system, and that problem may not be reflected in the previous parts of the trace because the route may be entirely different.

Let's say you have a timeout like this:

16  c1-pos5-3.snjsca1.home.net (24.7.66.77)  136.612 ms  129.795 ms  129.133 ms
17  bb1-pos6-0-0.rdc1.sfba.home.net (24.7.72.18)  130.473 ms  137.609 ms  134.162 ms
18  * * *

The last reachable system on the route is at hop 17. The problem may be with the system at hop 18, or with the network connection between hops 17 and 18. Or it may be on the return route. It's very possible that the routers at hop 17 and hop 18 have different return routes to your system. The return route from 17 may work just fine, while the return route from 18 has a problem. That problem could be with that system, or it could be a totally different system, many hops away. It could even be a problem at your own ISP. The only way to tell is to see the reverse trace. A reverse trace from hop 17 would be useful here as well, to verify that the routes are indeed different. Of course, it may be difficult or impossible to obtain traceroutes from those systems, because the network administrator at home.net would have to run them for you, and is probably too busy to worry about such a request.

In this case, you can try running traces to the target system from various other places (use the list at traceroute.org) to see if it is reachable from elsewhere. In the above example, if you knew what router was normally at hop 18 (from seeing it in previous traces), you could try a trace to that router from another site.

Finding the problem: long routes

If your route to a server is very long, performance is going to suffer. A long route can be due to less-than-optimal configuration within some network along the way. Take a look at this route:

traceroute to 24.48.145.237 (24.48.145.237), 30 hops max, 40 byte packets
 1  main2-249-97.iad.above.net (209.249.97.3)  1.143 ms  0.559 ms  0.382 ms
 2  core1-main2-oc3-1.iad.above.net (209.249.0.25)  0.574 ms  0.886 ms  0.429 ms
 3  sjc-iad-oc12-1.sjc.above.net (207.126.96.121)  82.134 ms  82.537 ms  82.158 ms
 4  sl-gw8-sj-0-1.sprintlink.net (144.232.192.129)  82.523 ms  82.383 ms  82.949 ms
 5  sl-bb12-sj-6-0.sprintlink.net (144.232.3.109)  82.348 ms  82.762 ms  83.029 ms
 6  sl-bb10-sj-8-0.sprintlink.net (144.232.3.85)  83.346 ms  83.012 ms  83.006 ms
 7  sl-bb10-rly-6-0.sprintlink.net (144.232.9.13)  136.004 ms  135.804 ms  136.274 ms
 8  sl-bb6-dc-0-0-0.sprintlink.net (144.232.7.170)  137.625 ms  137.204 ms  136.794 ms
 9  gip-dc-2-fddi1-0.gip.net (204.59.144.194)  137.344 ms  138.156 ms  139.390 ms
10  gip-arch-1-atm2-0-0-132-atm.gip.net (204.59.5.25)  311.850 ms  325.246 ms  285.607 ms
11  gip-telehouse-1-atm0-0-0-333-atm.gip.net (204.59.5.14)  281.472 ms  291.957 ms  314.661 ms
12  gip-linx-fddi0.gip.net (204.59.2.198)  277.425 ms  297.364 ms  248.030 ms
13  linx-gw1.UK.EU.net (195.66.224.90)  291.800 ms  213.447 ms  221.377 ms
14  Nyk-nr01.NY.US.EU.net (134.222.228.158)  266.863 ms  301.220 ms  320.008 ms
15  nyc-core-02.inet.qwest.net (205.171.17.9)  206.191 ms  233.207 ms *
16  nyc-core-03.inet.qwest.net (205.171.17.85)  235.085 ms  270.805 ms  252.668 ms
17  nyc-core-01.inet.qwest.net (205.171.17.82)  281.931 ms  277.519 ms  278.152 ms
18  wdc-core-02.inet.qwest.net (205.171.5.235)  265.548 ms  233.789 ms  219.698 ms
19  wdc-core-03.inet.qwest.net (205.171.24.6)  200.913 ms  225.456 ms  246.335 ms
20  atl-core-01.inet.qwest.net (205.171.5.243)  237.049 ms  253.304 ms  215.435 ms
21  atl-edge-04.inet.qwest.net (205.171.21.50)  234.406 ms  289.490 ms  300.829 ms
22  205.171.45.150 (205.171.45.150)  296.876 ms  333.235 ms  272.397 ms
23  Adelphia-pvc55-t3-gw.aibusiness.net (208.235.111.18)  287.180 ms  268.736 ms  276.649 ms
24  surf4-145-237.pbc.adelphia.net (24.48.145.237)  382.868 ms  420.165 ms  393.398 ms

In this example, both the source and destination of the trace are in the United States. However, note that between hops 11 and 14, the route goes to London and back (LINX is the London Internet Exchange). Obviously, this is a problem; there are two transatlantic hops here which are completely unnecessary. Sprintlink is handing the traffic off to gip.net, which is taking it across the ocean before giving it to Qwest.

Finding the problem: high latency

Recall that the three numbers given on each line of output show the round trip times (latency) in milliseconds. Smaller numbers generally mean better connections. As the latency of a connection inreases, interactive response suffers. Download speed can also suffer as a result of high latency (due to TCP windowing), or as a result of whatever is actually causing that high latency.

Typically, a modem connection's inherent latency will be around 120-130ms. The latency on an ISDN line is usually around 40-45ms. If you use a connection of this type, you won't see any better than these numbers.

If you see, in a trace output, a large “jump” in latency from one hop to the next, that could indicate a problem. It could be a saturated (overused) network link; a slow network link; an overloaded router; or some other problem at that hop. Of course, it could also be a problem anywhere on the return route from the high-latency hop as well. You can use the ping program (described below) to get a better idea of the latency as well as the packet loss to a given site or router; traceroute only does three probes per router (by default), which isn't a very good sample on its own.

A jump in latency can also indicate a long hop, such as a cross-country link or one that crosses an ocean. A long line is naturally going to have higher latency than a short one. For example:

 4  core1.telehouse.level3.net (195.66.224.77)  2.355 ms  4.932 ms  3.473 ms
 5  core1.London1.Level3.net (212.113.2.65)  2.550 ms  1.934 ms  3.110 ms
 6  atm10-0-100.core1.NewYork1.Level3.net (209.244.3.229)  77.629 ms  75.664 ms  75.351 ms

The link between hops 5 and 6 is transatlatic, and thus is adding more than 70ms to the latency. This is normal.

Finding the problem: routing weirdness

One example of “weirdness” that you might see in traceroute output is exposure of private address space. Certain ranges of IP addresses are reserved for private, non-Internet use. These address ranges are not assigned to anyone, and are open for use by any system. They cannot be routed over the Internet, and thus are for internal useonly. Sending traffic between private address space and outside networks must be done via internal routing or address translation.

The reserved private address ranges are:

• 10.*
• 172.[16-31].*
• 192.168.*

Private addresses should never be visible over the Internet. But, sometimes you will see them in traceroute output. If they appear within your local network, this is okay; private addresses inside your own network can be visible to you. If, however, they appear within someone else's network, this can be problematic:

10  ebay-2-gw.customer.ALTER.NET (157.130.197.90)  114.204 ms  123.232 ms  120.957 ms
11  10.1.2.5 (10.1.2.5)  110.693 ms  114.475 ms  107.747 ms
12  * * *
13  * * *

The private address 10.1.2.5 within another network should not be visible to us. In this case, though, it is the last visible address before the trace ends in timeouts.

Visibility of private IP addresses doesn't necessarily (or even usually) mean that the route does not work. It is often simply the way the administrators of the target network have set up their system. In fact, the output above, despite the private IP address and the timeouts, shows a route that works perfectly well for web access.

However, a route which includes private addresses is difficult to troubleshoot. You can't ping the private routers to see if there is any packet loss. You can't trace directly to them from other sites. And in general, they show a certain level of cluelessness in how the network is set up.

Here is another example of routing weirdness:

11  USW-phx-gw.customer.ALTER.NET (137.39.162.10)  142.840 ms  151.245 ms  129.564 ms
12  206.80.192.221 (206.80.192.221)  127.569 ms vdsla121.phnx.uswest.net (216.161.182.121)  185.214 ms *
13  vdsla121.phnx.uswest.net (216.161.182.121)  442.912 ms  205.956 ms  221.537 ms
14  vdsla121.phnx.uswest.net (216.161.182.121)  164.728 ms  186.997 ms  190.414 ms
15  vdsla121.phnx.uswest.net (216.161.182.121)  306.964 ms  189.152 ms  221.288 ms

All looks well until hop 12. At that hop, the first packet is replied to from 206.80.192.221, but the second and third (which should be coming from the same place) are being returned from a different address, and timing out, respectively. After that, hops 13, 14, and 15 are all showing the same address! Since the response times are actually different, though, we can guess that they are, in reality, different systems. The trace ends normally at hop 15.

So what the heck is going on here? US West says this is a security measure, to hide the details of their internal network. The last few hops all return the address of the end-user's ADSL line, rather than their actual address. I'm not entirely sure what kind of “security” this is meant to provide.

Obviously, this makes any kind of troubleshooting of this connection next to impossible. If you encounter problems in this situation, the best you can do is contact the network provider and let them deal with it.

Sometimes you might see a route start “looping” back and forth between two routers, until the 30-hop limit is reached. This is a routing loop. This usually means that one router has lost communication (BGP) with another, and thus has dropped that route. Since the router has lost the route it needs, it sends the packet back where it came from, thinking maybe that is the best route. That router knows better and sends it back to the other one, over and over. Here's an example of a loop:

14  hou-core-03.inet.qwest.net (205.171.5.146)  165.484 ms  164.335 ms  175.928 ms
15  hou-core-02.inet.qwest.net (205.171.23.5)  162.291 ms  172.713 ms  171.532 ms
16  kcm-core-01.inet.qwest.net (205.171.5.201)  212.967 ms  193.454 ms  199.457 ms
17  dal-core-01.inet.qwest.net (205.171.5.203)  206.296 ms  212.383 ms  189.592 ms
18  kcm-core-01.inet.qwest.net (205.171.5.201)  210.201 ms  225.674 ms  208.124 ms
19  dal-core-01.inet.qwest.net (205.171.5.203)  189.089 ms  201.505 ms  201.659 ms
20  kcm-core-01.inet.qwest.net (205.171.5.201)  334.19 ms  320.39 ms  245.182 ms
21  dal-core-01.inet.qwest.net (205.171.5.203)  218.519 ms  210.519 ms  246.635 ms

Finding the problem: using ping

The ping program is used to determine whether a route is experiencing packet loss, and to measure latency.

On a Unix SVR4 system (such as Solaris), use the command:

ping -s news.server.name

On BSD Unix, Mac OS X, or Linux, use:

ping news.server.name

And if you're stuck with Windows, open a DOS window and type:

ping -t news.server.name

The output will consist of one line per ping (one per second), giving you the round-trip response time (RTT, or latency). The lower, the better. Note that if you can't traceroute to a system due to administrative blocking, you may not be able to ping it either.

Let the pings go for a while, then press control-C to stop it. You'll see a summary like this, on Unix:

----usenet73.supernews.com PING Statistics----
76 packets transmitted, 76 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 138/144/179

Or like this, on Windows:

Ping statistics for 207.126.101.73:
    Packets: Sent = 73, Received = 73, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 132ms, Maximum =  164ms, Average =  139ms

First you see an indication of packet loss. The more loss you see, the worse your connection will be, because every lost packet on a data connection must be retransmitted. If you see 20% packet loss, it's going to be painful. This number is more meaningful if you let ping run for a while; if you only do five pings, 20% packet loss means it dropped one packet, which could be no big deal. Let it go for a while.

Latency times are important for performance; the lower the better. If you play online games like Quake you are probably familiar with this concept. For Usenet reading, this will matter most if you read news online, interactively, staying connected to the server the whole time. If you use an offline newsreader which downloads articles all at once and lets you read them from your local disk, latency is much less important (it can affect sustained download speeds, but that is beyond the scope of this document). What the output is showing you is the minimum, average, and maximum latency times seen during the ping run. A few systems may include a fourth number showing the standard deviation.

If you see packet loss on a connection, you can use ping with your traceroute output to find the source of the loss. Start by pinging the next to last router in the trace. If you still see packet loss, ping the one before that. Eventually the packet loss will disappear, and you have found the part of the path where the problem begins.

Note, however, that as with other problems, the cause of the loss could be the first router on the path showing packet loss, or it could be anywhere on the return path from that router. Remember that the return path can be totally different from what you see in your trace output. But, this gives you a good place to start pointing fingers.

Under the hood

You don't need to worry about the low-level details of how traceroute works in order to use it. But, if you're interested, here they are.

Traceroute works by causing each router along a network path to return an ICMP (Internet Control Message Protocol) error message. An IP packet contains a time-to-live (TTL) value which specifies how long it can go on its search for a destination before being discarded. Each time a packet passes through a router, its TTL value is decremented by one; when it reaches zero, the packet is dropped, and an ICMP Time-To-Live Exceeded error message is returned to the sender.

The traceroute program sends its first group of packets with a TTL value of one. The first router along the path will therefore discard the packet (its TTL is decremented to zero) and return the TTL Exceeded error. Thus, we have found the first router on the path. Packets can then be sent with a TTL of two, and then three, and so on, causing each router along the path to return an error, identifying it to us. Eventually either the final destination is reached, or the maximum value (default is 30) is reached and the traceroute ends.

At the final destination, a different error is returned. Most traceroute programs work by sending UDP datagrams to some random high-numbered port where nothing is likely to be listening. When that final system is reached, since nothing is answering on that port, an ICMP Port Unreachable error message is returned, and we are finished.

The Windows version of traceroute uses ICMP Echo Request packets (ping packets) rather than UDP datagrams. In practice, this seems to make little difference in the outcome, unless a system along the route is blocking one type of traffic but not the other.

In the unlikely even that some program happens to be listening on the UDP port that traceroute is trying to contact, the trace will fail at the last hop. You can run another trace ucing ICMP Echo Requests, which will probably succeed, or specify a different target port for the UDP datagrams.

A few versions of traceroute, such as the one on Solaris, allow you to choose either method (high-port UDP or ICMP echo requests).

---

Usenet provider traceroute pages - traceroute from a provider to you
Traceroute.org - traceroute from just about anywhere to anywhere else
VisualRoute - a graphical traceroute program

Usenet stuff  |  Providers  |  by Jeremy Nixon, copyright © 2000-2002  |  updated 2 September 2002