Bug #1977
closed
Added by neels about 7 years ago.
Updated over 4 years ago.
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 to Bug #1818: IuPS: CN should Iu Release in certain situations added
may or may not be related to #1818
- Assignee changed from 118 to 4368
See #1818#note-4 (and #1818's attached pcap) indicating a likely solution to this issue: mismatching keystatus.
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.
- Category set to Iu interface
- Related to Support #3920: PCAPs files of 3G PS for Osmocom network and Commercial one added
- Assignee changed from 4368 to lynxis
Do we still consider this to be the case? Or has this meanwhile been resolved?
I tried to quickly test IuPS to see how it fares, but hit a crash: #4208
I haven't yet seen a really reliable 3G data connection. Possibly problems are fixed, but let's consider this unresolved until osmo-sgsn works again.
- Status changed from New to In Progress
- % Done changed from 0 to 80
So far I see the following problems
- ran changes 2g/3g (patches in gerrit, but WIP)
- Iu release (patches needs to be merged)
- synchronize PDP Context: MS state with SGSN state (already merged)
- Related to Bug #3727: SGSN segfaults on network type change added
- Related to Bug #3995: OsmoSGSN doesn't close SCCP connection after successful LU over IuPS added
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?
- Status changed from In Progress to Closed
- % Done changed from 80 to 100
Also available in: Atom
PDF