Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have made an packet capture application running on intel machine, it is capturing packets with src address- 17.0.0.0 destination ip- 66.0.0.0, source port- 0, destination port- 0, and protocol- 0 what does this packet mean ?

share|improve this question

migrated from apple.stackexchange.com Feb 13 '13 at 1:22

This question came from our site for power users of Apple hardware and software.

    
Perhaps you could download Wireshark and compare? –  H3br3wHamm3r81 Feb 13 '13 at 20:00

1 Answer 1

In principle, those are valid IP addresses, but in practice they'll both be reserved as the addresses of networks, not individual computers, so you shouldn't see packets with them as the source or destination. Also, protocol 0 is apparently the IPv6 Hop-by-Hop option](http://www.iana.o[rg/assignments/protocol-numbers/protocol-numbers.xml), so I don't think you should see it on an IPv4 packet.

Net result: I'm pretty sure something is going wrong with your capturing and/or decoding. I'd try capturing with tcpdump and see what it makes of these packets.

share|improve this answer
    
The code written to interpreter captured bytes is given below. Which basically locate source address, destination address, source port, destination port, and protocol from various headers from packet captured. After it is done then only TCP and UDP packets are stored into a file. so it means only those packets having protocol number 6,17 should be saved but when i go through the file the packets with protocol 0,20,255,100,8,66 are also saved more over strange IP address are also seen like.2.8.2.8, 17.0.0.0, 66.0.0.0, 0.0.0.0 etc what are these packets, am i correct in my approach. –  Arunpushkar Feb 11 '13 at 9:57
1  
if (ntohs (eptr->ether_type) == ETHERTYPE_IP) struct iphdr ip4h = (struct iphdr *)(packet + sizeof(struct ethhdr) ); ip_hdr_len =ip4h->ihl*4; next_protocol=ip4h->protocol;next_protocol=ip4h->protocol;switch (next_protocol) { case 6:TCP struct tcphdr *tcph=(struct tcphdr)(packet + ip_hdr_len + sizeof(struct ethhdr)); case 17:UDP struct udphdr udph = (struct udphdr)(packet + ip_hdr_len + sizeof(struct ethhdr)); –  Arunpushkar Feb 11 '13 at 10:16
    
From your description, there's definitely something wrong with the packet handling code, but I can't tell what from that snippet. I suspect the easiest thing will be to save some raw packets that get weird results, see what tcpdump parses them as (so you know what the should parse out as),then step through your code in a debugger and see why it doesn't get the same result. –  Gordon Davisson Feb 13 '13 at 4:46

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.