ip.access nanobts 1800 model 139, get "disabled" states

historical

Hi!

On Fri, Oct 16, 2009 at 05:26:24PM +0200, Oystein Homelien wrote:
> On Fri, 16 Oct 2009, 246tnt at 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:
> 
> http://home.powertech.no/oystein/bsc-tcpdump-2.pcap

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,
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)