I have to manually reset states after WAN down to allow Asterisk to re-register.
-
Edit: More discussion here: https://redmine.pfsense.org/issues/1629
Looks like a real fix will go in for 2.2.Hmm:
#3181 is a band-aid for 2.1, this will need to wait 2.2
Would be nice if we could get a working band-aid, as it sounds like 2.2 is still a long way off.
-
You would have to feed it your old IP. Presumably this gets run when the gateway is detected as down rather than when when it is up again.
Steve
-
You would have to feed it your old IP. Presumably this gets run when the gateway is detected as down rather than when when it is up again.
WAN IP doesn't change with my cable modem reset. Well, generally it doesn't; I think it did once a few months ago, first time in 3-4 years.
-
So, any thoughts on what I should be looking at to debug this issue?
-
So, any thoughts on what I should be looking at to debug this issue?
Seems the issues are well-understood, but the 'band-aid' fix put in for 2.1 was evidently not effective in cases like ours. So debugging at this point would be to see why it's not effective in our cases. Read through the history and associated revisions here:
https://redmine.pfsense.org/issues/1629 and
https://redmine.pfsense.org/issues/3181There were some commits that reverted fixes that were deemed too excessive. At this point, I'll take excessive, big-hammer type fixes, but I haven't had time to go back and try anything.
-
Thanks. When I get some time i'll put some debug code in there and see if I can work out why it is not clearing the states.
for now, my added kill code in ppp-linkup is working.
-
OK, I have re-applied this commit to my system. It is the 'big hammer' approach, and I'm OK with that. If you are using multi-WAN, you probably don't want this.
That patch was later backed out (with this) and a few minutes later further modified (with this) with the comment "Ticket #3181 do the state flushing only on down gateway detection rather than any time".
I believe something in the last patch broke the state killing on my system. I'll follow up here next time my cable modem drops out.
-
OK, I have re-applied this commit to my system. It is the 'big hammer' approach, and I'm OK with that. If you are using multi-WAN, you probably don't want this.
I can confirm that re-applying the patch above fixed the reset states issue for me. My cable modem reset itself yesterday, and after coming back up, my VOIP adapter was able to register no problem.
Would be great if a fix for this could go into 2.1.1
-
ermal rverted that particular "fix" and made a more refined version: https://github.com/pfsense/pfsense/commit/19d723d2af5e8392d372720ef97b5b83336ec9e1 So it would be useful for people to confirm that the refined version works for their various use cases.
Or go for broke and use the latest filter.inc from the 2.1 branch - https://github.com/pfsense/pfsense/blob/RELENG_2_1/etc/inc/filter.inc -
ermal rverted that particular "fix" and made a more refined version: https://github.com/pfsense/pfsense/commit/19d723d2af5e8392d372720ef97b5b83336ec9e1 So it would be useful for people to confirm that the refined version works for their various use cases.
Yep, I noted that a few messages up. That 'more refined' version patch (5-Sep) was in 2.1 Release when built (11-Sep), and did not work for me or the OP here as noted.
Or go for broke and use the latest filter.inc from the 2.1 branch - https://github.com/pfsense/pfsense/blob/RELENG_2_1/etc/inc/filter.inc
I thought of that, but did not (yet) try it because:
- The commits since then did not seem to be in related areas,
- I thought it would be good to confirm which patch broke my use case
I can try it if it would be helpful though.
-
I guess the key here is the "on gateway failure" part. It uses the monitor functionality to test the link, and it never seems to fail, because it reconnects fast and in the next test it's up again/yet. So it never triggers. Note that i'm only talking about that checkbox (i also have it unchecked and it does not work for this particular problem).
That said, there is code in place that detects the wan ip change, but it does not seem to be the one that is calling rc.kill_states. There seem to be some confusion there. In those other threads (cited above) people seemed to have understood the problem well and were right on track to solving it, a patch was already working (that later was reversed because caused some other bugs) but in the last minute, in another thread, Cris modified the code to only trigger when gateway fails, said 'works' and marked as done. In the previous thread it was said that it was a bandaid and the real fix is for 2.2. Well, the bandaid does not work for this case.
The only really working solution so far is the one proposed in this thread (using ppp's ipup script), but that is clumsy for the average user and might get overwritten in the next update. There is about 4 or 5 other threads about this and all of them conclude with this being fixed with some commit before 2.1, but it's still there on 2.1.
I understand that a real/good solution could only be possible on 2.2, but we could get a bandaid that really works for 2.1.1 at least. Even if the solution is the big-hammer one of killing every state and giving the user a checkbox to enable it (not to confuse with the other checkbox that was commented above). Or the one in ipup that works too.
Maybe a section on the gui for the user to list all ips of voip devices that should have states tottally assassinated on wan ip change, and use this info to construct the calls to pfctl -k that should go in the ipup script. This way it gests more manageable, easy and upgrades-proof. But this only solves the problem for PPPoE, not for DHCP. And it also does not solve the case where the IP does not change, only the interface goes down/up and get the same IP again (which leaves some problems behind and should be treated like if there was an IP change).
-
Hello,
I realize this topic is a little old but I am having the same issue running 2.1. Are there any updates to resolve this issue? I noticed Bug #1629 may be related to this.
-
Same problem here (pfSense 2.1.4)
WAN DHCP, static IP. My pbx does not register the trunks until I reset the state table, even with the "State Killing on Gateway Failure" option is de-selected.
I'm not able to do replicate the problem, so after any change I have to wait (days) to see if something different is happening… :(
-
It's clear to me that this is not a high priority to be fixed with the 2.1.x series. As a work-around for 2.1.x, look at my post here:
https://forum.pfsense.org/index.php?topic=70418.msg387457#msg387457 and re-apply the patch that's in the link.Upgrading to 2.2 alpha has solved the problem for me, so you could consider that option as well.
-
It's clear to me that this is not a high priority to be fixed with the 2.1.x series. As a work-around for 2.1.x, look at my post here:
https://forum.pfsense.org/index.php?topic=70418.msg387457#msg387457 and re-apply the patch that's in the link.Upgrading to 2.2 alpha has solved the problem for me, so you could consider that option as well.
On 2.1.4 the commit that you suggest is not working.
I applied the commit 19d723d2af5e8392d372720ef97b5b83336ec9e1 and it changed the filter.inc.I will update you on my next gateway down event :)
-
It is working like a charm =)
-
Still the same Problem on 2.3.3 for me.
I have to do the following to fix it for me (found it some years ago on the pfsense forum):
cd /usr/local/sbin
vi voip-wan-wipe#!/bin/sh sleep 30 pfctl -F state
chmod 755 voip-wan-wipe
vi ppp-linkup and add before exit 0:
/usr/local/sbin/voip-wan-wipe &
Works for me like a charm.
–
But my question is: Is there any better way to do it in the actual release of pfsense?
-
I think I'm having the same issue with a flaky DSL modem – but registering a SIP trunk with Grandstream PBX (which is an Asterisk flavor).
I'm not sure that I understood the previous (last) reply: write the script and then call it as the last line in ppp-reconnect? Does that work for a DHCP WAN connection too? It's confusing to me that this is the only location (out of 16) that has this problem.
Thanks!