What this post will try to do is explain some other fields that one normally sees in day to day traffic. The reason I chose to look at the below noted packets is that my modem light was blinking while I had no applications open ie: Internet Explorer, Outlook Express, and the such. This concerned me for the simple reason that my modem lights should not really be blinking if nothing is open to receive packets, but more importantly be sending them.

I happened to be in Windows XP when this happened so I fired up windump.exe to capture some packets, and see what these mystery packets were.

Seen as I have a switch to share my broadband access I did not bother copying any arp packets, as there would be quite a few arp(address resolution protocol) broadcasts.

The command syntax I used is as follows:

Code:

windump.exe –nXvs 1514 not arp

Where windump.exe is the name of the program used to collect the packets
- is syntax used to denote a command switch to follow
n means denote addresses in numerical format vice name ie: 192.169.2.1 vice say www.monkeylabs.caX means dump the outputted packets in both hex and ascii
v means dump all of the header information such as IP ID numbers, win size, amongst others
s denotes snaplength this is the amount in bytes that you will capture of the packet. The default is normally 1514 for ethernet
not this is a primitive used in building bpf style filters
arp this is the protocol arp, when specified with not this means do not collect any arp packets

As noted in the above, 2 udp broadcast packets were sent before a response was received, as evidenced by the 2 other packets seen below. I will not spend a great deal of time covering the header metrics again except for a few which were not seen in the other packet trace.

The one’s I will cover and explain are as follows:

tos 0x0 This means that the type of service (tos) is set to 0. This means that there is no "type of service" set for this packet. Please see the following noted url for an explanation of tos values http://www.zvon.org/tmRFC/RFC1349/Output/chapter4.html
Of note as well here is the 0x0 what this means is that the 0x signifies that the following value after the 0x will be in hexadecimal vice just plain decimal. Just in case you were wondering. Be aware also that 0 in hex equates to 0 in decimal as well.

The ttl value and the IP ID fields have already been explained.

len 160 This relates to the overall size of the packet itself as measured in bytes. As seen above in the hex output 4500 is the first series of numbers and letters in the packet itself. It is seen on line 0x0000 in the very first packet. Ie: I also bolded it as well. These 4 characters actually represent 2 bytes of information or 16 bits as 1 byte is composed of 8 bits. So if you count across and all the way down you will notice that the entire packet length is indeed 160 bytes. Of note here is that you start counting from 0 and not 1. So 45 is actually byte 0 and you start counting up from there.
So what we see above is 192.168.2.112 sending out a udp broadcast packet to the switch itself to see if there are any pnp services that it can access and thereby “discover”.

What we see above here is icmp (internet control message protocol) in action. This protocol is used to convey error messages back to the originating ip address to let it know of a network problem.
ICMP itself though piggbacks a ride using IP (internet protocol) and will also take the first 8 bytes after the IP message ends. This is done so that the port numbers and such can be included in the icmp message itself. This way the originating machine who sent the packet will know what went wrong.

We now see some values we have not seen before, such as the following:

icmp 36 This means that the icmp packet itself is 36 bytes long. This makes sense if you count the actual number of packets as well. It comes out to 56, and when 20 is subtracted for the ip header of 20 bytes it equals 36.

udp port 1900 unreachable This is the actual error message itself. This means that port 1900 has no service running on it so it unreachable, as it were.

What really happened here is that the switch I have received this packet, and as it was handed up the tcp/ip stack it choked on layer 3 ie: network layer IP. This layer saw the packet was sending to port 1900 udp, and the stack realized it has no such service on that port. The stack then generated an icmp message which we see above and sent it back to the originator to let it know.

I have included a couple of references below which or may not interest you. They are about the upnp protocol, and some vulnerability stuff on it. I have also included a link on the tos field in the ip header. I sincerely hope this was of some benefit to you. If part of this was unclear please post back to this thread or pm me.

For some reason, the activity light on my cable modem keeps on blinking. The WAN diagnostic light on the router also blinks when the cable modem light blinks. I tried doing what you mentioned here, but windump doesn't seem to work always. In some cases, it captures a few packets, though the light keeps on blinking all the time.

Here's a few sample packets captured. ( none of the applications were working atm )

Hello there 13x, have you had any driver issues on your computer recently? I ask this because windump definitely should capture everything that is being sent to your computer. Can you paste here what the syntax was that you used to invoke windump? The linksys is a no go as it has very limited logging capabilities iirc. I suppose it is possible that the light that is blinking is faulty but that is unlikely, however it must still be considered. Why not run a test on your box? Send it some packets and then log what it was that your received to confirm or deny your suspicions.
HTH, and if not post back.

This multicast explanation from the Linux multicasting howto explains the whole multicast concept quite well and defines 224.0.0.1 as

Quote:

224.0.0.1 is the all-hosts group. If you ping that group, all multicast capable hosts on the network should answer, as every multicast capable host must join that group at start-up on all it's multicast capable interfaces.

ttl 1 means that this is a local subnet multicast (see the howto - it explains this too).
The cable modem is probably a multicast capable device that is trying to find other multicast enabled devices on the same subnet (192.168.100.0/24).

My cable modem acts like this too. I have always assumed that this is because cable modem networks are not immediately switched at the neighboorhood level. You are not only getting packets destined for your computer, but all your neighbors as well. Your modem sends all packets to your router, which in turn recognizes that the packets aren't meant for your network, and discards them. You could test this by connecting your computer directly to the cable modem and dumping packets to see what you see. Make sure your program can capture ALL packets that the interface sees.

My cable connection only receives packets destined for it, and does not have the ability to see any other packes on my cable segment. If your ISP is set up that way it is a pretty horrible security mistake for them to have made.

Beause cable is equivilent to a shared ethernet, its the cable modem doing the filtering, and as the activity light on the surfboard is Cable activity, not the inside LAN activity, the light is flickering constantly, but most of the traffic is filtered by the modem, and you never see it.