Old WAN ip still in the state table
-
OK, I knew I remembered a shell script from a year or so ago to help solve this issue. I just added it to my RC1 system and forced an IP change with success.
Here is the old posting.
http://forum.pfsense.org/index.php/topic,18053.msg106801.html#msg106801I modified the script myself to simply remove all the states for my voip server with no regard for destination since I have several and the IPs can change from the provider.
I also installed the cron package to add the script.
-
Same problem again - old ip is in the table with SINGLE:NO_TRAFFIC
From the log:
Mar 18 18:24:15 php: : phpDynDNS: (Success) IP Address Changed Successfully! (x.x.35.132) Mar 18 18:24:15 php: : phpDynDNS: updating cache file /conf/dyndns_wandyndns'xxxxx.homedns.org'.cache: x.x.35.132 Mar 18 18:24:15 php: : DynDns debug information: x.x.35.132 extracted from local system. Mar 18 18:24:15 php: : DynDns: _checkIP() starting. Mar 18 18:24:15 php: : DynDns: Current Service: dyndns Mar 18 18:24:15 php: : DynDns: DynDns _checkStatus() starting. Mar 18 18:24:14 php: : Gateways status could not be determined, considering all as up/active. Mar 18 18:24:12 php: : Gateways status could not be determined, considering all as up/active. Mar 18 18:24:11 php: : DynDns: DynDns _update() starting. Mar 18 18:24:11 php: : DynDns debug information: DynDns: cacheIP != wan_ip. Updating. Cached IP: x.x.38.167 WAN IP: x.x.35.132 Mar 18 18:24:11 php: : DynDns: Cached IP: x.x.38.167 Mar 18 18:24:11 php: : DynDns: Current WAN IP: x.x.35.132 Mar 18 18:24:11 php: : DynDns debug information: x.x.35.132 extracted from local system. Mar 18 18:24:11 php: : DynDns: _checkIP() starting. Mar 18 18:24:11 php: : DynDns: _detectChange() starting. Mar 18 18:24:11 php: : DynDns: updatedns() starting Mar 18 18:24:11 php: : DynDns: Running updatedns() Mar 18 18:24:11 apinger: Starting Alarm Pinger, apinger(26077) Mar 18 15:24:11 check_reload_status: reloading filter Mar 18 15:24:10 check_reload_status: reloading filter Mar 18 18:24:10 apinger: Exiting on signal 15. Mar 18 18:24:09 php: : ROUTING: change default route to x.x.32.1 Mar 18 15:24:06 check_reload_status: Rewriting resolv.conf Mar 18 18:24:06 apinger: ALARM: GW_WAN(x.x.32.1) *** down *** Mar 18 18:24:04 dnsmasq[60480]: no servers found in /etc/resolv.conf, will retry Mar 18 18:24:04 dnsmasq[60480]: no servers found in /etc/resolv.conf, will retry Mar 18 15:23:56 check_reload_status: Rewriting resolv.conf -
I recently switched from PPP to DHCP on WAN and have the same issue with the stale records.
After reading some old posts I noticed that a few workarounds were suggested earlier, all of them use pfctl and run 'by event' or as a cron job.My question is - what will be better or safer way to cleanup the states?
pfctl -b {WAN ip}
pfctl -k {voip host ip}
pfctl -F state -i {WAN interface name} (interface name seems to be ignored?)
or ???Is it OK to call this command from the script defined like this:
<system><afterfilterchangeshellcmd>/usr/local/bin/reset_states.sh</afterfilterchangeshellcmd></system>Will it be called on DHCP address change?
Thanks!
-
Try new snapshots and your issue might already be fixed.
-
i have a problem that might be related but am not sure…..
multiwan setup on failover
for some reason it started sending traffic out on the tier 2 opt IF while the tier 1 wan is online ... this occured after wan received a new ip lease after electrical failure of multiple hours.
going into the routing menu and saving the gateway solves the problem till one of the gateways goes offline for a brief moment and then the same thing happens again.
i'm running one of the early RC1 snapshots btw
-
@ermal:
Try new snapshots and your issue might already be fixed.
I'm now on 2.0-RC2 (i386) built on Thu May 19 20:23:36 EDT 2011, will see how it will behave.
With the previous version(s) it seems the issue was still there.Thanks
-
With 2.0-RC2 (i386) built on Fri May 20 12:55:52 EDT 2011 the problem was still there.
If it will not be fixed - what is the best way to clean up the states using the script?
-
If it will not be fixed - what is the best way to clean up the states using the script?
To only kiil voip states IMO
/sbin/pfctl -k $local_voip_ip -k $provider_voip_ipInstead of using afterfilterchangeshellcmd you can watch states with a cron job
#!/bin/sh local_voip_ip='' provider_voip_ip='' # Write phone states to file /sbin/pfctl -s state | grep $local_voip_ip > /tmp/statetmp.status # Kill VOIP phone states if in wrong state awkrepley3=`awk '/'$local_voip_ip'/ && /'$provider_voip_ip'/ && /SINGLE/ {print "down"}' /tmp/statetmp.status` if [ "${awkrepley3}" = "down" ] ; then /sbin/pfctl -k $local_voip_ip -k $provider_voip_ip echo "states frozen kill them" | logger fi -
Perry, thanks a lot!
How can I use an alias instead of an IP address in local_voip_ip='' ? Is it safe to add a port number there?
Is it OK to leave provider_voip_ip='' empty or it will be better to remove "-k $provider_voip_ip" completely?
I cannot put all the provider's IPs there, and, actually, do not want to do so. -
If it's not a single voip phone and local and remote ip's isn't static maybe you should just clear all states. Different ways to use pfctl can be found here.
http://www.freebsd.org/cgi/man.cgi?query=pfctl&apropos=0&sektion=8&manpath=FreeBSD+8.1-RELEASE&format=html -
If it's not a single voip phone and local and remote ip's isn't static maybe you should just clear all states. Different ways to use pfctl can be found here.
I think I've started from such approach.
[2.0-RC2][admin@gw.lan]/root(2): pfctl -F state -i vr1 0 states clearedvr1 is my WAN and it seems that I cannot flush just this interface and have to flush all. Is it a known bug?
Going back to my earlier questions:
- what is better or safer: -b or -k or -F ?
- is it OK to use afterfilterchangeshellcmd? will it be called on every DHCP address change?
And how can I refer in my script to:
- the host alias I've defined, like 'pbx'
- ip address of the WAN interface (to use with -b)
Thanks
-
Re reading this thread again made my question?
How does your sip use the old ip address?
-
@ermal:
How does your sip use the old ip address?
It doesn't. The stale state records are preventing client-to-server communication. Client keeps sending packets to server and get no response until the sates are cleared manually.
The problem is known for quite a long time, in 1.2.3 it was 'fixed' by installing fit123 package (similar to the cron-based solution your suggested earlier).