asterisk users - Jun 2020 - Voice broken during calls (again...)

Am 23.06.2020 09:28, schrieb Marek Greško:

Hi
> if you need clampmss then it is highly probable there is a PMTU
> discovery problem. The clampmss does not work for UDP.
Is there a way to check if I have this problem?
> I probably counted the size incorrectly. So you are able to ping with
> size 1464 and not with 1466. How about trying same ping sizes from the
> internet towards your site? I mean trying to ping from sites with
> higher MTU than yours without lower MTU links in the path.
lucabert at ns:~$ ping -4 -M  do -s 1465 bpi.d.lucabert.com
PING bpi.d.lucabert.com (93.241.91.232) 1465(1493) bytes of data.
 From 62.156.246.57 (62.156.246.57) icmp_seq=1 Frag needed and DF set 
(mtu = 1492)
ping: local error: Message too long, mtu=1492
ping: local error: Message too long, mtu=1492
ping: local error: Message too long, mtu=1492
^C
--- bpi.d.lucabert.com ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 
3965ms
pipe 2

With paket size of 1464 it works...
> You know MTU is a size of l2 frame, so using ipv6 you are able to use
> higher payload sizes because of ip header size.
OK, thanks!
Luca Bertoncello
(lucabert at lucabert.de)

Hello,

this is a correct response:
>From 62.156.246.57 (62.156.246.57) icmp_seq=1 Frag needed and DF set
(mtu = 1492)

So PMTU discovery is working. No problem here. You got correct message
to lower the packet size from 62.156.246.57. This is probably the last
hop before your site.

Marek



2020-06-23 9:40 GMT+02:00, Luca Bertoncello <lucabert at
lucabert.de>:
> Am 23.06.2020 09:28, schrieb Marek Greško:
>
> Hi
>
>> if you need clampmss then it is highly probable there is a PMTU
>> discovery problem. The clampmss does not work for UDP.
>
> Is there a way to check if I have this problem?
>
>> I probably counted the size incorrectly. So you are able to ping with
>> size 1464 and not with 1466. How about trying same ping sizes from the
>> internet towards your site? I mean trying to ping from sites with
>> higher MTU than yours without lower MTU links in the path.
>
> lucabert at ns:~$ ping -4 -M  do -s 1465 bpi.d.lucabert.com
> PING bpi.d.lucabert.com (93.241.91.232) 1465(1493) bytes of data.
>  From 62.156.246.57 (62.156.246.57) icmp_seq=1 Frag needed and DF set
> (mtu = 1492)
> ping: local error: Message too long, mtu=1492
> ping: local error: Message too long, mtu=1492
> ping: local error: Message too long, mtu=1492
> ^C
> --- bpi.d.lucabert.com ping statistics ---
> 4 packets transmitted, 0 received, +4 errors, 100% packet loss, time
> 3965ms
> pipe 2
>
> With paket size of 1464 it works...
>
>> You know MTU is a size of l2 frame, so using ipv6 you are able to use
>> higher payload sizes because of ip header size.
>
> OK, thanks!
> Luca Bertoncello
> (lucabert at lucabert.de)
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
>       https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users

Am 23.06.2020 10:07, schrieb Marek Greško:

Hi
> this is a correct response:
> 
> From 62.156.246.57 (62.156.246.57) icmp_seq=1 Frag needed and DF set
> (mtu = 1492)
> 
> So PMTU discovery is working. No problem here. You got correct message
> to lower the packet size from 62.156.246.57. This is probably the last
> hop before your site.
No, the last hop is 62.156.246.65:

lucabert at ns:~$ mtr -4nr bpi.d.lucabert.com
Start: Tue Jun 23 10:10:16 2020
HOST: ns.lucabert.de              Loss%   Snt   Last   Avg  Best  Wrst 
StDev
   1.|-- 185.242.112.1              0.0%    10    0.4   1.1   0.3   4.4   
1.2
   2.|-- 84.200.230.82              0.0%    10    0.8   0.7   0.5   0.8   
0.0
   3.|-- 87.190.233.113             0.0%    10    1.6   1.7   1.4   2.5   
0.0
   4.|-- 217.5.82.94                0.0%    10    7.9   7.6   7.4   7.9   
0.0
   5.|-- 217.5.82.94                0.0%    10    7.7   7.5   7.2   7.7   
0.0
   6.|-- 62.156.246.49              0.0%    10    7.4   7.4   7.3   7.4   
0.0
   7.|-- 62.156.246.65              0.0%    10    7.6   7.6   7.4   7.8   
0.0
   8.|-- 93.241.91.232              0.0%    10   21.4  21.9  21.4  24.3   
0.7

Don't know where this 62.156.246.57 comes... :(

Everyway: you think, my network works as expected? At least the part 
using DSL?
Any idea, where could be the problem?

Thanks a lot
Luca Bertoncello
(lucabert at lucabert.de)