<div dir="auto">Well, beware TCP is second-class citizen in the SIP land, for the very same reasons HTTP is moving away from it in HTTP3/QUIC.<div dir="auto"><br></div><div dir="auto">-Max</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed., May 20, 2020, 10:52 p.m. Olle Frimanson, <<a href="mailto:olle@zaark.com">olle@zaark.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for the tips will give it a try to see what happens, but I guess TCP is the solution.<br>
<br>
Br Olle <br>
<br>
Skickat från min iPhone<br>
<br>
> 21 maj 2020 kl. 07:41 skrev junkmail <<a href="mailto:junkmail@djrance.com" target="_blank" rel="noreferrer">junkmail@djrance.com</a>>:<br>
> <br>
> Yea that is it.<br>
> <br>
> so if you are doing something like tcpdump udp port 5060 or udp port 5080 etc. you would have to change it to the specific host IP that you are testing with.<br>
> <br>
> so more like tcpdump host 10.1.1.1 or something like that to make sure that you see all the traffic. Or I am sure there is a way to tell TCPdump to capture fragments but I am a bit too lazy to look it up. But that was why I was not seeing the fragments.<br>
> <br>
> <br>
> <br>
> 20.05.2020 15:46 に Maxim Sobolev さんは書きました:<br>
>> Olle, this is what he has been warning you about. See, the<br>
>> fragmentation is done at IP level, so that if your UDP packet gets<br>
>> fragmented, only the first fragment is going to contain a UDP header<br>
>> with a port number. Therefore, if you are using a port number(s) as a<br>
>> capture filter with your tcpdump then you won't see those subsequent<br>
>> fragment(s). You should be using IP with destination address as a<br>
>> filter for example and not UDP with a port number(s). Or combine udp<br>
>> rule with rule that would only match IP fragment(s).<br>
>> -Max<br>
>>> On Wed, May 20, 2020 at 12:57 PM Olle Frimanson <<a href="mailto:olle@zaark.com" target="_blank" rel="noreferrer">olle@zaark.com</a>><br>
>>> wrote:<br>
>>> Hi thanks for the tip, how dit you find it? I just capture 3 ports<br>
>>> in my tcpdump.<br>
>>> Br Olle<br>
>>> Skickat från min iPhone<br>
>>>> 20 maj 2020 kl. 19:18 skrev junkmail <<a href="mailto:junkmail@djrance.com" target="_blank" rel="noreferrer">junkmail@djrance.com</a>>:<br>
>>>> Sorry that is what I was trying to let you know. Is that I had<br>
>>> thought the same thing that the Fragment was not even sent, but it<br>
>>> was just because of the tcpdump filter I had not that it actually<br>
>>> wasn't being sent. If you have not try capturing all IP traffic to<br>
>>> a host IP and see if you see it.<br>
>>>> 20.05.2020 11:11 に Olle Frimanson さんは書きました:<br>
>>>>> Hi the issue on my side is that it’s not the network that is<br>
>>> the<br>
>>>>> problem the second fragment is not even sent. I also kind on lean<br>
>>> to<br>
>>>>> TCP at the moment but it would be good to get a comment from<br>
>>> Opensips<br>
>>>>> team on this if and how they setup the sockets and if there is a<br>
>>>>> difference on different routes<br>
>>>>> Br Olle<br>
>>>>> Skickat från min iPhone<br>
>>>>>>> 20 maj 2020 kl. 17:14 skrev junkmail <<a href="mailto:junkmail@djrance.com" target="_blank" rel="noreferrer">junkmail@djrance.com</a>>:<br>
>>>>>> Hello, I had run into the same issue. One thing I was a bit<br>
>>> mistaken because I was using tcpdump and doing a capture filter of<br>
>>> port 5060 or the such. So I was missing the Fragment in my sniff as<br>
>>> it does not include the UDP header. Just something to be aware of.<br>
>>> But I was having problems specifically traffic inside of GCP <<br>
>>> google cloud. As well as traffic traversing the VPN to GCP. I am<br>
>>> not certain about what changed for internal to GCP but that started<br>
>>> working and now the only thing using TCP is over VPNs. Sorry not a<br>
>>> lot of information here. but my best guess is either the<br>
>>> firewall/router on my side or Googles is dropping the UDP fragment.<br>
>>> I didn't dig into it much further as TCP fixed the issue and this<br>
>>> was just a transit between opensisps systems.<br>
>>>>>> 19.05.2020 01:21 に <a href="mailto:olle@zaark.com" target="_blank" rel="noreferrer">olle@zaark.com</a> さんは書きました:<br>
>>>>>>> Hi, this happens one single opensips instance server it<br>
>>> receives the<br>
>>>>>>> inbound packet fine, then when its send out on the same<br>
>>> interface<br>
>>>>>>> it’s fragmented, so I don’t think it’s network or router<br>
>>> switch<br>
>>>>>>> related. Have seen such problems in the past in virtual<br>
>>> environments<br>
>>>>>>> but this is not the case now.<br>
>>>>>>> My prime suspect is Centos since it send out the first part of<br>
>>> the<br>
>>>>>>> fragmented packet but not the following part that would<br>
>>> complete the<br>
>>>>>>> packet.<br>
>>>>>>> But indeed it is a strange bug, since it does not always<br>
>>> happen.<br>
>>>>>>> BR/Olle<br>
>>>>>>> FRÅN: Users <<a href="mailto:users-bounces@lists.opensips.org" target="_blank" rel="noreferrer">users-bounces@lists.opensips.org</a>> FÖR Giovanni<br>
>>>>>>> Maruzzelli<br>
>>>>>>> SKICKAT: den 19 maj 2020 09:13<br>
>>>>>>> TILL: OpenSIPS users mailling list <<a href="mailto:users@lists.opensips.org" target="_blank" rel="noreferrer">users@lists.opensips.org</a>><br>
>>>>>>> ÄMNE: Re: [OpenSIPS-Users] UDP fragmentation in reply routes<br>
>>>>>>> Can be a problem of the virtual env, and/or the<br>
>>> router/switch...<br>
>>>>>>> Try substitute real hardware to virtual, and different models<br>
>>> of<br>
>>>>>>> router/switch<br>
>>>>>>> In a LAN, UDP fragmentation is not supposed to be a problem at<br>
>>> all...<br>
>>>>>>> answered from mobile, please pardon terseness and typos,<br>
>>>>>>> -giovanni<br>
>>>>>>>> On Tue, May 19, 2020, 08:05 <<a href="mailto:olle@zaark.com" target="_blank" rel="noreferrer">olle@zaark.com</a>> wrote:<br>
>>>>>>>> Thanks for the reply Max,<br>
>>>>>>>> we are doing all we can to make the packets smaller, but<br>
>>> before we<br>
>>>>>>>> move over to TCP, which is most likely our next step, I wanted<br>
>>> to<br>
>>>>>>>> explore what could be happening.<br>
>>>>>>>> AFAIK the application have some control of this since these<br>
>>> are<br>
>>>>>>>> parameters that partly can be set when you open a socket,<br>
>>> that’s<br>
>>>>>>>> why I wonders if Opensips might use those parameters or not,<br>
>>>>>>>> especially since we have so very different behaviour in<br>
>>> different<br>
>>>>>>>> directions.<br>
>>>>>>>> BR/Olle<br>
>>>>>>>> FRÅN: Users <<a href="mailto:users-bounces@lists.opensips.org" target="_blank" rel="noreferrer">users-bounces@lists.opensips.org</a>> FÖR Maxim<br>
>>> Sobolev<br>
>>>>>>>> SKICKAT: den 18 maj 2020 22:03<br>
>>>>>>>> TILL: OpenSIPS users mailling list <<a href="mailto:Users@lists.opensips.org" target="_blank" rel="noreferrer">Users@lists.opensips.org</a>><br>
>>>>>>>> ÄMNE: Re: [OpenSIPS-Users] UDP fragmentation in reply routes<br>
>>>>>>>> Smells like a OS/kernel bug to me. There is little application<br>
>>> can<br>
>>>>>>>> do in that regard, UDP fragmentation/reassembly happens at<br>
>>> much<br>
>>>>>>>> lower layers of the OSI stack.<br>
>>>>>>>> However, as a workaround as long as SIP goes you can try to<br>
>>> reduce<br>
>>>>>>>> your SIP signalling packet size by using compact version of<br>
>>> SIP<br>
>>>>>>>> headers, as well as dropping headers that are not used. That<br>
>>> would<br>
>>>>>>>> save you 100-150 bytes per SIP message perhaps. I don't know<br>
>>> if<br>
>>>>>>>> OpenSIP can do that in the proxy mode out of the box though,<br>
>>> so you<br>
>>>>>>>> might want to add b2b into the flow.<br>
>>>>>>>> -Max<br>
>>>>>>>> On Mon., May 18, 2020, 12:34 p.m. Olle Frimanson,<br>
>>> <<a href="mailto:olle@zaark.com" target="_blank" rel="noreferrer">olle@zaark.com</a>><br>
>>>>>>>> wrote:<br>
>>>>>>>>> Hi,<br>
>>>>>>>>> We have an issue on our home proxy (opensips 2.4.6), when it<br>
>>>>>>>>> receives 200 OK (over UDP) from our Freeswitch and the<br>
>>> package<br>
>>>>>>>>> size is higher than the MTU size , we sometimes get<br>
>>> fragmentation<br>
>>>>>>>>> of the UDP packets, but only the first part of the fragmented<br>
>>>>>>>>> package is sent to our edge proxy. Is this a known issue or<br>
>>> is it<br>
>>>>>>>>> a OS bug?<br>
>>>>>>>>> We have not yet spotted any pattern on this and in most cases<br>
>>>>>>>>> bigger packets with MTU around 1600 bytes gets through<br>
>>> without an<br>
>>>>>>>>> issue.<br>
>>>>>>>>> I can add that in the other direction in the normal request<br>
>>> routes<br>
>>>>>>>>> we don’t have any issue at all can have packets > 2000<br>
>>> bytes<br>
>>>>>>>>> without any issues.<br>
>>>>>>>>> Does Opensips use IP_MTU_DISCOVER or how is fragmentation<br>
>>>>>>>>> controlled and is it expected to have different behavior in<br>
>>> reply<br>
>>>>>>>>> routes vs other routes?<br>
>>>>>>>>> We use Centos 7 in a virtual server environment.<br>
>>>>>>>>> I was hoping someone can share some light on this strange<br>
>>> issue.<br>
>>>>>>>>> BR/Olle<br>
>>>>>>>>> _______________________________________________<br>
>>>>>>>>> Users mailing list<br>
>>>>>>>>> <a href="mailto:Users@lists.opensips.org" target="_blank" rel="noreferrer">Users@lists.opensips.org</a><br>
>>>>>>>>> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
>>>>>>>> _______________________________________________<br>
>>>>>>>> Users mailing list<br>
>>>>>>>> <a href="mailto:Users@lists.opensips.org" target="_blank" rel="noreferrer">Users@lists.opensips.org</a><br>
>>>>>>>> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
>>>>>>> _______________________________________________<br>
>>>>>>> Users mailing list<br>
>>>>>>> <a href="mailto:Users@lists.opensips.org" target="_blank" rel="noreferrer">Users@lists.opensips.org</a><br>
>>>>>>> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
>>>>>> _______________________________________________<br>
>>>>>> Users mailing list<br>
>>>>>> <a href="mailto:Users@lists.opensips.org" target="_blank" rel="noreferrer">Users@lists.opensips.org</a><br>
>>>>>> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
>>>>> _______________________________________________<br>
>>>>> Users mailing list<br>
>>>>> <a href="mailto:Users@lists.opensips.org" target="_blank" rel="noreferrer">Users@lists.opensips.org</a><br>
>>>>> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
>>> _______________________________________________<br>
>>> Users mailing list<br>
>>> <a href="mailto:Users@lists.opensips.org" target="_blank" rel="noreferrer">Users@lists.opensips.org</a><br>
>>> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
> <br>
> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@lists.opensips.org" target="_blank" rel="noreferrer">Users@lists.opensips.org</a><br>
> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</blockquote></div>