16 Apr
2011
16 Apr
'11
10:57 a.m.
Dear List,
I'm a long time listener, first time caller - but have been enjoying
experimenting with OpenBSC for a little while now.
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?
Thank You,
-MM
16 Apr
16 Apr
7:16 p.m.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
21 Apr
21 Apr
10:45 a.m.
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(a)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(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
12:36 p.m.
On 04/21/2011 10:45 AM, Max Marbler wrote:
./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.
Yes, this is one of the problems with ipaccess-config. We should have a queue
of things we want to do with the nanoBTS (always putting reboot to the end)
and then execute this queue.. instead we probably issue reboot after the first
ack we get before we set the IP address.
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.
No NACk or such on the OML link?
23 Apr
23 Apr
5:06 a.m.
Holger,
Nothing resembling a nack that I could see; definitely nothing erroneous on
the openBSC console, but I didn't have time to check the packet traces too
carefully.
-MM
On Thu, Apr 21, 2011 at 3:36 AM, Holger Hans Peter Freyther <
holger(a)freyther.de> wrote:
On 04/21/2011 10:45 AM, Max Marbler wrote:
./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.
Yes, this is one of the problems with ipaccess-config. We should have a
queue
of things we want to do with the nanoBTS (always putting reboot to the end)
and then execute this queue.. instead we probably issue reboot after the
first
ack we get before we set the IP address.
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.
No NACk or such on the OML link?
10:59 a.m.
Hi Max,
On Fri, Apr 22, 2011 at 08:06:06PM -0700, Max Marbler wrote:
Nothing resembling a nack that I could see; definitely
nothing erroneous on
the openBSC console, but I didn't have time to check the packet traces too
carefully.
If possible, you could simply make the pcap file available for others to review.
--
- 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)
4763
days inactive
4770
days old
5 comments
3 participants
participants (3)
-
Harald Welte -
Holger Hans Peter Freyther -
Max Marbler