Project

General

Profile

Actions

Bug #1977

closed

3G IuPS is unreliable

Added by neels about 7 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Iu interface
Target version:
-
Start date:
03/09/2017
Due date:
% Done:

100%

Spec Reference:
Tags:
3G

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

Related to OsmoSGSN - Bug #1818: IuPS: CN should Iu Release in certain situationsNew10/12/2016

Actions
Related to OsmoSGSN - Support #3920: PCAPs files of 3G PS for Osmocom network and Commercial oneIn Progress04/12/2019

Actions
Related to OsmoSGSN - Bug #3727: SGSN segfaults on network type changeResolveddaniel12/12/2018

Actions
Related to OsmoSGSN - Bug #3995: OsmoSGSN doesn't close SCCP connection after successful LU over IuPSClosedlynxis05/10/2019

Actions
Actions #1

Updated by neels about 7 years ago

  • Related to Bug #1818: IuPS: CN should Iu Release in certain situations added
Actions #2

Updated by neels about 7 years ago

may or may not be related to #1818

Actions #3

Updated by laforge over 6 years ago

  • Assignee changed from 118 to 4368
Actions #4

Updated by neels over 6 years ago

See #1818#note-4 (and #1818's attached pcap) indicating a likely solution to this issue: mismatching keystatus.

Actions #5

Updated by neels over 6 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.

Actions #6

Updated by laforge over 6 years ago

  • Category set to Iu interface
Actions #7

Updated by laforge almost 6 years ago

  • Tags set to 3G
Actions #8

Updated by laforge almost 5 years ago

  • Related to Support #3920: PCAPs files of 3G PS for Osmocom network and Commercial one added
Actions #9

Updated by laforge over 4 years ago

  • Assignee changed from 4368 to lynxis

Do we still consider this to be the case? Or has this meanwhile been resolved?

Actions #10

Updated by neels over 4 years ago

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.

Actions #11

Updated by lynxis over 4 years ago

  • 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)

Actions #12

Updated by lynxis over 4 years ago

  • Related to Bug #3727: SGSN segfaults on network type change added
Actions #13

Updated by lynxis over 4 years ago

  • Related to Bug #3995: OsmoSGSN doesn't close SCCP connection after successful LU over IuPS added
Actions #14

Updated by neels over 4 years 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?

Actions #15

Updated by lynxis over 4 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 80 to 100
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)