Revision history [back]

I'm building custom pcap files to meet business requirements for different pcap files using data streaming from a raw socket. These are UDP packets with a IPV 4 header. I'm creating a prototype of this custom pcap file manually to verify before automating it. When creating the IP header, an additional byte is inserted into the location of the TTL location resulting in the TTL value displaying the warning: ""Time To Live" only 0" rather than the value 128 that should be displayed. "128" is displayed at the protocol location. Using .Net binaryWriter and following the order of the IP header protocol, I'm writing the following values in this order:

ushort usTotalLength = (ushort)IPAddress.HostToNetworkOrder(68); //Sixteen bits for total length of the datagram (header + message) ushort usIdentification = (ushort)IPAddress.HostToNetworkOrder(27715);//Sixteen bits for identification ushort usFlagsAndOffset = (ushort)0; //Sixteen bits for flags and offset byte byTTL = 128 //Eight bits for TTL (Time To Live)

I can't upload the pcap file (don't have enough points), but it is showing a "00" byte at the location where byte value of 128 should be displayed. 128 is displayed at the next byte where protocol should be.

How is the additional byte getting added and how can I prevent it? I suspect it has something to do with the flags and offset this appear as 16 bits in wireshark.

I'm building custom pcap files to meet business requirements for different pcap files using data streaming from a raw socket. These are UDP packets with a IPV 4 header. I'm creating a prototype of this custom pcap file manually to verify before automating it. When creating the IP header, an additional byte is inserted into the location of the TTL location resulting in the TTL value displaying the warning: ""Time To Live" only 0" rather than the value 128 that should be displayed. "128" is displayed at the protocol location. Using .Net binaryWriter and following the order of the IP header protocol, I'm writing the following values in this order:

ushort usTotalLength = (ushort)IPAddress.HostToNetworkOrder(68); //Sixteen bits for total length of the datagram (header + message) ushort usIdentification = (ushort)IPAddress.HostToNetworkOrder(27715);//Sixteen bits for identification ushort usFlagsAndOffset = (ushort)0; //Sixteen bits for flags and offset byte byTTL = 128 //Eight bits for TTL (Time To Live)

I can't upload the pcap file (don't have enough points), but it is showing a "00" byte at the TTL location where byte value of 128 should be displayed. 128 is displayed at the next byte where protocol should be.

How is the additional byte getting added and how can I prevent it? I suspect it has something to do with the flags and offset this appear as 16 bits in wireshark.

I'm building custom pcap files to meet business requirements for different pcap files using data streaming from a raw socket. These are UDP packets with a IPV 4 header. I'm creating a prototype of this custom pcap file manually to verify before automating it. When creating the IP header, an additional byte is inserted into the location of the TTL location resulting in the TTL value displaying the warning: ""Time To Live" only 0" rather than the value 128 that should be displayed. "128" is displayed at the protocol location. Using .Net binaryWriter and following the order of the IP header protocol, I'm writing the following values in this order:

ushort usTotalLength = (ushort)IPAddress.HostToNetworkOrder(68); //Sixteen bits for total length of the datagram (header + message) ushort usIdentification = (ushort)IPAddress.HostToNetworkOrder(27715);//Sixteen bits for identification ushort usFlagsAndOffset = (ushort)0; //Sixteen bits for flags and offset byte byTTL = 128 //Eight bits for TTL (Time To Live)

I can't upload the pcap file (don't have enough points), but it is showing a "00" byte at the TTL location where byte with value of 128 should be displayed. 128 is displayed at the next byte where protocol should be.

How is the additional byte getting added and how can I prevent it? I suspect it has something to do with the flags and offset this appear as 16 bits in wireshark.

I'm building custom pcap files to meet business requirements for different pcap files using data streaming from a raw socket. These are UDP packets with a IPV 4 header. I'm creating a prototype of this custom pcap file manually to verify before automating it. When creating the IP header, an additional byte is inserted into the location of the TTL location resulting in the TTL value displaying the warning: ""Time To Live" only 0" rather than the value 128 that should be displayed. "128" is displayed at the protocol location. Using .Net binaryWriter and following the order of the IP header protocol, I'm writing the following values in this order:

ushort usTotalLength = (ushort)IPAddress.HostToNetworkOrder(68); //Sixteen bits for total length of the datagram (header + message) ushort usIdentification = (ushort)IPAddress.HostToNetworkOrder(27715);//Sixteen bits for identification ushort usFlagsAndOffset = (ushort)0; //Sixteen bits for flags and offset byte byTTL = 128 //Eight bits for TTL (Time To Live)

I can't upload the pcap file (don't have enough points), but it is showing a "00" byte at the TTL location where byte "80" with value of 128 should be displayed. 128 "80" is displayed at the next byte where protocol should be.

How is the additional byte getting added and how can I prevent it? I suspect it has something to do with the flags and offset this appear as 16 bits in wireshark.

I'm building custom pcap files to meet business requirements for different pcap files using data streaming from a raw socket. These are UDP packets with a IPV 4 header. I'm creating a prototype of this custom pcap file manually to verify before automating it. When creating the IP header, an additional byte is inserted into the location of the TTL location resulting in the TTL value displaying the warning: ""Time To Live" only 0" rather than the value 128 that should be displayed. "128" is displayed at the protocol location. Using .Net binaryWriter and following the order of the IP header protocol, I'm writing the following values in this order:

ushort usTotalLength = (ushort)IPAddress.HostToNetworkOrder(68); (ushort)IPAddress.HostToNetworkOrder(68);
           //Sixteen bits for total length of the datagram (header + message)
ushort usIdentification = (ushort)IPAddress.HostToNetworkOrder(27715);//Sixteen (ushort)IPAddress.HostToNetworkOrder(27715);
           //Sixteen bits for identification
ushort usFlagsAndOffset = (ushort)0; (ushort)0;
           //Sixteen bits for flags and offset
byte byTTL = 128  //Eight bits for TTL (Time To Live)
Live)

I'm building custom pcap files to meet business requirements for different pcap files using data streaming from a raw socket. These are UDP packets with a IPV 4 header. I'm creating a prototype of this custom pcap file manually to verify before automating it. When creating the IP header, an additional byte is inserted into the location of the TTL location resulting in the TTL value displaying the warning: ""Time To Live" only 0" rather than the value 128 that should be displayed. "128" is displayed at the protocol location. Using .Net binaryWriter and following the order of the IP header protocol, I'm writing the following values in this order:

ushort usTotalLength = (ushort)IPAddress.HostToNetworkOrder(68);
           //Sixteen bits for total length of the datagram (header + message)
ushort usIdentification = (ushort)IPAddress.HostToNetworkOrder(27715);
           //Sixteen bits for identification
ushort usFlagsAndOffset = (ushort)0;
           //Sixteen bits for flags and offset
byte byTTL = 128 
           //Eight bits for TTL (Time To Live)

I can't upload the pcap file (don't have enough points), but it is showing a "00" byte at the TTL location where byte "80" with value of 128 should be displayed. "80" is displayed at the next byte where protocol should be.

How is the additional byte getting added and how can I prevent it? I suspect it has something to do with the flags and offset this appear as 16 bits in wireshark.