Holger,<br><br>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.<br><br>-MM<br><br><div class="gmail_quote">
On Thu, Apr 21, 2011 at 3:36 AM, Holger Hans Peter Freyther <span dir="ltr"><<a href="mailto:holger@freyther.de">holger@freyther.de</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;">
<div class="im">On 04/21/2011 10:45 AM, Max Marbler wrote:<br>
<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<br>
> commands seems to work reliably.<br>
<br>
</div>Yes, this is one of the problems with ipaccess-config. We should have a queue<br>
of things we want to do with the nanoBTS (always putting reboot to the end)<br>
and then execute this queue.. instead we probably issue reboot after the first<br>
ack we get before we set the IP address.<br>
<div class="im"><br>
<br>
><br>
> This, at least, has been my experience, test on two separate hosts targeting<br>
> both a model 139 and 165 nanoBTS.<br>
><br>
> Your suggestion about using telnet as a diagnostic mechanism came in handy<br>
> 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<br>
> openBSC side of things, the unit continues to slow-flash the green light,<br>
> indicating that the radio is not transmitting.<br>
<br>
</div>No NACk or such on the OML link?<br>
<br>
</blockquote></div><br>