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

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

Hi Francesco,

If you are filling out the Via header before sending the message to the stack and you are populating with an IP address that is not owned by your NICs on the box, then you are asking for trouble.  Resip stack logic is setup to auto populate the top via header for you.  If you pre-populate it, then you are doing so to provide hints to the stack as to which interface to use to send out.  If you specify an interface IP that is not on this machine, then that is bad.

One way to get around this problem, is to modify the Via after the stack is done with the routing process.  This can be done via an Outbound Message Decorator:

https://www.resiprocate.org/Modifying/Decorating_messages_sent

Hope this helps!

Scott

On Mon, Nov 19, 2018 at 1:18 PM Francesco Lamonica <alienpenguin@xxxxxxxxx> wrote:

Hello Scott and others,

I found what was the issue triggering the assert:

There was a NAT between my UAC (that i bind on 0.0.0.0:0) 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.

Scott

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 93.36.18.7:47813 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 0.0.0.0 and random port, but the connection is done via UDP.

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