[SR-Users] Wrong Record-Route and Via header fields when TCP is used
Daniel-Constantin Mierla
miconda at gmail.com
Wed Aug 14 15:11:17 CEST 2019
Hello,
I tried to reproduce a while ago on a system with many network
interfaces, but all was fine. I guess it has to do with network/ip
routing configuration there.
Open the issue, maybe other people will give some input based on their
experience.
Cheers,
Daniel
On 14.08.19 13:37, Leonid Fainshtein wrote:
> Hello Daniel,
> Should I open a bug regarding this issue?
>
> Thank you,
> Leonid
>
> On Sun, Jul 21, 2019 at 1:26 PM Leonid Fainshtein
> <leonid.fainshtein at xorcom.com <mailto:leonid.fainshtein at xorcom.com>>
> wrote:
>
> 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 <http://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 <http://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 <http://10.28.80.0/24> dev lxdbr0 proto kernel scope
> link src 10.28.80.1
> 192.168.0.0/20 <http://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 <mailto: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
> <mailto: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 <mailto: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
> <mailto: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
> <mailto: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
> <http://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 <http://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
> <http://10.28.80.1:5060>
> listen=tcp:10.28.80.1:5060
> <http://10.28.80.1:5060>
> listen=udp:192.168.9.103:5060
> <http://192.168.9.103:5060>
> listen=tcp:192.168.9.103:5060
> <http://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 <mailto: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
> <mailto: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 <http://10.159.65.0/24>
> dev lxdbr0 proto kernel scope link src 10.159.65.1
> > >>> 172.200.4.0/24 <http://172.200.4.0/24>
> dev eno1 proto kernel scope link src 172.200.4.1
> > >>> 192.168.0.0/20 <http://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
> <mailto: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
> <http://sip:2000@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
> <http://sip:2005@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
> <mailto:sr-users at lists.kamailio.org>
> > >>>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> > >> --
> > >> Daniel-Constantin Mierla --
> www.asipto.com <http://www.asipto.com>
> > >> www.twitter.com/miconda
> <http://www.twitter.com/miconda> --
> www.linkedin.com/in/miconda
> <http://www.linkedin.com/in/miconda>
> > >>
> > --
> > Daniel-Constantin Mierla -- www.asipto.com
> <http://www.asipto.com>
> > www.twitter.com/miconda
> <http://www.twitter.com/miconda> --
> www.linkedin.com/in/miconda
> <http://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
>
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20190814/d6ed9321/attachment.html>
More information about the sr-users
mailing list