Project

General

Profile

Actions

Bug #2320

closed

osmo-gsm-tester aoip runs fail consistently

Added by neels almost 7 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Urgent
Assignee:
Target version:
-
Start date:
06/08/2017
Due date:
% Done:

0%

Spec Reference:

Description

runs end due to timeout when waiting for modems to attach

Actions #1

Updated by neels almost 7 years ago

trial-451.tgz reveals in the osmo-msc log:

gsup_client.c:344 GSUP not connected, unable to send
Actions #2

Updated by neels almost 7 years ago

  • Assignee changed from 55360 to pespin

this has to happen ever since this commit:

commit db59bcf9fcdc5f05fdb9047b905ab497472440bc
Author: Pau Espin Pedrol <pespin@sysmocom.de>
Date:   Wed May 31 15:28:16 2017 +0200

    Use reserved ip address for osmo-hlr GSUP interface

    Otherwise 0.0.0.0 was being used and we want all interfaces for a
    specific osmo-hlr instance to use the same IP

    Requires osmo-hlr change id I79f7a300480f308b21116dd14d1698be38725afd
    otherwise osmo-hlr won't be able to parse the configuration file.

    Change-Id: I4e0063abc8de3d739ebd81942b692cc2e75792f1

diff --git a/src/osmo_gsm_tester/templates/osmo-hlr.cfg.tmpl b/src/osmo_gsm_tester/templates/osmo-hlr.cfg.tmpl
index fbd6cfc..ccb8224 100644
--- a/src/osmo_gsm_tester/templates/osmo-hlr.cfg.tmpl
+++ b/src/osmo_gsm_tester/templates/osmo-hlr.cfg.tmpl
@@ -10,3 +10,6 @@ line vty
  bind ${hlr.ip_address.addr}
 ctrl
  bind ${hlr.ip_address.addr}
+hlr
+ gsup
+  bind ip ${hlr.ip_address.addr}

The point is that osmo-hlr was re-configured to run GSUP on 10.42.42.*, but the osmo-msc was not reconfigured to connect to this address and still attempts to connect to GSUP at 127.0.0.1. This obviously fails and no subscribers can be attached.

pespin: you submitted this patch and it was merged, but you onviously never checked whether your change actually works. When you submit a patch, I assume that you have actually verified that it works. Wen I was reviewing the patches, I did indeed oversee the obvious mistake of changing only one of the GSUP sides, but it was clearly your responsibility to follow up on this and verify that it works.

Furthermore, when our osmo-gsm-tester runs were failing consistently, you decided to not take a quick look at the logs, which would have shown your patch to be the cause, within five minutes of reading the logs. Instead, you continued to develop new features. When I asked you about it, you said that you first want to submit a new patch and then check the failure. This clearly was a second neglect of your responsibilities.

In the future I expect you to handle these issues in the obvious way: immediately investigate the failure for a few minutes; check that your own patches work; do not defer, planning to merge new features before investigating old failures.

Actions #3

Updated by neels almost 7 years ago

  • Assignee changed from pespin to neels
Actions #5

Updated by neels almost 7 years ago

  • Status changed from New to Resolved
Actions #6

Updated by pespin almost 7 years ago

When I did the patch to add the option in the osmo-hlr I tested it running osmo-hlr locally and checking with netstat that the correct address was being used to bind.
As per osmo-gsm-tester, when solving this issue written in the task I assumed the client side was already correctly configured and only the server side was missing proper IP bind (was using 0.0.0.0 so any client could connect). Indeed I should have checked anyway, sorry for that.

Thanks for fixing the issue.

Actions #7

Updated by laforge over 6 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)