Ask Your Question

Malformed S1AP NAS-PDU

asked 2018-12-12 18:35:22 +0000

dandreye gravatar image

updated 2018-12-12 19:44:48 +0000

Hi All,

I'm getting "Malformed Packet: NAS-PDU" when trying to decode my S1AP Initial UE Message (Attach Request):

Item #1 NAS-PDU appears to include (besides several others) the last IE 40 05 70 40 26 00 00, which looks formatted as TLV with IEI=0x40, Length = 5 and Value = 70 40 26 00 00. What type of IE is that and why is it not decoding? I briefly checked 24.007 and 24.008 and didn't come across IEI 0x040 although pretty sure I'm overlooking it. My Wireshark version is 2.4.5 (v2.4.5-0-g153e867ef1).

Many thanks in advance!

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2018-12-12 20:29:38 +0000

Pascal Quantin gravatar image


IEI 0x40 is the Supported Codecs one.

Wireshark triggers a malformed packet because the previous IE (MS Classmark 3) is malformed, leading to the parsing error in Wireshark.

I will probably modify Wireshark to explicitly flag the MS Classmark 3 as having a length too short compared to the payload parsing.

But the Supported Codecs IE is also malformed...

edit flag offensive delete link more


Hi Pascal - thank you,

the MS Classmark 3 as having a length too short

Not sure if I got the idea right but looks like manually changing its current length 03 to 0A makes the whole message decode correctly, so I'm wondering if that 40 05 70 40 26 00 00 is Supported Codecs IE indeed or rather it's just part of MS Classmark 3..

Please let me know if you want me to file a bug/enhacement on it anyway.

Thanks & Regards,


dandreye gravatar imagedandreye ( 2018-12-12 21:09:13 +0000 )edit

Manually modifying the IE length allows you to hide the problem, but still the MS Classmark 3 content is suspicious (spare bit set to 1, A5/7 algorithm supported while it does not exist), so I doubt it is valid.

Anyway I added an extra check in this commit:

It will trigger another malformed error but with a more meaningful message.

Pascal Quantin gravatar imagePascal Quantin ( 2018-12-12 22:06:21 +0000 )edit

Thank you: I'm checking NAS-EPS PDU encoding with our Engineering team in parallel.

dandreye gravatar imagedandreye ( 2018-12-12 22:11:01 +0000 )edit

Hi Pascal, sorry could you please explain why exactly Wireshark used to consider my MS Classmark 3 "as having a length too short compared to the payload parsing"? After Item 1 ID code 0x26 (id-NAS-PDU) and 0x00 (criticality=reject) goes 0x37, which looks like a valid length of the remainder as it covers it exactly incl Supported Codecs IE. Meanwhile MS Classmark 3 IE itself has allowed length 0x03 (which can be 1-32 octets as per 3gpp 48.008), same as MS Classmark 2 IE. So I'm struggling to understand why Wireshark used to consider Supported Codecs IE as the continuation of MS Classmark 3 before the changes you've made. Meanwhile how can I obtain the build with the changes? Thanks in advance, Dmitriy

dandreye gravatar imagedandreye ( 2018-12-15 16:05:35 +0000 )edit

You need to check the MS Classmark 3 encoding in 3GPP 24.008 spec and do the decoding manually. You will see that the parsing of the bits goes beyond the 3 bytes indicated in the IE, which is an encoding error. You an find builds with my change here: But again it simply gives a better error message, it does not solve anything as the message is not properly encoded.

Pascal Quantin gravatar imagePascal Quantin ( 2018-12-15 19:32:40 +0000 )edit

Here are my manual MS Classmark 3 decoding results: 20 = its IE type, 03 = its length, E8 80 1F = its value. I cannot see anything wrong here... what exactly makes Wireshark decide that what follows is the continuation of MS Classmark 3 IE and not the next IE? Shouldn't it obey MS Classmark 3 length alone and parse exactly 3 successive octets no matter what?

dandreye gravatar imagedandreye ( 2018-12-15 23:25:06 +0000 )edit

Did you try to decode the e8 80 1f bytes according 24.008 spec, as I already asked you? You will see that there is not enough bits and that the third byte ends in the middle of a field.

Pascal Quantin gravatar imagePascal Quantin ( 2018-12-16 11:19:46 +0000 )edit

I did that indeed. Everything was in line with Wireshark decoding until the last 3 bits (111) of the 3rd value octet (1F), which Wireshark names SMS_VALUE field spanning that octet and the next one (40). As per 3GPP 24.008, e.g. fairly recent v14.7.0 of it, definition of those bits looks different and doesn't span 2 octets: { 0 | 1 < MS Positioning Method Capability > } { 0 | 1 < ECSD Multi Slot Capability > } { 0 | 1 < 8-PSK Struct > } Having seen no obvious errors by that moment and knowing that length 03 is legitimate for this IE I haven't tried decoding it any further. If properly looking MS Classmark 3 IE has to be longer than 3 octets I suppose it's fine to flag it as potentially malformed (based on the too low value in its Length field as you already pointed out ...(more)

dandreye gravatar imagedandreye ( 2018-12-16 20:35:55 +0000 )edit

Wireshark was parsing above the 3 bytes due to a variable underflow, as the length was too short for the bits encoding. This is what I fixed in my patch, and you can use a 2.9.1 development build to have it. And even if you consider only 3 bytes for his IE, the codecs list IE is also malformed as I already explained. I have no idea what generated this attach message, but it has several errors and Wireshark is here to spot them, not ignore them (a real MME would probably ignore the Classmark 3 and codecs list as it would simply forward them to the MSC for combined attach). The Wireshark development tree is currently based on release 15. The 2.6.x releases must be around release 14, but I did not double check.

Pascal Quantin gravatar imagePascal Quantin ( 2018-12-16 23:30:40 +0000 )edit

Understood. It's perfectly fine to flag any errors as long as any other IEs that can be decoded are still decoded, e.g. TAI, EUTRAN-CGI, RRC-Establishment-Cause in my trace, which all seem to be encoded correctly. I'll double check the 24.008 version supported by our internal test tool that generates those messages.

dandreye gravatar imagedandreye ( 2018-12-17 08:58:22 +0000 )edit

Note that the Classmark 3 encoding has not changed since years (it gives the GSM capabilities), and that those bits (that are at the beginning of the IE) where already present in release 3 (year 2000). So you should probably fix your internal test tool to at least provide a meaningful content.

Pascal Quantin gravatar imagePascal Quantin ( 2018-12-17 10:47:11 +0000 )edit

Thank you - they've just fixed both IEs. Could you please confirm they look good now?

dandreye gravatar imagedandreye ( 2018-12-17 16:25:59 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2018-12-12 18:35:22 +0000

Seen: 526 times

Last updated: Dec 12 '18