7 Oct
2011
7 Oct
'11
11:12 a.m.
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.
8 Oct
8 Oct
12:18 a.m.
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.
2:02 p.m.
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!
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
4:39 p.m.
Hi Harald,
On Sat, Oct 8, 2011 at 16:02, Harald Welte <laforge(a)gnumonks.org> wrote:
Hi Alexander,
On Sat, Oct 08, 2011 at 02:18:50AM +0400, Alexander Chemeris wrote:
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.
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?
http://cgit.osmocom.org/cgit/libosmocore/tree/include/osmocom/core/gsmtap.h
vs
http://anonsvn.wireshark.org/viewvc/trunk/epan/dissectors/packet-gsmtap.c?r…
Value for GSMTAP_CHANNEL_PACCH
Still, my main question is what is the difference between Osmocom's
Wireshark and mainline?
--
Regards,
Alexander Chemeris.
8:13 p.m.
Hi Alexander,
On Sat, Oct 08, 2011 at 06:39:53PM +0400, Alexander Chemeris wrote:
luckily it hasn't. I've imported those changes into gsmtap.h on our
side.
yes, thanks, I've now raised that wit the wireshark guys and the sierra
wireless guy originally developing the code for PACCH.
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?r…
Value for GSMTAP_CHANNEL_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
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
5005
days inactive
5006
days old
4 comments
2 participants
participants (2)
-
Alexander Chemeris -
Harald Welte