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

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?