Bug #3805
closedOsmoMSC sends invalid BSSMAP length field on CSFB CLEAR COMMAND
100%
Description
When sending a BSSMAP CLEAR COMMAND with CSFB indicator, osmo-msc currently sends '0004200401098' where '04' is the length of the BSSMAP message which we follow with 5 bytes of IEs :(
Let's not only fix that one encoding bug but also add a general consistency checker in the BSSAP output path to ensure we catch sending invalid length fields inside osmo-msc (and osmo-bsc) itself.
See also: https://www.eclipse.org/forums/index.php/t/1097647/
Related issues
Updated by laforge about 5 years ago
- Related to Feature #3778: Support CSFB "Fast Return" added
Updated by laforge about 5 years ago
- % Done changed from 0 to 80
Actual encoding bug adressed in https://gerrit.osmocom.org/#/c/libosmocore/+/12924/
The bug only came about because- the related function gsm0808_create_clear_command2() was introduced without any unit test coverage.
- the feature in osmo-msc was developed / added before having a TTCN-3 testcase in place
It saddens me a bit that >= 1.5 years after introducing test-driven development we still see those kind of issues slipping into master. We need to work together to improve our processes. This doesn't only affect the developer, but also the reviewers. We should have spotted the missing unit test during review.
- https://gerrit.osmocom.org/#/c/libosmocore/+/12933/ adds the missing unit test
- https://gerrit.osmocom.org/#/c/osmo-msc/+/12928/ adds a generic "encoded length value" check to all BSSAP messages transmitted by osmo-msc.
Updated by laforge about 5 years ago
- Status changed from In Progress to Resolved
- % Done changed from 80 to 100
libosmocore patch merged, OsmoMSC now sends correct length values.
Updated by laforge about 5 years ago
- Related to Bug #3806: OsmoBSC accepts BSSAP with wrong length field added