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@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.