Freepbx Voip no longer works after upgrade

MPenzi · November 27, 2023, 3:54pm

Hello,
I use OpenWrt 23.05.0 on a Linksys WRT1900ACS. Until today I still had an earlier version of OPenWRT installed. In addition, I connected a FreePBX on a Raspberry Pi directly to the router as a telephone system. So far I've been able to make phone calls just fine. Since the upgrade this no longer works. When I go out, I hear the announcements from my FreePBX and when I come in, I hear the Telekom announcement that it is not available.

I also had kmod-nf-nathelper-extra with the upgrade
opkg install kmod-nf-nathelper-extra
Installed.
The necessary modules are loaded

lsmod | grep nf_conntrack_sip
nf_conntrack           77824 22 nft_redir,nft_nat,nft_masq,nft_flow_offload,nft_ct,nf_nat_tftp,nf_nat_snmp_basic,nf_nat_sip,nf_nat_pptp,nf_nat_irc,nf_nat_h323,nf_nat_amanda,n f_nat,nf_flow_table,nf_conntrack_
tftp,nf_conntrack_snmp,nf_conntrack_sip,nf_conntrack_pptp,nf_conntrack_irc,nf_conntrack_h323,nf_conntrack_broadcast,nf_conntrack_amanda
nf_conntrack_sip 24576  3 nf_nat_sip

and

lsmod | grep nf_nat_sip
nf_conntrack           77824 22 nft_redir,nft_nat,nft_masq,nft_flow_offload,nft_ct,nf_nat_tftp,nf_nat_snmp_basic,nf_nat_sip,nf_nat_pptp,nf_nat_irc,nf_nat_h323,nf_nat_amanda,n f_nat,nf_flow_table,nf_conntrack_
tftp,nf_conntrack_snmp,nf_conntrack_sip,nf_conntrack_pptp,nf_conntrack_irc,nf_conntrack_h323,nf_conntrack_broadcast,nf_conntrack_amanda
nf_conntrack_sip       24576  3 nf_nat_sip
nf_nat                 32768 10 nft_redir,nft_nat,nft_masq,nft_chain_nat,nf_nat_tftp,nf_nat_sip,nf_nat_pptp,nf_nat_irc,nf_nat_h323,nf_nat_amanda
nf_nat_sip             16384  0

On the Asterisk Cli I see incoming calls
[2023-11-27 16:24:57] ERROR[9058]: pjproject: <?>: sip_inv.c .Error parsing/validating SDP body: Invalid SDP connection line (PJMEDIA_SDP_EINCONN)

The output for outgoing calls is more extensive. But both don't show me what's going wrong.

I haven't changed the firewall rules. That's why I don't understand why SIP obviously no longer works.

Does anyone here know anything about FreePBX and OpenWRT? And above all, where can I log the SIP protocol on OpenWRT so that any problems can be identified?

Greetings
MPenzi

hecatae · November 27, 2023, 4:54pm

what did you upgrade from, do you have sngrep available on both Openwrt and FreePBX?

AndrewZ · November 27, 2023, 5:27pm

Make sure you're not cheating your SIP provider by using SIP ALG and IP address substitution.
If your SIP endpoint is behind NAT - your provider should see this. If they are not capable to work with NATed endpoints - that's a separate story.
Look into your SIP (pjsip) protocol debug, not generic console output.
Use tcpdump on your router to capture SIP and RTP traffic for future analysis.
If you cannot analyse SIP yourself - ask a question in Asterisk forum.
There is nothing to do with FreePBX or OpenWrt yet.

MPenzi · November 28, 2023, 7:35am

From OpenWrt 22.03.0 to OpenWrt 23.05.0. No, sngrep I don't know. But thanks for your advice.

MPenzi · November 28, 2023, 7:38am

Why should I do that? As we already told you, the FreePBX together has worked perfectly so far. The problem only occurs after the upgrade. So I'm definitely not cheating.

Lucky1 · November 28, 2023, 9:41am

only thing I can say is running asterisk on the router
still works fine on v23.05.2

MPenzi · November 28, 2023, 11:26am

Hmm, did you misunderstand something? I'm not talking about Asterisk on OpenWRT. Only traffic coming from the FreeBPX server runs via OpenWRT.

Lucky1 · November 28, 2023, 12:22pm

since freepbx is on top of asterisk at lest the sip traffic is working or through it ok
I'm sure you just have to navigate the normal NAT mitigation's
do you know how your return traffic is coming back from your sip connection ?
is it returning via the out going connection or a return port mapped etc

Lucky1 · November 28, 2023, 12:33pm

anyway
ssh into your raspberry pi
go into asterisk via
asterisk -vvvvvr
you will see the running system and errors
you may have to change the log configuration in free pbx
to show the level of detail you want to see

Lucky1 · November 28, 2023, 12:46pm

oh just as a check make sure your routers MAC address are ok
my linksys ea8500 had the same mac address for lan and wan
this broke tings like ipv6
as a new problem in v23.02.5

MPenzi · November 28, 2023, 3:21pm

That sounds very interesting. As you can see, the WAN interface with "c6:41:1e:33:b4:3b" differs only slightly from the four LAN interfaces. They all have "c4:41:1e:33:b4:3b" and the Raspberry Pi with Asterisk is on lan1@eth0.


ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508 qdisc mq state UP qlen 1024
    link/ether c4:41:1e:33:b4:3b brd ff:ff:ff:ff:ff:ff
3: lan4@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
    link/ether c4:41:1e:33:b4:3b brd ff:ff:ff:ff:ff:ff
4: lan3@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
    link/ether c4:41:1e:33:b4:3b brd ff:ff:ff:ff:ff:ff
5: lan2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether c4:41:1e:33:b4:3b brd ff:ff:ff:ff:ff:ff
6: lan1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether c4:41:1e:33:b4:3b brd ff:ff:ff:ff:ff:ff
7: wan@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether c6:41:1e:33:b4:3b brd ff:ff:ff:ff:ff:ff
10: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether c4:41:1e:33:b4:3b brd ff:ff:ff:ff:ff:ff
11: br-lan.1@br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether c4:41:1e:33:b4:3b brd ff:ff:ff:ff:ff:ff
12: br-lan.2@br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether c4:41:1e:33:b4:3b brd ff:ff:ff:ff:ff:ff
13: phy1-ap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether 00:25:9c:14:9a:09 brd ff:ff:ff:ff:ff:ff
14: phy0-ap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether 00:25:9c:14:9a:0a brd ff:ff:ff:ff:ff:ff
15: pppoe-wan: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN qlen 3
    link/ppp

I don't know if the second digit in the MACs 6 versus 4 makes a difference.

Lucky1 · November 28, 2023, 3:49pm

unusual but ok they are normal 1 digit different the last one
but different is good

Lucky1 · November 28, 2023, 3:53pm

I think that devices mac addresses are broken as well
the wifi addresses are also very different
I would not be surprised if some are random and changing on each boot
I don't think it's your problem tho

MPenzi · November 28, 2023, 3:54pm

I now have means
dd if=/dev/urandom bs=1024 count=1 2>/dev/null | md5sum | sed -e 's/^$..$$..$$..$$..$$..$$..$.*$/\1: \2:\3:\4:\5:\6/' -e 's/^$.$[13579bdf]/\10/'
a new MAC is generated for the WAN interface. But that doesn't change the behavior of the telephony.
This is an outgoing call from my phone to somewhere. Made visible thanks to sngrep:


2023/11/28 16:34:09.508286 192.168.0.208:5060 -> 217.0.146.197:5060
INVITE sip:+4971166734971@tel.t-online.de SIP/2.0
Via: SIP/2.0/UDP [2003:e5:9710:d801:b70e:d35b:11c:8d34]:5060;rport;branch=z9hG4bKPj22dd8457-1cc3-489f-8db6-d3bd049c2fb5
From: <sip:+498969295180@tel.t-online.de>;tag=5184a0f3-362d-47b0-b200-554da09fa331
To: <sip:+4971166734971@tel.t-online.de>
Contact: <sip:+498969295180@[2003:e5:9710:d801:b70e:d35b:11c:8d34]:5060>
Call-ID: b0ecd1e4-6e43-4e82-afc2-ccf27d8d3bdb
CSeq: 3451 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub, histinfo
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: FPBX-16.0.19(16.16.1)
Content-Type: application/sdp
Content-Length:   313

v=0
o=- 2129977020 2129977020 IN IP4 [2003:e5:9710:d801:b70e:d35b:11c:8d34]
s=Asterisk
c=IN IP4 [2003:e5:9710:d801:b70e:d35b:11c:8d34]
t=0 0
m=audio 18248 RTP/AVP 9 8 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv


2023/11/28 16:34:09.508286 192.168.0.208:5060 -> 217.0.146.197:5060
INVITE sip:+4971166734971@tel.t-online.de SIP/2.0
Via: SIP/2.0/UDP [2003:e5:9710:d801:b70e:d35b:11c:8d34]:5060;rport;branch=z9hG4bKPj22dd8457-1cc3-489f-8db6-d3bd049c2fb5
From: <sip:+498969295180@tel.t-online.de>;tag=5184a0f3-362d-47b0-b200-554da09fa331
To: <sip:+4971166734971@tel.t-online.de>
Contact: <sip:+498969295180@[2003:e5:9710:d801:b70e:d35b:11c:8d34]:5060>
Call-ID: b0ecd1e4-6e43-4e82-afc2-ccf27d8d3bdb
CSeq: 3451 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub, histinfo
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: FPBX-16.0.19(16.16.1)
Content-Type: application/sdp
Content-Length:   313

v=0
o=- 2129977020 2129977020 IN IP4 [2003:e5:9710:d801:b70e:d35b:11c:8d34]
s=Asterisk
c=IN IP4 [2003:e5:9710:d801:b70e:d35b:11c:8d34]
t=0 0
m=audio 18248 RTP/AVP 9 8 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

I notice this mishmash. On the one hand, IPv4 addresses appear and on the other hand, IPv6, such as here:

IN IP4 [2003:e5:9710:d801:b70e:d35b:11c:8d34]
s=Asterisk
c=IN IP4 [2003:e5:9710:d801:b70e:d35b:11c:8d34]

Maybe that's the solution to the puzzle?

Lucky1 · November 28, 2023, 3:58pm

look on your sticker on you router for mac address
I think it would be 00:25:9c:14:9a:07
lan 00:25:9c:14:9a:07
wan 00:25:9c:14:9a:08
2.4G 00:25:9c:14:9a:09
5G 00:25:9c:14:9a:0a
i would put fixed addresses in here based off you sticker

Lucky1 · November 28, 2023, 4:07pm

sure look wrong to have an ipv6 address with it saying it's ipv4
I'd remove ipv6 from the pi
i have never seen ipv6 used on mine voip server

MPenzi · November 28, 2023, 4:12pm

Okay, I only have a MAC address there. Exactly the one that all LANs received. I'll put my random MAC back in as nothing changes with the telephony problem.

Lucky1 · November 28, 2023, 4:33pm

I'd fix them to
lan c4:41:1e:33:b4:3b
wan c4:41:1e:33:b4:3c
2.4G c4:41:1e:33:b4:3d
5G c4:41:1e:33:b4:3e
then reboot it
and then reboot the pi & phones to eliminate any residual arp or mac residue

MPenzi · November 28, 2023, 4:37pm

Yes, you are certainly right. I just deactivated that and restarted the Raspi to be on the safe side. No positive result.
I have to call it a day because my head is spinning. Tomorrow is a new day with fresh thoughts.
Thank you so much to this point.

MPenzi · November 29, 2023, 7:41am

Unfortunately that wasn't effective.