[OpenSIPS-Users] siptrace picks incorrect source socket

[Jeff Pyle]

Bogdan,

Yes.  Here's a Homer DB record written on the capture server from the HEP
packet:

          date: 2017-02-10 09:08:04
        method: REGISTER
         via_1: SIP/2.0/TLS
[2607:FB90:1234:5678:9ABC:DEF0:955D:F1E5]:60640;branch=z9hG4bKo9TPB60p8Y2aQLbm;rport
     source_ip: 2607:FB90:1234:5678:9ABC:DEF0:955D:F1E5
destination_ip: 2607:FB90:1234:5678:9ABC:DEF0:955D:F1E5

(IPs mangled to protect the guilty.)


- Jeff


On Wed, Feb 8, 2017 at 4:21 PM, Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

> Jeff,
>
> So, for the REGISTER request, in HEP, you have as both src and dst the
> incoming IP of the request ??
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
> On 02/08/2017 11:12 PM, Jeff Pyle wrote:
>
> Bogdan and team,
>
> This does appear to fix the source interface issue ... at least for IPv4.
> On IPv6, the errors are gone, but the source address is being reported as
> both the source and destination address for a message in siptrace.
>
> I'm using the following:
>
> listen=hep_udp:127.0.0.1:4530 children=1
> listen=hep_udp:[::1]:4530 children=1     # Not doing anything
>
> loadmodule "proto_hep.so"
> modparam("proto_hep", "hep_id", "[heppy] 127.0.0.1:9060; version=3;
> transport=udp")
>
> loadmodule "siptrace.so"
> modparam("siptrace", "trace_on", 1)
> modparam("siptrace", "trace_id", "[tid]uri=hep:heppy")
>
>
> I was looking at a registration in this particular case captured with
> sip_trace("tid", "t").
>
>
> - Jeff
>
>
> On Tue, Feb 7, 2017 at 3:08 AM, Ionut Ionita <ionutionita at opensips.org>
> wrote:
>
>> It's not that syntax anymore, but the docs weren't updated. Now you have
>> to declare an hep_id
>>
>> in proto_hep like:
>>
>>     *modparam("proto_hep", "hep_id", "[heppy] 10.0.0.135:6061
>> <http://10.0.0.135:6061>; version=3; transport=tcp")*
>>
>> then in sip_trace you have to declare a trace_id like:
>>
>>   *  modparam("siptrace", "trace_id", "[hep_id]uri=hep:heppy")*
>>
>> The docs will be updated soon.
>>
>> Regards,
>>
>> Ionut Ionita
>> OpenSIPS Developer
>>
>> On 02/07/2017 04:27 AM, Jeff Pyle wrote:
>>
>> Hi Bogdan,
>>
>> Now it won't start.  I see the following errors on config check:
>>
>> Feb  6 21:21:03 [30051] ERROR:siptrace:parse_siptrace_uri: Invalid key
>> <version> in trace id!
>> Feb  6 21:21:03 [30051] ERROR:siptrace:parse_siptrace_id: invalid uri
>> <3;transport=udp;>
>> Feb  6 21:21:03 [30051] ERROR:siptrace:parse_trace_id: failed to parse
>> siptrace uri [3;transport=udp;]
>> Feb  6 21:21:03 [30051] CRITICAL:core:yyerror: parse error in config file
>> /usr/local//etc/opensips/opensips.cfg, line 225, column 20-21: Parameter
>> <trace_id> not found in module <siptrace> - can't set
>> Feb  6 21:21:03 [30051] ERROR:core:main: bad config file (1 errors)
>> Feb  6 21:21:03 [30051] NOTICE:core:main: Exiting....
>>
>>
>> The script has:
>>
>>    223 loadmodule "siptrace.so"
>>    224 modparam("siptrace", "trace_on", 1)
>>    225 modparam("siptrace", "trace_id", "[tid]uri=hep:127.0.0.1:9060;v
>> ersion=3;transport=udp;")
>>
>>
>> This is on 2.3/devel git revision 2bcf891 from around 01:00 UTC Feb 07.
>>
>>
>>
>> - Jeff
>>
>>
>> On Sun, Feb 5, 2017 at 11:00 AM, Bogdan-Andrei Iancu <
>> <bogdan at opensips.org>bogdan at opensips.org> wrote:
>>
>>> Hi Jeff,
>>>
>>> Thank you for detailed report. I was able to reproduce and fix it.
>>> Please see:
>>>     https://github.com/OpenSIPS/opensips/commit/b30af734cdb84991
>>> e1f906e3920a94e87c33ea04
>>>
>>> If you confirm the fix, I will do the backporting to 2.2 too.
>>>
>>> Thanks and Regards,
>>>
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>>
>>> On 02/04/2017 04:41 AM, Jeff Pyle wrote:
>>>
>>> Hello,
>>> I recently enabled siptrace on an OpenSIPS 2.2.2 system acting as a
>>> registrar and a proxy.  It has one IPv4 address with several ports for UDP,
>>> TCP and TLS.  In a case where the INVITE is relayed from TLS to UDP, the
>>> replies to the UAC are incorrectly being reported as coming from the UDP
>>> socket.
>>> In the below scenario the UAC is at 64.65.66.67, and its ephemeral TCP
>>> client port for this call is 61235.  The OpenSIPS proxy is at
>>> 131.132.133.134 listening on UDP 5060 and TLS 5061.  Also on
>>> 131.132.133.134 there is a Freeswitch media server listening on UDP 5080.
>>> The UAC sends an INVITE to the proxy over TLS which routes it to the media
>>> server over UDP.  The replies relayed to the UAC are reported as having
>>> come from port 5060 over UDP when in reality they have come from port 5061
>>> over TCP (TLS).
>>> My config:
>>>
>>> listen=udp:131.132.133.134:5060
>>> listen=tls:131.132.133.134:5061
>>> listen=hep_udp:127.0.0.1:9030
>>> loadmodule "siptrace.so"
>>> modparam("siptrace", "trace_on", 1)
>>> modparam("siptrace", "trace_id", "[hep]uri=hep:127.0.0.1:9060;t
>>> ransport=udp;")
>>>
>>> Debugs:
>>>
>>> INVITE in from UAC over TLS
>>> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24673]:
>>> DBG:siptrace:pipport2su: proto 22, host 64.65.66.67 , port 61235
>>> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24673]:
>>> DBG:siptrace:pipport2su: proto 22, host 131.132.133.134 , port 5061
>>> INVITE out to media server over UDP
>>> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24673]:
>>> DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5060
>>> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24673]:
>>> DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5080
>>> 100 Trying in from media server over UDP
>>> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24650]:
>>> DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5080
>>> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24650]:
>>> DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5060
>>> 180 Ringing in from media server over UDP
>>> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24651]:
>>> DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5080
>>> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24651]:
>>> DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5060
>>> 180 Ringing out to UAC over TLS (even though it reports UDP)
>>> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24651]:
>>> DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5060
>>> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24651]:
>>> DBG:siptrace:pipport2su: proto 22, host 64.65.66.67 , port 61235
>>> 200 OK in from media server over UDP
>>> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24651]:
>>> DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5080
>>> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24651]:
>>> DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5060
>>> 200 OK out to UAC over TLS (even though it reports udp)
>>> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24651]:
>>> DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5060
>>> Feb  3 21:20:22 testproxy /usr/sbin/opensips[24651]:
>>> DBG:siptrace:pipport2su: proto 22, host 64.65.66.67 , port 61235
>>> ACK in from UAC over TLS
>>> Feb  3 21:20:23 testproxy /usr/sbin/opensips[24673]:
>>> DBG:siptrace:pipport2su: proto 22, host 64.65.66.67 , port 61235
>>> Feb  3 21:20:23 testproxy /usr/sbin/opensips[24673]:
>>> DBG:siptrace:pipport2su: proto 22, host 131.132.133.134 , port 5061
>>> ACK out to media server over UDP
>>> Feb  3 21:20:23 testproxy /usr/sbin/opensips[24673]:
>>> DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5060
>>> Feb  3 21:20:23 testproxy /usr/sbin/opensips[24673]:
>>> DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5080
>>>
>>> Everything routes properly, but it isn't reported by siptrace properly.
>>> Is this a bug or am I doing something wrong?
>>> - Jeff
>>>
>>> _______________________________________________
>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>> _______________________________________________
>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>> _______________________________________________ Users mailing list
>> Users at lists.opensips.org http://lists.opensips.org/cgi-
>> bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20170210/63e9aca7/attachment-0001.html>