This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Max Marbler madmaxmarbler at gmail.comHolger, 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 at 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? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20110422/500abd93/attachment.htm>