FTP - no Hell :-) -, but [Solved !!]….

[Gertjan]

I'm using a PPPoE connection - my ISP resets the connection every 24 hours - No hasle Pfsense, it reconnects on the fly.
I'm running 1.0-SNAPSHOT-09-10-06 - built on Sun Sep 10 19:36:58 UTC 2006 - but I consider it 'hot' from the oven.

The pFsense box has an LAN IP of 192.168.1.1 - I have a FTP server on 192.168.1.2.
When I added a NAT rule to the WAN interface like Port 21 - Port 21 (192.168.1.2) everything works great. Two firewall rules weres also created 'by magic'.
The processes that were running:

 620  ??  Ss     0:00.01 /usr/local/sbin/pftpx -c 8021 -g 8021 192.168.1.1
 1797  ??  Ss     0:00.01 /usr/local/sbin/pftpx -f 192.168.1.2 -b 82.125.193.13

During night time, of course, my WAN IP changed.

I use a Dyndns URL to reach my network from the outside. A PC-Anywhere and remote SSH (by PPTP) from 'my place' resolved and worked - I could reach my compagny LAN and the pFsense box as normal.
But I couldn't reach the ftp server anymore….

Checking the processes, I noticed that ...pftpx -f 192.168.1.2 -b 82.125.193.13 was still point to the WAN IP 'before' - the new one was 82.125.196.18 - it has been changed, but somehow the instance of pftpx wasn't informed about it (killed and restared with the new WAN IP ?!).

Simply removing the WAN-NAT rule, Apply, remvoving the firewall rule, Apply, putting back the WAN-NAT rule and all is fine again for a near 24 hours (when ever the WAN IP times out).

Also, if it's important: one's in a while (and always after a reboot like shutdown -r now) the line …pftpx -f 192.168.1.2 -b x.y.z.w is just missing, but I have 1 or 2 line like this:
x  ??  Ss     0:00.01 /usr/local/sbin/pftpx -c 8021 -g 8021 192.168.1.1
x  ??  Ss     0:00.01 /usr/local/sbin/pftpx -c 8021 -g 8021 192.168.2.1
I found this in the GUI System log:

Sep 12 09:15:44 php: : DynDns: updatedns() starting
Sep 12 09:15:44 php: : DynDns: Running updatedns()
Sep 12 09:15:42 pftpx[1151]: pftpx exiting on signal 0
Sep 12 09:15:42 pftpx[1151]: pftpx exiting on signal 0
Sep 12 09:15:42 pftpx[1151]: event_dispatch error: Operation not supported by device
Sep 12 09:15:42 pftpx[1151]: event_dispatch error: Operation not supported by device
Sep 12 09:15:42 pftpx[1151]: listening on 82.125.88.115 port 21
Sep 12 09:15:42 pftpx[1151]: listening on 82.125.88.115 port 21
Sep 12 09:15:39 php: : Creating rrd graph index
Sep 12 09:15:39 php: : Creating rrd update script

Meaning the end of pftpx after a complete boot & connection sequence.
Simply redoing my NAT-WAN ftp setup puts all up again.

Please note that I have a OPT1 interface (192.168.2.1), running the Captive Portale for compagny visitors (running a hotel overhere  ;)).
Please note also that after 28 Aug-2006, Dyndns info (log type: User.info) is shown in the System logs on the GUI interface. Nothing is present in the syslog remote output. A line like User.Info @192.168.1.x is missing  in /var/etc/syslog.conf?

[Gertjan]

For the experts…..

In /etc/rc.newwanip the file /tmp/rc.newwanip_oldip is used - and it should contain the current ip (or the latest wan ip - before the new current one…). Doesn't Dyndns use somehwo the same scheme ?!!  ;)

Very clever: this file is used to kill the current pftpx instances that are still using the OLD WAN IP - its being found by using the OLD WAN IP on a 'ps auwx | grep $OLDWANIP….' command line. Like this, the old ftpx instances are located and killed.

Ok.

How comes that I never found a file like /tmp/rc.newwanip_oldip (in any condition).
Meaning: these pftpx are never getting killed - and, I gues, new one can be started with the correct, new WAN IP.

Can't even find where it is created in the first pace.

Tell me that I'm all wrong - untill then I think I'm rater close to a small pb  :-\

[sullrich]

Check out /sbin/dhclient-script

Must be used on exit.  Invokes the local dhcp client exit hooks, if any.

exit_with_hooks() {
        echo $interface > /tmp/rc.newwanip
        echo $old_ip_address > /tmp/rc.newwanip_oldip
        # probably should do something with exit status of the local script
        exit 0
}

[Gertjan]

Ok, get it.
Thanks.

Under 'some' circumstances this file is created. But, I'm not using a dhcpclient on my WAN side, but PPPoE !

So, this file can't be made, and used, in my case (from what I know now).

So, how should the script file rc.newwanip kill the /usr/local/sbin/pftpx instances (with the old WAN IP attached to it) ?

What I'm trying to do is :
A little bit futher along in rc.newwanip is created a "{$g['vardb_path']}/{$interface}_ip" (nice code for /var/db/wan_ip) with the actual WAN IP in it. Why not using that one ? It will be the old one the next time rc.newwanip is executed. (Except for the first time after a fresh install - I must take care of this situation also - another way to wack the pftpx instances is needed then).

So, what I'm testing right now, is that 'I don't break things' (the dhcpclient part) but that my PPPoE setup also works (aka: starting a new pftpx instance) for the use of ftp.

As stated, when a new WAN IP comes arround, rc.newwanip is executed (when my PPPoE makes a 24H time-out), but no new pftpx is started, what means that my ftp server becomes unreachable. Or, from what I understood, rc.newwanip should do just that !!

I'll keep you posted.

[sullrich]

Please test / check out : http://www.pfsense.com/~sullrich/rc.newwanip

[Gertjan]

@sullrich:

Please test / check out : http://www.pfsense.com/~sullrich/rc.newwanip

….. Incredible..... you've being copying my idea here  ;)

I'll paste it in, throw some log_error(...); in it for debugging, and keep you posted !

Please note that this part (the end of rc.newwanip) always asures that a "{$g['vardb_path']}/{$interface}_ip" (/var/db/wan_ip) file will exist.

        /* write current WAN IP to file */
        $fd = fopen("{$g['vardb_path']}/{$interface}_ip", "w");
        if ($fd) {
			fwrite($fd, $curwanip);
			fclose($fd);
        }

So, it will always be used.

Better be sure that the always word is correct here.
It make this part:

		/* grab the prior ip for pftpx tests */
		if(file_exists("/tmp/rc.newwanip_oldip")) {
			/* grab hint from dhclient */
			$old_ip = file_get_contents("/tmp/rc.newwanip_oldip");
			unlink("/tmp/rc.newwanip_oldip");
		}
```for an execution point of view useless.

I'll better think about the side effects (like switching between dhcp and pppoe on the wan side - although rare), etc.

[sullrich]

I just commited this.  Does it work?  Note, that I updated the file a few times due to a few minor bugs.

The commited version is here:

http://cvs.pfsense.com/cgi-bin/cvsweb.cgi/pfSense/etc/rc.newwanip?rev=1.21.2.15;content-type=text%2Fplain;only_with_tag=RELENG_1

[Gertjan]

Sorry for the late answer : was working yesterday evening remotly on my pFsense system (from home to work) - locked the system up / and myself out…..  :o

Well.. of course it works  ;D

Have a look at:

Sep 13 08:47:39 php: : rc.newwanip :: Killing process: 13731 using 82.125.219.28 

I added a log_error() just before the kill in rc.newwanip.

I'm heading now for the last issue.
From filter.inc is executed this:

        /* run items scheduled for after filter configure run */
        foreach($after_filter_configure_run as $afcr) {
                log_error("filter.inc :: {$afcr}");
                mwexec($afcr);
        }
```which actually starts a new pftpx task with the new wan address.

I logged this :

Sep 13 08:47:43 php: : filter.inc :: /usr/local/sbin/pftpx -f 192.168.1.2 -b 86.201.200.142 -c 21 -g 21 2>>/tmp/pftpx_errors

@in:

> …
> Sep 13 08:47:43 php: : filter.inc :: /usr/local/sbin/pftpx -f 192.168.1.2 -b 86.201.200.142 -c 21 -g 21 2>>/tmp/pftpx_errors
> Sep 13 08:47:43 pftpx[14159]: listening on 86.201.200.142 port 21
> Sep 13 08:47:43 pftpx[14159]: listening on 86.201.200.142 port 21
> Sep 13 08:47:43 pftpx[14159]: event_dispatch error: Operation not supported by device
> Sep 13 08:47:43 pftpx[14159]: event_dispatch error: Operation not supported by device
> Sep 13 08:47:43 pftpx[14159]: pftpx exiting on signal 0
> Sep 13 08:47:43 pftpx[14159]: pftpx exiting on signal 0
> Sep 13 08:47:45 php: : DynDns: Running updatedns()
> …

right after it.

Retyping the green command (ok, I used a Ctrl-C, Ctrl-V from the log) a couple of secondsd later work well, the pftpx was running without complaining. So, the command constructed in filter.inc (in **after_filter_configure_run[][/b]) is correct.

It seems that pftpx is started….well, let's say, _to early_ from **filter.inc**. Some kind of a timing issue ?**

[Gertjan]

In fact : all this was already known : http://cvstrac.pfsense.com/tktview?tn=772

I'll keep digging….

[Gertjan]

Had to make it work.
This

/usr/local/sbin/pftpx -f 192.168.1.2 -b 90.5.250.2 -c 21 -g 21 2>>/tmp/pftpx_errors

can't be run from filter.inc. (Go figure why, I'll leave that for the crackers  :))

So, I re-wrote this part in filter.inc:

        /* run items scheduled for after filter configure run */
        $lateron = fopen("/tmp/lateron.sh","w");
        foreach($after_filter_configure_run as $afcr) {
                fwrite($lateron, $afcr); /* Yes, we write a command file, we're not executing now) */
        }
        fclose($lateron);

Add this file: rc.ftp

#!/bin/sh
if [ -f /tmp/lateron.sh ]; then
        chmod +x /tmp/lateron.sh
        /tmp/lateron.sh
        rm /tmp/lateron.sh
fi

and of course, a small chmod +x /etc/rc.ftp on it.

And add this to crontab:

1       *       *       *       *       root            /usr/bin/nice -n20 /etc/rc.ftp

And pftpx will be re-run nicely with every new dynamic (non-dhcp) WAN IP.

Of course, cron can execute the rc.ftp script file to fast (when it times out) - and things will go wrong again - So I can say this is a half baken 15 min. solution. I'll have this running for some time to see what happens.

[sullrich]

ewwwww.

We really need to figure out why the pftpx process won't start from filter.inc.

This used to be a problem when first booting up but not sure why it would be a problem since pf is already running.

[Gertjan]

Yup, when booting (just tried it 30 sec ago) ftp access is restored just fine (took 30 sec more - but never more then 1 min  8)) and I was up ftp-ing again…
Still, have to admit that this is lousy programming, but.... it works.

I'll have a look at this pftpx program - but I'm not ready to attack pf…

[sullrich]

Filter.inc really does get invoked as it should?  Are we sure of this?

After the IP address change you should see a php process for /etc/rc.filter_configure running.  Is this the case?

[Gertjan]

@sullrich:

Filter.inc really does get invoked as it should?  Are we sure of this?

After the IP address change you should see a php process for /etc/rc.filter_configure running.  Is this the case?

Yep.

/etc/filter.inc runs as it should (i.e. when adding the ftp - port 21 rule on the NAT).
The function filter_configure_sync() is being called. I shows me a nice log_error("filter_configure_sync() being called $mt\n"); (see the fith line from the start of the function) to be sure.
The $after_filter_configure_run array is polutated as it should be.
At the end of filter_configure_sync() all these lines (actualy, just one) are executed.
This does starts, i.e., /usr/local/sbin/pftpx -f 192.168.1.2 -b 82.125.93.41 -c 21 -g 21 - and, when started from (or, better to say: 'during') filter.inc, will bail out with an error (see above). pftpx will stop - incoming ftp won't work.

Thats why I decided to write the lines in $after_filter_configure_run array to a file, and execute this file a little bit later on.

[sullrich]

I must be blind, I don't see the error message?

[Gertjan]

To be sure, SSH loggings shows me
***** Welcome to pfSense 1.0-SNAPSHOT-09-12-06-pfSense on pfsense *****
(installed this morning)

I put back the 'original' /etc/inc/filter.inc file (yours).

I rebooted. Logged in again (remotly, by PPTP), and the GUI system log shows me:

Sep 14 21:03:21 php: : DynDns: Current WAN IP: 82.125.220.118
Sep 14 21:03:21 php: : DynDns: _detectChange() starting.
Sep 14 21:03:21 php: : DynDns: updatedns() starting
Sep 14 21:03:21 php: : DynDns: Running updatedns()
Sep 14 21:03:20 pftpx[1002]: pftpx exiting on signal 0
Sep 14 21:03:20 pftpx[1002]: pftpx exiting on signal 0
Sep 14 21:03:20 pftpx[1002]: event_dispatch error: Operation not supported by device
Sep 14 21:03:20 pftpx[1002]: event_dispatch error: Operation not supported by device
Sep 14 21:03:20 pftpx[1002]: listening on 82.125.220.118 port 21
Sep 14 21:03:20 pftpx[1002]: listening on 82.125.220.118 port 21
Sep 14 21:03:16 php: : Creating rrd graph index
Sep 14 21:03:16 php: : Creating rrd update script

A shows ps auwx | grep ftp | grep -v grep

proxy    616  0.0  0.1   656   492  ??  Ss    9:03PM   0:00.00 /usr/local/sbin/pftpx -c 8021 -g 8021 192.168.1.1
proxy    624  0.0  0.1   656   492  ??  Ss    9:03PM   0:00.00 /usr/local/sbin/pftpx -c 8022 -g 8021 192.168.2.1

We all agree here that FTP from the outside isn't possible right now….  :'(

Gona take a beer - and start to think about..... taking a static WAN IP (still 25 € a month here).

Will do an compleet ISO install tomorrow (did one last monday already with the latest & greatest at that time - but I'll better be sure)

[sullrich]

Can I get access to this machine?