[OpenSIPS-Users] siptrace picks incorrect source socket
Bogdan-Andrei Iancu
bogdan at opensips.org
Mon Feb 13 10:08:58 EST 2017
Hi Jeff,
Somehow it's very difficult to accept your report, as both IPv4 and IPv6
are handled (in terms of reporting) exactly in the same way. Are the
logs from "pipport2su" showing the same IPs too ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 02/10/2017 04:29 PM, Jeff Pyle wrote:
> 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 <mailto: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 Developer
> http://www.opensips-solutions.com <http://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 <http://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
>> <http://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 <mailto: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:
>>>
>>> 223loadmodule "siptrace.so"
>>> 224modparam("siptrace", "trace_on", 1)
>>> 225modparam("siptrace", "trace_id",
>>> "[tid]uri=hep:127.0.0.1:9060
>>> <http://127.0.0.1:9060>;version=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 <mailto: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/b30af734cdb84991e1f906e3920a94e87c33ea04
>>> <https://github.com/OpenSIPS/opensips/commit/b30af734cdb84991e1f906e3920a94e87c33ea04>
>>> If you confirm the fix, I will do the backporting to 2.2
>>> too. Thanks and Regards,
>>>
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developer
>>> http://www.opensips-solutions.com
>>> <http://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
>>>> <http://131.132.133.134:5060>
>>>> listen=tls:131.132.133.134:5061
>>>> <http://131.132.133.134:5061>
>>>> listen=hep_udp:127.0.0.1:9030 <http://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
>>>> <http://127.0.0.1:9060>;transport=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 list
>>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>> <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>> <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>> _______________________________________________ Users mailing
>> list Users at lists.opensips.org
>> <mailto:Users at lists.opensips.org>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20170213/32f71a2d/attachment-0001.html>
More information about the Users
mailing list