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 < [email protected]> 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? > >
