5 Oct
2009
5 Oct
'09
11:38 a.m.
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
5 Oct
5 Oct
10:09 p.m.
New subject: nanoBTS 140 is working now[
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?
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
6 Oct
6 Oct
1:08 p.m.
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?
2:02 p.m.
On Tue, Oct 06, 2009 at 01:08:47PM +0200, Philipp Hug wrote:
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.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
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?
7 Oct
7 Oct
8:26 a.m.
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:
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,
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
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?
10:43 a.m.
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
12:04 p.m.
New subject: Ticket spam
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
4:59 p.m.
New subject: Ticket spam
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.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
3:14 p.m.
On Wed, Oct 07, 2009 at 10:43:34AM +0200, Philipp Hug wrote:
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 <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
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.
5321
days inactive
5323
days old
8 comments
3 participants
participants (3)
-
Harald Welte -
Lars Immisch -
Philipp Hug