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.
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.
Hi Alexander,
On Sat, Oct 08, 2011 at 02:18:50AM +0400, Alexander Chemeris wrote:
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?
a third party (actually, apparently developers of ip.access Ltd.) have merged GPRS related changes to wireshark mainline without consulting the author of the gsmtap.h header file (me). This apparently was an accident and they have contacted me after it was included in wireshark.
So in order to resolve it, I had looked at their changes (wireshark mainline) and updated gsmtap.h in libosmocore to reflect their modifications.
So I'm a bit puzzled that you say there are again some differences. Can you please let me know more details where you found those incompatible values?
Thanks!
Hi Harald,
On Sat, Oct 8, 2011 at 16:02, Harald Welte laforge@gnumonks.org wrote:
Hi Alexander,
On Sat, Oct 08, 2011 at 02:18:50AM +0400, Alexander Chemeris wrote:
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?
a third party (actually, apparently developers of ip.access Ltd.) have merged GPRS related changes to wireshark mainline without consulting the author of the gsmtap.h header file (me). This apparently was an accident and they have contacted me after it was included in wireshark.
I just realized that we also haven't contacted you about our WiMAX changes to GSMTAP. We just posted our changes to the Wireshark tracker and waited until they accept them. Sorry if this broken something for you.
So in order to resolve it, I had looked at their changes (wireshark mainline) and updated gsmtap.h in libosmocore to reflect their modifications.
So I'm a bit puzzled that you say there are again some differences. Can you please let me know more details where you found those incompatible values?
http://cgit.osmocom.org/cgit/libosmocore/tree/include/osmocom/core/gsmtap.h vs http://anonsvn.wireshark.org/viewvc/trunk/epan/dissectors/packet-gsmtap.c?re...
Value for GSMTAP_CHANNEL_PACCH
Still, my main question is what is the difference between Osmocom's Wireshark and mainline?
Hi Alexander,
On Sat, Oct 08, 2011 at 06:39:53PM +0400, Alexander Chemeris wrote:
a third party (actually, apparently developers of ip.access Ltd.) have merged GPRS related changes to wireshark mainline without consulting the author of the gsmtap.h header file (me). This apparently was an accident and they have contacted me after it was included in wireshark.
I just realized that we also haven't contacted you about our WiMAX changes to GSMTAP. We just posted our changes to the Wireshark tracker and waited until they accept them. Sorry if this broken something for you.
luckily it hasn't. I've imported those changes into gsmtap.h on our side.
So in order to resolve it, I had looked at their changes (wireshark mainline) and updated gsmtap.h in libosmocore to reflect their modifications.
So I'm a bit puzzled that you say there are again some differences. Can you please let me know more details where you found those incompatible values?
http://cgit.osmocom.org/cgit/libosmocore/tree/include/osmocom/core/gsmtap.h vs http://anonsvn.wireshark.org/viewvc/trunk/epan/dissectors/packet-gsmtap.c?re...
Value for GSMTAP_CHANNEL_PACCH
yes, thanks, I've now raised that wit the wireshark guys and the sierra wireless guy originally developing the code for PACCH.
Still, my main question is what is the difference between Osmocom's Wireshark and mainline?
the additional protocol dissectors for Abis OML, SIM card protocol, Ericsson OM2000 and other GSM related stuff that is not merged mainline yet.
Pablo Neira has been trying to get some of the stuff merged (with varying degrees of success), but some of the code is simply not mature enough to get it merged yet.
We used to maintain patches, but it is cumbersome to keep them up to date with wireshark svn, and to indicate the exact version they are applying against. That's why we created the repo.
Regards, Harald
-
Alexander Chemeris -
Harald Welte