Strange nanoBTS Behavior

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Max Marbler madmaxmarbler at gmail.com
Thu Apr 21 08:45:39 UTC 2011


Harald,

Thanks for the helpful reply; you were right in that the OML was going
somewhere.

My error was a combination of two things:

1) A smart switch that was too smart for it's own good (in dropping the
outgoing OML from my nanoBTS to an unroutable host)
2) A repeatable (at least for me) quirk in ipaccess-config, where specifying
both the unit ID and the OML ip in one pass seems to not save the OML IP.

eg. issuing a command of the form:

./ipaccess-config -u 1801/0/0 -o <OML IP> -r <nanoBTS IP>

...has been failing to properly set the OML IP. However, issuing two
separate commands seems to work reliably.

This, at least, has been my experience, test on two separate hosts targeting
both a model 139 and 165 nanoBTS.

Your suggestion about using telnet as a diagnostic mechanism came in handy
though for me to determine that the original problem-unit is probably dead.

After establishing the primary OML and with everything looking good on the
openBSC side of things, the unit continues to slow-flash the green light,
indicating that the radio is not transmitting.

Note line 32319 and 32638. A telnet-dump of the OML startup follows:

29389:DBG:IP_CHANNEL:Assigning RX Client A
29389:DBG:IP_CHAN_RX_A:39369:ipChanConn: EVENT 0x00001742 rxd in STATE
notconnected
29389:DBG:IP_CHAN_RX_A:Attempting connection to 192.168.15.1:3002
29389:DBG:IP_CHAN_RX_A:39370:ipChanConn: EVENT 0x00001747 rxd in STATE
outgoingconnecting
29389:DBG:IP_STREAM:inside ipStreamChannelPeerIdentifiedEntry channelId =64
PeerPort = 3002
29823:DBG:OAM_IM:Changing SYSTEM LINK from 0.0 to 64.255
29893:DBG:OAM_MOI:oid=BTS:0 publisher attributes set
29913:DBG:TRX_BOOT:Trx Boot Timer started
29913:DBG:TRX_BOOT:Booting TRX image idx=1
30098:DBG:TRX_BOOT:Downloading blackfin boot code...
30767:DBG:TRX_BOOT:BFIN Booted successfully
30767:DBG:TRX_BOOT:actualItemId found = 0x900a
30815:DBG:TRX_BOOT:HPI Readback worked!
30815:DBG:TRX_BOOT:uncompressTrxImage : TRXtgtaddr = 0, sourceLen = 13086,
max = 1500
30822:DBG:TRX_BOOT:uncompressTrxImage totals: stream.total_in = 13086,
total_out = 46896
30822:DBG:TRX_BOOT:Downloaded FirstBootAndPost to DSP
30822:DBG:TRX_BOOT:DEBUG from TRX: First Boot and Post running...
30822:DBG:TRX_BOOT:DEBUG from TRX: Testing internal RAM...
30836:DBG:TRX_BOOT:DEBUG from TRX: Testing external RAM...
31195:DBG:TRX_BOOT:DEBUG from TRX: Testing FPGA...
31195:DBG:TRX_BOOT:DEBUG from TRX: TRX reports FPGA version number as 0826
31195:DBG:TRX_BOOT:DEBUG from TRX: Testing NWL VBC...
31195:DBG:TRX_BOOT:DEBUG from TRX: Testing DL VBC...
31517:DBG:TRX_BOOT:DEBUG from TRX: Testing AD9874...
31518:DBG:TRX_BOOT:DEBUG from TRX: [    AD9874 ID reg=0x0089]
31518:DBG:TRX_BOOT:DEBUG from TRX: firstBootAndPost finished
31518:DBG:TRX_BOOT:TRX boot reported all okay
31518:DBG:TRX_BOOT:DEBUG from TRX: requesting main app. download
31518:DBG:TRX_BOOT:TRX Requested image dld of imageId: 0x100b
31518:DBG:TRX_BOOT:actualItemId found = 0x900b
31518:DBG:TRX_BOOT:Reseting TRX for main application download
31564:DBG:TRX_BOOT:uncompressTrxImage : TRXtgtaddr = 80000000, sourceLen =
735441, max = 1500
31946:DBG:TRX_BOOT:uncompressTrxImage totals: stream.total_in = 735441,
total_out = 2187808
31946:DBG:TRX_BOOT:Starting the TRX
32280:DBG:GENIE_SERVER:TRX now ready for genie signals.
32280:DBG:TRX_BOOT:Booted TRX idx=1
32284:DBG:RSL:39909:rsl: EVENT 0x0000104a rxd in STATE initial
32284:DBG:RSL:39909:rsl: ENTERING open
32319:DBG:BH_TRX_ROUTER_UL:AlarmInd rx'd:"l1_bg_db.c:202Failed to
initialise"
32319:DBG:BH_TRX_ROUTER_UL:AlarmInd rx'd:"l1_bg_db.c:202Failed to
initialise"
32526:DBG:OAM_MOI:oid=BBTRX:0-0 publisher attributes set
32528:DBG:OAM_MOI:oid=Carrier:0-0 subscriber attributes set
32529:DBG:RSL:40381:rsl: EVENT 0x0000104b rxd in STATE opennotconnected
32530:DBG:OAM_MOI:oid=BBTRX:0-0 subscriber attributes set
32530:DBG:OAM_MOI:oid=Carrier:0-0 publisher attributes set
32627:DBG:RSL:41176:rsl: EVENT 0x00001049 rxd in STATE
configurednotconnected
32627:DBG:RSL:41176:rsl: ENTERING on
32628:DBG:IP_CHANNEL:Assigning RX Client B
32629:DBG:RSL:41205:rsl: EVENT 0x00001044 rxd in STATE ongoingconnecting
32629:DBG:IP_CHAN_RX_B:41206:ipChanConn: EVENT 0x00001742 rxd in STATE
notconnected
32629:DBG:IP_CHAN_RX_B:Attempting connection to 192.168.15.1:3003
32629:DBG:IP_CHAN_RX_B:41207:ipChanConn: EVENT 0x00001747 rxd in STATE
outgoingconnecting
32629:DBG:IP_STREAM:inside ipStreamChannelPeerIdentifiedEntry channelId =65
PeerPort = 3003
32630:DBG:RSL:41214:rsl: EVENT 0x00001043 rxd in STATE onconnecting
32630:DBG:RSL:41214:rsl: ENTERING onconnected
32638:DBG:BH_TRX_ROUTER_UL:AlarmInd
rx'd:"l1_bg_activate.c:238TX_OPLL_RADIO_FAIL"
32651:DBG:RSL:41536:rsl: EVENT 0x00001048 rxd in STATE onconnected
32651:DBG:RSL:41536:rsl: EXITING on

I'm assuming that this unit is dead unless someone knows better; the
extended write-up is mostly to document the experience and symptoms.

Thanks Again!

-MM

On Sat, Apr 16, 2011 at 10:16 AM, Harald Welte <laforge at gnumonks.org> wrote:

> Hi Max,
>
> On Sat, Apr 16, 2011 at 01:57:55AM -0700, Max Marbler wrote:
>
> > I've come across a new (to me) nanoBTS with some strange behavior: it
> seems
> > to come up normally and pull an IP over DHCP, and interacts as expected
> with
> > the ipaccess-find and ipaccess-config tools, but *never* attempts to
> > establish an OML link.
> >
> > After provisioning the correct settings with ipaccess-config, the unit
> > reboots and slow-flashes the orange light (no OML) and there is *no*
> network
> > traffic initiated by the nanoBTS past the DHCP exchange; however, I can
> ping
> > the unit using ipaccess-find and ping.
> >
> > After running a reset with the dongle and a repeat of the above, I get
> the
> > same results.
> >
> > Any ideas?
>
> you can try to set the respective nvram flags and then use ipaccess-telnet
> to get some debug information.  maybe it will tell you what is happening.
>
> http://openbsc.osmocom.org/trac/wiki/nanoBTS#TelnetDebugPort
>
> the other thing I would do is to take a pcap trace with wireshark/tcpdump
> _directly_ at the BTS, either only with a hub (no switch!!) or beter with
> a crossover-cable between poe injector and a computer.  This way you can
> see all the messages in detail that are sent by the BTS.  I'm pretty
> confident
> it is trying to connect somewhere, maybe just the wrong address.
>
> Maybe the DHCP sender is sending some attributes that we don't know which
> contain the OML ip address?
>
> Regards,
>        Harald
> --
> - 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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20110421/42425a8b/attachment.htm>


More information about the OpenBSC mailing list