WAP-over-SMS experiments (Nokia 7110)

, ,

@billy549 recently discovered that his Nokia 7110 can connect to a WAP site using SMS (instead of a more common CSD or GPRS connection):

Of course, we needed to play with that and try to get a website loaded via SMS.

We did this testing in the public networks and just configured the phone to connect to a prepaid SIM.
This prepaid SIM was inserted into a ZTE USB 3G dongle. Kannel was used as a gateway between HTTP calls and SMS via AT-commands.

[218764] [6] DEBUG: AT2[/dev/ttyUSB1]: <-- +CMT: ,116
[218764] [6] DEBUG: AT2[/dev/ttyUSB1]: <-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx06050423F0C34E01401C687474703A2F2F7761702E62696C6C792E77616C65732F6D2E776D6C8094809580A180988083839981848102EA5181040203E83DA94E6F6B6961373131302F312E30202830342E39342900582D5741502E544F44000100
[218764] [6] DEBUG: AT2[/dev/ttyUSB1]: received message from SMSC: +49172xxxxxx
[218764] [6] DEBUG: AT2[/dev/ttyUSB1]: Numeric sender (international) <+4474xxxxxx>

Decoded view:

As we can see, the request is just a regular SMS with UDH.
It uses IEI 0x05, Application port addressing scheme, 16 bit address to address port 9200 (aka the WAP UDP port).

We then configured Kannel to forward each incoming SMS to an HTTP server, where a PHP script was waiting for the incoming SMS.
The header was stripped/parsed and the payload data of the SMS is being sent as an actual IP/UDP packet to Kannel’s WAP proxy on localhost.
Kannel then responds, the response is getting encoded in the same way (but with destination and source ports reversed) and sent back as an SMS to the phone :slight_smile:

Granted: Not the most complex WAP page, but it needed to fit into a single message.
Works :tada::partying_face:

Multi-part SMS

To support larger packets, we needed to support concatenated short messages.
Blamba already does this for multi-media content and so I tried to encode the responses in the same way, but could never get the phone to respond/parse the messages in any way.

@billy549 then came up with the clever idea of purposefully crafting a huge request that would be split over multiple messages, so we could inspect the way a request is being split…
This worked rather well:


The 3 parts are clearly visible.
In Blamba, I would typically encode concatenated messages like this:

$header = [
	"\x0b", // UDH length
	"\x05", // Application Port Addressing, 16 bit address
	"\x04", // content length
	pack("n", $destination_port), // Destination port number
	"\x23\xF0", // Source port number
	"\x00", // Information Element Identifier: Concatenated short message, 8bit reference number
	"\x03", // Information Element Data Length (always 03 for this UDH)
	"\x01", // Information Element Data: Concatenated short message reference, should be same for all parts of a message
	chr($total_sms), // Information Element Data: Total number of parts
	chr($current_sms), // Information Element Data: Number of this part

where the Application Port Addressing IE is first, concatenation is second.
This worked very well for all Nokia phones I’ve tested.

The request from the Nokia 7110 was the other way around however, concatenation header first, port addressing last. I’ve switched this encoding around in the code, but it didn’t seem to make any difference.

Testing this is a bit tedious, because we’re sending SMS between DE and UK over public networks, only @billy549 has a compatible phone and only I have a GSM BTS/test setup available (for now).

Any ideas on why the phone doesn’t like the replies would be appriciated :smile:
This was a fun journey either way (and the gateway mechanism might find its way into the main Blamba source code, because it doesn’t interfere with anything else).