Harald,<br><br>Thanks for the helpful reply; you were right in that the OML was going somewhere.<br><br>My error was a combination of two things:<br><br>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)<br>
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.<br><br>eg. issuing a command of the form:<br><br>./ipaccess-config -u 1801/0/0 -o <OML IP> -r <nanoBTS IP><br>
<br>...has been failing to properly set the OML IP. However, issuing two separate commands seems to work reliably.<br><br>This, at least, has been my experience, test on two separate hosts targeting both a model 139 and 165 nanoBTS.<br>
<br>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.<br><br>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.<br>
<br>Note line 32319 and 32638. A telnet-dump of the OML startup follows:<br><br>29389:DBG:IP_CHANNEL:Assigning RX Client A<br>29389:DBG:IP_CHAN_RX_A:39369:ipChanConn: EVENT 0x00001742 rxd in STATE notconnected<br>29389:DBG:IP_CHAN_RX_A:Attempting connection to <a href="http://192.168.15.1:3002">192.168.15.1:3002</a><br>
29389:DBG:IP_CHAN_RX_A:39370:ipChanConn: EVENT 0x00001747 rxd in STATE outgoingconnecting<br>29389:DBG:IP_STREAM:inside ipStreamChannelPeerIdentifiedEntry channelId =64 PeerPort = 3002 <br>29823:DBG:OAM_IM:Changing SYSTEM LINK from 0.0 to 64.255<br>
29893:DBG:OAM_MOI:oid=BTS:0 publisher attributes set<br>29913:DBG:TRX_BOOT:Trx Boot Timer started<br>29913:DBG:TRX_BOOT:Booting TRX image idx=1<br>30098:DBG:TRX_BOOT:Downloading blackfin boot code...<br>30767:DBG:TRX_BOOT:BFIN Booted successfully<br>
30767:DBG:TRX_BOOT:actualItemId found = 0x900a<br>30815:DBG:TRX_BOOT:HPI Readback worked!<br>30815:DBG:TRX_BOOT:uncompressTrxImage : TRXtgtaddr = 0, sourceLen = 13086, max = 1500<br>30822:DBG:TRX_BOOT:uncompressTrxImage totals: stream.total_in = 13086, total_out = 46896<br>
30822:DBG:TRX_BOOT:Downloaded FirstBootAndPost to DSP<br>30822:DBG:TRX_BOOT:DEBUG from TRX: First Boot and Post running...<br>30822:DBG:TRX_BOOT:DEBUG from TRX: Testing internal RAM...<br>30836:DBG:TRX_BOOT:DEBUG from TRX: Testing external RAM...<br>
31195:DBG:TRX_BOOT:DEBUG from TRX: Testing FPGA...<br>31195:DBG:TRX_BOOT:DEBUG from TRX: TRX reports FPGA version number as 0826<br>31195:DBG:TRX_BOOT:DEBUG from TRX: Testing NWL VBC...<br>31195:DBG:TRX_BOOT:DEBUG from TRX: Testing DL VBC...<br>
31517:DBG:TRX_BOOT:DEBUG from TRX: Testing AD9874...<br>31518:DBG:TRX_BOOT:DEBUG from TRX: [ AD9874 ID reg=0x0089]<br>31518:DBG:TRX_BOOT:DEBUG from TRX: firstBootAndPost finished<br>31518:DBG:TRX_BOOT:TRX boot reported all okay<br>
31518:DBG:TRX_BOOT:DEBUG from TRX: requesting main app. download<br>31518:DBG:TRX_BOOT:TRX Requested image dld of imageId: 0x100b<br>31518:DBG:TRX_BOOT:actualItemId found = 0x900b<br>31518:DBG:TRX_BOOT:Reseting TRX for main application download<br>
31564:DBG:TRX_BOOT:uncompressTrxImage : TRXtgtaddr = 80000000, sourceLen = 735441, max = 1500<br>31946:DBG:TRX_BOOT:uncompressTrxImage totals: stream.total_in = 735441, total_out = 2187808<br>31946:DBG:TRX_BOOT:Starting the TRX<br>
32280:DBG:GENIE_SERVER:TRX now ready for genie signals.<br>32280:DBG:TRX_BOOT:Booted TRX idx=1<br>32284:DBG:RSL:39909:rsl: EVENT 0x0000104a rxd in STATE initial<br>32284:DBG:RSL:39909:rsl: ENTERING open<br>32319:DBG:BH_TRX_ROUTER_UL:AlarmInd rx'd:"l1_bg_db.c:202Failed to initialise"<br>
32319:DBG:BH_TRX_ROUTER_UL:AlarmInd rx'd:"l1_bg_db.c:202Failed to initialise"<br>32526:DBG:OAM_MOI:oid=BBTRX:0-0 publisher attributes set<br>32528:DBG:OAM_MOI:oid=Carrier:0-0 subscriber attributes set<br>32529:DBG:RSL:40381:rsl: EVENT 0x0000104b rxd in STATE opennotconnected<br>
32530:DBG:OAM_MOI:oid=BBTRX:0-0 subscriber attributes set<br>32530:DBG:OAM_MOI:oid=Carrier:0-0 publisher attributes set<br>32627:DBG:RSL:41176:rsl: EVENT 0x00001049 rxd in STATE configurednotconnected<br>32627:DBG:RSL:41176:rsl: ENTERING on<br>
32628:DBG:IP_CHANNEL:Assigning RX Client B<br>32629:DBG:RSL:41205:rsl: EVENT 0x00001044 rxd in STATE ongoingconnecting<br>32629:DBG:IP_CHAN_RX_B:41206:ipChanConn: EVENT 0x00001742 rxd in STATE notconnected<br>32629:DBG:IP_CHAN_RX_B:Attempting connection to <a href="http://192.168.15.1:3003">192.168.15.1:3003</a><br>
32629:DBG:IP_CHAN_RX_B:41207:ipChanConn: EVENT 0x00001747 rxd in STATE outgoingconnecting<br>32629:DBG:IP_STREAM:inside ipStreamChannelPeerIdentifiedEntry channelId =65 PeerPort = 3003 <br>32630:DBG:RSL:41214:rsl: EVENT 0x00001043 rxd in STATE onconnecting<br>
32630:DBG:RSL:41214:rsl: ENTERING onconnected<br>32638:DBG:BH_TRX_ROUTER_UL:AlarmInd rx'd:"l1_bg_activate.c:238TX_OPLL_RADIO_FAIL"<br>32651:DBG:RSL:41536:rsl: EVENT 0x00001048 rxd in STATE onconnected<br>32651:DBG:RSL:41536:rsl: EXITING on<br>
<br>I'm assuming that this unit is dead unless someone knows better; the extended write-up is mostly to document the experience and symptoms.<br><br>Thanks Again!<br><br>-MM<br><br><div class="gmail_quote">On Sat, Apr 16, 2011 at 10:16 AM, Harald Welte <span dir="ltr"><<a href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi Max,<br>
<div class="im"><br>
On Sat, Apr 16, 2011 at 01:57:55AM -0700, Max Marbler wrote:<br>
<br>
> I've come across a new (to me) nanoBTS with some strange behavior: it seems<br>
> to come up normally and pull an IP over DHCP, and interacts as expected with<br>
> the ipaccess-find and ipaccess-config tools, but *never* attempts to<br>
> establish an OML link.<br>
><br>
> After provisioning the correct settings with ipaccess-config, the unit<br>
> reboots and slow-flashes the orange light (no OML) and there is *no* network<br>
> traffic initiated by the nanoBTS past the DHCP exchange; however, I can ping<br>
> the unit using ipaccess-find and ping.<br>
><br>
> After running a reset with the dongle and a repeat of the above, I get the<br>
> same results.<br>
><br>
> Any ideas?<br>
<br>
</div>you can try to set the respective nvram flags and then use ipaccess-telnet<br>
to get some debug information. maybe it will tell you what is happening.<br>
<br>
<a href="http://openbsc.osmocom.org/trac/wiki/nanoBTS#TelnetDebugPort" target="_blank">http://openbsc.osmocom.org/trac/wiki/nanoBTS#TelnetDebugPort</a><br>
<br>
the other thing I would do is to take a pcap trace with wireshark/tcpdump<br>
_directly_ at the BTS, either only with a hub (no switch!!) or beter with<br>
a crossover-cable between poe injector and a computer. This way you can<br>
see all the messages in detail that are sent by the BTS. I'm pretty confident<br>
it is trying to connect somewhere, maybe just the wrong address.<br>
<br>
Maybe the DHCP sender is sending some attributes that we don't know which<br>
contain the OML ip address?<br>
<br>
Regards,<br>
Harald<br>
<font color="#888888">--<br>
- Harald Welte <<a href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a>> <a href="http://laforge.gnumonks.org/" target="_blank">http://laforge.gnumonks.org/</a><br>
============================================================================<br>
"Privacy in residential applications is a desirable marketing option."<br>
(ETSI EN 300 175-7 Ch. A6)<br>
</font></blockquote></div><br>