< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate-users] strange crash depending on connection type

Hello Scott and others,
I found what was the issue triggering the assert:
There was a NAT between my UAC (that i bind on and the UAS that would change IP and port,
in my app, in order to allow better compatibility when the UAS responds to the REGISTER with a received and rport set to something different from what i have in contact, i do perform an UN-register and then register again setting the contact to specify the reported IP and port.

What happens within resiprocate is the following:
findTransportByVia (line 931 of resip 1.10.2 might be a few lines off due to debugging statements) fails (because it tries to determine the transport using a non-zero port) but the transport is anyhow found by the findTransportByDest (line 937 - same caveats as before)

But the point is that findTransportByVia, if successful, will clear the sentHost header, while this does not happen when transport is found by findTransportByDest() and that is what is triggering that assert in determineSourceInterface.

Now i am asking - because i am not getting it -, why is the assert checking for the via header in the first place?
would it be safe to clear the via senthost (as done in the findtransportByVia)?

thanks a lot for your hints.

On Wed, Nov 7, 2018 at 6:02 PM Francesco Lamonica <alienpenguin@xxxxxxxxx> wrote:
Hi Scott,
i will double check but i'm pretty sure that the version of TransportSelector is the vanilla from 1.10.2
I am seeing this on macOS (tested on 10.14.1 and 10.13.6)
i managed to try a TLS connection and/or UDP via VPN and i do *not* get any crash, so i'm suspecting some sort of ALG being applied over that connection, however the wireshark traces seems absolutely identical...

On Wed, Nov 7, 2018 at 4:31 PM Scott Godin <sgodin@xxxxxxxxxxxxxxx> wrote:
That's odd I can't remember seeing that assert trigger before (for UDP or TCP).  Your line numbers are off by about 50 lines, and there hasn't been changes to this file since 2016, so I'm curious of you have custom changes that might be triggering this.  With UDP there is no "connection".   Not that it will help with much, but I am curious which OS you are seeing this on.  I would recommend diffing your version of TransportSelector with GIT master to see whats different and that you try to determine which condition in the assert is failing - in order to help you track this down.


On Tue, Nov 6, 2018 at 5:58 PM Francesco Lamonica <alienpenguin@xxxxxxxxx> wrote:
Hello all,
i am baffled by a strange (for me) error that i get from an application of mine.

when sending an invite (don't know if upon receiving the first 401 or when trying to send the authorized invite) i get the following assert:

Assertion failed: ((!(msg->isRequest() && !via.sentHost().empty())) || isSecure(target.getType())), function determineSourceInterface, file TransportSelector.cxx, line 718.

WARNING | 20181106-230440.412 | | RESIP:TRANSPORT | 0x70000deee000 | TransportSelector.cxx:1569 | Can't find matching transport [ V4 UDP ]

Now, the one thing that i find very strange is that the same code crashes deterministically when i am connected with certain internet providers: i.e. vodafone but not with others. This is deterministic and the wireshark traces does not seem to differ apart from the ip addresses.

What might be triggering the assert that depends on connectivity?

P.S. the app creates transport for UDP and TCP binding on and random port, but the connection is done via UDP.

resiprocate-users mailing list
List Archive: http://list.resiprocate.org/archive/resiprocate-users/