GTP PDP request APN corrupted问题

海浪

当前在处理一个比较奇怪的问题，GTP请求的APN有时候时正常的，但有时候就是乱码无法显示，不知道是什么设备更改了。
请查看附件，有一个是正常，有一个是不正常的。大家集思广益看看什么东西导致这个问题。

爱卫生

回复 海浪 的帖子

  我个人认为是不是抓包的问题，而且wireshark的显示也不正常，因为两个包对比来看，GTP层抓到都是152字节，除基本包头部分8字节外，剩余还有144字节的扩展包头。第2个正常的包中，实际上后面的QOS，MSISDN，GSN地址在第1个不正常的包中都有，但却没有显示，（实际上是有的，看它的16进制代码部分是能够看到的）。
  另外，我看到的现象是两个GTP都是对同一个UE的PDP上下文激活请求消息，但却隔了6秒发送（应该是T3计数器超时了）。延迟太大了。是不是create pdp context response消息被过滤了没上传还是没抓到？
  如果有条件的话，要再定位下问题，最好能抓到create pdp context response消息。如果收到的是Cause Code219 missing or unknown APN。如附件所示。如果是这个CC，就可以排除抓包的问题（GGSN没有这个APN的配置基本可以排除)，需要进行进一步的定位。
有可能是设备的问题。但基本可以确定这个不是爱立信的SGSN。

海浪

感觉不像是wireshark的问题。如果实际的报文正常，会有响应报文。

这个附件是第一个PDP请求corrupted，应为home operator发现报文异常防火墙丢到了。等了6秒第二个PDP重发，报文正常，也有了PDP的回复报文。
比较前后两个pdp二进制的信息，是从imsi开始有问题。
之前的PDP APN有问题的是从APN开始二进制的信息都不一样了。不知道是什么设备会改这个东西当pdp从SGSN出来。

爱卫生

回复 海浪 的帖子

  我同意你的观点。是比较奇怪，从错误的包来看，应该不是SGSN所为，因为在create pdp context request消息中，很多参数是必选参数，例如控制和用户平面的TEID，传输地址，QOS profile都是一定要携带的。要遵从3GPP 29.060的规范。除非是SGSN自身出现了bug。另外，以我的了解，几个厂家的SGSN上好像没有这样的feature来过滤GTP的消息，因为这样也是不合规范的。
  刚给的这个包和之前给的包不大一样，这次的包IMSI不同，是两个用户，第一个给出的包IMSI相同。是同一个用户。
  所以如果要进一步定位的话，能否分段抓包？就是在离SGSN最近的那个lab switch上能否抓包？至少可以判断出不是SGSN的问题。我觉得有可能是home operator的防火墙的过滤问题。特别是现在有很多专门针对GTP协议的防火墙。是不是把GTP消息里的某个IE当成非法字符了？这个包我猜一定是过了home operator的防火墙之后抓到的。
另外，如果有可能有条件的话，能否请用户配合，使用internet的备份链路或者专线再试一次。排除因为MPLS网络导致的IP骨干网MTU过大而导致的协商问题。我怀疑这个也很有可能就是MTU的问题。不一定和GSN节点有关。
还有就是，如果这个错误的create pdp context request消息，一旦发到了GGSN，GGSN也应该回response消息，只不过会携带一个cause code来指示出错。例如APN的缺失、缺少必要的IE等。而不是不予理睬。肯定有response。所以如果GGSN没有回response消息，那一定是这个GGSN没有收到SGSN过来的请求包。所以这个请求可能是被丢弃了。可能是防火墙，可能不是。但感觉防火墙没丢。因为如果这个包是在经过防火墙之前抓的，那和防火墙无关。如果是在经过防火墙之后抓的，那被丢弃之后，应该是抓不到这个被丢弃的报文的，而只应有正确的报文。有可能是GTP防火墙根据规则对GTP内容做了修改。

海浪

报文是在GRX抓到的，客户那边的防火墙发现GTP corrupted给丢掉了。
应该是拜访地的运营商发出来的报文可能已经有问题了。
还在继续抓包等待测试分析。

爱卫生

回复 海浪 的帖子

  海浪，我同意你的观点。从现象来看，的确很像。但如果要确认的话，是否能有条件在离SGSN最近也就是连SGSN的那个Lan Swtich上做个镜像抓下看，就可以确认是不是SGSN的问题了！

海浪

不知道他们那边能否这样做。先等他们的结果吧。
比较难处理的就是，有时都正常，有时就不正常。20：1的比例差不多。