Hi everyone,
Thanks to some hints from Sylvain my nanoBTS 140 is working now. We found the following problems: * Software Activation request is not complete ( it needs to contain tag + FILE_ID and FILE_VERSION). See patch sent by Sylvain. * It's relevant which Software is activated, but our logic to always use the first SW Description record works most of the time because the nanoBTS will move the software that was activated the last time to the first position.
So maybe we need hard-code which software to prefer for activation or we put some warnings in the wiki.
What's left is that after some time the BTRS reports an error and goes to Disabled state, but I have to investigate that more.
Philipp
Hi Philipp,
thanks for your feedback.
On Mon, Oct 05, 2009 at 11:38:31AM +0200, Philipp Hug wrote:
Thanks to some hints from Sylvain my nanoBTS 140 is working now. We found the following problems:
- Software Activation request is not complete ( it needs to contain tag +
FILE_ID and FILE_VERSION). See patch sent by Sylvain.
Ok, I will look into this patch as soon as I have some time.
- It's relevant which Software is activated, but our logic to always use the
first SW Description record works most of the time because the nanoBTS will move the software that was activated the last time to the first position.
So maybe we need hard-code which software to prefer for activation or we put some warnings in the wiki.
why? If you say we are activating the most recently activated software, why is there a need for a warning of any sort? Or why would we need to hardcode?
So maybe we need hard-code which software to prefer for activation or we put some warnings in the wiki.
why? If you say we are activating the most recently activated software, why is there a need for a warning of any sort? Or why would we need to hardcode?
the problem is, that at least on my nanoBTS, the most recently activated software was not the correct one and I had to manually activate the correct one.
philipp
On Tue, Oct 06, 2009 at 01:08:47PM +0200, Philipp Hug wrote:
So maybe we need hard-code which software to prefer for activation or we put some warnings in the wiki.
why? If you say we are activating the most recently activated software, why is there a need for a warning of any sort? Or why would we need to hardcode?
the problem is, that at least on my nanoBTS, the most recently activated software was not the correct one and I had to manually activate the correct one.
the question is: which is the 'correct' one? this is a choice only the administrator can take, based on his information of which versions are installed in the BTS, and his information on what differentiates those software versions.
On Tue, Oct 06, 2009 at 02:02:17PM +0200, Harald Welte wrote:
On Tue, Oct 06, 2009 at 01:08:47PM +0200, Philipp Hug wrote:
So maybe we need hard-code which software to prefer for activation or we put some warnings in the wiki.
why? If you say we are activating the most recently activated software, why is there a need for a warning of any sort? Or why would we need to hardcode?
the problem is, that at least on my nanoBTS, the most recently activated software was not the correct one and I had to manually activate the correct one.
the question is: which is the 'correct' one? this is a choice only the administrator can take, based on his information of which versions are installed in the BTS, and his information on what differentiates those software versions.
To summarize: I think it is good if we simply document the fact that we will activate the default software, and that it is the users responsibility to ensure the default software will work.
What we should do, though, is to create a list of known-working ip.access firmware versions on the wiki.
Regards,
To summarize: I think it is good if we simply document the fact that we will activate the default software, and that it is the users responsibility to ensure the default software will work.
What we should do, though, is to create a list of known-working ip.access firmware versions on the wiki.
I agree, and it would be nice if we could add an option to ipaccess-config to switch the active firmware.
Philipp
Hi,
I'm noticing ticket spam on the Trac instance, for example http://bs11-abis.gnumonks.org/trac/ticket/31
Since I see the spam on me News reader, I wouldn't mind purging it as it see it coming in, but trac doesn't allow to delete tickets natively.
There are plugins, however:
http://trac-hacks.org/svn/ticketdeleteplugin/0.10/ticketdelete/
I'd suggest to install this or a similar plugin.
In the meantime, should I mark them as fixed/invalid?
Andreas, is there anything I can help you with for your work with 26c3?
- Lars
Hi Lars,
On Wed, Oct 07, 2009 at 12:04:19PM +0200, Lars Immisch wrote:
I'm noticing ticket spam on the Trac instance, for example http://bs11-abis.gnumonks.org/trac/ticket/31
Since I see the spam on me News reader, I wouldn't mind purging it as it see it coming in, but trac doesn't allow to delete tickets natively.
thanks.
There are plugins, however:
http://trac-hacks.org/svn/ticketdeleteplugin/0.10/ticketdelete/
I'd suggest to install this or a similar plugin.
thanks, I will do that and see that you get the apropriate permissions.
In the meantime, should I mark them as fixed/invalid?
just wait, i'll try to do it within the hour.
On Wed, Oct 07, 2009 at 10:43:34AM +0200, Philipp Hug wrote:
To summarize: I think it is good if we simply document the fact that we will activate the default software, and that it is the users responsibility to ensure the default software will work.
What we should do, though, is to create a list of known-working ip.access firmware versions on the wiki.
I agree, and it would be nice if we could add an option to ipaccess-config to switch the active firmware.
All my nanoBTS only have one firmware, so I have no idea how to switch (and how to reproduce/test this). If somebody writes a reasonably good patch for adding this support, I'm willing to merge it.
-
Harald Welte -
Lars Immisch -
Philipp Hug