We've run in to cases where we are getting sent proprietary UDP packets on the same port used by L2TP (1701). The result is that the UdpPacket intercepts the raw bytes and instead attempts to parse them as an L2tp Packet. We need a way to disable automatic Udp PayloadPacket (force payload data). Is there a way to do this already? I am working on a custom build that just disables this, but would be great if there is an API flag somewhere to optionally disable this.

Could be usefull a IPortPacket interface for TcpPacket and UdpPacket

public interface IPortPacket
{
        /// <summary> Fetch the port number on the source host.</summary>
        ushort SourcePort { get; set; }
        /// <summary> Fetches the port number on the destination host.</summary>
        ushort DestinationPort { get; set; }
}

or add it to TransportPacket

Using this lib in a signed assembly generates the warning:

warning CS8002: Referenced assembly 'PacketDotNet, Version=1.0.1.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.

Is there a specific reason for not using signing?

Hi, I am getting error when I am trying to get Packet.TotalPacketLength in my app. Could you please look at this? Am I doing something wrong?

Packet which causes this error:

3333000000FBE88D28562B6086DD6000000004D82CFFFE80000000000000EA8D28FFFE562B60FF0200000000000000000000000000FB1100000134A858D314E914E905B04849000084000000001E0000000101320131033136380331393207696E2D61646472046172706100000C80010000007800120A50726F4E6574776F726B056C6F63616C001835302D33352D31302D37302E312050726F4E6574776F726B0C5F736C6565702D70726F7879045F756470C03B0010800100001194000100095F7365727669636573075F646E732D7364C068000C0001000011940002C05BC05B000C0001000011940002C0422D44356173456D5255574F65516F5445453843756C4B674045373766316F6C37587375384F3644755864784E6A77095F6163702D73796E63045F746370C03B0010800100001194008B2763753D34646465363562372D656539302D353535662D613561392D6632306565313465393332320D6E6D3D50726F4E6574776F726B156D61633D45383A38443A32383A35363A32423A36300F737369643D50726F4E6574776F726B2E627373696E666F3D4151494C55595949414141483649306F572B43375A48715743414141422B694E4B4676677641C07A000C0001000011940002C0D6C0D6000C0001000011940002C0A80130013601420132013601350145014601460146013801320144013801410145013001300130013001300130013001300130013001300130013001380145014603697036C020000C8001000000780002C0300A50726F4E6574776F726B085F616972706F7274C0E0001080010000119400AAA977614D413D45382D38442D32382D35362D32422D36302C72614D413D45382D38442D32382D35422D45302D42422C72614D323D45382D38442D32382D35422D45302D42432C72614E6D3D50726F4E6574776F726B2C726143683D31312C724368323D3130302C726153743D302C72614E413D302C7379466C3D3078383030432C737941503D3131372C737956733D372E362E342C737263763D37363430302E31302C626A53643D3634C07A000C0001000011940002C1F5C1F5000C0001000011940002C1EA0A50726F4E6574776F726B0C5F6465766963652D696E666FC0E000100001000011940013126D6F64656C3D416972506F7274352C313137C0420021800100000078000800000000F928C030C03000018001000000780004C0A80102C0A800218001000000780008000000001391C030C030001C8001000000780010FE80000000000000EA8D28FFFE562B60C1EA00218001000000780008000000001391C030023531033138340332353403313639C018000C8001000000780002C030C03000018001000000780004A9FEB833C07A000C000100001194000B085F616972706C6179C0E0C3A8000C000100001194000F0C4170706C6520545620283429C3A80C4170706C6520545620283429C2DB0010000100001194000C0B6D6F64656C3D4A33334150C07A000C0001000011940008055F72616F70C0E0C3FF000C000100001194001C19394332303742394239373844404170706C6520545620283429C3FFC07A000C000100001194000E0B5F746F7563682D61626C65C0E0C43B000C00010000119400131037333233423843413738383237453343C43BC07A000C000100001194000E0B5F6170706C6574762D7632C0E0255F30303030303030302D343539392D346332322D386339662D343062643964393434633565045F737562C474000C0001000011940013103733323342384341373838323745

System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.
Parameter name: startIndex
at PacketDotNet.MiscUtil.Conversion.EndianBitConverter.CheckByteArgument(Byte[] value, Int32 startIndex, Int32 bytesRequired)
at PacketDotNet.UdpPacket.get_DestinationPort()
at PacketDotNet.UdpPacket.<.ctor>b__21_0()
at System.Lazy1.CreateValue() at System.Lazy1.LazyInitValue()
at System.Lazy`1.get_Value()
at PacketDotNet.Packet.get_TotalPacketLength()
at PacketDotNet.Packet.get_TotalPacketLength()
at PacketDotNet.Packet.get_TotalPacketLength()
at Shared.Core.ExtensionMethods.ConvertToStatistics(RawCapture rawCapture) in C:\Git\Katalyzer\Client\Shared\Core\ExtensionMethods.cs:line 53
at Shared.Core.KaTaLyzerWorker.ProcessPacket(Object networkAdapter, RawCapture rawCapture) in C:\Git\Katalyzer\Client\Shared\Core\KaTaLyzerWorker.cs:line 99

Hi,

I've been doing some work with ICMPv6 packets and I was getting some exceptions handling ICMPv6 packets since not all of the ICMPType values in the RFC were in the ICMPv6Types enumeration. I've added them as shown below. I'm sending it along to get it incorporated in the main branch:

public enum ICMPv6Types : byte
{

pragma warning disable 1591

    #region ICMPv6 Error Messages
    Reserved = 0,
    DestinationUnreachable = 1,
    PacketTooBig = 2,
    TimeExceeded = 3,
    ParameterProblem = 4,
    PrivateExperimentation1 = 100,
    PrivateExperimentation2 = 101,
    ReservedForExpansion1 = 127,
    #endregion
    #region ICMPv6 Informational Messages
    EchoRequest = 128,
    EchoReply = 129,
    MulticastListenerQuery = 130,
    MulticastListenerReport = 131,
    MulticastListenerDone = 132,
    RouterSolicitation = 133,
    RouterAdvertisement = 134,
    NeighborSolicitation = 135,
    NeighborAdvertisement = 136,
    RedirectMessage = 137,
    RouterRenumbering = 138,
    ICMPNodeInformationQuery = 139,
    ICMPNodeInformationResponse = 140,
    InverseNeighborDiscoverySolicitationMessage = 141,
    InverseNeighborDiscoveryAdvertisementMessage = 142,
    Version2MulticastListenerReport=143,
    HomeAgentAddressDiscoveryRequestMessage = 144,
    HomeAgentAddressDiscoveryReplyMessage = 145,
    MobilePrefixSolicitation = 146,
    MobilePrefixAdvertisement = 147,
    CertificationPathSolicitationMessage = 148,
    CertificationPathAdvertisementMessage = 149,
    ICMPExperimentalMobilityProtocols = 150,
    MulticastRouterAdvertisement = 151,
    MulticastRouterSolicitation = 152,
    MulticastRouterTermination = 153,
    FMIPv6Messages = 154,
    RPLControlMessage = 155,
    ILNPv6LocatorUpdateMessage = 156,
    DuplicateAddressRequest = 157,
    DuplicateAddressConfirmation = 158,
    MPLControlMessage=159,
    PrivateExperimentation3 = 200,
    PrivateExperimentation4 = 201,
    ReservedForExpansion2 = 255
    #endregion

pragma warning restore 1591

}

Versions have been bumped up but nuget packages aren't being pushed. @haufes any ideas?

Hello,

This specific line is annoying if we are setting an Ethernet Type out of the switch scope provided. We need to re-write the type after the PayloadPacket set. I think we can remove or set a warning message on debug that uncommon Ethernet type is used.

https://github.com/chmorgan/packetnet/blob/86e8aaaf59590cb6c81fe19c3ff350f79eebcdc5/PacketDotNet/EthernetPacket.cs#L153

Regards

IP Header Protocol is 50(ESP), how to look ESP Info?

Hi,
there are plans to support the dissection of the DNS protocol packets?

Thanks in advance!

• Parameter renaming, many function parameters are named with a Capital, this makes it hard to distinguish them from properties and fields.
• Remove unneccessary this.
• Replace declarations with var where applicable.
• Use collection initializers.
• Simply type names, e.g., System.Type can be just Type.
• Remove redundant else.
• Remove empty constructors
• Use string interpolation instead of String.Format.

I can do this one by one, but it would require a merged PR before moving to the next point as it's too messy to put these in separate PRs all at once.

Hi. The question is, why don't all package classes implement the IEquatable interface or override the Equals and GetHashCode methods? But the toString method is overridden and returns the full representation of the entire package as a string. Why can't you do something similar for comparison methods? In my opinion, this would be useful. For example, when working with collections, this will eliminate the need to write a comparator for comparing packages.
Anton.

See appveyor/ci#2753 and https://help.appveyor.com/discussions/problems/27680-deployment-issue-nuget.

The GRE protocol is not correctly parsed by the PacketNet library

in GrePacket.cs

original code :
public bool HasCheckSum => 8 == (Header.Bytes[Header.Offset + 1] & 0x8);
public bool HasKey => 2 == (Header.Bytes[Header.Offset + 1] & 0x2);
public bool HasReserved => 4 == (Header.Bytes[Header.Offset + 1] & 0x4);
public bool HasSequence => 1 == (Header.Bytes[Header.Offset + 1] & 0x1);

proposal for new code :
public bool HasCheckSum => 0x80 == (Header.Bytes[Header.Offset + 0] & 0x80);
public bool HasKey => 0x20 == (Header.Bytes[Header.Offset + 0] & 0x20);
public bool HasReserved => false; // 4 == (Header.Bytes[Header.Offset + 1] & 0x4);
public bool HasSequence => 0x10 == (Header.Bytes[Header.Offset + 0] & 0x10);

See also https://en.wikipedia.org/wiki/Generic_Routing_Encapsulation

Example where the original code fails :
gre_seq_2.zip

I parse a packet by doing with Packet.ParsePacket(LinkLayers.Ieee80211_Radio, buffer), which gives me a RadioPacket.

That RadioPacket.PayloadPacket contains a QosDataFrame which itself contains some PayloadData, but no PayloadPacket.

In Wireshark I still see Logical-Link Control, then IPv4, then TCP, then finally some payload data (see OnePacket.zip). Am I doing something wrong, or are things not yet implemented?

I tried with the latest release 0.14.0, as well as with the current master.

System.ArgumentException: Source array was not long enough. Check the source index, length, and the array's lower
   at System.Array.Copy(Array sourceArray, Int32 sourceIndex, Array destinationArray, Int32 destinationIndex, Int32 length, Boolean reliable)
   at PacketDotNet.Utils.ByteArraySegment.ActualBytes()
   at ********.HandlePacketAsync(DateTime packetTimeStamp, IPPacket packet, Object packetData) in ******\TcpParser.cs:line 167

The exception was at the end of one async function that even doesn't call ActualBytes. I can't give the packet that caused that issue, because it happend on production where we do not collect all packets.

I am trying to parse out packets from a IPv4 UDP stream that I know in their payloads have IPv6 TCP data. They are being encapsulated using the Teredo protocol. https://tools.ietf.org/html/rfc4380

Can packetnet be able to parse the UDP payload and notice there are embedded packets.

Hey,

Just wanted to ask a question about your thoughts on how PacketDotNet fits in with a single file deployment?

We're using PacketDotNet, and want to package our app as a single file, but we're aware that the LGPL for PacketDotNet requires the DLL for the library be swappable.

Do you have a position on this?

Thanks (and appreciate the library!)

Please be kind, I'm new at this....

Can anyone help me through the process of adding another Ethertype? I see that support for Profinet was added back in late 2017, but I need a very similar/related type added, Profinet MRP (PN-MRP), 0x88e3.

What I am not sure of is after I edit the appropriate file, what do I then do to get a new dll to use in my project? I am just not clear on the steps. And can I do this with VS 2015 or do I need a much newer version?

Thanks for any help.

Tom

Hello?

When I try to parse udp packet like this:

Packet packet = Packet.ParsePacket( LinkLayers.Ethernet, raw_capture.Data ) ;
Debug.Assert( packet is EthernetPacket ) ; // OK.
Debug.Assert( packet.PayloadPacket is IPv4Packet ) ; // OK
Debug.Assert( packet.PayloadPacket.ParentPacket != null ) ; // Nop. it is always null.

In my thought, packet.PayloadPacket should be IPv4Packet, and packet.PayloadPacket.ParentPacket must be packet itself. Isn't it?
But, in my code, packet.PayloadPacket is IPv4Packet, but packet.PayloadPacket.ParentPacket is always null.

It is null even I try with ARP packet.

What should I do or check?

My PacketDotNet is downloaded from nuget.org and its version is v1.1.1.

I noticed while going through the code of packetnet the following pattern:

        /// <value>
        /// The Type/Code enum value
        /// </value>
        public virtual ICMPv4TypeCodes TypeCode
        {
            get
            {
                var val = EndianBitConverter.Big.ToUInt16(header.Bytes, header.Offset + ICMPv4Fields.TypeCodePosition);

                //TODO: how to handle a mismatch in the mapping? maybe throw here?
                if(Enum.IsDefined(typeof(ICMPv4TypeCodes), val))
                    return (ICMPv4TypeCodes)val;
                else
                    throw new System.NotImplementedException("TypeCode of " + val + " is not defined in ICMPv4TypeCode");
            }

            set
            {
                ///
            }
}

The statement throw new System.NotImplementedException(...); is a big GOTCHA, for most developers
and according to SonarQube, a CodeSmell

Thinking about this backwards, the line return (ICMPv4TypeCodes)val; actually never fails.

So the above code could be simplified as

        /// <value>
        /// The Type/Code enum value
        /// </value>
        public virtual ICMPv4TypeCodes TypeCode
        {
            get
            {
                return (ICMPv4TypeCodes) EndianBitConverter.Big.ToUInt16(header.Bytes, header.Offset + ICMPv4Fields.TypeCodePosition);;
            }

            set
            {
                ///
            }
}

When I upgraded from sharppcap 5.1 to 5.3 a new version of PacketDotNet also came with the upgrade. Now when I parse large wireshark files, ones larger than 1.6 GB, packetDotNet crashes every time with outOfMemory exceptions.

If I rollback to SharpPcap 5.1 it works perfectly, even capture files over 6 GB in size.

It is very confusing, I wish it had little help or documents.

This is less of an issue and more a feature request possibly? But I was wondering if there was a way to get the information column, similar to what you see in wireshark, from the pcap file? Is this something we could easily add to this library? or does anyone know how that is created? Thanks!

I get corrupted data when reading a PCAP file that contains a packet with IPv6 fragment header.

Repro code:

    class Program
    {
        static void Main(string[] args)
        {
            var captureDevice = new CaptureFileReaderDevice("test2.pcap");
            captureDevice.OnPacketArrival += captureDevice_OnPacketArrival;
            captureDevice.StartCapture();
        }

        static void captureDevice_OnPacketArrival(object sender, CaptureEventArgs captureEventArgs)
        {
            RawCapture rawCapture = captureEventArgs.Packet;

            // The assertions below test against the correct data - and they pass.
            Debug.Assert(rawCapture.Data[66] == 0);
            Debug.Assert(rawCapture.Data[67] == 0);
            
            Packet packet = Packet.ParsePacket(LinkLayers.Ethernet, rawCapture.Data);

            // The line below, or any further dissecting of the packet, triggers the corruption.
            byte[] bytes = packet.Bytes;

            // The assertions below test against the correct data - and they now fail.
            Debug.Assert(rawCapture.Data[66] == 0);
            Debug.Assert(rawCapture.Data[67] == 0);

            // Cannot really dissect any packets with fragment header for IPv6 - the data gets corrupted.
        }

PCAP file (zipped) - it has just one packet in it:
test2.zip

As it can be verified e.g. in Wireshark or by viewing the PCAP file in hex editor, there should be zeros in two bytes close to the beginning of this 2nd fragment of UDP payload (offsets are 4, 5 in this fragment of the UDP payload). And indeed, the raw capture initially has the zeros. But I cannot work with raw capture - I want to dissect it. After Packet.ParsePacket however, accessing the Packet.Bytes or further dissecting the packets modifies the raw capture - and anything derived from it becomes immediately corrupted as well. The second set of assertions in the code shows how the bytes inside the payload have changed from zero to non-zero.

Do packetnet have plan to support automatic combine this MTU split packet into finally one large packet,so that I can decode it more easily.

I'm working to convert the tests from a .net framework target to .net core so it is compatible with windows, Mac, and linux again without using mono. Binary serialization is a lot different in .net core, see https://github.com/dotnet/corefx/issues/23213 and when running as a .net core executable there are several failures like:

Message: System.Runtime.Serialization.SerializationException : Type 'System.Lazy`1[[PacketDotNet.PacketOrByteArraySegment, PacketDotNet, Version=0.30.1.0, Culture=neutral, PublicKeyToken=null]]' in Assembly 'System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e' is not marked as serializable.

should we drop these tests? What is the benefit/purpose of keeping these serialization tests working? @Phyxion any thoughts?

Could you please publish latest release as NuGet package?

@PhyxionNL should we fix the appveyor build? Maybe we can just upgrade the visual studio version and it will be fixed? I can take a look.

https://github.com/chmorgan/packetnet/blob/master/PacketDotNet/TcpPacket.cs#L431
causing false positive detection as DRDA packet and corrupt it.

Hello dear @chmorgan

When I'm parsing the following packet I get this error :

byte[] b = new byte[]{0,140,250,155,238,45,8,158,1,238,86,55,8,0,69,0,0,23,59,214,0,185,128,6,44,53,192,168,6,1,192,168,6,2,158,163,173};
PacketDotNet.Packet packet = PacketDotNet.Packet.ParsePacket(LinkLayers.Ethernet,b );

An unhandled exception of type 'System.IndexOutOfRangeException' occurred in PacketDotNet.dll
Additional information: Index was outside the bounds of the array.

Dear Chmorgan:
Test will fail if linktype_null_capture packet is in pcapng format, I try to convert it to pcap format using wireshark, and error will fix.

Would it be possible to support the PROFINET protocol as a valid EtherType?

This would be 0x8892 PROFINET Protocol.

I can create a tcp packet with class TcpPacket by using constructor:
public TcpPacket(ushort sourcePort, ushort destinationPort)

But if I Change Property OptionsCollection, it will throw exception, becouse the tcp header's length is not big enough to hold the options. Is this a bug or not implemented?

Is there anyway when I processing files, to know the offset of the current packet within the larger pcap file? I am having a hard time figuring/finding it out, and it could be helpful for me. Thanks!

How to construct a valid ICMPv4Packet using PacketDotNet?

Currently I can only use PcapDotNet.Packets to construct these packets.

Love this project. Good job on it. I've got a question regarding physical address section of the ethernet packet. How can this be obtained without using SharpPcap? I saw an example of resolving it but it required this library to do it.

Another question is how can I transform my "ready" ethernetpacket into bytes that will be ready to be sent over a raw socket on windows using c#?

The proper tag is TargetFramework not TargetFrameworks. Until that tag is changed, the "Target Framework" box on the "Application" tab in the project properties will be greyed out.

Hi Chris,

I come across Span and Memory recently and realized that it may greatly improve performance instead of ByteArraySegment. Without further needs for allocation of new memory and copying parts of payload.

What are your thoughts?

An 802.1ad (EthernetPacketType.ProviderBridging) VLAN tag is just an 802.1Q (EthernetPacketType.VLanTaggedFrame) VLAN tag with a TPID value of 0x88a8 rather than 0x8100.

When EthernetPacket.ParseNextSegment() is parsing the Ethernet payload data to set the PayloadPacket property, it creates an Ieee8021QPacket object for an 802.1Q tag, but not for an 802.1ad tag, thus the PayloadPacket ends up being set to null.

I suggest setting the PayloadPacket to an Ieee8021QPacket for an 802.1ad tag. Maybe even create a new Ieee8021ADPacket class that derives from Ieee8021QPacket.

During some testing I found that the parse wasn't able to handle the the raw link layer (101)

In LinkLayers.cs it's set to 12.

Here is the list of linktypes
http://www.tcpdump.org/linktypes.html

I actually have the fixed it locally and have it working with pcap that I feed it, but I can't submit it because 2 of the test that read are expecting a LinkLayer of 12. That is being returned from Sharppcap. I haven't gone very far into looking as to why.

Current solution targets .NET framework 4.6.1. Windows Server 2012 R2 and 8.1 was shipped with 4.5.1 and is still widely used and no newer version might be available because of policies.

Could 4.5.1 be the default?

As description in HERE, when constructing a LLDP packet and getting bytes by calling Packet.Bytes, we will get a NullReferenceException (see the stackoverflow page for details).

And there is a workaround in that page:

var packet = LLDPPacket.RandomPacket();
var lldpBytes = packet.Bytes;
var lldpPacket = new LLDPPacket(new ByteArraySegment(lldpBytes));

After "reparsing" we can get the bytes. I think this may be a bug. also see

When I run analysis on a L2tp Packet, the session ID is showing up as 0, but when I open the same packet in wireshark, It shows the session ID as 4000? Checking the Bytes, it also looks like it should be 4000.

The call to TcpPacket.IsValidChecksum lead to that exception:

Fatal error. System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at PacketDotNet.Utils.ChecksumUtils.Sum(Byte*, Int32, UInt64)
   at PacketDotNet.Utils.ChecksumUtils.OnesSum(Byte*, Int32, Byte*, Int32)
   at PacketDotNet.Utils.ChecksumUtils.OnesSum(PacketDotNet.Utils.ByteArraySegment, Byte[])
   at PacketDotNet.TransportPacket.IsValidChecksum(TransportChecksumOption)

I can't give the packet that caused that issue, because it happend on production where we do not collect all packets.

When using ToString(Verbose) with an LLDP packet for some TLVs the value is not printed (there is instead the string System.Byte[]).
This is the output I have when reading a packet:

LLDP:[ChassisID: SubType=MACAddress, SubTypeValue=4C9EFFF4F183]
LLDP:[PortID: SubType=LocallyAssigned, SubTypeValue=System.Byte[]]
LLDP:[TimeToLive: Seconds=120]
...
LLDP:[ManagementAddress: AddressLength=5, AddressSubType=IPv4, MgmtAddress=[NetworkAddress: AddressFamily=IPv4, Address=192.168.1.1], InterfaceSubType=3, InterfaceNumber=0, ObjIdLength=0, ObjectIdentifier=]
LLDP:[OrganizationSpecific: OrganizationUniqueID=System.Byte[], OrganizationDefinedSubType=1, OrganizationDefinedInfoString=System.Byte[]]
LLDP:[OrganizationSpecific: OrganizationUniqueID=System.Byte[], OrganizationDefinedSubType=2, OrganizationDefinedInfoString=System.Byte[]]
LLDP:[OrganizationSpecific: OrganizationUniqueID=System.Byte[], OrganizationDefinedSubType=3, OrganizationDefinedInfoString=System.Byte[]]
LLDP:[OrganizationSpecific: OrganizationUniqueID=System.Byte[], OrganizationDefinedSubType=4, OrganizationDefinedInfoString=System.Byte[]]
LLDP:[OrganizationSpecific: OrganizationUniqueID=System.Byte[], OrganizationDefinedSubType=5, OrganizationDefinedInfoString=System.Byte[]]
LLDP:[EndOfLLDPDU]
LLDP:

I would like to ask you if somebody knows how to help with this problem. I cannot run my project in Ubuntu 14.04. There is missed package "PacketDotNet" and I need to run it in .Net Core project.
Thanks for any idea and help.

was the any plan support SCTP ?

Hello @Phyxion. I can't recall why we are releasing for .netframework 4.5 at this point. Thoughts on dropping that and targeting .net core 2.0 only?

Hi, I've found a fancy bug during some tests over a PCAP file.
During the PCAP file parsing I've got an error over this line of code:
IPv4Packet innerIpPacket = new IPv4Packet(new PacketDotNet.Utils.ByteArraySegment(icmpPacket.PayloadData));

I've spent a bit of time to understand why I've got this error. The only thing I've found it's a somekind of mismatch between the actual size of the IP packet and the one included within the ICMP packet (as shown in the attached image).

I've found that PCAP on the NETRESEC page (https://www.netresec.com/?page=PCAP4SICS) and the file is the 4SICS-GeekLounge-151021.pcap one.
The "faulty" packet is the number 499531.

I think that this kind of mismatch should be checked within the library.
The bug is present on the NuGet version and on the latest, master, version of the library.

A simple walkaround is to catch the exception, and gather all the data is possible from the original IP packet and from the ICMP packet, but everything inside the ICMP packet is "lost".

I hope that you can find a better solution for this kind of cases.