Dear all, what is the purpose of TTL on the Internet Protocol message? it live which conversation. regards, Hafiz! asked 25 Jun '13, 20:24  Hafiz edited 27 Jun '13, 02:31  grahamb ♦ |
3 Answers:
TTL indicates the remaining life time of a packet when it is floating on a network. If a packet arrives at a router with TTL Value 1 then that router should discard(as TTL becomes 0) it and send back ICMP Type 11 and Code 0 message(Time to live exceeded). One advantage/purpose i can think of is to avoid Looping at Layer3 .If there is any packet loop in the network and each time it hits a routing interface it's value will be decremented and eventually this unhealthy packet perishes. Moreover TraceRoute make use of this TTL mechanism. answered 25 Jun '13, 20:53  krishnayeddula edited 25 Jun '13, 21:25 Dear Krishnayeddula, thanks from your support and help. my issue is in a GSM network and below is my scenario. {{{{{{Mobile Station====> (MSC=TTL=63)====>(STP=TTL=255)====>(HLR=TTL=62)====>(STP=TTL=255)====>USSD}}}}}} {{{{{(USSD=TTL=62)====>(STP=TTL=255)====>(HLR=TTL=62)====>STP=TTL=255)====>MSC=-------===>Mobile Station}}}}}} MS send *303# to USSD USSD send back to MS please enter you facebook ID/// while i am typing my facebook on the screen of mobile my transection disconnecting. as i check on the trace release is coming from Mobile side. but i don't know to blame which platform. best Regards, Hafiz AWCC Afghanistan i don't know how to attached my trace. (25 Jun '13, 23:51) Hafiz |
The IP TTL is a time-to-live at the IP layer to prevent packet destined for an undeliverable address from looping through the network forever. It is defined as: (see: RFC 791 page 14) I believe the hops you are drawing in your response to @krishnayeddula are hop at the application layer and not at the IP layer. Between these application layer hops are routers to get the IP packet from one server to the other. Each of these routers will decrement the IP TTL, but each server will create a new IP packet, with a new TTL value. (You can share traces by uploading the trace to www.cloudshark.org and then paste the link to the trace here) answered 26 Jun ‘13, 00:02  SYN-bit ♦♦ thanks Mr. SYN, (26 Jun ‘13, 02:13) Hafiz kindly please put some more light on:(each server will create a new IP packet, with a new TTL value)in my network (26 Jun ‘13, 02:16) Hafiz 2 Consider the following setup: srvA -> rtr1 -> rtr2 -> srvB -> rtr3 -> srvC Different systems use different initial TTL values (mostly 64, 128 or 255), for now, assume they all use 64. A message from srvA to srvB will have the following headers: Then if srvA has an application that somehow forwards the message to srvC, the following headers can be seen: So you need to make a distinction in your analysis between routing hops and application hops. I believe you were mentioning application hops in your example. In your example capture, made on 172.18.8.69 you can see that it communicates with 3 other systems: Packets from 172.21.40.31 have a TTL of 63, which means there is one router in between 172.21.40.31 and 172.18.8.69 (assuming the 64 start value of the IP TTL). Packets from 172.17.90.5 have a TTL of 62, which means there are two routers in between 172.17.90.5 and 172.18.8.69 (assuming the 64 start value of the IP TTL). Packets from 192.168.236.5 have a TTL of 62, which means there are two routers in between 192.168.236.5 and 172.18.8.69 (assuming the 64 start value of the IP TTL). The problem you are researching is not at the IP layer but in one of your application layers. I have very little knowledge of the mobile networking protocols. But I see an error in frame 17 with a 60 second delta, this looks like a timeout on that server to me. Could that be your problem source? (26 Jun ‘13, 03:10) SYN-bit ♦♦ Thanks Mr. SYN, TTL is now cleared for me. appreciate for your support. I looking to the other part of trace if faced any confusion i will come to you. Regards, Hafiz AWCC Afghanistan (26 Jun ‘13, 06:21) Hafiz Thanks Mr. Edmond, my test scenario is: from MS i am sending *303# toward USSD getway USSD getway replaying press 1 to confirm from MS i press 1 and send to USSD USSD replay enter you Facebook ID while i am typing my Facebook ID its not waiting for some more secounds its disconnecting after 45 secound before i complete my ID. our USSD team is saying that they have increased this time to 2 minutes. our HLR/MSC and STP teams are saying we don’t have timer for this. {{{{{{Mobile Station====> ((MSC=TTL=63)SPC=5300)====>((STP=TTL=255)SPC=7100 or 7200)====>((HLR=TTL=62)SPC=5001)====>((STP=TTL=255)====>(USSD=SPC=5252)}}}}}} {{{{{(USSD=TTL=62)====>(STP=TTL=255)====>(HLR=TTL=62)====>STP=TTL=255)====>MSC=——-===>Mobile there are many different packets in one transaction i don’t know how to describe it, i attached an snapshoot of sorting the trace by time on the image place of YOUR ANSWER box. (26 Jun ‘13, 07:25) Hafiz also, note that ICMP embeds the original packet inside the ICMP data. So the IP address that you see in Wireshark is the actual device that sent you the ICMP type 11 code 0 (TTL Exceeded) message. So it’s pretty easy to figure out who sent you the error message and why. It has nothing to do with your problem, and Sake (syn-bit) already explained some of this for you. But in case others are wondering, ICMP’s ability to embed the original pkt header can be quite useful. (26 Jun ‘13, 19:21) hansangb showing 5 of 6 show 1 more comments |
National laws may vary, but those are public point codes in that trace file and you have subscriber IMSIs in there, including their mobility procedures and an SMS delivery. That includes SMS text payload, which looks like it might be clear-text though it doesn't decode well into this alphabet. I just want you to be very aware of that before proceeding further - Since you're including all TCAP transactions within a given IP packet toward an STP in that trace (even if you're just searching for the one subscriber), you are including all of your IN traffic, your SMSC signaling and potentially sensitive/compromising data for the carrier and subscribers. Having said that, a couple things to be clarified: The path you have drawn is not the path of any single routed IP packet, but rather they are paths that individual signaling messages in a call flow will take between the systems you are talking about, as SYN-Bit correctly surmised. Since this is SS7 over IP, you may be routing at a point code or GT level but the SS7 messages that the STP is routing are going to get their own separate IP packets. Between end points in each M3UA association there is a new IP packet, from this perspective. Also there is a separate IP packet between RNC/BSC and MSC (RANAP packet), and between base station and RNC/BSC (NBAP packet), each carrying this same USSD/NAS message along its way. Different IP packet, different TTL. So now, finally, for your actual signaling problem :) We can see in the trace that the USSD message got routed across the STP just fine and got sent to HLR. The invoke goes through and gets a response. The problem is that the return at packet 17 for TCAP transaction 0003bc30 (this USSD invoke) is a return error, with code 34 (System Failure). Therefor the question is:
My suggestion is to step back from the noise in that trace file and focus here on packets 14 and 17, where the invoke is sent to HLR, it receives it, waits 60 seconds, then returns the error. So, focus on the content of TCAP transaction 0003bc30 ("tcap.tid == 00:03:bc:30" filter in Wireshark) and why it failed. answered 26 Jun '13, 20:46  Quadratic edited 26 Jun '13, 21:03 Thanks Sir Quadratic and All, actually the packet follows are correct i don't have complain.the issue is that while i am typing my Facebook ID on the screen of phone the connection shuld waite utill to i sumit my Facebook ID, but my connection intrupting after 45 second before to i submit my Facebook ID. And as i check on the trace the release starting from Mobile phone not any other network node. if you kindly tell me that do we can change TTL value in any kindly of Platforms? Best Regards, Hafiz (26 Jun '13, 23:51) Hafiz Look at TCAP transaction 0003BC30 in packet number 17 in the trace file. In that message, we see a return on the USSD transaction after 60 seconds with a return error for system failure. Compare with the transaction of the same number in packet 14 and see that the error was indeed a response for the USSD invoke, so in my mind you have a clear error returned by HLR after a 60 second timeout. In that call flow, HLR should be sending to your USSD system at that point but tht is not in the trace file. For TTL, I really think you're looking at the wrong thing here. If there was an issue with IP TTL, you'd see it decrement down to 1 and you would not see a return message sent in response to your invokes between MSC and HLR. The fact that you see the SS7 routing between point codes proves that each IP packet is being sent and received correctly between MsC and zsTP, and between STP and HLR. For the MS-initiated release you're talking about, what protocol are you referring to? For sure the user device will eventually release RRC control and time out at the NAS layer if it has to (in this case) wait a whole minute and not see anything, but the question at hand is why you see a 60-second delay between invoke and return, why the return is system failure and really what is happening between HLR and USSD system. Why do you believe there is any TTL problem, or IP level problem at all? Is there any request not responded to at MAP level? It does not appear so in that trace. (27 Jun '13, 03:41) Quadratic I am very sorry, that i did not provide all details at first. On the previous trace it was really correct that HLR send Error toward USSD and we took a wireshark trace from HLR there we saw that error is coming from MS and we took a trace from MSC its format is different i couldn’t attached it to cloudshark there the error is coming from BSS side with (Radio Interface Failure) At this point USSD team expanded the time to 2 minutes but NSS STP and HLR teams are not accepting the error on there side According to the traces as far as i know on BSS there is no timer. so i was thinking that TTL is any kind of timer which is Releasing the connection, thanks to all that cleared my mind about it specially Mr.Quadratic last comment. new attached trace details At packet number 10 on the TCAP message Transaction ID=08240705 show an (abort by user) from MSC while you can see the MSC GT (93702993007) at SCCP message above the mentioned TCAP message. And on packet 3 we can see the HLR-GT(93702980007) forward the error message which is coming from MSC side toward USSD-GT(93702992006) and we took a trace from MSC its format is different i couldn't attached it to cloudshark. there Mentioned that the error is coming from BSS side with (Radio Interface Failure) Error. at this point if anyone have idea about timer expansion on NSN MSC, Hwawei STP, and NSN HLR or BSS kindly help and comment. http://www.cloudshark.org/captures/da0a025d550d Best Regards, Hafiz (29 Jun '13, 22:52) Hafiz Ah, I see thanks for clearing that up. If the system failure in the trace is being caused by MS-initiated abort then it sounds to me like something that needs to be handled at the USSD application level. While the systems in this call flow can have timeout timers at a TCAP transaction level, and at a MAP level for invoke/return exchanges, the end-to-end session would be controlled by the USSD application at the MS and USSD gateway. Is the device timing out at a USSD level? The RRC connection on the radio side is also stateful (thus could potentially time out), as would the MS' mobility state with the serving MSC technically, but really this sounds like a USSD, application-specific timer problem. Also for the final question on TTL, the IP protocol itself is stateless. There is no "session" at an IP level and no timer that can expire. (30 Jun '13, 13:03) Quadratic |
Hafiz, can you explain what is the flow/test that you are performing, and the error generated to your HS and ussd app? Also, transaction id's would be appreciated (related to the trace you have provided).