Hi Daniel,

The location was always wrong, but it wasn't noticed because it doesn't cause calls to fail straight away. It's only after a while that encryption stops working. This can be verified by watching to see if the values in /proc/rtpengine/0/list change, or do not change which indicates the kernel module isn't receiving packets.

Step 2 should be solved by a reboot, yes.



On Mon, 7 Jan 2019 at 21:15, Daniel-Constantin Mierla <miconda@gmail.com> wrote:

Hello,

thanks for sharing, very useful to know.

Was the wrong location of the iptables module a result of ugrading some packages (like kernel or iptables)? I assume the initial installation deploys the module in the right location. Asking to see if one needs to do a re-install of the rtpengine after kernel or other specific updates.

Can step 2 be solved by a reboot of the server?

Cheers,
Daniel

On 07.01.19 02:42, David Cunningham wrote:
Hello all,

We solved this issue with the help of Richard Fuchs. There were two issues:

1. The iptables module was in the wrong location and thus wasn't loaded. The daemon thought that the kernel was handling packets and took the ROC updates from it, but didn't actually see any packets and so the ROC reset, resulting in decryption errors. The correct location can be found with "pkg-config xtables --variable=xtlibdir".

2. Even after fixing the above, the iptables module didn't load properly until rtpengine was stopped, the iptables rules removed, the kernel module unloaded, and then this process reversed to load everything again.

I hope this helps someone else in the future.


On Wed, 12 Dec 2018 at 11:05, David Cunningham <dcunningham@voisonics.com> wrote:
Hello,

We're having an issue with rtpengine (used by Kamailio) where audio works initially, but then after an apparently random amount of time stop working. We see that when audio stops working rtpengine logs this:

Dec 10 09:58:57 hostname rtpengine[376]: WARNING: [Pl1SeGDssOsDNWQdvey4lg.. port 48766]: Discarded invalid SRTP packet: authentication failed

It then logs similar messages until the call hangs up. No such messages were logged while audio was working.

Searching for this error message suggests that a change in the SSRC can cause the problem, but we don't see any such change in the PCAP. The source IP, port, codec, and SSRC all stay the same, and the Sequence increments as normal.

Does anyone have suggestions on where to look next? We can share the PCAP privately if that would help anyone.

Thanks for any advice!

--
David Cunningham, Voisonics Limited
http://voisonics.com/
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782


--
David Cunningham, Voisonics Limited
http://voisonics.com/
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782

_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in Washington, DC, USA -- www.asipto.com


--
David Cunningham, Voisonics Limited
http://voisonics.com/
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782