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@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?