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.comHarald, 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>