Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - gvlachos

Pages: [1]
1
Thank you for your help  :) as well as your patience  ;) !

Following your instructions I read through the specs, experimented with Wireshark and understood finally what I was doing, took me some time to go through all the concepts (all too new for me) but it all works now.

Much appreciated !
Please consider this question closed.

--
 

2
hello,

I have made some progress, mainly reading the specs (ETSI TS 100 942 and ETSI TS 124 011) and this site as well (http://www.spallared.com/old_nokia/nokia/smspdu/smspdu.htm). Sadly I still have no luck with making a correct pdu to send to the mobile and I get 'rpdu: 04000161' (RP-ERROR Message type non-existent or not implemented).

There is one approach though I thought about: in our current implementation the mobile (MS) sends a binary sms (SMS-SUBMIT) to SMSC. Then using some javacript code (nodejs) I connect to yates and install listeners to catch when an MS is registered and the SMS that are exchanged:

Code: [Select]
var YATEBTS_EXTERNAL_MODULE_PORT = 5040;
var IP = "127.0.0.1";

var net = require('net');

var client = new net.Socket();

client.on('connect', function(){
  // install listeners
  client.write('%%>install:50:user.register\r\n');
  client.write('%%>install:50:idle.execute\r\n');
  client.write('%%>install:50:msg.execute\r\n');
});

cls.client.on('data', function onWatch(rawData) {
  // show and parse the rawData ...
});

// connect to yates
client.connect(YATEBTS_EXTERNAL_MODULE_PORT, IP);

this way I see when an MS is registered and get some info (e.g. IMEI and IMSI) as well as messages sent from the MS to/from the SMSC. So I can see the following binary SMS that the MS sends to SMSC (all fields shown are as expected for the current setup):

Code: [Select]
----------------------------------->
25253e6d6573736167653a30783766316262386662356236302e313233303634373635343a313439363239383934313a6d73672e657865637574653a3a6d6f64756c653d796274733a726f7574655f747970653d6d73673a63616c6c65723d544d534930303762303030313a696d73693d3233343130313731333939363639313a746d73693d30303762303030313a696d65693d3335393236303036323338373030303a63616c6c65643d3638373737303030393a63616c6c65646e756d706c616e3d6973646e3a63616c6c65646e756d747970653d696e7465726e6174696f6e616c3a736d732e63616c6c65643d3132333435363738393a736d732e63616c6c65642e706c616e3d6973646e3a736d732e63616c6c65642e6e61747572653d6e6174696f6e616c3a727064753d303030393030303639313836373730373030663930663031373830396131323134333635383766393030303430333466346233653a7068795f696e666f3d54413d332054453d302e303030205570525353493d2d31342054785077723d3520446e5253534964426d3d2d39372074696d653d313439363239383933392e3335343a68616e646c6572733d6a617661736372697074257a31352c6364726275696c64257a35302c6a617661736372697074257a38303a63616c6c746f3d6e69625f736d7363
info:    [yate-watchsms.js/log_debug] Thu Jun 01 2017 06:35:40 GMT+0000 (UTC) raw: %%>message:0x7f1bb8fb5b60.1230647654:1496298941:msg.execute::module=ybts:route_type=msg:caller=TMSI007b0001:imsi=234101713996691:tmsi=007b0001:imei=359260062387000:called=687770009:callednumplan=isdn:callednumtype=international:sms.called=123456789:sms.called.plan=isdn:sms.called.nature=national:rpdu=000900069186770700f90f017809a121436587f90004034f4b3e:phy_info=TA=3 TE=0.000 UpRSSI=-14 TxPwr=5 DnRSSIdBm=-97 time=1496298939.354:handlers=javascript%z15,cdrbuild%z50,javascript%z80:callto=nib_smsc
info:    [yate-watchsms.js/log_debug] message: %%>message:0x7f1bb8fb5b60.1230647654:1496298941:msg.execute
info:    [yate-watchsms.js/log_debug] fields: module=ybts,route_type=msg,caller=TMSI007b0001,imsi=234101713996691,tmsi=007b0001,imei=359260062387000,called=687770009,callednumplan=isdn,callednumtype=international,sms.called=123456789,sms.called.plan=isdn,sms.called.nature=national,rpdu=000900069186770700f90f017809a121436587f90004034f4b3e,phy_info=TA=3 TE=0.000 UpRSSI=-14 TxPwr=5 DnRSSIdBm=-97 time=1496298939.354,handlers=javascript%z15,cdrbuild%z50,javascript%z80,callto=nib_smsc
{ module: 'ybts',
  route_type: 'msg',
  caller: 'TMSI007b0001',
  imsi: '234101713996691',
  tmsi: '007b0001',
  imei: '359260062387000',
  called: '687770009',
  callednumplan: 'isdn',
  callednumtype: 'international',
  'sms.called': '123456789',
  'sms.called.plan': 'isdn',
  'sms.called.nature': 'national',
  rpdu: '000900069186770700f90f017809a121436587f90004034f4b3e',
  phy_info: 'phy_info=TA=3 TE=0.000 UpRSSI=-14 TxPwr=5 DnRSSIdBm=-97 time=1496298939.354',
  handlers: 'javascript%z15,cdrbuild%z50,javascript%z80',
  callto: 'nib_smsc' }
info:    [yate-watchsms.js/log_debug] Thu Jun 01 2017 06:35:40 GMT+0000 (UTC) imei: 359260062387000
info:    [yate-watchsms.js/log_debug] Thu Jun 01 2017 06:35:40 GMT+0000 (UTC) imsi: 234101713996691
info:    [yate-watchsms.js/log_debug] Thu Jun 01 2017 06:35:40 GMT+0000 (UTC) rpdu: 000900069186770700f90f017809a121436587f90004034f4b3e
info:    [yate-watchsms.js/log_debug] Thu Jun 01 2017 06:35:40 GMT+0000 (UTC) ok message (OK> - 4f4b3e)
<-----------------------------------

So here I get a valid rpdu (000900069186770700f90f017809a121436587f90004034f4b3e) for an SMS-SUBMIT (MS to SMSC) which I would like to parse and understand so I can make an binary SMS for SMS-DELIVER (SMSC to MS).

Here I wonder if you could help me i.e. in understanding how the values are attributed to the correct field from the specs.

So the rpdu is:

Code: [Select]
00 09 00 06 91 86 77 07 00 f9 0f 01 78 09 a1 21 43 65 87 f9 00 04 03 4f 4b 3e

Looking at the spec for SMS-SUBMIT and examining the rpdu I observe the following:

  • there is some initial octets I cannot understand:
Code: [Select]
00 09 00

  • then I get the SCA (which I can also see from the 'called' field in my log above):

Code: [Select]
06 91 86 77 07 00 f9

  • then I get the 'PDU type':

Code: [Select]
0f

  • then there are some more octets that I cannot account for:

Code: [Select]
01 78 09 a1

  • I recognize the DA (the 'sms.called' field from the log above):

Code: [Select]
21 43 65 87 f9

  • then is the PID:

Code: [Select]
00

  • then is the DCS:

Code: [Select]
04

  • then the UDL:

Code: [Select]
03

  • and finally the UDD which is the text "OK>" as expected:

Code: [Select]
4f 4b 3e

    Thank you in advance !


    3
    The message that gives me the 'Invalid mandatory information' is for a binary SMS with the command ATCAT+CGMI (changed to hex and set to the RPDU field).

    In the Message I set the following parameters:

    Code: [Select]
    route_type:msg
    callednumplan:isdn
    callednumtype:international
    sms.called.plan:isdn
    sms.called.nature:national
    caller:123456789
    called:3996691
    sms.caller:123456789
    callto:ybts/TMSI007b0001
    oimsi:234101713996691
    otmsi:007b0001
    maxpdd:5000
    rpdu:41544341542b43474d49

    not sure if this info helps, my question really is : how to find which is the invalid information ?

    or a more general question: I have tried to send a binary SMS message with different RPDU content (e.g. 'TON', 'PRF', 'HLP0', 'HLP1', 'AT+CMGF=?', 'SMSABC') and I always get some error response, so how can I find the appropriate fields and values to pass to YatesBts in a Message (from nib.js) ?


    4
    ok,

    still I get 2 cause numbers, i.e. 60 (01100000) and 61 (01100001) that do not appear in the list of valid RP-Cause numbers.

    5
    So these are the errors I get for different values set to RPDU I get as an error response

    • 04540160 (in binary 100 01010100 00000001 01100000) and
    • 04ff0161  (in binary 100 11111111 00000001 01100001)

    Looking at http://www.etsi.org/deliver/etsi_ts/100900_100999/100942/07.01.00_60/ts_100942v070100p.pdf, sections 7.3.4 and 8.2.5.4,
    I get the following sections:

    • RP-Message Type (3 bits): so that's the 04 for RP-ERROR
    • RP-Message Reference (1 octet): 01010100 or 11111111, different in the two examples above as they are errors for different messages sent
    • RP-Cause (2-3 octets): 00000001 01100000 for the first and 00000001 01100001 for the second

    The first octet of RP-Cause in both cases is the same 00000001, does that indicate the 'Unassigned (unallocated) number' (cause number 1) of the "Table 8.4/3GPP TS 04.11 (part 1)" of the specification? I think it shouldn't be as the message I try to sent is from YateBts to a mobile phone.

    If I search "Table 8.4/3GPP TS 04.11 (part 2)" of the specification I find no values that match what I think is the RP-Cause value of the messages I get.

    I am not sure how to proceed.

    6
    ok,

    one question once m.dispatch() returns false, how can I find the error/rpdu from nib.js ?

    7
    ok I tried setting m.rpdu to '41544341542b43474d49' however m.dispatch() return false, the log is:


    Code: [Select]
    2017-05-23_09:10:21.073131 <ybts-mm:ALL> Added UE (0x7fa98c002740) TMSI=007b0001 IMSI=234101713996691 [0x107b360]
    2017-05-23_09:10:21.073143 <ybts:INFO> MT SMS 'ybts/sms/1' to (0x7fa98c002740) TMSI=007b0001 IMSI=234101713996691
    2017-05-23_09:10:21.073164 <ybts-signalling:INFO> Sending [0x107af80]
    -----
    Primitive: StartPaging
    Info: 1

    <StartPaging>
      <identity>TMSI007b0001</identity>
      <imsi>234101713996691</imsi>
    </StartPaging>
    -----
    2017-05-23_09:10:21.073177 <ybts:ALL> Started paging TMSI007b0001
    2017-05-23_09:10:21.461247 <gsmtrx:INFO> ARFCN[0]: Slot 0. Receiver clipping 1.90356 dB (FN=36846) count=5 [0x7fa98800fc50]
    2017-05-23_09:10:21.461538 <gsmtrx:ALL> Handling command 'CMD 0 NOHANDOVER 0' arfcn=0 [0x7fa988008da0]
    2017-05-23_09:10:21.461558 <gsmtrx:ALL> Command 'CMD 0 NOHANDOVER 0' (ARFCN=0) RSP '0'
    2017-05-23_09:10:21.461625 <gsmtrx:ALL> Handling command 'CMD 0 NOHANDOVER 0' arfcn=0 [0x7fa988008da0]
    2017-05-23_09:10:21.461634 <gsmtrx:ALL> Command 'CMD 0 NOHANDOVER 0' (ARFCN=0) RSP '0'
    2017-05-23_09:10:21.770979 <ybts-signalling:INFO> Received [0x107af80]
    -----
    Primitive: PhysicalInfo
    Info: 0
    Connection: 3

    <PhysicalInfo>TA=0 TE=2.000 UpRSSI=1 TxPwr=33 DnRSSIdBm=-84 time=1495530621.474</PhysicalInfo>
    -----
    2017-05-23_09:10:21.771048 <ybts-signalling:INFO> Received [0x107af80]
    -----
    Primitive: L3Message
    Info: 0
    Connection: 3

    <RRM>
      <SkipIndicator>0</SkipIndicator>
      <Message type="PagingResponse">
        <CipheringKeySequenceNumber>no-key/reserved</CipheringKeySequenceNumber>
        <MobileStationClassmark2>
          <RFPowerCapability>class4</RFPowerCapability>
          <RevisionLevel>GSM-phase2</RevisionLevel>
          <SSScreeningIndicator>ellipsis-notation-and-phase2-error-handling</SSScreeningIndicator>
          <Flags>ES-IND,E-GSM-and-R-GSM-support,MT-sms-point-to-point-capability,pseudo-sync-capability,A5/3-support,CMSP-support,LCS-VA-support,CM3-support</Flags>
        </MobileStationClassmark2>
        <MobileIdentity>
          <TMSI>007b0001</TMSI>
        </MobileIdentity>
      </Message>
    </RRM>
    -----
    2017-05-23_09:10:21.771061 <ybts-signalling:ALL> Added connection (0x7fa9940023b0,3) [0x107af80]
    2017-05-23_09:10:21.771067 <ybts-mm:ALL> PagingResponse with TMSI=007b0001 conn=3 [0x107b360]
    2017-05-23_09:10:21.771079 <ybts-signalling:INFO> Sending [0x107af80]
    -----
    Primitive: StopPaging
    Info: 0

    <StopPaging>
      <identity>TMSI007b0001</identity>
    </StopPaging>
    -----
    2017-05-23_09:10:21.771088 <ybts:ALL> Stopped paging TMSI007b0001
    2017-05-23_09:10:21.771093 <ybts-signalling:ALL> Connection 3 set UE (0x7fa98c002740) TMSI=007b0001 IMSI=234101713996691 [0x7fa9940023b0]
    2017-05-23_09:10:21.771100 <ybts-signalling:INFO> Sending [0x107af80]
    -----
    Primitive: EstablishSAPI
    Info: 3
    Connection: 3
    -----
    2017-05-23_09:10:22.006355 <ybts-signalling:INFO> Received [0x107af80]
    -----
    Primitive: PhysicalInfo
    Info: 0
    Connection: 3

    <PhysicalInfo>TA=0 TE=2.000 UpRSSI=1 TxPwr=33 DnRSSIdBm=-84 time=1495530621.474</PhysicalInfo>
    -----
    2017-05-23_09:10:22.467595 <gsmtrx:INFO> ARFCN[0]: Slot 0. Receiver clipping 1.71572 dB (FN=37064) count=18 [0x7fa98800fc50]
    2017-05-23_09:10:22.492632 <ybts-signalling:INFO> Received [0x107af80]
    -----
    Primitive: EstablishSAPI
    Info: 3
    Connection: 3
    -----
    2017-05-23_09:10:22.492656 <ybts-signalling:ALL> Connection 3 sapi establish 3 state 0x09 [0x107af80]
    2017-05-23_09:10:22.492687 <ybts-signalling:INFO> Sending [0x107af80]
    -----
    Primitive: L3Message
    Info: 3
    Connection: 3

    <SMS>
      <TID TIFlag="false">0</TID>
      <Message type="CP-Data">
        <RPDU>41544341542b43474d49</RPDU>
      </Message>
    </SMS>
    -----
    2017-05-23_09:10:22.492707 <ybts:ALL> MT SMS 'ybts/sms/1' to (0x7fa98c002740) TMSI=007b0001 IMSI=234101713996691 sent on conn 3
    2017-05-23_09:10:22.958063 <ybts-signalling:INFO> Received [0x107af80]
    -----
    Primitive: PhysicalInfo
    Info: 0
    Connection: 3

    <PhysicalInfo>TA=2 TE=0.000 UpRSSI=1 TxPwr=33 DnRSSIdBm=-84 time=1495530622.463</PhysicalInfo>
    -----
    2017-05-23_09:10:22.958112 <ybts-signalling:INFO> Received [0x107af80]
    -----
    Primitive: L3Message
    Info: 3
    Connection: 3

    <SMS>
      <TID TIFlag="true">0</TID>
      <Message type="CP-Ack"/>
    </SMS>
    -----
    2017-05-23_09:10:22.958142 <ybts:ALL> SMS CP-ACK conn=3 callRef=0 tiFlag=true
    2017-05-23_09:10:23.200404 <ybts-signalling:INFO> Received [0x107af80]
    -----
    Primitive: PhysicalInfo
    Info: 0
    Connection: 3

    <PhysicalInfo>TA=2 TE=0.000 UpRSSI=1 TxPwr=27 DnRSSIdBm=-84 time=1495530622.463</PhysicalInfo>
    -----
    2017-05-23_09:10:23.200457 <ybts-signalling:INFO> Received [0x107af80]
    -----
    Primitive: L3Message
    Info: 3
    Connection: 3

    <SMS>
      <TID TIFlag="true">0</TID>
      <Message type="CP-Data">
        <RPDU enc="hex">04540160</RPDU>
      </Message>
    </SMS>
    -----
    2017-05-23_09:10:23.200477 <ybts:ALL> MT SMS 'ybts/sms/1' to (0x7fa98c002740) TMSI=007b0001 IMSI=234101713996691 responded
    2017-05-23_09:10:23.200495 <ybts-signalling:INFO> Sending [0x107af80]
    -----
    Primitive: L3Message
    Info: 3
    Connection: 3

    <SMS>
      <TID TIFlag="false">0</TID>
      <Message type="CP-Ack"/>
    </SMS>
    -----
    2017-05-23_09:10:23.205598 <ybts:INFO> MT SMS 'ybts/sms/1' to (0x7fa98c002740) TMSI=007b0001 IMSI=234101713996691 failed reason='' RPDU=04540160




    8
    Using YatesBts, BladeRF and nib.js (https://github.com/ctxis/yate-bts/blob/master/nib/nib.js)

    I changed mtLocalDelivery (https://github.com/ctxis/yate-bts/blob/master/nib/nib.js#L756), so that all fields the same the same except the following where I set:

    • m.text to 'hello', for a text sms, m.dispatch succeeds and the message is delivered
    • m.rpdu to '0x41544341542b43474d49' (hex string), m.text is not set (for a binary sms), m.dispatch fails
    • m.rpdu to 0x41544341542b43474d49 (hex number), m.text is not set (for a binary sms), m.dispatch fails

    also I ran 'yate -vvvvv -l /var/log/yate.log' and in the log (for the 2nd and 3rd tries above) I get the following:


    Code: [Select]
    2017-05-23_08:00:32.687154 <ybts-signalling:ALL> Connection 3 sapi establish 3 state 0x09 [0x14592d0]
    2017-05-23_08:00:32.687177 <ybts-signalling:WARN> Encoding of mandatory parameter RPDU finished with status=MissingMandatoryIE [0x14592d0]
    2017-05-23_08:00:32.687182 <ybts-signalling:WARN> Encoding of mandatory parameter Message finished with status=MissingMandatoryIE [0x14592d0]
    2017-05-23_08:00:32.687186 <ybts-signalling:WARN> Encoding of mandatory parameter PD finished with status=MissingMandatoryIE [0x14592d0]
    2017-05-23_08:00:32.687191 <ybts-signalling:NOTE> Failed to build L3Message (0): Codec error 7 (MissingMandatoryIE) [0x14592d0]
    2017-05-23_08:00:32.692124 <ybts:INFO> MT SMS 'ybts/sms/1' to (0x7fbb98007f70) TMSI=007b0001 IMSI=234101713996691 failed reason='' RPDU=
    2017-05-23_08:00:32.692273 <nib:INFO> Could not deliver sms from imsi nib_smsc to number 3996691.

    what is the correct way ?

    --
    George


    Pages: [1]