IP header "total length" vs. packet size

I'm trying to write a sniffer using pcap -- but that's probably not so relevent to my question(s). I'm learning about network layers at the same time.

My first question is: will the "total length" field of an ip header usually be larger than than the packet size because the packets are split up on a lower level?

If so then I'm sure I've got my read on the ip header aligned correctly. I'm still not sure about the tcp header tho. Here's some sample output:

Code:

---

Destination: 00:1f:90:01:0e:8c  Source: 00:e0:4d:89:b5:73 (type 8)
IP from: 192.168.1.26 to: 67.51.182.68 length=13312 (protocol 6)
<port #15835, >port #20480, FLAGS: ACK  (tcp header is 32 bytes)
Packet Size 66

Destination: ff:ff:ff:ff:ff:ff  Source: 00:18:de:0b:f1:93 (type 8)
IP from: 192.168.1.27 to: 192.168.1.255 length=60672 (protocol 17)
<port #35328, >port #35328, FLAGS: PUSH URG  (tcp header is 48 bytes)
Packet Size 251

---

The tcp stuff is the third line. It looks like there's two machines (26 & 27) in the sample. But the port numbers look possibly wrong to me; like I said, I know almost nothing about networking. Anyone with some experience and an opinion?

ps. what are ethernet types 9728 and 1544?

later...okay I have this right. I was just hoping these ports would align with IANA assignments so I could, eg. pick out SMTP or HTTP

Quote:

---

My first question is: will the "total length" field of an ip header usually be larger than than the packet size because the packets are split up on a lower level?

---

fragmentation is managed by the IP layer so it's not at a lower level, the field size is the size of the packet, if the initial data buffer was fragmented, there is another field indicating the current packet offset whithin the whole buffer.

Quote:

---

But the port numbers look possibly wrong to me;

---

not necessarily, it depends on what you're sniffing, but remember that not only servers but clients use ports too (generally assigned by the kernel, so those values are generally higher as the first 5000 ports are reserved). To convince you, try 'netstat' on your machine and look at the client ports.

Well, as it turns out some of those numbers (besides the addresses themselves) in the ip & tcp headers are in network byte order, surprise. So I had to apply ntohs() to the length and port numbers to yield more predictable results (in which the "total length" given in the ip header is 14 bytes shorter than the packet size, since it doesn't include the eth header), and I see a lot of "port #80" (hey, now I know port 80 is 20480 in network byte order).

Still don't know what those other types are; they must be internal to the LAN or machine.