[SR-Users] Wrong Record-Route and Via header fields when TCP is used

Leonid Fainshtein leonid.fainshtein at xorcom.com
Sun Jul 21 12:26:05 CEST 2019 

Hello Daniel,
The traces and the simplified config file can be downloaded by using the
link below:

http://updates.xorcom.com/~xorcom/2019-jul-21.tar.gz

Regarding to an IP route from the local IP appearing in Record-Route to the
target IP. I don't have a special route for it. But the net.ipv4.ip_forward
is enabled in the system.
Anyway, I'm sending you IP addresses and the current routing table:

# ip a
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state
UP group default qlen 1000
    link/ether 00:0c:29:ad:af:e9 brd ff:ff:ff:ff:ff:ff
    inet 192.168.9.103/20 brd 192.168.15.255 scope global dynamic ens32
       valid_lft 116999sec preferred_lft 116999sec
    inet6 fe80::20c:29ff:fead:afe9/64 scope link
       valid_lft forever preferred_lft forever
3: lxdbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
UP group default qlen 1000
    link/ether fe:d8:26:e7:21:dc brd ff:ff:ff:ff:ff:ff
    inet 10.28.80.1/24 scope global lxdbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::501d:dbff:fe72:876e/64 scope link
       valid_lft forever preferred_lft forever
5: vethHT3VX5 at if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
master lxdbr0 state UP group default qlen 1000
    link/ether fe:d8:26:e7:21:dc brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::fcd8:26ff:fee7:21dc/64 scope link
       valid_lft forever preferred_lft forever

# ip r
default via 192.168.0.1 dev ens32 proto dhcp src 192.168.9.103 metric 100
10.28.80.0/24 dev lxdbr0 proto kernel scope link src 10.28.80.1
192.168.0.0/20 dev ens32 proto kernel scope link src 192.168.9.103
192.168.0.1 dev ens32 proto dhcp scope link src 192.168.9.103 metric 100

Thank you,
Leonid


On Sun, Jul 21, 2019 at 9:35 AM Daniel-Constantin Mierla <miconda at gmail.com>
wrote:

> Can you load debugger module and enable cfgtrace to see the actions
> executed in config file for such INVITE - reproduce and send the log
> messages. Might be an effect of something done there.
>
> Did I asked if you have IP route from the local IP appearing in
> Record-Route to the target IP address? Kamailio has the rule of trying to
> reuse first the local ip where the request was received also for sending
> out.
>
> On Thu, Jul 18, 2019 at 2:09 PM Leonid Fainshtein <
> leonid.fainshtein at xorcom.com> wrote:
>
>> Yes, I have.
>>
>> Best regards,
>> Leonid Fainshtein
>> Xorcom Ltd
>>
>>
>> On Thu, Jul 18, 2019 at 9:31 AM Daniel-Constantin Mierla <
>> miconda at gmail.com> wrote:
>>
>>> Hello,
>>> traveling, so not much time available ...
>>> I looked over the logs when expected socket is not used, I couldn't spot
>>> any message about selecting the socket, so there is a route from them
>>> "wrong" socket to the destination.
>>>
>>> Do you have "mhomed=1" in kamailio.cfg?
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On Wed, Jul 17, 2019 at 5:27 PM Leonid Fainshtein <
>>> leonid.fainshtein at xorcom.com> wrote:
>>>
>>>> Dear Daniel,
>>>> Did you have a chance to check the traces?
>>>>
>>>> Best regards,
>>>> Leonid
>>>>
>>>> On Wed, Jul 10, 2019 at 9:15 AM Leonid Fainshtein <
>>>> leonid.fainshtein at xorcom.com> wrote:
>>>>
>>>>> Hello Daniel,
>>>>> The requested traces can be downloaded by using the link below:
>>>>>
>>>>> http://updates.xorcom.com/~xorcom/kam-tcp-problem.tar.gz
>>>>>
>>>>> I don't use the force send socket option and doesn't route out via
>>>>> dispatcher in this particular call flow.
>>>>> I found that the problem happens only when the "listen" parameters are
>>>>> defined in the Kamailio configuration.
>>>>> Thus the server where I made the tests have the following IPs
>>>>> configured:
>>>>>
>>>>> 2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
>>>>> state UP group default qlen 1000
>>>>>    link/ether 00:0c:29:ad:af:e9 brd ff:ff:ff:ff:ff:ff
>>>>>    inet 192.168.9.103/20 brd 192.168.15.255 scope global dynamic ens32
>>>>> 3: lxdbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
>>>>> state UP group default qlen 1000
>>>>>    link/ether fe:d8:26:e7:21:dc brd ff:ff:ff:ff:ff:ff
>>>>>    inet 10.28.80.1/24 scope global lxdbr0
>>>>>
>>>>> The request is accepted on 10.28.80.1 and forwarded from 192.168.9.103
>>>>>
>>>>> If I define:
>>>>> listen=udp:10.28.80.1:5060
>>>>> listen=tcp:10.28.80.1:5060
>>>>> listen=udp:192.168.9.103:5060
>>>>> listen=tcp:192.168.9.103:5060
>>>>>
>>>>> Then the problem occurs. Ref. files syslog-bad.log and bad.cap.
>>>>> If I remove all of the 'listen' parameters then the forwarded INVITE
>>>>> request is built properly. Ref. files syslog-good.log and good.cap
>>>>>
>>>>> Best regards,
>>>>> Leonid Fainshtein
>>>>> Xorcom Ltd
>>>>>
>>>>> Best regards,
>>>>> Leonid Fainshtein
>>>>> Xorcom Ltd
>>>>>
>>>>>
>>>>> On Tue, Jul 9, 2019 at 9:53 AM Daniel-Constantin Mierla
>>>>> <miconda at gmail.com> wrote:
>>>>> >
>>>>> > Hello,
>>>>> >
>>>>> > set debug = 3 in kamailio cfg and reproduce this case. Send here all
>>>>> the
>>>>> > log messages printed by kamailio from the moment it receives the
>>>>> request
>>>>> > till it sends it out.
>>>>> >
>>>>> > Some further questions:
>>>>> >
>>>>> >   - do you use any force send socket option?
>>>>> >   - do you route out via dispatcher? If yes, is the socket attribute
>>>>> set?
>>>>> >
>>>>> > Cheers,
>>>>> > Daniel
>>>>> >
>>>>> > On 08.07.19 21:23, Leonid Fainshtein wrote:
>>>>> > > Hello,
>>>>> > > The source address is correct: 192.168.0.31. I see it in tcpdump
>>>>> and
>>>>> > > also in sngrep.
>>>>> > >
>>>>> > > Thank you,
>>>>> > > Leonid
>>>>> > >
>>>>> > > On Mon, Jul 8, 2019 at 9:02 PM Daniel-Constantin Mierla
>>>>> > > <miconda at gmail.com> wrote:
>>>>> > >> Hello,
>>>>> > >>
>>>>> > >> when you look at the network traffic 9e.g., with ngrep, sngrep,
>>>>> ...)
>>>>> > >> what is shown as source address for outbound leg?
>>>>> > >>
>>>>> > >> Cheers,
>>>>> > >> Daniel
>>>>> > >>
>>>>> > >> On 08.07.19 19:21, Leonid Fainshtein wrote:
>>>>> > >>> I just found Daniel's response to a similar question (ref.:
>>>>> > >>>
>>>>> https://lists.kamailio.org/pipermail/sr-users/2019-February/104853.html
>>>>> ):
>>>>> > >>>
>>>>> > >>> "check the routing rules/table of the operating systems, there
>>>>> should be
>>>>> > >>> some differences between the two servers.
>>>>> > >>> If you mhomed=1 and an unexpected interface is used for routing
>>>>> out the
>>>>> > >>> traffic, it means that the operating system has internal routing
>>>>> rules that
>>>>> > >>> allow going from that interface to the target address."
>>>>> > >>>
>>>>> > >>> Don't see anything suspicious in my server routing table:
>>>>> > >>>
>>>>> > >>> default via 192.168.0.1 dev eno1 proto static
>>>>> > >>> 10.159.65.0/24 dev lxdbr0 proto kernel scope link src
>>>>> 10.159.65.1
>>>>> > >>> 172.200.4.0/24 dev eno1 proto kernel scope link src 172.200.4.1
>>>>> > >>> 192.168.0.0/20 dev eno1 proto kernel scope link src 192.168.0.31
>>>>> > >>>
>>>>> > >>> The request is received on the lxdbr0 interface (10.159.65.1)
>>>>> and sent
>>>>> > >>> out from the eno1 interface (192.168.0.31).
>>>>> > >>> I even tried to delete the default route but nothing helped. The
>>>>> > >>> request is sent out with 10.159.65.1 in the via and Record-Route
>>>>> > >>> fields...
>>>>> > >>>
>>>>> > >>> Best regards,
>>>>> > >>> Leonid
>>>>> > >>>
>>>>> > >>> On Thu, Jul 4, 2019 at 6:20 PM Leonid Fainshtein
>>>>> > >>> <leonid.fainshtein at xorcom.com> wrote:
>>>>> > >>>> Hi,
>>>>> > >>>> Kamailio server has two legs that are connected to different
>>>>> networks.
>>>>> > >>>> I'm using Kamailio v.5.2.3 and the "enable_double_rr" is
>>>>> implicitly set to "1".
>>>>> > >>>> The leg "A" IP address is 10.159.65.1
>>>>> > >>>> The leg "B" IP address is 192.168.0.31
>>>>> > >>>> The call is initiated from 10.159.65.18
>>>>> > >>>>
>>>>> > >>>> According to the "rr" module documentation, function
>>>>> record_route()
>>>>> > >>>> should insert two "Record_Route" header fields when a request is
>>>>> > >>>> accepted on one leg is should go out via the second leg. This
>>>>> works as
>>>>> > >>>> expected in case of UDP protocol:
>>>>> > >>>>
>>>>> > >>>> INVITE sip:2000 at 192.168.6.106:5460;transport=UDP SIP/2.0
>>>>> > >>>> Record-Route: <sip:192.168.0.31;r2=on;lr;did=e2c.a191>
>>>>> > >>>> Record-Route: <sip:10.159.65.1;r2=on;lr;did=e2c.a191>
>>>>> > >>>> Via: SIP/2.0/UDP
>>>>> > >>>>
>>>>> 192.168.0.31;branch=z9hG4bKcfa5.d64ecbd87d5315b5993c4ccf16f86537.0
>>>>> > >>>> Via: SIP/2.0/UDP 10.159.65.18:5060
>>>>> ;rport=5060;branch=z9hG4bK3a9e9a4d
>>>>> > >>>>
>>>>> > >>>> But when the TCP protocol is used then the outbound message
>>>>> looks like this:
>>>>> > >>>>
>>>>> > >>>> INVITE sip:2005 at 192.168.0.178:35058;transport=tcp SIP/2.0
>>>>> > >>>> Record-Route: <sip:10.159.65.1;transport=tcp;lr;did=bb6.7dc1>
>>>>> > >>>> Via: SIP/2.0/TCP
>>>>> > >>>>
>>>>> 10.159.65.1;branch=z9hG4bKc85a.14afc3867dd3220826f9b9940f78168f.0;i=3
>>>>> > >>>> Via: SIP/2.0/TCP 10.159.65.18:5060
>>>>> ;rport=58616;branch=z9hG4bK1469331f
>>>>> > >>>>
>>>>> > >>>> There are two problems there:
>>>>> > >>>> a) only one Record-Route with leg is inserted
>>>>> > >>>> b) the added "Via" header field contains the leg "A" IP address
>>>>> > >>>> instead of expected leg "B" IP address (192.168.0.31). In the
>>>>> LAN
>>>>> > >>>> trace I see that in reality the message was sent from leg "B".
>>>>> > >>>>
>>>>> > >>>> Is it a bug?
>>>>> > >>>>
>>>>> > >>>> Best regards,
>>>>> > >>>> Leonid Fainshtein
>>>>> > >>> _______________________________________________
>>>>> > >>> Kamailio (SER) - Users Mailing List
>>>>> > >>> sr-users at lists.kamailio.org
>>>>> > >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>> > >> --
>>>>> > >> Daniel-Constantin Mierla -- www.asipto.com
>>>>> > >> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>>>>> > >>
>>>>> > --
>>>>> > Daniel-Constantin Mierla -- www.asipto.com
>>>>> > www.twitter.com/miconda -- www.linkedin.com/in/miconda
>>>>> >
>>>>>
>>>>
>>>
>>> --
>>> Daniel-Constantin Mierla - http://www.asipto.com
>>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>>
>>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.com
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20190721/f08c282f/attachment.html>

More information about the sr-users mailing list