Hello Christopher, I can probably provide some insight as I use Kannel for RFM. A couple of points:
1) Most carrier production SIMs will not allow RFM without basic KId authentication. Some also require the sync counter verification, which is a problem. I am assuming you are using a SIM here that you have verified will allow OTA without any kind of authentication? I work with many carriers and they all have different settings. 2) Your APDU below is a simple select statement for 3F00. I assume this is what you want and you are simply testing the basic command works and you are looking for the 90 00 in the PoR as your basic test? Here is my HTTP request that I run in Perl to submit the message to Kannel: `wget -O- 'http://10.0.2.105:$Port/cgi-bin/sendsms?validity=$ValidityPeriod&username=x&password=y&to=$MSISDNs[$count]&from=990200$ESME&coding=1&pid=127&dlr-mask=3&mclass=2&udh=%02%70%00&alt-dcs=1&text=$Headers_Http%$Checksum[0]%$Checksum[1]%$Checksum[2]%$Checksum[3]%$Checksum[4]%$Checksum[5]%$Checksum[6]%$Checksum[7]$APDU_Http_Refresh'` Debug bearerbox logs for a PUK1 change using KId authentication, delivery receipt requested, and (I believe) no PoR requested: 2012-03-08 07:58:13 [29063] [6] DEBUG: SMPP[BIGDOG01]: Manually forced source addr ton = 1, source add npi = 3 2012-03-08 07:58:13 [29063] [6] DEBUG: SMPP[BIGDOG01]: Manually forced dest addr ton = 1, dest add npi = 1 2012-03-08 07:58:13 [29063] [6] DEBUG: SMPP[BIGDOG01]: Sending PDU: 2012-03-08 07:58:13 [29063] [6] DEBUG: SMPP PDU 0x158305b0 dump: 2012-03-08 07:58:13 [29063] [6] DEBUG: type_name: submit_sm 2012-03-08 07:58:13 [29063] [6] DEBUG: command_id: 4 = 0x00000004 2012-03-08 07:58:13 [29063] [6] DEBUG: command_status: 0 = 0x00000000 2012-03-08 07:58:13 [29063] [6] DEBUG: sequence_number: 18 = 0x00000012 2012-03-08 07:58:13 [29063] [6] DEBUG: service_type: NULL 2012-03-08 07:58:13 [29063] [6] DEBUG: source_addr_ton: 1 = 0x00000001 2012-03-08 07:58:13 [29063] [6] DEBUG: source_addr_npi: 3 = 0x00000003 2012-03-08 07:58:13 [29063] [6] DEBUG: source_addr: "9902003" 2012-03-08 07:58:13 [29063] [6] DEBUG: dest_addr_ton: 1 = 0x00000001 2012-03-08 07:58:13 [29063] [6] DEBUG: dest_addr_npi: 1 = 0x00000001 2012-03-08 07:58:13 [29063] [6] DEBUG: destination_addr: "XXXXXXXXXXXXXXX" 2012-03-08 07:58:13 [29063] [6] DEBUG: esm_class: 67 = 0x00000043 2012-03-08 07:58:13 [29063] [6] DEBUG: protocol_id: 127 = 0x0000007f 2012-03-08 07:58:13 [29063] [6] DEBUG: priority_flag: 0 = 0x00000000 2012-03-08 07:58:13 [29063] [6] DEBUG: schedule_delivery_time: NULL 2012-03-08 07:58:13 [29063] [6] DEBUG: validity_period: "120315143813000+" 2012-03-08 07:58:13 [29063] [6] DEBUG: registered_delivery: 1 = 0x00000001 2012-03-08 07:58:13 [29063] [6] DEBUG: replace_if_present_flag: 0 = 0x00000000 2012-03-08 07:58:13 [29063] [6] DEBUG: data_coding: 246 = 0x000000f6 2012-03-08 07:58:13 [29063] [6] DEBUG: sm_default_msg_id: 0 = 0x00000000 2012-03-08 07:58:13 [29063] [6] DEBUG: sm_length: 40 = 0x00000028 2012-03-08 07:58:13 [29063] [6] DEBUG: short_message: 2012-03-08 07:58:13 [29063] [6] DEBUG: Octet string at 0x15831220: 2012-03-08 07:58:13 [29063] [6] DEBUG: len: 40 2012-03-08 07:58:13 [29063] [6] DEBUG: size: 1024 2012-03-08 07:58:13 [29063] [6] DEBUG: immutable: 0 2012-03-08 07:58:13 [29063] [6] DEBUG: data: 02 70 00 00 23 15 0a 00 f1 f1 00 00 01 32 76 89 .p..#........2v. 2012-03-08 07:58:13 [29063] [6] DEBUG: data: 77 80 00 f3 71 99 09 22 ee 0e 5a a0 28 00 01 08 w...q.."..Z.(... 2012-03-08 07:58:13 [29063] [6] DEBUG: data: 33 32 34 30 ff ff ff ff 3240.... 2012-03-08 07:58:13 [29063] [6] DEBUG: Octet string dump ends. 2012-03-08 07:58:13 [29063] [6] DEBUG: SMPP PDU dump ends. 2012-03-08 07:58:13 [29063] [6] DEBUG: SMPP[BIGDOG01]: Got PDU: 2012-03-08 07:58:13 [29063] [6] DEBUG: SMPP PDU 0x158305b0 dump: 2012-03-08 07:58:13 [29063] [6] DEBUG: type_name: submit_sm_resp 2012-03-08 07:58:13 [29063] [6] DEBUG: command_id: 2147483652 = 0x80000004 2012-03-08 07:58:13 [29063] [6] DEBUG: command_status: 0 = 0x00000000 2012-03-08 07:58:13 [29063] [6] DEBUG: sequence_number: 18 = 0x00000012 2012-03-08 07:58:13 [29063] [6] DEBUG: message_id: "539e172" 2012-03-08 07:58:13 [29063] [6] DEBUG: SMPP PDU dump ends. 2012-03-08 07:58:13 [29063] [6] DEBUG: DLR[internal]: Adding DLR smsc=BIGDOG01, ts=539e172, src=9902003, dst=XXXXXXXXXXXXXXX, mask=3, boxc= 2012-03-08 07:58:20 [29063] [9] DEBUG: boxc_receiver: sms received 2012-03-08 07:58:20 [29063] [9] DEBUG: send_msg: sending msg to box: <127.0.0.1> Kent From: [email protected] [mailto:[email protected]] On Behalf Of Christopher Burke Sent: Wednesday, May 02, 2012 9:58 AM To: [email protected] Subject: OTA RFM (SMS-PP) from Kannel / SMSC Hi All, I am currently attempting to implement remote file management from a Kannel instance. I've personalised my own SIM for this, and it has the following configuration settings: No Counter, No Integrity, No Confidentiality, RFM TAR: B00100, RAM TAR: 000000 and PoR is required. Using a USB dongle I was able to complete RFM via OTA by sending an SMS message as follows: 0051000C915383661028967FF6AA1A02700000150D00010000B00010000000000000A0A40000023F00 The break down is below; <--> Lets the telephone set the message reference <--> <--> First Octet of SMS Submit <--> <--> <--> ???? <--> <--> <--> <12> Telephone Number Length <--> <--> <--> <--> <--> Telephone number is in international format <--> <--> <--> <--> <--> <-- -- -- -- -- --> Telephone number (nibbles swapped) <--> <--> <--> <--> <--> <-- -- -- -- -- --> <--> TP-PID (Protocol Identifier) <--> <--> <--> <--> <--> <-- -- -- -- -- --> <--> <--> F6 is for use with SMSC, 16 for Dongle (odd, as this works with Dongle) <--> <--> <--> <--> <--> <-- -- -- -- -- --> <--> <--> <--> TP Validity Period <--> <--> <--> <--> <--> <-- -- -- -- -- --> <--> <--> <--> <26> Length of Packet 00 51 40 0C 91 ** ** ** ** ** ** 7F F6 AA 1A -- (Telephone number has been blanked out) Length of packet: 26 <-- -- --> User Data Header (02 70 00 == OTA) <-- -- --> <--> ???? <-- -- --> <--> <21> Remaining Length of Packet <-- -- --> <--> <--> <13> Remaining length of data before APDU <-- -- --> <--> <--> <--> <-- -- -- --> ???? <-- -- --> <--> <--> <--> <-- -- -- --> <-- -- -- --> RFM Toolkit Application Reference <-- -- --> <--> <--> <--> <-- -- -- --> <-- -- -- --> <-- -- -- -- -- --> Command Type <-- -- --> <--> <--> <--> <-- -- -- --> <-- -- -- --> <-- -- -- -- -- --> <-- -- -- --> Command <-- -- --> <--> <--> <--> <-- -- -- --> <-- -- -- --> <-- -- -- -- -- --> <-- -- -- --> <-- --> Data 02 70 00 00 15 0D 00 01 00 00 B0 00 10 00 00 00 00 00 00 A0 A4 00 00 02 3F 00 However, using Kannel I am having issues (the messages are either coming through as plain text, or when I set the coding to 1 coming through as unreadable) however, ultimately, I can't do RFM. I have access to a tracer, so I should receive an 'SMS-PP Envelope' upon successful OTA. My Kannel configuration uses a HSL SMSC. I have read that only the UDH and message are required, however I have tried all sorts of other combinations (including the above). I am sending via the HTTP interface: http://server.tld:15013/cgi-bin/sendsms?username=user&password=pass&from=************&to=************&smsc=knl3&udh=%02%70%00&text=%00%15%0D%00%01%00%00%B0%00%10%00%00%00%00%00%00%A0%A4%00%00%02%3F%00&coding=1 If anybody has successfully implemented OTA RFM from a Kannel instance could they please give me some pointers, any help at all would be highly appreciated! Kind Regards, Christopher Burke -- Christopher Burke http://simulity.com Mobile: +44 7590 571 833 Skype: krslynx
