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@gmail.com ---
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
On Thu, 3 Feb 2011 14:54:14 +0100, Sylvain Munaut wrote:
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).
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
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
baseband-devel@lists.osmocom.org
-
Leonardo Nve -
Mad -
Sylvain Munaut