Recurring PPPoE + UDP SIP problem on AC68

[misteradrian]

So I have a problem on on my AC68R + Merlin. I'm using PPPoE and if the PPP tunnel drops (due to DSL issue, etc) then my SIP connections get hungup.

You can see here the ip_conntrack showing the problem. The state is showing the return traffic going to the router's eth0 interface, and not the PPP interface as it should. I'm assuming as the packets come back from my SIP provider, they are just dropped by iptables as there is no connection entry for the UDP session.

admin@RT-AC68R:/proc/22127/net# cat ip_conntrack | grep 5060
udp      17 3598 src=10.0.0.14 dst=216.115.69.144 sport=5060 dport=5060 [UNREPLIED] src=216.115.69.144 [B]dst=192.168.0.2[/B] sport=5060 dport=5060 mark=0 use=2
udp      17 3599 src=10.0.0.14 dst=70.167.153.130 sport=5060 dport=5060 [UNREPLIED] src=70.167.153.130 [B]dst=192.168.0.2[/B] sport=5060 dport=5060 mark=0 use=2

I did a 'ifconfig eth0 down ; ifconfig eth0 up' and that cleared out the errant connections and Asterisk promptly connects back to my SIP provider.

admin@RT-AC68R:/proc/22127/net# cat /proc/net/ip_conntrack | grep 5060
udp      17 3594 src=10.0.0.14 dst=216.115.69.144 sport=5060 dport=5060 src=216.115.69.144 [B]dst=67.5.247.34[/B] sport=5060 dport=5060 [ASSURED] mark=0 use=2
udp      17 3594 src=10.0.0.14 dst=70.167.153.130 sport=5060 dport=5060 src=70.167.153.130 [B]dst=67.5.247.34[/B] sport=5060 dport=5060 [ASSURED] mark=0 use=2

You can see above it's now pointing to the WAN address as it should be.

Anyone have any thoughts on how to automate this process? I thought about the script 'wan-start' but I was wondering if this will run every time PPPoE is established?

 

[bits]

I don't fully get the problem. Your ISP uses PPP tunnel for auth over DSL. If the PPP tunnel drops likely because your DSL sync dropped ofcourse your sip will hangup, you will have no data flow to your ISP.

The answer I find to all sip problems like you seem to be describing though is sip alg's are broken in every device ever to exist. Your isp provider should use a session border controller that will correct your sip data better than the alg in your router.

Turn off the sip alg in your Asus and depend on your isp providers session border controller instead.

 

[misteradrian]

I should have been more clear -- bad phrasing on my part.

The problem appears after the PPPoE tunnel is up again. Internet is working normally but 'iptables' is hanging onto some bad UDP states that must have happened during the outage while Asterisk was trying to register. Once PPP is up, the connection states are invalid for my two SIP registrations... with the SRC of the inbound UDP being the router's own ETH0 instead of the internet IP of my SIP provider. This prevents Asterisk from being able to register until I manually clear the connections (by dropping eth0) or I reboot my router.

This is 100% a problem with the states not being cleared when the PPP tunnel is brought up and since Asterisk keeps trying to reregister, the UDP connection timeout is never reached.

My ISP != SIP provider. They are unrelated.

And of course the SIP is down while the PPP tunnel is down. That's a given. It's what happens when the PPP tunnel is up again that I'm concerned with.