2Apr il 2003, 17:00:47 The Complete FreeBSD (netdebug.mm), page 401
23
Network debugging
In this chapter:
• Howtoapproach
networ k problems
• Link layerproblems
• Networ k layer
problems
• traceroute
• tcpdump
• Tr anspor t and
application layers
• Ethereal
In this chapter:
• Howtoapproach
networ k problems
• Link layerproblems
• Networ k layer
problems
• traceroute
• tcpdump
• Tr anspor t and
application layers
• Ethereal
The chances are quite good that you’ll have some problems somewhere when you set up
your network. FreeBSD givesyou a large number of tools with which to find and solve
the problem.
In this chapter,we’ll consider a methodology of debugging network problems. In the
process, we’ll look at the programs that help debugging. It will help to have your finger
in Chapter 16 while reading this section.

--- bumble.example.org ping statistics ---
4packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.612/0.765/1.137/0.216 ms
In this case, we are sending the messages to the system bumble.example.org.Bydefault,
ping sends messages of 56 bytes. With the IP header,this makes packets of 64 bytes.
By default, ping continues until you stop it—notice the ˆC indicating that this invocation
wasstopped by pressing Ctrl-C.
The information that ping givesyou isn’tmuch, but it’suseful:
• It tells you howlong it takes for each packet to get to its destination and back.
• It tells you howmanypackets didn’tmakeit.
• It also prints a summary of packet statistics.
But what if this doesn’twork? You enter your ping command, and all you get is:
$ ping wait
PING wait.example.org (223.147.37.4): 56 data bytes
ˆC
--- wait.example.org ping statistics ---
5packets transmitted, 0 packets received, 100% packet loss
Obviously,something’swrong here. We’lllook at it in more detail below. This is very
different, however, from this situation:
$ ping presto
ˆC
In the second case, evenafter waiting a reasonable amount of time, nothing happened at
all. ping didn’tprint the PING message, and when we hit Ctrl-C there was no further
output. This is indicative ofaname resolution problem: ping can’tprint the first line
(PING presto...)until it has found the IP address of the system, in other words, until it
has performed a DNS lookup. If we wait long enough, it will time out, and we get the
message ping: cannot resolve presto: Unknown host.Ifthis happens, use the
IP address instead of the name. DNS is an application, so we won’teventry to debug it
netdebug.mm,v v4.15 (2003/04/02 03:23:15)
403 Chapter 23: Networ k debugging

In this case, check the physical connections. If you’re using UTP,check that you
have the right kind of cable, normally a ‘‘straight-through’’cable. If you accidentally
use a crossovercable where you need a straight-through cable, or vice versa, you will
not get anyconnection. Also, manyhubs and switches have a ‘‘crossover’’switch
that achievesthe same result.
• If you’re on an RG-58 thin Ethernet, the most likely problem is a break in the cabling.
Youcan check the static resistance between the central pin and the external part of the
connector with a multimeter.Itshould be approximately 25Ω.Ifit’s50Ω,it
indicates that there is a break in the cable, or that one of the terminators has been
disconnected.
• If your interface is configured correctly,and you’re using a 10 Mb/s card, check
whether you are using the correct connection to the network. Some older Ethernet
boards support multiple physical connections (for example, both BNC and UTP). For
netdebug.mm,v v4.15 (2003/04/02 03:23:15)
Link layerproblems 404
2April 2003, 17:00:47 The Complete FreeBSD (../tools/tmac.Mn), page 404
example, if your network runs on RG58 thin Ethernet, and your interface is set to
AUI, you may still be able to send data on the RG58, but you won’tbeable to receive
any.
The method of setting the connection depends on the board you are using. PCI
boards are not normally a problem, because the drivercan set the parameters directly,
butISA boards can drive you crazy.Inthe case of very old boards, such as the
Western Digital 8003, you may need to set jumpers. In others, you may need to run
the setup utility under DOS, and with others you can set it with the link flags to
ifconfig.For example, on a 3Com 3c509 ‘‘combo’’board, you can set the connection
likethis:
# ifconfig ep0 -link0 set BNC
# ifconfig ep0 link0 -link1 set AUI
# ifconfig ep0 link0 link1 set UTP
This example is correct for the ep driver, but not necessarily for other Ethernet

• Is the status associated?The alternative is no carrier.Some cards, including
this one, show no carrier when communicating with a station operating in IBSS
mode, but theynev ershow associated unless theyare really associated.
• If the card is not associated, check the frequencies and the network name.
• Check the WEP (encryption) parameters to ensure that theymatch. Note that
ifconfig does not display the WEP key unless you are root.
Your card may show associated ev enifthe WEP key doesn’tmatch. In such a
case, it knows about the network, but it can’tcommunicate with it.
After checking all these things, you should have a connection. But you may not be home
yet:
• If you have a connection, check if all packets got there. Lost packets could mean line
quality problems. That’snot very likely on an Ethernet, but it’svery possible on a
PPP or DSL link. There’sanuncertainty about dropped packets: you might hit Ctrl-
C after the last packet went out, but before it came back. If the line is very slow, you
might lose multiple packets. Compare the sequence number of the last packet that
returns with the total number returned. If it’sone less, all the packets except the ones
at the end made it.
• Check that each packet comes back only once. If not, there’sdefinitely something
wrong, or you have been pinging a broadcast address. That looks likethis:
$ ping 223.147.37.255
PING 223.147.37.255 (223.147.37.255): 56 data bytes
64 bytes from 223.147.37.1: icmp_seq=0 ttl=255 time=0.428 ms
64 bytes from 223.147.37.88: icmp_seq=0 ttl=255 time=0.785 ms (DUP!)
64 bytes from 223.147.37.65: icmp_seq=0 ttl=64 time=1.818 ms (DUP!)
64 bytes from 223.147.37.1: icmp_seq=1 ttl=255 time=0.426 ms
64 bytes from 223.147.37.88: icmp_seq=1 ttl=255 time=0.442 ms (DUP!)
64 bytes from 223.147.37.65: icmp_seq=1 ttl=64 time=1.099 ms (DUP!)
64 bytes from 223.147.37.126: icmp_seq=1 ttl=255 time=45.781 ms (DUP!)
FreeBSD systems do not respond to broadcast pings, but most other systems do, so
this effectively counts the number of non-BSD machines on a network.

localhost localhost UH 2 525 lo0
223.147.37 link#1 UC 6 0xl0
sat-gw 00:80:c6:f9:d3:fa UHLW 0 0 xl0 1150
bumble 00:50:da:cf:17:d3 UHLW 0 24 lo0
presto 00:80:c6:f9:a6:c8 UHLW 0 5 xl0 1200
freebie 00:50:da:cf:07:35 UHLW 6 760334 xl0 1159
223.147.37.255 ff:ff:ff:ff:ff:ff UHLWb 1 403 xl0
The default route is via gw,which is correct. The first thing is to ensure that you can
ping gw;that’salink levelissue, so we’ll assume that you can. But what if you try to
ping aremote system and you see something likethis?
# ping rider.fc.net
PING rider.fc.net (207.170.123.194): 56 data bytes
36 bytes from gw.example.org (223.147.37.5): Destination Host Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
45006800 c5da 00000 fe 01 246d 223.147.37.2 207.170.123.194
36 bytes from gw.example.org (223.147.37.5): Destination Host Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
45006800 c5e7 00000 fe 01 2460 223.147.37.2 207.170.123.194
ˆC
--- rider.fc.net ping statistics ---
2packets transmitted, 0 packets received, 100% packet loss
These are ICMP messages from gw indicating that it does not knowwhere to send the
data. This is almost certainly a routing problem; on gw you might see something like:
netdebug.mm,v v4.15 (2003/04/02 03:23:15)