Bug #67
closedgb_proxy keeps stale PTP-BVCI <-> NSVCI mappings
0%
Description
When BVCI A first establishes a connection through NSVCI/NSEI B, then later establishes a connection through NSVCI/NSEI A, gb_proxy permanently keeps a stale proxy mapping associating BVCI A with NSVCI B.
This causes all downlink messages from the SGSN to be routed still through NSVCI B, despite now NSVCI A being the correct one.
Updated by laforge over 6 years ago
- Project changed from OpenBSC to OsmoSGSN
- Category deleted (
osmo-gb_proxy)
Updated by laforge almost 4 years ago
- Project changed from OsmoSGSN to osmo-gbproxy
- Category deleted (
299)
Updated by laforge over 3 years ago
- Assignee changed from laforge to daniel
- Priority changed from Low to Normal
Updated by laforge over 3 years ago
I would expect this to not be an isuse with the new architecture/rewrite?
Updated by daniel over 3 years ago
Yeah, the BVCI <-> NSVCI mapping doesn't even make sense now that one NSE could have multiple NSVCs.
Not sure if we have a similar issue in the new gbproxy or if it is already taken care of. Some code related to this got #if 0'd in rx_bvc_reset_from_bss() (gbproxy.c line 793).
Updated by daniel over 3 years ago
- Status changed from New to Rejected
In gb_proxy.c:597 the old bvc is freed if a cell exists and points to (the old) bvc.
So I would think this is not an issue anymore.