Hi!
On Fri, Oct 16, 2009 at 05:26:24PM +0200, Oystein Homelien wrote:
On Fri, 16 Oct 2009, 246tnt@gmail.com wrote:
You need to use the -s 1500 option of tcpdump. Because as it is, you capture only the first 90 bytes of each packet.
Wow, this is really not my best day. Sorry for the inconvenience. New file here:
ok, everything looks fine, i.e. there are no NACKs (apart from the one intended NACK of GPRS) and no unknown messages or error messages.
What is interesting is that the individual timeslots all look like:
operational state: disabled availability state: dependency administrative state: unlocked
the first part "opstate == disabled" is strange, since we have issued the OPSTART command to change that. Maybe the old unit/firmware is more picky with regard to the ordering of the commands.
It might well be that we have to obey the following sequence of things:
1) we set the object attributes 2) we wait for the ack 3) we change the administrative state to unlocked 4) we wait for the ack 5) we now send the OPSTART command 6) we receive an ack.
Right now, we have the order "1,2,5,6,3,4" which is not quite logical. How can something start operating if it is still in locked state.
The 'locked' state is intended to lock an object for OML configuration such as setting channel attributes. While an object is locked, it is not available to the regular network (and thus RSL).
If you want to play with the sequence of things, bsc_init.c:nm_state_event() is where you have to start.
Regards,