Dear Daniel and Jan,
you have been working very closely with and on the u-blox GPS receiver during your work on the Openmoko GTA02.
As far as I know, it is possible to obtain the ephemeris data from a u-blox receiver.
I would like to see some code that obtains and converts that ephemeris data into the format described by the RRLP protocol specification. I know this involves asn.1 PER ugliness, but this can all be done well outside the OpenBSC codebase.
What I'll propose is to simply use some pattern matching to determine the RRLP request for assistance data, and if such a request exists, open some file in the filesystem and send the contents binary as-is to the phone in response.
Any responses from the phone are already stored in the database anyway.
In case any of you are interested in working on something to generate the required ephemeris data and have time before or even at the 26C3, you can simply give me the resulting binary file, I can drop it into the OpenBSC directory and we'll see what happens.
If this doesn't happen right now, it doesn't matter all that much, as the 26C3 is an indoor event and I don't think we'll be getting that many GPS fixes in such an environment anyway. But eventually, for the next outdoor test, and to do some more RRLP security research, the ephemeris data formatter would be really great!
Cheers, Harald
Just FYI, I have code that generates the ephemeris data in the good format for RRLP message from a u-blox receiver. I sent it to dieter, just need to plug it into openbsc.
On Tue, Dec 22, 2009 at 9:02 PM, Harald Welte laforge@gnumonks.org wrote:
Dear Daniel and Jan,
you have been working very closely with and on the u-blox GPS receiver during your work on the Openmoko GTA02.
As far as I know, it is possible to obtain the ephemeris data from a u-blox receiver.
I would like to see some code that obtains and converts that ephemeris data into the format described by the RRLP protocol specification. I know this involves asn.1 PER ugliness, but this can all be done well outside the OpenBSC codebase.
What I'll propose is to simply use some pattern matching to determine the RRLP request for assistance data, and if such a request exists, open some file in the filesystem and send the contents binary as-is to the phone in response.
Any responses from the phone are already stored in the database anyway.
In case any of you are interested in working on something to generate the required ephemeris data and have time before or even at the 26C3, you can simply give me the resulting binary file, I can drop it into the OpenBSC directory and we'll see what happens.
If this doesn't happen right now, it doesn't matter all that much, as the 26C3 is an indoor event and I don't think we'll be getting that many GPS fixes in such an environment anyway. But eventually, for the next outdoor test, and to do some more RRLP security research, the ephemeris data formatter would be really great!
Cheers, Harald
--
- Harald Welte laforge@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On Tue, Dec 22, 2009 at 09:20:15PM +0100, Sylvain Munaut wrote:
Just FYI, I have code that generates the ephemeris data in the good format for RRLP message from a u-blox receiver. I sent it to dieter, just need to plug it into openbsc.
That's great!
I remember hearing/reading that you've been working on it, but never realised that this work was actually completed. Thanks a lot.
I've imported it into the openbsc.git repository, hope you don't mind.
On Tue, Dec 22, 2009 at 9:55 PM, Harald Welte laforge@gnumonks.org wrote:
On Tue, Dec 22, 2009 at 09:20:15PM +0100, Sylvain Munaut wrote:
Just FYI, I have code that generates the ephemeris data in the good
format
for RRLP message from a u-blox receiver. I sent it to dieter, just need to plug it into openbsc.
That's great!
I remember hearing/reading that you've been working on it, but never realised that this work was actually completed. Thanks a lot.
The main.c is currently a test stub, reading from a file, printing on stdout, but fixing that into something usable for 26c3 shouldn't be long. I'm working on SMS and ciphering right now but at worse I could write something up in the plane or the day just before.
The plan was to have a daemon running that would essentially play the role of the LCS, mapping a tcp session to a RRLP session. This way I could have re-used the same code for both openbsc/openbts.
It also misses the Reference Position decoding/encoding (currently my home GPS coordinates are hardcoded :), I'll have to fix that.
BTW, when do you setup the network ? I should be in Berlin the 26th late afternoon if you need help setup/pre-testing.
I've imported it into the openbsc.git repository, hope you don't mind.
Not at all, that's what it was written for :)
Sylvain
Hi Sylvain,
On Wed, Dec 23, 2009 at 02:30:34AM +0100, Sylvain Munaut wrote:
The main.c is currently a test stub, reading from a file, printing on stdout, but fixing that into something usable for 26c3 shouldn't be long. I'm working on SMS and ciphering right now but at worse I could write something up in the plane or the day just before.
Don't bother with encryption (at least not for the 26C3)...
The plan was to have a daemon running that would essentially play the role of the LCS, mapping a tcp session to a RRLP session. This way I could have re-used the same code for both openbsc/openbts.
Mh, that would be possible, too. I thought reading from a file is even simpler, but handing all data off to a TCP socket is certainly also not much more difficult.
The biggest task is the APDU fragmentation/reassembly that needs to be done. At the moment I have no idea how flow control would be implemented for this, as we have a very fat TCP pipe to the LCS but a very narrow SDCCH on the other end. And the narrow pipe terminates at the BTS, while the TCP socket terminates at the BSC. We have no clue when the BTS's per-channel buffers will overrun, all we might get is a generic indication that the A-bis interface is overloaded (and that's too late).
How big is the ephemeris data from your experience?
It also misses the Reference Position decoding/encoding (currently my home GPS coordinates are hardcoded :), I'll have to fix that.
That's quick to fix.
BTW, when do you setup the network ? I should be in Berlin the 26th late afternoon if you need help setup/pre-testing.
We'll set it up in the 25th and 26th morning, so by late afternoon everything should already be running (though the license only allows us to switch it on on the 27th).
The main.c is currently a test stub, reading from a file, printing on stdout, but fixing that into something usable for 26c3 shouldn't be long. I'm working on SMS and ciphering right now but at worse I could write something up in the plane or the day just before.
Don't bother with encryption (at least not for the 26C3)...
I know it's not much use for events since you need a known Ki which most people don't have that. But looking at it yesterday, it seemed pretty straightforward to implement and if the user doesn't have a Ki in the HLR, that code path would not be executed at all ... Basically for : - LOCATION UPDATE REQUEST - PAGING RESPONSE - CM SERVICE REQUEST
You need : - Test if key_seq is the last known key_seq, - If yes you can just re-use the last Kc and send cipher mode command - If no, need to do an auth request, then send cipher mode command - On cipher mode complete, just pursue the task you were asked to do (loc update or paging. for cm service ack, the cipher mode command means implicit ack).
The biggest task is the APDU fragmentation/reassembly that needs to be done.
At the moment I have no idea how flow control would be implemented for this, as we have a very fat TCP pipe to the LCS but a very narrow SDCCH on the other end. And the narrow pipe terminates at the BTS, while the TCP socket terminates at the BSC. We have no clue when the BTS's per-channel buffers will overrun, all we might get is a generic indication that the A-bis interface is overloaded (and that's too late).
Application PDU do have a fragmentation mechanism but you can't use it. The spec says :
""" The RRLP maximum PDU size is 242 octets. If the amount of data that needs to be sent is larger than RRLP maximum PDU size, the RRLP pseudo-segmentation shall be used. The RRLP pseudo-segmentation is the use of several RRLP components (one in each RRLP message) to deliver a large amount of information. For SMLC to MS messages, the Assistance Data component is the one that is sent several times in order to deliver the information. For MS to SMLC messages, the Measure Position Response component may be sent twice in order to deliver the information. Legacy MS and SMLC (3GPP Rel-4 or older) may send RRLP components that are larger than the RRLP maximum PDU size. In this case lower level segmentation will be used. """
However, in my experience, low level segmentation (as described in gsm 04.08 3.4.21.2.2) just isn't accepted by the handsets I have. So we have to use pseudo segmentation where we send multiple complete RRLP messages.
How big is the ephemeris data from your experience?
Around 12 APDU of 200 bytes in average. (for ref location + ref time + full almanach + ephemeris for 12 SVs).
Sylvain
-
Harald Welte -
Sylvain Munaut