- About Us
A controlled dial-on-demand router is a convenient tool. An uncontrolled dial-on-demand router is not. The Wireshark network protocol analyzer helped me track down the cause of some strange and unwanted dialup connections.
Wireshark is a 20MB download. The GPL-licensed utility runs under Linux, Unix, Mac OS X, and Windows. The problems I needed to solve were all with a Windows client.
My SMC Barricade 7004AWBR wireless router has an RS-232 port and can control an external modem, which I use for Internet connectivity. While there is quite a bit of Ethernet traffic on my network between several Windows machines and a Linux server, only a small portion of the traffic is addressed to the gateway, calling for an outside connection. Connections are made automatically if required, and if the connection is idle for a specified interval, the router quietly drops the connection and waits for later requests to dial out again.
However, I was puzzled as to why my on-demand router was dialing out on my phone line when I did not appear to have any applications running. Within seconds after an idle connection dropped, some mysterious force would ask the modem to dial out again.
Wireshark watches network traffic and makes a note of all the different packets traveling past the network interfaces. With Wireshark running on my main work computer, I could see the network interface cards for the machine on which it was running, but I could not monitor interfaces on other machines, including the router. However, the application can see packets headed to the gateway router through my machine's network adapter, and that should help me diagnose the problem.
I figured I might have three types of problems where network packet monitoring would be helpful:
To solve my immediate problem I started Wireshark and walked through its menu choices: Capture -> Interfaces -> Fast Ethernet -> Start. Here are a few lines from the resulting output that show what was happening:
1 0.000000 192.168.0.3 188.8.131.52 SIP Request: REGISTER sip:sip.ca1.voip.ms;transport=UDP ... 21 161.474036 192.168.0.3 184.108.40.206 UDP Source port: sip Destination port: sip ... 83 643.352918 192.168.0.3 192.168.0.1 DNS Standard query A www.dyndns.com 84 643.568823 192.168.0.1 192.168.0.3 DNS Standard query response A 220.127.116.11 85 643.571379 192.168.0.3 18.104.22.168 TCP hpvmmagent > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460
On each line, Wireshark reports a line number, a timestamp, a source IP address, a destination IP address, the protocol, and a summary of the packet. Line 1 shows that the source IP is my local machine and the destination IP is at my VoIP service provider. The protocol is the SIP (Session Initiation Protocol) VoIP protocol and something is trying to register itself.
I remembered that I was running the free Zoiper softphone. I allow it to load and then hide until I need it. I had left one account to automatically register itself. Once I told it to stop doing that, I had one problem solved.
Line 21 is just a keep-alive request to the same server. These UDP requests happen all the time, but if there is no active Internet connection the request will not trigger the connection sequence.
Lines 83 to 85 tell a slightly different story. Line 83 is asking the gateway for the IP address of www.dyndns.com, and the next line is the response that it resolves to 22.214.171.124. The following line is the start of the Dyndns updater application, which attempts to register my current dynamic IP address with the Dyndns service. I set it to stop doing that. Two problems down.
Both calls to the router were completely valid. I had just allowed them to fall off my radar. Once my immediate on-demand router problems were resolved, the modem remained quiet.
Another useful task for Wireshark is to test the behaviour of applications. Occasionally, I wonder if an application is making calls through the Internet unnecessarily. By limiting running programs to a bare minimum of applications that are not calling for Internet services, you can begin capturing packet information with Wireshark and then start an application you suspect of misbehaving. If packets start flowing unnecessarily, further investigation is required.
Here is part of a log that shows the behavior of Zoiper when it starts up:
No. Time Source Destination Protocol Info 1 0.000000 Ibm_xx:xx:xx Broadcast ARP Who has 192.168.0.1? Tell 192.168.0.3 2 0.001479 SmcNetwo_xx:xx:xx Ibm_xx:xx:xx ARP 192.168.0.1 is at xx:xx:xx:xx:xx:xx 3 0.001511 192.168.0.3 192.168.0.1 DNS Standard query A sip.ca1.voip.ms 4 0.345817 192.168.0.1 192.168.0.3 DNS Standard query response A 126.96.36.199 5 1.763508 192.168.0.3 192.168.0.1 DNS Standard query A www.asteriskguru.com 6 2.089622 192.168.0.1 192.168.0.3 DNS Standard query response A 188.8.131.52 7 2.264280 192.168.0.3 184.108.40.206 TCP attachmate-uts > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 8 2.494002 220.127.116.11 192.168.0.3 TCP http > attachmate-uts [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1380 9 2.494103 192.168.0.3 18.104.22.168 TCP attachmate-uts > http [ACK] Seq=1 Ack=1 Win=65535 Len=0 10 4.334396 192.168.0.3 22.214.171.124 HTTP GET /counter/?version=2.14&dllversion=650&branch=zoiper HTTP/1.1 11 4.617804 126.96.36.199 192.168.0.3 TCP http > attachmate-uts [ACK] Seq=1 Ack=204 Win=6432 Len=0 12 4.911492 188.8.131.52 192.168.0.3 TCP [TCP Previous segment lost] http > attachmate-uts [FIN, ACK] Seq=522 Ack=204 Win=6432 Len=0 13 4.911571 192.168.0.3 184.108.40.206 TCP [TCP Dup ACK 10#1] attachmate-uts > http [ACK] Seq=204 Ack=1 Win=65535 Len=0 SLE=522 SRE=523 14 5.014078 220.127.116.11 192.168.0.3 HTTP [TCP Retransmission] HTTP/1.1 200 OK (text/plain) 15 5.014208 192.168.0.3 18.104.22.168 TCP attachmate-uts > http [ACK] Seq=204 Ack=523 Win=65014 Len=0 16 5.030427 192.168.0.3 22.214.171.124 TCP attachmate-uts > http [FIN, ACK] Seq=204 Ack=523 Win=65014 Len=0 17 5.256204 126.96.36.199 192.168.0.3 TCP http > attachmate-uts [ACK] Seq=523 Ack=205 Win=6432 Len=0
You can research unfamiliar words in the log, such as 'attachmate-uts.' In this case nothing raised any red flags for me; all of these records look like normal behaviour. Zoiper wants to connect with www.asteriskguru.com and sip.ca1.voip.ms, but once Zoiper is running it does not retry. I can't be sure nothing is wrong, but I can be a bit more comfortable.
Occasionally while the computer is running but no applications are active, I try to make a phone call but find the line busy, thanks to a rogue application that called for the phone line. I can't sit by the computer watching the output, but Wireshark can record all the packets over an extended period for later review. The result could be many thousands of lines of output; fortunately Wireshark has extensive filtering and highlighting capabilities.
A quick scan for DNS protocol entries quickly turned up the following line:
48 185.761385 192.168.0.3 192.168.0.1 DNS Standard query A au.download.windowsupdate.com
No doubt you can see for yourself what was trying to call out.
In addition to the examples covered here, since Wireshark can record minute details about network traffic, it can show that specific protocols are behaving as they should. Not only that, but a student of networking can spend hours digging deeply into just what does happen when your computer is calling outside.
Wireshark is one of those must-have tools in the toolbox. When using a dial-on-demand router in particular, you need to know what's demanding a dial.
Colin Beckingham is a freelance programmer and writer in Eastern Ontario. He is currently working on a project that logs and charts the operation of a biomass burner using open source resources.