Age | Commit message (Collapse) | Author | Files | Lines |
|
Make a crazy test that will test each possible PDCH configuration
and MS Class and verify that the UL/DL assignments work and that
they are on the same first_common_ts.
|
|
Generate results for all possible classes.
|
|
The allocation in the TBF/BTS code is quite complex. In parts this
is due the assignment and requests occuring under differen circumstances.
Attempt to re-create the commono scenarios.
Remove the bogus msclass check in gprs_rlcmac_tbf::update as the
allocation code will check the ms class anyway.
|
|
Coverity complains about this code as it doesn't know that the
OSMO_ASSERT is always on. But it is good practice to now have the
side-effect in here.
Fixes: Coverity CID 1080724
|
|
|
|
|
|
|
|
Use it to compare rbb
|
|
Test that ssn and rbb are updated correctly.
|
|
|
|
|
|
|
|
|
|
|
|
* Make append_data, remaining_space and fits_in_current.. work
on m_length and not the index. This ways things can't overflow.
* The current API consumer was moving the m_index so it should have
worked okay.
|
|
|
|
During a routing area update a new P-TMSI was assigned. During
the PACKET CONTROL ACK on the DL we notice the change of TLLI
but didn't propagate this. This means that a Routing Area Update
Complete was only sent after a new RACH request.
Addresses:
<0007> gprs_rlcmac_meas.cpp:103 UL RSSI of TLLI=0x88661bc6: -67 dBm
<0002> bts.cpp:945 Got ACK, but UL TBF is gone TLLI=0xe512eba3
<0007> gprs_rlcmac_meas.cpp:158 DL packet loss of IMSI=274080000004765 / TLLI=0xe512eba3: 0%
<0002> tbf.cpp:668 TBF TFI=0 TLLI=0x88661bc6 T3169 timeout during transsmission
<0002> tbf.cpp:690 - Assignment was on PACCH
<0002> tbf.cpp:694 - No uplink data received yet
|
|
|
|
The list belongs to the BTS. This makes cleaning this up more easy
and establishes a hierachy of resources that start from the BTS. The
debug_diagram code is now broken.
|
|
When a PDCH is disabled all resources should be freed. This is
currently not possible as the PDCH does not know where it belongs
to. On top of that the list (and other resources) should be
properly initialized on construction so that disable() is idempotent
and does not check if it was disabled. During the re-factoring I
noticed that during a sysmobts re-start some resources are not
freed. I left a warning in the code to resolve this issue later.
|
|
Compared to the previous code there will be a branch to get the
global pointer so the code will be slightly slower than the previous
version but it allows us to start creating objects but still use
the code from C. It is best approach I have found so far.
One downside of C++ is that by default talloc will not be used
(unless we override the new operator to use talloc. Right now
we need to memset the C data structure by hand. The benefit of
enforcing a better structure should is more important though.
|
|
Begin to make the BTS a real C++ object with real responsibilities.
The biggest issue will be the pcu_vty.c that might not like C++
at all.
|
|
|
|
Introduce the concept of tests that will be ran one after the other.
This new test will send static message that will lead to the opening
of a PDP context. At this point one should use ping with a large
packet size and suspend/stop the emulator. Once the NS connection is
considered dead the SGSN will crash with a double free.
Reproduce:
0.) Add IMSI 901700000003094 to the ACL
1.) Stop/Suspend the emulation process so the NS Alive times out
2.) Use ping IP -s 2048
This will create a double free...
#4 0xb7bb2646 in talloc_abort_double_free () at talloc.c:175
#5 0xb7bbd41a in talloc_chunk_from_ptr (ptr=0x8091208) at talloc.c:190
#6 _talloc_free (ptr=0x8091208) at talloc.c:517
#7 talloc_free (ptr=ptr@entry=0x8091208) at talloc.c:990
#8 0xb7bb319b in msgb_free (m=m@entry=0x8091208) at msgb.c:72
#9 0x0804db54 in sndcp_send_ud_frag (fs=0xbfffcc6c) at gprs_sndcp.c:423
#10 sndcp_unitdata_req (msg=msg@entry=0x808eed8, lle=0x808fbc8, nsapi=5 '\005',
mmcontext=mmcontext@entry=0x80903e8) at gprs_sndcp.c:471
|
|
Use the OpenBSC SGSN code to parse the LLC data and look into
the data we receive. Add assertions to verify the the sequence
number is increasing.
|
|
This will send a static message. It will trigger the GMM code
on the SGSN and might ask us for the IMEI/IMSI or send us an
accept. As we are not replying at all the SGSN needs to send new
requests and we can observe if the sequence number is increasing
like it should.
|
|
This code can open a BSSGP connection toward a SGSN and will
inititate the unblocking. It does not send any user data.
|
|
As a last minute change I probably ran git rebase --whitespace=fix
on the patch set and broke the test result. Update the expected
file and tests should pass.
|
|
|
|
|