GTPv2 Support

[ArmanTulegenov]

Would be great to add GTPv2 Support. Do you have some plans around it?

[seladb]

That's a good idea! currently I don't have plans for that, but please feel free to contribute to this project and add this support. I can assist in guidance and code reviews

[ArmanTulegenov]

Yes, I will try to add GTPv2 layer.

[seladb]

@ArmanTulegenov do you know when you'll work on this?

[mmanoj]

@ArmanTulegenov

Let ne know any help required,I also like to contribute to this patch. Pls share PCAP file with GTPv2

[seladb]

@mmanoj please feel free to implement GTPv2, let me know if you need my help!

Here are a few pcap files with GTPv2 I found online:

• 3_reattach.zip, found it here: https://blog.colte.network/pcap-library/
• test.0530152301.pcap.zip, found it here: https://gitlab.com/wireshark/wireshark/-/issues/16594

[mmanoj]

@seladb

Thanks for the quick reply and support,sure I will looking in to it and update you.Currently I'm working on Radius 3GPP dictionary attributes decoding.I will check is it possible to open source with pcpp.

[mmanoj]

Hi @seladb

I'm working on initial work for GTPv2 message decoding, I will update you the progress,currently checking the core spec and protocol details.

[seladb]

Sounds good @mmanoj , thanks for the update!

I am looking forward to seeing your PR.

cc @egecetin

[mmanoj]

@seladb
Can you explain the below code, are you looking the bit pattern, I'm trying to relate with wireshark output for GTPv1 to plan the GTP2 code

bool GtpV1Layer::isGTPv1(const uint8_t* data, size_t dataSize)
{
if(data != NULL && dataSize >= sizeof(gtpv1_header) && (data[0] & 0xE0) == 0x20)
{
return true;
}

return false;

}

[mmanoj]

[mmanoj]

above from 3_reattach.zip

[seladb]

@mmanoj the idea is to look at the first 3 bits of the Flags byte. In GTPv1 these bits will be set to 001:

And in GTPv2 they will be set to 010:

Please let me know if that makes sense

[mmanoj]

@seladb
Can you check my calculation and understanding is correct?

GTPv1:
00110000
11100000 (0xE0) AND

00100000 = 20 in hex

GTPv2:
01001000
11100000 (0xE0) AND

01000000 =40 in Hex

bool GtpV2Layer::isGTPv2(const uint8_t* data, size_t dataSize)
{
if(data != NULL && dataSize >= sizeof(gtpv2_header) && (data[0] & 0xE0) == 0x40)
{
return true;
}

return false;
}

[seladb]

@seladb Can you check my calculation and understanding is correct?

GTPv1: 00110000 11100000 (0xE0) AND

00100000 = 20 in hex

GTPv2: 01001000 11100000 (0xE0) AND

01000000 =40 in Hex

bool GtpV2Layer::isGTPv2(const uint8_t* data, size_t dataSize) { if(data != NULL && dataSize >= sizeof(gtpv2_header) && (data[0] & 0xE0) == 0x40) { return true; }

return false; }

@mmanoj I think this is correct. The best way to make sure is to test with a real GTPv2 packet 😃

[mmanoj]

@seladb

Thanks for the feedback.I will check and update you.Please share your email if possible to easy communication.

[seladb]

Sure @mmanoj thank you! 🙏

You can always reach out to me at pcapplusplus@gmail.com

[mmanoj]

@seladb

can you advice, what will be the impact of below in example live capture app
// Capturing packets in a packet vector
pcpp::multiPlatformSleep(10)
As per my tests it will impact the capture performance/PPS

I observed low sleep leading to packet loss.Any idea?

[seladb]

@mmanoj as mentioned in the comment below this line:

PcapPlusPlus/Examples/Tutorials/Tutorial-LiveTraffic/main.cpp

Line 181 in fb3a560

// sleep for 10 seconds in main thread, in the meantime packets are captured in the async thread

We sleep for 10 seconds in the main thread while the packet capture happens in another thread. Packet loss may happen if the capture thread cannot handle the volume of packets...

[mmanoj]

@seladb

Thanks for the feedback, when I shifted to blocking mode it's seems drop rate reduce to 0.02% . The PPS we tested around 5000 PPS. I dont think it's big amount as per the framework bench marked results.

[seladb]

it's hard to analyze the packet loss without diving deeper into the details. In general blocking mode might be a bit faster because the packet capture happens on the main thread, while in non-blocking mode the main thread is running in parallel to the capture thread. But it's hard to say for sure if this is causing the difference in packet loss

[hpirlo]

@seladb

I want to start working on GTPv2. Would you please tell me what the current situation is with this issue?
Is there any progress, or should I start from scratch?

[seladb]

@seladb

I want to start working on GTPv2. Would you please tell me what the current situation is with this issue? Is there any progress, or should I start from scratch?

@hpirlo I don't think anyone is working on it now, I'd really appreciate if you can work on it

[mmanoj]

@seladb and @hpirlo

Sorry for late reply, not much work done after above due to other priority work.However I can help much as I can also I can share the initial work I done for the GTPv2.

[hpirlo]

@mmanoj

I think it is good to create a branch and share what you've done in GTPv2 so that I can continue and complete it. Thanks.