51学通信技术论坛

标题: 请问大家Wireshark里如果在Iu接口过滤出对应的用户呢？ [打印本页]

作者: 爱卫生 时间: 2011-7-25 16:38:38 标题: 请问大家Wireshark里如果在Iu接口过滤出对应的用户呢？

  经常在Wireshark里抓包，大家都会发现，Iu-C接口抓的包如果不涉及上层的NAS消息，例如附着、去附着、激活等等。则无法在RANAP这一层过滤出对应的手机用户。Gb接口则可以通过TLLI来过滤和对应。
  但Iu接口还有很多消息是不涉及NAS层的，例如Iu连接的释放、建立等流程。这些消息如果对应呢？
  或者引申出来一个问题，RNC在Iu-C接口上的Iu连接相关的消息，它自己是如何知道和哪个用户对应呢？根据哪个字段？还是说RNC不需要知道？不知道又怎么能保证释放正确的用户连接呢？
  谢谢!

作者: watson100 时间: 2011-7-26 10:08:59

不知道是不是SCCP层的Destination Local Reference这个字段了。

作者: 爱卫生 时间: 2011-7-27 20:24:22

经过确认，不是这个。
引述一段描述：
这个字段是用于SCCP层的连接，：在连接建立的过程中，当第一条连接请求消息被路由到某处理模块后，该模块的SCCP的协议栈会分配本次连接的本地连接标识，即表1中的源本地参考标识(Source local reference)和表2中的目的本地参考标识(Destination local reference 。如果我们在这些连接标识中添加上该处理模块的索引或者是地址信息，那么本次连接的所有后续消息(比如DT、RLSD、RI C等等)就都可以根据这个唯一标识找到正确的消息处理模块，而无须再进行路由选择了。

另外，我找了一个完整的用户基于Iu接口的附着流程来看，发现这个值每个RNC-SGSN交互的RANAP消息里都在变。并不能用于区分用户。

作者: zhenjiucuo 时间: 2011-7-28 00:13:00

回复爱卫生的帖子

在RANAP层里有IuSigId，在每次InitialUE消息中携带，两边交互后，RANAP层就依靠此来识别一个用户。在整个用户存在于网络时，此Id不变的。

作者: 爱卫生 时间: 2011-7-28 06:49:42

本帖最后由爱卫生于 2011-7-28 07:01 编辑

想请问下你说的IuSigId是指RANAP消息里的procedurecode吗？
仔细看了下，这个字段确实是在连接建立后不变的。应能实现标识用户的功能，表示感谢！
但如果是这样，这里还有两个疑问。
1 用procedurecode来标识的话，发现只有是手机和网络侧之间有NAS信令交互时，如附着/RAU等。这个标识才不变，但如果不涉及NAS，只是Iu口的其他和连接管理相关的消息，如Iu release，RAB Assignment消息，则这个标识好像是变化的。无法标识用户。
也就是例如：我想过滤出用户在Iu口上做PDP激活，这个激活过程和RAB建立的包要想同时过滤出来，怎么过滤。假设这个Iu口上有很多用户的情况下。
2 procedurecode只有1个字节，即8个bit，那怎么来标识那么多的用户呢？就是说如果RNC/SGSN上用户数超过256个，这个字段不会溢出吗？
还请再次指教。

作者: lsjier 时间: 2011-7-28 13:31:03

太深奥了，学习

作者: watson100 时间: 2011-7-28 15:01:44

4#说的应该是IuSignallingConnectionIdentifier，但是我的疑问也是和楼主一样，IU release是不带这个参数的。

作者: watson100 时间: 2011-7-28 15:02:08

另外楼主能不能把包发上来给大家看看。谢谢。

作者: zhenjiucuo 时间: 2011-7-28 23:34:01

回复爱卫生的帖子

爱老大，这个Iu Sig Id在一次InitialUE消息后，这个Id就被核心网和无线记下来了。可以去wireshark中看到，在发送InitialUE消息时SCCP层用Connection Request消息封装，当SGSN收到后，在SCCP层用独立的Connection Confirm消息回复，在SCCP层上建链，这样就保证了在后续跟UE相关的消息发送时能够关联到正确的用户，即除了InitialUE消息外，其他消息都是用SCCP层上的两端的标识来关联到用户的。个人理解如此：-）

作者: xiner 时间: 2011-7-29 15:09:35

第一步：根据imsi找出用户的ranap消息。
例如：ranap.imsi_digits == "460011227300025" //460011227300025是用户imsi号

第二步：
在找出来的ranap消息，以SCCP层的sccp.dlr或sccp.slr为过滤条件，进行过滤。
例如：sccp.dlr == 0x050502。这里的sccp.dlr或sccp.slr在这一系列的信令流程中代表是RNC或SGSN。在另外的信令流程中是另外一个值，是随机的。一系列信令流程指的是类似附着流程，路由更新流程。

第三步：
在“sccp.dlr”中去掉“d”变成“sccp.lr”，和在“ sccp.slr”中去掉“s”变成“sccp.lr”组成复合的过滤条件。例如“sccp.lr= =0x9d1a02 or sccp.lr= =0xabdfb0”。再进行过滤，就可以把所有这一系列的消息包过滤出来。

作者: 爱卫生 时间: 2011-7-31 20:05:59

xiner 发表于 2011-7-29 15:09
第一步：根据imsi找出用户的ranap消息。
例如：ranap.imsi_digits == "460011227300025" //460011227300 ...

非常感谢几位的帮助。很有收获。
你的这个方法我大致明白了。就就是先用ranap.imsi_digits过滤出IMSI，然后在这个包中找到SCCP层的destination local preference确定对端节点，这两个过滤参数就可以唯一的过滤出一个用户的连接流程来了。我觉得应该是很有道理的。
但我在试的时候，发现总是无法过滤出一个完整的用户。我都不确定是不是这个包就根本没有一个用户的完整信令流程。但即使没有完整的，但不可能这么巧为什么总是过滤出来只有一个用户一个包呢？很奇怪。
这个包是论坛有位朋友分享的，这个问题好像他也提过，我怕沉底了，赶紧再请教下大家。再次向他表示感谢！
[attach]736[/attach]
BTW,watson100 / zhenjiucuo / xiner的答题贡献积分都已添加。请查收。感谢！

作者: 爱卫生 时间: 2011-7-31 21:33:48 标题: RE: 请问大家Wireshark里如果在Iu接口过滤出对应的用户呢？

回复爱卫生的帖子

  终于找到一个最典型的Iu和GTP-C的一起的抓包。
  这里的已知条件是：
  已知#18 --- #23是一个完整的MS-SGSN之间的PDP上下文激活流程，并包括RAB的创建。已知这是属于同一个手机用户的。
  但我怎么也过滤不出来（这个包中还有其他的信令流程也对应同一个用户的。但就是过滤不出来），求解中。谢谢！
[attach]738[/attach]

作者: 爱卫生 时间: 2011-8-15 19:50:20

回复 uranus1225 的帖子

非常感谢哦！看了下你的附件，发现确实是一个过滤后的完整的结果，也是我期望的。但为什么和我之前放上去的RAB Modification(如果过滤出Iu口同一个用户的报文).pcap这个包里面的内容对应不上呢？例如源、目的IP，OPC、DPC还有SCCP里的SLR、DLR。比如你附件中解出来看到通信的两个信令点是15131和15104，而我的RAB Modification(如果过滤出Iu口同一个用户的报文).pcap里是112和1130啊。
麻烦再帮忙确认下，多谢了！

作者: 爱卫生 时间: 2011-8-17 17:03:39

好的，非常感谢！威望和贡献都已+10。问题已解决。

作者: njdjj 时间: 2011-9-21 15:47:53

没看明白。
“
回复 uranus1225 的帖子

非常感谢哦！看了下你的附件，发现确实是一个过滤后的完整的结果，也是我期望的。但为什么和我之前放上去的RAB Modification(如果过滤出Iu口同一个用户的报文).pcap这个包里面的内容对应不上呢？例如源、目的IP，OPC、DPC还有SCCP里的SLR、DLR。比如你附件中解出来看到通信的两个信令点是15131和15104，而我的RAB Modification(如果过滤出Iu口同一个用户的报文).pcap里是112和1130啊。
麻烦再帮忙确认下，多谢了！”

uranus1225 的帖子怎么找不到了？？

作者: 爱卫生 时间: 2011-9-21 21:44:52

回复 njdjj 的帖子

晕。这个是因为之前这篇帖子出现了广告和和谐关键字，被网站提供商和谐掉了。我好不容易找回贴子。没发现还漏了回复。不好意思哈。

作者: arrowbroken 时间: 2011-10-10 14:39:41

本帖最后由 arrowbroken 于 2011-10-10 14:40 编辑

回复爱卫生的帖子

这个是我过滤的同一个用户的完整的RANAP包，
规范里提到一个用户同时只能有一个SCCP链接，所以我就用Local Reference进行过滤。

作者: rubik 时间: 2011-11-9 19:33:32

IU用户面的怎么过滤用户上下行数据呢？可以更加TEID但是这个从什么消息可以找到TEID呢？是从信令面去找么？

作者: yigeren_198436 时间: 2011-12-31 04:10:22

回复 xiner 的帖子

哥们，为什么我抓到的包用ranap.imsi_digits == "xxxx"过滤后，只有SGSN发给RNC的包，没有回包呢?而且没有抓到attach request 消息，之后的激活什么的都有，请教！

作者: yigeren_198436 时间: 2011-12-31 04:13:30

回复 arrowbroken 的帖子

请教一下如何过滤IU-C口的包？ranap.imsi_digits == "460011227300025" 过滤后是单方向的，为什么啊？方便的话请附上过滤条件，谢谢哈！

作者: arrowbroken 时间: 2012-5-11 13:25:45

回复 yigeren_198436 的帖子

你好，抱歉这么晚才回答你的问题，很久没有上来。
我的帖子里写的很清楚，在过滤条件里有的，请看看！
有什么问题给我发消息了！

作者: arrowbroken 时间: 2012-5-11 13:27:17

回复 rubik 的帖子

是的，在控制面去找，在RAB ASSIGNMENT 流程里有TEID

作者: imwoohan 时间: 2012-12-17 12:52:39

爱总，你这个RAB Modification的包，我用 "sccp.dlr == 0x80fc69 || sccp.slr == 0x80fc69" 过滤了一下，发现ms发上来附着请求的时候，带的follow-on request pending位是false，但是SGSN回给它的attach accept里面却是true，随后还对它发起了GMM Information和Common-id流程，然后才发起的Iu-Release。
请问为什么SGSN不立即回follow-on requeset pending=true，直接Iu-Release呢？

作者: imwoohan 时间: 2012-12-17 12:54:51

爱总，你这个RAB Modification的包，我用 "sccp.dlr == 0x80fc69 || sccp.slr == 0x80fc69" 过滤了一下，发现ms发上来附着请求的时候，带的follow-on request pending位是false，但是SGSN回给它的attach accept里面却是true，随后还对它发起了GMM Information和Common-id流程，然后才发起的Iu-Release。
请问为什么SGSN不立即回follow-on requeset pending=true，直接Iu-Release呢？

作者: 爱卫生 时间: 2012-12-17 19:43:08

imwoohan 发表于 2012-12-17 12:54
爱总，你这个RAB Modification的包，我用 "sccp.dlr == 0x80fc69 || sccp.slr == 0x80fc69" 过滤了一下，发 ...

这个感觉应该还是符合规范的。

因为这个是SCTP消息的multile steam特性，这三个消息是放在一起发送的。GMM Information是Attach流程的一部分。是一个可选的消息，可参考23.060。另外，Common ID是SGSN为RNC提供用户的IMSI，帮助RNC建立IMSI和RRC连接的关联并可用于寻呼的目的。参考TS25.413。如下：“

The purpose of the Common ID procedure is to inform the RNC about the permanent NAS UE Identity (i.e. IMSI) of a user. This is used by the RNC e.g. to create a reference between the permanent NAS UE identity of the user and the RRC connection of that user for UTRAN paging co-ordination. ”。

欢迎光临 51学通信技术论坛 (http://51xuetongxin.com/bbs/)