This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

I have created custom IP packets using Java jpcap library. The packet header and data are assigned 20 and 26 respectively. As data I am sending "ABCDEFGHIJKLMNOPQRSTUVWXYZ". But when I analyze the packets using wireshark, it reads the 1st byte of the data, and treats it as a part of some upper layer header (say TCP!). Say the 1st IP data byte is 0x41 , i.e. 'A' so it reads 4 and treats it as start of another IPv4 header. I think I may have to change some settings! If I change the 1st data byte to some other value say 0x65, it now assumes a 'TCP' header follows.

This can happen, as wireshark reads the IP header length and data length from IP header, but it does not know when does the IP data start. It may also follow a TCP header. Is there a way I can get around this problem??

asked 26 Nov '13, 02:42

mohit93's gravatar image

mohit93
21226
accept rate: 0%


If you're creating packets you need to follow protocol specifications. Most likely you set a protocol type of 6 in your IP header, which means that the next protocol layer is TCP. And of course Wireshark will then try to decode the next bytes after the IP header as TCP - it's not Wireshark's fault that you put something else entirely in those bytes.

So if you're making stuff up try to keep it valid, so no, you do not need to change "some settings". You need to make sure your packet generator does things the right way ;-)

permanent link

answered 26 Nov '13, 02:50

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

The IP header has protocol specification as 4, and it reads IP header fine. How do I make sure that Wireshark knows -- What follows this IP header is IP data, and not the start of some other protocol header?

The first character of my IP data is 'A' or 0x41, so it reads 4 and thinks it is the start of another IP header!

I am generating my packets using jpcap and the following code:

IPPacket p=new IPPacket(); //specify IPv4 header parameters p.setIPv4Parameter(0,false,false,false,0,false,false,false,0,65,128, IPPacket.IPPROTO_IP,InetAddress.getByName("10.109.22.96"),InetAddress.getByName("10.109.22.17")); p.data=("ABCDEFGHIJKLMNOPQRSTUVWXYZ").getBytes(); EthernetPacket ether=new EthernetPacket(); ether.frametype=EthernetPacket.ETHERTYPE_IP; //set source and destination MAC addresses String strdst = new String("54:42:49:73:99:18"); ether.dst_mac = strdst.getBytes(); String strsrc = new String("70:5a:b6:8a:3b:e9"); ether.src_mac = strsrc.getBytes(); //set the datalink frame of the packet p as ether p.datalink=ether;

(26 Nov '13, 03:31) mohit93

What is the protocol type you use? You might want to take a look at this list to select a protocol type that works for you:

http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

(26 Nov '13, 03:32) Jasper ♦♦

I think you're creating an IPv4 header with a protocol type of IPv4, which means that the first IP layer marks the bytes following itself as another IPv4 header. I have no documentation about the "setIPv4Parameter" function (and I don't want to waste time on googling it), but I guess the "IPPacket.IPPROTO_IP" parameter is what is causing this.

(26 Nov '13, 03:45) Jasper ♦♦

@mohit93: see my answer to your other question:

http://ask.wireshark.org/questions/27372/two-ip-headers-before-data-using-jpcap

I think you might (probably) misunderstand the IPv4 header structure.

(26 Nov '13, 03:46) Kurt Knochner ♦
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×1,620
×248
×178
×5

question asked: 26 Nov '13, 02:42

question was seen: 3,270 times

last updated: 26 Nov '13, 03:47

p​o​w​e​r​e​d by O​S​Q​A