Bug #2320
closedosmo-gsm-tester aoip runs fail consistently
Added by neels almost 7 years ago. Updated over 6 years ago.
0%
Description
runs end due to timeout when waiting for modems to attach
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
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.
Updated by neels almost 7 years ago
- Assignee changed from pespin to neels
pushed a patch in neels/msc-hlr, verified in http://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run/454/
Updated by neels almost 7 years ago
- Status changed from New to Resolved
merged, verified to work after merge in http://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run/455/
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.