GPRS' PDCH idle filling

[Alexander Chemeris]

Luca Melette pointed out that I can compile gprs_decode with
"-DRLC_DEBUG" which will enable sending RLC/MAC frames to Wireshark
with GSMTAP:

diff --git a/Makefile b/Makefile
index 9e95f07..2e6737b 100644
--- a/Makefile
+++ b/Makefile
@@ -1,5 +1,5 @@
 default:
-       gcc -O2 -g -o gprsdecode main.c bit_func.c viterbi.c process.c
gsm_interleave.c cch.c crc.c -pthread -losmogsm -losmocore
+       gcc -O2 -g -o gprsdecode main.c bit_func.c viterbi.c process.c
gsm_interleave.c cch.c crc.c -pthread -losmogsm -losmocore -DRLC_DEBUG
        gcc -O2 -g -o synmux synchro_muxer.c

 clean:


Then I just have to set correct GASMTAP channel type value and I can
see GPRS RLC/MAC messages in Wireshark. E.g. for the latest stock
Wireshark patch looks like this:

diff --git a/output.c b/output.c
index b720187..7d5840d 100644
--- a/output.c
+++ b/output.c
@@ -14,7 +14,7 @@ void net_init()
 void net_send_rlcmac(uint8_t *msg, int len, uint8_t ul)
 {
        if (gti) {
-               gsmtap_send(gti, ul?ARFCN_UPLINK:0, 0,
chantype_rsl2gsmtap(0x08, 0x80), 0, 0, 0, 0, msg, len);
+               gsmtap_send(gti, ul?ARFCN_UPLINK:0, 0, 0x0b, 0, 0, 0,
0, msg, len);

                while (osmo_select_main(1));
        }


Attached .pcap files are generated this way from captures, provided by
Karsten and Luca at http://srlabs.de/gprs/ You can open them with the
latest Wireshark and they will be correctly decoded (as far as
dissector is implemented). E.g. this allowed us to see those filler
messages I was asking about.

Now, Osmocom's gsmtap.h have different channel ID's then gsmtap from
stock Wireshark. Does that mean that Osmocom's Wireshark have
different dissector implementation for PDCH/PACCH/PTCCH/etc then the
stock one? Which one is more advanced?

On Fri, Oct 7, 2011 at 13:12, Alexander Chemeris
<alexander.chemeris at gmail.com> wrote:
> Hi all,
>
> Does anyone know how should we fill PDCH when no downlink transmission
> is present? I can't find any mention about this in the standard. If
> someone have traces from existing networks, I would very much
> appreciate this.
>
> Some background - we've recently started working on GPRS
> implementation for OpenBTS, and we're stuck at the very beginning -
> mobile sends RACH, but doesn't respond to our Packet Channel Immediate
> Assignment. After spending quite some time tweaking Immediate
> Assignment message, our conclusion is that mobile may want to see some
> "filler" date at the idle PDCH and we don't do this yet.
>
> I know that OpenBSC has GPRS working, so I hope someone here may help us.
>
> --
> Regards,
> Alexander Chemeris.
>



-- 
Regards,
Alexander Chemeris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gprs_262_80_0001_0000_20110710_2251_875_494777_0f.pcap
Type: application/cap
Size: 112712 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20111008/dff1f705/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gprs_262_80_0001_0000_20110710_2252_875_514147_0f.pcap
Type: application/cap
Size: 285132 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20111008/dff1f705/attachment-0001.bin>