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/.

Holger Hans Peter Freyther holger at freyther.de
Thu Apr 21 10:36:09 UTC 2011


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?




More information about the OpenBSC mailing list