Old WAN ip still in the state table

AndrewZ

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!

eri--

Try new snapshots and your issue might already be fixed.

heper

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

AndrewZ

@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

AndrewZ

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?

Perry

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_ip

Instead 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

AndrewZ

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.

Perry

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

AndrewZ

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 cleared

vr1 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

eri--

Re reading this thread again made my question?

How does your sip use the old ip address?

AndrewZ

@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).