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?