Hi, after receiving an E1 card, I tried (unsuccessfully) to get bsc_hack up and running: http://pbot.rmdir.de/19e2baa94ffedfdb814dce0a9346532e
After that, no new network can be found with a mobile phone.
bs11_config is reporting: PHASE: 3 Normal MBCCU0: Load MBCCU1: Load Abis-link: Up
When bsc_hack is started, the following message appears a huge number of times in the kernel log: Mar 1 17:24:51 faui43g kernel: mISDN_send: error -12 and then sometimes messages like: Mar 1 17:24:52 faui43g kernel: ph_data_indication 0x0 0x3 0x0
The kernel version is 2.6.27.19 (patched), but I also tried the newest git tree from Linus with the same results.
I think the configuration of my BS-11 is somehow broken, as both TRX seem to be enabled:
BS11 Power Amplifier 0 ATTRIBUTES: TRX Power: 30mW (GSM)
BS11 Power Amplifier 1 ATTRIBUTES: TRX Power: 30mW (GSM)
But running bs11_config delete-trx1 (or create-trx1) just produces BS11 DELETE OBJECT NACK (respectively BS11 CREATE OBJECT NACK): http://pbot.rmdir.de/53344f67ed0cb86f24c4a79f0af4fe2e
Trying to reset the standard configuration by deleting and recreating all objects in create_objects() doesn't work, too: http://pbot.rmdir.de/13e0b928689c0d527b13fa52698b9391 (Patch: http://pbot.rmdir.de/e549a8a52da6d389326e2e2891c2f289)
It seems to me, that I have to reset the BS-11 to the factory defaults and recreate the configuration with bs11_config, but I don't know how to do that (and if I need the firmware files for that...).
Did I miss something obvious, or is the configuration of my BS11 somehow broken?
Thanks & Regards, Michael
On Sun, Mar 01, 2009 at 06:01:52PM +0100, Michael Gernoth wrote:
Hi, after receiving an E1 card, I tried (unsuccessfully) to get bsc_hack up and running: http://pbot.rmdir.de/19e2baa94ffedfdb814dce0a9346532e
I'm sorry to hear that :(
After that, no new network can be found with a mobile phone.
It looks just right, though. OML and RSL are bootstrapped. can you start it with -dDMI:DRSL:DNM to see if it actually ever receives something back from the BS-11? You should see something like 'E1 RX:' lines
bs11_config is reporting: PHASE: 3 Normal MBCCU0: Load MBCCU1: Load Abis-link: Up
good!
When bsc_hack is started, the following message appears a huge number of times in the kernel log: Mar 1 17:24:51 faui43g kernel: mISDN_send: error -12 and then sometimes messages like: Mar 1 17:24:52 faui43g kernel: ph_data_indication 0x0 0x3 0x0
this is strange.
The kernel version is 2.6.27.19 (patched), but I also tried the newest git tree from Linus with the same results.
sad.
I think the configuration of my BS-11 is somehow broken, as both TRX seem to be enabled:
This is not broken, it is just an option. The second TRX does not interfere in any way in the communication of the OML and RSL-first-TRX bringup, since OML never tells the TRX1 on which TEI/TS to talk to us.
I have BS-11 with both TRX enabled without any problem here.
BS11 Power Amplifier 0 ATTRIBUTES: TRX Power: 30mW (GSM)
BS11 Power Amplifier 1 ATTRIBUTES: TRX Power: 30mW (GSM)
But running bs11_config delete-trx1 (or create-trx1) just produces BS11 DELETE OBJECT NACK (respectively BS11 CREATE OBJECT NACK): http://pbot.rmdir.de/53344f67ed0cb86f24c4a79f0af4fe2e
yes, this is a known [to me] bug. Maybe Dieter can check his LMT traces and see what I am doing wrong when sending the DELETE OBJECT command to the BS-11.
Trying to reset the standard configuration by deleting and recreating all objects in create_objects() doesn't work, too: http://pbot.rmdir.de/13e0b928689c0d527b13fa52698b9391 (Patch: http://pbot.rmdir.de/e549a8a52da6d389326e2e2891c2f289)
It seems to me, that I have to reset the BS-11 to the factory defaults and recreate the configuration with bs11_config, but I don't know how to do that (and if I need the firmware files for that...).
the configuration seems correct, it is set to the right Timeslot / TEI and thus OML should come up. Since the TEI is established between BS-11 site manager and OpenBSC, the problems must happen at a much higher/later level. All other parameters (such as RSL TEI/timeslot are configured over that OML link).
I'm currently also out of further suggestions. the mISDN_send problems sound like a software issue on the PC within or above mISDN. I think everything on layer1 + TEI works just right.
Cheers,
On Sun, Mar 01, 2009 at 09:45:44PM +0100, Harald Welte wrote:
On Sun, Mar 01, 2009 at 06:01:52PM +0100, Michael Gernoth wrote:
After that, no new network can be found with a mobile phone.
It looks just right, though. OML and RSL are bootstrapped. can you start it with -dDMI:DRSL:DNM to see if it actually ever receives something back from the BS-11? You should see something like 'E1 RX:' lines
I've started it with all debug messages enabled: http://pbot.rmdir.de/48e64191d52377dc88b4e939cd232dbc
There is just one RX line in the whole output: Mon Mar 2 09:44:34 2009 <1000> input/misdn.c:151 RX: 80 80 00 05 10 00 ff ff ff followed by: Mon Mar 2 09:44:34 2009 <0020> abis_nm.c:565 Software Activated Report
But running bs11_config delete-trx1 (or create-trx1) just produces BS11 DELETE OBJECT NACK (respectively BS11 CREATE OBJECT NACK): http://pbot.rmdir.de/53344f67ed0cb86f24c4a79f0af4fe2e
yes, this is a known [to me] bug. Maybe Dieter can check his LMT traces and see what I am doing wrong when sending the DELETE OBJECT command to the BS-11.
Ok, then I don't worry about this anymore.
I'm currently also out of further suggestions. the mISDN_send problems sound like a software issue on the PC within or above mISDN. I think everything on layer1 + TEI works just right.
The mISDN_send messages went away, when removing the usleep(100000) in handle_ts1_write() of input/misdn.c, but it still does not seem to work :-(
Regards, Michael
On Mon, Mar 02, 2009 at 09:57:27AM +0100, Michael Gernoth wrote:
The mISDN_send messages went away, when removing the usleep(100000) in handle_ts1_write() of input/misdn.c, but it still does not seem to work :-(
I've moved the E1 card to another machine and it's working now with a clean checkout :-) I still get the mISDN_send errors, but I'm ignoring them.
Regards, Michael
On Mon, Mar 02, 2009 at 02:16:09PM +0100, Michael Gernoth wrote:
On Mon, Mar 02, 2009 at 09:57:27AM +0100, Michael Gernoth wrote:
The mISDN_send messages went away, when removing the usleep(100000) in handle_ts1_write() of input/misdn.c, but it still does not seem to work :-(
I've moved the E1 card to another machine and it's working now with a clean checkout :-)
great. so maybe there is some timing related issue that still needs to be sorted out. Those usleep()s should all go sooner than later anyway. Patches welcome :)