[CentOS] Centos 7: UPD packet checksum verification?

Tue Jan 28 20:39:19 UTC 2020
hw <hw at gc-24.de>

On Tuesday, January 28, 2020 9:00:22 AM CET Nataraj wrote:
> On 1/26/20 5:44 PM, hw wrote:
> > On Sunday, January 26, 2020 11:18:36 PM CET Pete Biggs wrote:
> >> First of all - disclaimer - I'm no network specialist, I just read and
> >> am interested in it.  I may get things wrong!!
> >> 
> >>> Both physical interfaces show the same.  But does this mean it's on as
> >>> in
> >>> "rx- checksumming: on" or off as in "tx-checksum-ipv4: off [fixed]"?
> >> 
> >> As far as I understand it rx-checksum is the underlying wire
> >> checksumming - and from what I've read about it, disabling that
> >> disables the UDP checksums.
> > 
> > You mean layer 1 checksumming?  Is there such a thing with ethernet?  I
> > think I read something about encoding, when I was trying to understand
> > what "bandwidth" actually means, being involved in signal transmissions;
> > and I seem to remember that there was no checksumming involved and it had
> > to do with identifying signals as a requirement for the very possibility
> > to transmit something before anything could be transmitted at all.
> > 
> >>> Assuming that I do not receive packets with invalid UPD checksums, then
> >>> the
> >>> packages must be somehow altered and their UPD checksums recalculated to
> >>> arrive here.  Does bad hardware etc. do that?  Why would the UDP
> >>> checksums
> >>> just happen to get recalculated correctly but like randomly without
> >>> intent?
> >> 
> >> I'm not sure I understand what you are asking.
> > 
> > It is about VOIP calls via SRTP being interrupted at irregular intervals. 
> > The intervals appear to depend on the time of day:  Such phone calls can
> > last for a duration of about 5--25 minutes during the day to up to 1.5
> > hours at around 3am before being interrupted.
> 
> My sense is you may be starting at too low of a level in trying to debug
> this.

One of the reasons I have to look into it is that it is usually good to know 
more/better.

> I have seen the same kind of problems with my voip service when
> there is a problem with my Internet connection.  When this happens I
> also see high retransmission rates for tcp connections and other signs
> of network problem.

How do you monitor such retransmissions to be able to see if and when they 
occur?

> If I check the modem for my Internet connection
> there are issues with the signal levels and high error rates reported by
> the modem.  If you believe your Internet connection is reliable, then if
> you run managed switches, check your switch logs for any reported errors.
> 
> You could try tools like iperf to check for problems on your internal
> network.  You could run some of the basic tools for testing voip
> performance of your Inetnet connection and if necessary run iperf to a
> cloud hosted system.

Can you suggest useful tools to analyze VOIP performance, and how do you 
define VOIP performance?

The performance is kinda acceptable as long as the calls are not interrupted.  
It's still worlds apart from what it used to be 25 years ago, before VOIP was 
used.  Back then, you never had to worry that calls could be interrupted or 
that you couldn't hear someone or that you couldn't have a conversation 
because the latency makes it impossible.  You could just talk to someone on a 
phone, like it should be.  Nowadays, we get to pay 10 times as much and more, 
plus all the expensive hardware, and it still doesn't work right and doesn't 
even come close.

> I think it is highly unlikely that you are only having issues with srtp
> packets and I would look at the broader picture first to try to isolate
> some other problem in your network or Internet connection.

See it this way: It is highly likely that I don't have any issues with SRTP at 
all.  Calls over the LAN work fine.  The only issue is with the VOIP provider.  
What I have learned about SRTP so far tells me that, like everything else 
does.

How would you explain that the same problem occurs at two entirely unrelated 
physical locations each having their own asterisk installations, using 
entirely different hardware and entirely different internet connections from 
entirely different ISPs, with the only thing in common being the VOIP 
provider?

If it was only my internet connection which is affected, I'd be talking to my 
ISP (probably useless) instead of the VOIP provider (who will probably do 
something about it).