From: David B. <da...@ra...> - 2012-09-27 17:54:45
|
Hello - We have a MultiTech GSM/EDGE modem which (I think) is based on a Sierra Wireless baseband chipset. It sometimes responds to RR Immediate Assignment with an SABM frame, on the assigned DCCH, containing the RR Measurement Report message. As far as I know, this message should never appear on a DCCH and should never be in an SABM frame. Has anyone seen this before? Any suggestions on how to deal with it? -- David BTW, here it is, as seen in Wireshark: GSM TAP Header, ARFCN: 52 (Uplink), TS: 2, Channel: FACCH/F (0) Version: 2 Header length: 16 bytes Payload Type: GSM Um (MS<->BTS) (1) Time Slot: 2 ..00 0000 0011 0100 = ARFCN: 52 .1.. .... .... .... = Uplink: 1 Signal/Noise Ratio (dB): 0 Signal Level (dBm): 0 GSM Frame Number: 0 Channel Type: FACCH/F (9) Antenna Number: 0 Sub-Slot: 0 Link Access Procedure, Channel Dm (LAPDm) Address Field: 0x01 .00. .... = LPD: Normal GSM (0) ...0 00.. = SAPI: RR/MM/CC (0) .... ..0. = C/R: 0 .... ...1 = EA: Final octet (1) Control field: U P, func=SABM (0x3F) ...1 .... = Poll: True 001. 11.. = Command: Set Asynchronous Balanced Mode (0x0b) .... ..11 = Frame type: Unnumbered frame (0x03) Length Field: 0x49 0100 10.. = Length: 18 .... ..0. = M: Last segment (0) .... ...1 = EL: Final octet (1) GSM A-I/F DTAP - Measurement Report Protocol Discriminator: Radio Resources Management messages .... 0110 = Protocol discriminator: Radio Resources Management messages (0x06) 0000 .... = Skip Indicator: 0 DTAP Radio Resources Management Message Type: Measurement Report (0x15) Measurement Results 0... .... = BA-USED: 0 .0.. .... = DTX-USED: DTX was not used ..10 1010 = RXLEV-FULL-SERVING-CELL: -69 <= x < -68 dBm (42) 0... .... = 3G-BA-USED: 0 .1.. .... = MEAS-VALID: The measurement results are not valid RXLEV-SUB-SERVING-CELL: Unknown (106) .000 .... = RXQUAL-FULL-SERVING-CELL: BER < 0.2%, Mean value 0.14% (0) .... 000. = RXQUAL-SUB-SERVING-CELL: BER < 0.2%, Mean value 0.14% (0) .... ...0 00.. .... = NO-NCELL-M: No neighbour cell measurement result (0) David A. Burgess, CEO Range Networks, Inc. San Francisco cell +1 707 208 2622 ____________________________________________ Cellular networks made simple and affordable. http://www.rangenetworks.com ____________________________________________ |
From: Sylvain M. <24...@gm...> - 2012-09-27 20:55:19
|
Hi, > We have a MultiTech GSM/EDGE modem which (I think) is based on a Sierra Wireless baseband chipset. It sometimes responds to RR Immediate Assignment with an SABM frame, on the assigned DCCH, containing the RR Measurement Report message. As far as I know, this message should never appear on a DCCH and should never be in an SABM frame. Has anyone seen this before? Any suggestions on how to deal with it? My first reaction is WTH ??? I've never seen that before and although I can't recheck because I don't have the specs at hand, I'm fairly sure that only 3 messages are authorized as first message: PAGING RESPONSE, LOCATION UPDATE REQUEST, CM SERVICE REQUEST and each tree contains identity which is pretty much what guarantees that the contention resolution thing works. So AFAICT, this is completely invalid and I would just drop the channel, maybe just try to cleanly shut it down to be able to reuse faster. Cheers, Sylvain |
From: Ben W. <bwo...@gm...> - 2012-09-28 18:37:32
|
David, I would agree with Sylvain that this is highly unusual. Do you have the raw bytes of the message? I would be interested in hand parsing it. Thanks, Ben On Thu, Sep 27, 2012 at 3:55 PM, Sylvain Munaut <24...@gm...> wrote: > Hi, > >> We have a MultiTech GSM/EDGE modem which (I think) is based on a Sierra Wireless baseband chipset. It sometimes responds to RR Immediate Assignment with an SABM frame, on the assigned DCCH, containing the RR Measurement Report message. As far as I know, this message should never appear on a DCCH and should never be in an SABM frame. Has anyone seen this before? Any suggestions on how to deal with it? > > My first reaction is WTH ??? > > I've never seen that before and although I can't recheck because I > don't have the specs at hand, I'm fairly sure that only 3 messages are > authorized as first message: PAGING RESPONSE, LOCATION UPDATE REQUEST, > CM SERVICE REQUEST and each tree contains identity which is pretty > much what guarantees that the contention resolution thing works. > > So AFAICT, this is completely invalid and I would just drop the > channel, maybe just try to cleanly shut it down to be able to reuse > faster. > > Cheers, > > Sylvain > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://ad.doubleclick.net/clk;258768047;13503038;j? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss |
From: David B. <da...@ra...> - 2012-09-28 19:54:58
|
Ben - We have another clue. This happens only when we try to use very early assignment. The raw PCAP bytes, including the GSM frame, is the end of this decoding: No. Time Source Destination Protocol Length Info 28222 2012-09-27 01:45:52.77 127.0.0.1 127.0.0.1 LAPDm 83 U P, func=SABM(DTAP) (RR) Measurement Report Frame 28222: 83 bytes on wire (664 bits), 83 bytes captured (664 bits) WTAP_ENCAP: 25 Arrival Time: Sep 27, 2012 01:45:52.779851000 PDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1348735552.779851000 seconds [Time delta from previous captured frame: 0.018703000 seconds] [Time delta from previous displayed frame: 0.722129000 seconds] [Time since reference or first frame: 1361.992006000 seconds] Frame Number: 28222 Frame Length: 83 bytes (664 bits) Capture Length: 83 bytes (664 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: sll:ip:udp:gsmtap:lapdm:gsm_a_dtap] [Coloring Rule Name: GSM] [Coloring Rule String: gsmtap] Linux cooked capture Packet type: Unicast to us (0) Link-layer address type: 772 Link-layer address length: 6 Source: 00:00:00_00:00:00 (00:00:00:00:00:00) Protocol: IP (0x0800) Internet Protocol Version 4, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00) Total Length: 67 Identification: 0x0000 (0) Flags: 0x02 (Don't Fragment) 0... .... = Reserved bit: Not set .1.. .... = Don't fragment: Set ..0. .... = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (17) Header checksum: 0x3ca8 [correct] [Good: True] [Bad: False] Source: 127.0.0.1 (127.0.0.1) Destination: 127.0.0.1 (127.0.0.1) [Source GeoIP: Unknown] [Destination GeoIP: Unknown] User Datagram Protocol, Src Port: 54297 (54297), Dst Port: gsmtap (4729) Source port: 54297 (54297) Destination port: gsmtap (4729) Length: 47 Checksum: 0xfe42 [validation disabled] [Good Checksum: False] [Bad Checksum: False] GSM TAP Header, ARFCN: 52 (Uplink), TS: 2, Channel: FACCH/F (0) Version: 2 Header length: 16 bytes Payload Type: GSM Um (MS<->BTS) (1) Time Slot: 2 ..00 0000 0011 0100 = ARFCN: 52 .1.. .... .... .... = Uplink: 1 Signal/Noise Ratio (dB): 0 Signal Level (dBm): 0 GSM Frame Number: 0 Channel Type: FACCH/F (9) Antenna Number: 0 Sub-Slot: 0 Link Access Procedure, Channel Dm (LAPDm) Address Field: 0x01 .00. .... = LPD: Normal GSM (0) ...0 00.. = SAPI: RR/MM/CC (0) .... ..0. = C/R: 0 .... ...1 = EA: Final octet (1) Control field: U P, func=SABM (0x3F) ...1 .... = Poll: True 001. 11.. = Command: Set Asynchronous Balanced Mode (0x0b) .... ..11 = Frame type: Unnumbered frame (0x03) Length Field: 0x49 0100 10.. = Length: 18 .... ..0. = M: Last segment (0) .... ...1 = EL: Final octet (1) GSM A-I/F DTAP - Measurement Report Protocol Discriminator: Radio Resources Management messages .... 0110 = Protocol discriminator: Radio Resources Management messages (0x06) 0000 .... = Skip Indicator: 0 DTAP Radio Resources Management Message Type: Measurement Report (0x15) Measurement Results 0... .... = BA-USED: 0 .0.. .... = DTX-USED: DTX was not used ..10 1010 = RXLEV-FULL-SERVING-CELL: -69 <= x < -68 dBm (42) 0... .... = 3G-BA-USED: 0 .1.. .... = MEAS-VALID: The measurement results are not valid RXLEV-SUB-SERVING-CELL: Unknown (106) .000 .... = RXQUAL-FULL-SERVING-CELL: BER < 0.2%, Mean value 0.14% (0) .... 000. = RXQUAL-SUB-SERVING-CELL: BER < 0.2%, Mean value 0.14% (0) .... ...0 00.. .... = NO-NCELL-M: No neighbour cell measurement result (0) 0000 00 00 03 04 00 06 00 00 00 00 00 00 00 00 08 00 ................ 0010 45 00 00 43 00 00 40 00 40 11 3c a8 7f 00 00 01 E..C..@.@.<..... 0020 7f 00 00 01 d4 19 12 79 00 2f fe 42 02 04 01 02 .......y./.B.... 0030 40 34 00 00 00 00 00 00 09 00 00 00 01 3f 49 06 @4...........?I. 0040 15 2a 6a 00 00 00 00 00 00 00 00 00 00 00 00 00 .*j............. 0050 00 2b 2b .++ On Sep 28, 2012, at 11:37 AM, Ben Wojtowicz wrote: > David, > > I would agree with Sylvain that this is highly unusual. Do you have > the raw bytes of the message? I would be interested in hand parsing > it. > > Thanks, > Ben > > On Thu, Sep 27, 2012 at 3:55 PM, Sylvain Munaut <24...@gm...> wrote: >> Hi, >> >>> We have a MultiTech GSM/EDGE modem which (I think) is based on a Sierra Wireless baseband chipset. It sometimes responds to RR Immediate Assignment with an SABM frame, on the assigned DCCH, containing the RR Measurement Report message. As far as I know, this message should never appear on a DCCH and should never be in an SABM frame. Has anyone seen this before? Any suggestions on how to deal with it? >> >> My first reaction is WTH ??? >> >> I've never seen that before and although I can't recheck because I >> don't have the specs at hand, I'm fairly sure that only 3 messages are >> authorized as first message: PAGING RESPONSE, LOCATION UPDATE REQUEST, >> CM SERVICE REQUEST and each tree contains identity which is pretty >> much what guarantees that the contention resolution thing works. >> >> So AFAICT, this is completely invalid and I would just drop the >> channel, maybe just try to cleanly shut it down to be able to reuse >> faster. >> >> Cheers, >> >> Sylvain >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://ad.doubleclick.net/clk;258768047;13503038;j? >> http://info.appdynamics.com/FreeJavaPerformanceDownload.html >> _______________________________________________ >> Openbts-discuss mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openbts-discuss David A. Burgess, CEO Range Networks, Inc. San Francisco cell +1 707 208 2622 ____________________________________________ Cellular networks made simple and affordable. http://www.rangenetworks.com ____________________________________________ |
From: Sylvain M. <24...@gm...> - 2012-09-28 22:17:11
|
> We have another clue. This happens only when we try to use very early assignment. Yes, I saw that it was on a FACCH/F on your first post. I think that the stack is just buggy. Very much like the MTK stack that can't send SMS on TCH/F .... they only test on common network config I guess, and VEA is not one of those. Cheers, Sylvain |