3 Feb
2011
3 Feb
'11
2:14 p.m.
Hi everyone.
I´m coding a fuzzer with osmocombb API, I expect send you something good in a mounth or
two (It depends how much work i have).
I have two questions.
First, I triying a simple SMS handler, to send and receive. With wireshark I don´t see
RACH request, I suppose it is because the DSP inside the phone manage it, am I wrong?
About this, I don´t have knowledge about electronics, so I don´t want touch, any filter.
So I need to see the RACH of the same phone were osmo is running, not another.
The second question is about SI AGCH response, I didn´t find the algorithm to know which
SDCCH channel gives the BTS to the MS to send/recv LAPDm bursts.
---
Leonardo Nve
leonardo.nve(a)gmail.com
---
3 Feb
3 Feb
2:54 p.m.
Hi,
First, I triying a simple SMS handler, to send and
receive. With wireshark I don´t see RACH request, I suppose it is because the DSP inside
the phone manage it, am I wrong? About this, I don´t have knowledge about electronics, so
I don´t want touch, any filter. So I need to see the RACH of the same phone were osmo is
running, not another.
We only send to GSMTAP recomposed L2 packets from Normal Bursts.
We don't have debug support for other burst types like dummy/sch/rach,
I'm not even sure the gsmtap has a "spec" for it, or that the
wireshark dissector has code to process it.
Feel free to add support for all of this tough.
The second question is about SI AGCH response, I
didn´t find the algorithm to know which SDCCH channel gives the BTS to the MS to send/recv
LAPDm bursts.
There is none specified ... the BTS is free to allocate whatever it
wants ... (well technically it's not the BTS itself, but other
component of the core network).
Cheers,
Sylvain
3:45 p.m.
On Thu, 3 Feb 2011 14:54:14 +0100, Sylvain Munaut wrote:
But there is at least some kind of predictability. The assigned arfcn
and time slot is usually the same until a certain load it reached and
a second ts or even other arfcn/ts is used. The subchannel is hard to
predict as I've never seen a stable pattern, it looks quite random.
At least these are my observations with some live networks.
Regards,
Mad
We only send to GSMTAP recomposed L2 packets from
Normal Bursts.
We don't have debug support for other burst types like
dummy/sch/rach,
I'm not even sure the gsmtap has a "spec" for it, or that the
wireshark dissector has code to process it.
As gsmtap supports the payload type raw GSM Um burst and all possible
burst types like GSMTAP_BURST_ACCESS, ..._SCH and so on, it should be
possible to send these out to wireshark.
But I'm not sure whether the dissector already decodes them as it
doesn't
do it with normal bursts.
The second
question is about SI AGCH response, I didn´t find the
algorithm to know which SDCCH channel gives the BTS to the MS to
send/recv LAPDm bursts.
There is none specified ... the BTS is free to allocate whatever it
wants ... (well technically it's not the BTS itself, but other
component of the core network).
3:56 p.m.
But I'm not sure whether the dissector already
decodes them as it doesn't
do it with normal bursts.
It doesn't dissect anything, just display the raw burst bits.
There is however a GSMTAP_CHANNEL_RACH channel type (using
GSMTAP_TYPE_UM) that could just carry the 8 encoded bits.
Not dissected either but much easier to read than the raw burst bits.
Neither is sent by osmocom thus far.
But there is at least some kind of predictability. The
assigned arfcn
and time slot is usually the same until a certain load it reached and
a second ts or even other arfcn/ts is used. The subchannel is hard to
predict as I've never seen a stable pattern, it looks quite random.
At least these are my observations with some live networks.
Well, it highly depends on the network ... and on channel types you want.
I've seen plenty of behaviors, some very predictable, some seemingly random.
Point is: You can't really rely on it.
Cheers,
Sylvain
4854
days inactive
4854
days old
baseband-devel@lists.osmocom.org
3 comments
3 participants
participants (3)
-
Leonardo Nve -
Mad -
Sylvain Munaut