Bug #1977
3G IuPS is unreliable
100%
Description
When first registering on a 3G network, IuPS data service often does not work right away.
Going to flight mode and back into the network may resolve the issue. Sometimes it takes several of them.
Once showing a website the first time, it seems to work well further on.
Related issues
History
#1 Updated by neels over 2 years ago
- Related to Bug #1818: IuPS: CN should Iu Release in certain situations added
#3 Updated by laforge about 2 years ago
- Assignee changed from Osmocom CNI Developers to sysmocom
#4 Updated by neels about 2 years ago
See #1818#note-4 (and #1818's attached pcap) indicating a likely solution to this issue: mismatching keystatus.
#5 Updated by neels about 2 years ago
hmm, it doesn't seem so easy to reproduce a situation where the new_key flag reflects the wrong value.
I do get unreliable behavior, like web browser page failing to load, failing DNS lookups on-and-off, but all the while the new_key flag reflects the actual key status that is transmitted.
It doesn't seem to be as quick a fix as I thought.
#6 Updated by laforge almost 2 years ago
- Category set to Iu interface
#7 Updated by laforge over 1 year ago
- Tags set to 3G
#8 Updated by laforge 6 months ago
- Related to Support #3920: PCAPs files of 3G PS for Osmocom network and Commercial one added
#9 Updated by laforge about 1 month ago
- Assignee changed from sysmocom to lynxis
Do we still consider this to be the case? Or has this meanwhile been resolved?
#14 Updated by neels 27 days ago
So, I learned that the crash is known and comes from changing from 2G to 3G.
Taking care not to do that, I tried the 3G IuPS successfully.
I actually don't see the weird behavior that made me create this issue originally.
It seems that the cause making the IuPS data uplink hickup has indeed been fixed.
lynxis from my side it seems that we can close this, and track the remaining known IuPS problems in their own issues each. Agree?
