I can reproduce your problem on a GSM900 nanoBTS, but I don't really
have any idea why that happens.
Using ipaccess-telnet and using moi::states to look at the debug console
of the nanoBTS, I can see:
----- MOI States -----
[ Site] (Null:255), Enabled,
[ BTS:0] (Unlocked), Disabled, <Dependency>
[ BBTRX:0-0] (Unlocked), Disabled, <Dependency>>
[ Channel:0-0-0] (Locked), Disabled, <Dependency>>
[ Channel:0-0-1] (Locked), Disabled, <Dependency>>
[ Channel:0-0-2] (Locked), Disabled, <Dependency>>
[ Channel:0-0-3] (Locked), Disabled, <Dependency>>
[ Channel:0-0-4] (Locked), Disabled, <Dependency>>
[ Channel:0-0-5] (Locked), Disabled, <Dependency>>
[ Channel:0-0-6] (Locked), Disabled, <Dependency>>
[ Channel:0-0-7] (Locked), Disabled, <Dependency>>
[ Carrier:0-0] (Unlocked), Disabled, >
[ GPRS NSE:0] (Locked), Disabled, <Dependency>
[ GPRS Cell:0-0] (Unlocked), Disabled, <Dependency>>
[ GPRS NSVC:0-0] (Locked), Disabled, >
[ GPRS NSVC:0-1] (Locked), Disabled, >
The problem is the radio carrier. It is Disabled, without having any
dependency on other objects. Sending OPSTART even twice does not change
its state.
If the Radio Carrier would get into Enabled state, the Channels would
all get rid of their Dependency problem.
--
- 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)