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
