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