23 Apr
2011
23 Apr
'11
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?