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(a)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.