During the GSM deployment in the CCC Camp, Daniel Willmann
noticed that the LCR and the MNCC were closing the local
connection over unix sockets communication quite so often.
After some debugging, Peter Stuge noticed that openBSC was
closing the connection since write was returning 0.
Then, I suggested that it could be a malformed message with
zero length. By skipping empty messages, Peter confirmed that
the connection between the LCR and the MNCC was not closing
anymore. However, there was no voice in the calls that went
over MNCC.
After some more debugging I found that we were not building
GSM_TCHF_FRAME over MNCC appropriately in the TRAU multiplexer
code, since we forgot to msgb_put() the message.
Scenario: BTS are configured and working, then the BSC stops working
for some reason (crash or administrative stop).
If the BSC comes back to life, LAPD among other things does not know
about the previous existing TEIs. Instead of ignoring these frames,
we notify the driver that we are seeing frames with unknown TEIs, so
it can try to recover, e.g. by resending the SABM message.
Running the entire bts_nokia_site.c through the 'Lindent' script
to match indent/coding style with remainder of project.
There are still lots of other cleanups pending, but this one is
a purely cosmetic one.
DAHDI creates one device node for every E1 timeslot, starting from '1',
and keeps incrementing that number even for additional ports/cards.
Thus, we have to use the e1inp_line number multiplied by 31 as a base.
The byte ordering is a bit odd: The least significant byte is ahead of
the most significant byte, different from everything else in GSM that
seems to be big-endian.
Thanks to Seungju Kim <admin@manateeshome.com> for repoerting the bug.
This fixes a bug introduced more than one year ago in commit
e38bd6caa34005816a9336f021fd17d328d5c901:
The RSL_IE_CHAN_IDENT is a TLV, but the GSM48_IE_CHANDESC_2 contained in
it, is a mere TV type IE with fixed length.
The problem specifically has caused problems on Nokia MetroSite BTS,
which apparently read the TSC out of this Layer3 IE.
The MS Radio Access Capability IE can be _very_ long in some recent
high-end mobile phones, way beyond the old 14-byte limit. We increase
our array to 52 bytes, and make sure not to overflow that buffer.
It was possible to set the LAC=0 on a subscriber that just has
done a LU because it did not respond to a paging request.
E.g. when a phone is rebooting, a SMS being delivered, the phone
is doing the LU, sub_ready_for_sm will try to send a SMS (but the
phone is not ready yet and it will timeout), then the paging code will
send us an expiration note and we might set the LAC=0 for this
subscriber.
Ideally we would be able to stop the paging request once the subscriber
is authenticated and then hand this to the SMS layer, right now the
best thing to do is to detect that we will run into this problem and
not send the SMS, not try to set the LAC=0.
When the BSC is refusing to open an outgoing connection the SCCP
connection was leaked. Use the normal free as the socket should
be either closed or disconnected.
Reset the BTS MO State on BTS bootstrap. This way we will always
test the BTS disconnect/reconnect case of the BTS.
Do not reset the administrative state of objects. The BSC might
have set these and wants to maintain them across disconnect/
reconnect. Right now this is true for the TRX state.
We want to compare the file more_magic[0] and more_magic[1]
with the static more_magic array to see where the difference
is.
src/ipaccess/ipaccess-firmware.c +64 ipaccess_analyze_file(26) warn: buffer overflow 'firmware_header->more_magic' 2 <= 2
src/ipaccess/ipaccess-firmware.c +64 ipaccess_analyze_file(26) warn: buffer overflow 'firmware_header->more_magic' 2 <= 3
Harald Welte
Daniel Willmann
Dieter Spaar