Cellular Network Infrastructure » OsmoGSMTester

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

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

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.

pushed a patch in neels/msc-hlr, verified in http://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run/454/

https://gerrit.osmocom.org/2860

merged, verified to work after merge in http://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run/455/

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.