<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>ClearChain &#187; FreeBSD</title>
	<atom:link href="http://www.clearchain.com/blog/tags/freebsd/feed" rel="self" type="application/rss+xml" />
	<link>http://www.clearchain.com/blog</link>
	<description>-= Daily Happenings =-</description>
	<lastBuildDate>Sun, 25 Jul 2010 15:47:38 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
		<item>
		<title>FreeBSD Sudo Upgrade Gone Wrong, Password No longer working with Sudo 1.7.2p2 / 1.7.2p3, Sudo Broken</title>
		<link>http://www.clearchain.com/blog/posts/freebsd-sudo-upgrade-gone-wrong-password-no-longer-working-with-sudo-1-7-2p2-1-7-2p3-sudo-broken</link>
		<comments>http://www.clearchain.com/blog/posts/freebsd-sudo-upgrade-gone-wrong-password-no-longer-working-with-sudo-1-7-2p2-1-7-2p3-sudo-broken#comments</comments>
		<pubDate>Wed, 14 Apr 2010 04:09:02 +0000</pubDate>
		<dc:creator>Benjamin Close</dc:creator>
				<category><![CDATA[FreeBSD]]></category>
		<category><![CDATA[password]]></category>
		<category><![CDATA[security]]></category>
		<category><![CDATA[sudo]]></category>

		<guid isPermaLink="false">http://www.clearchain.com/blog/?p=681</guid>
		<description><![CDATA[Recently a port audit security advisor was released that indicated an exploit with sudoedit of the security/sudo FreeBSD port. At the time I was running sudo 1.6.9 and being a responsible system administrator, I decided to upgrade sudo to the latest revision of the port (1.7.2p2 at the time). The upgrade went very smoothly, with [...]]]></description>
			<content:encoded><![CDATA[<p>Recently a port audit security advisor was released that indicated an <a href="http://www.freebsd.org/ports/portaudit/018a84d0-2548-11df-b4a3-00e0815b8da8.html">exploit</a> with sudoedit of the <a href="http://www.freebsd.org/cgi/cvsweb.cgi/ports/security/sudo/">security/sudo</a> <a href="http://www.freebsd.org">FreeBSD</a> port. At the time I was running sudo 1.6.9 and being a responsible system administrator, I decided to upgrade sudo to the latest revision of the port (1.7.2p2 at the time). The upgrade went very smoothly, with portupgrade doing it&#8217;s job quickly and reliably. It wasn&#8217;t until I tried to use sudo for the first time after the upgrade that the problems started.</p>
<p>Initially I tried get a root shell using:</p>
<pre>sudo -s
</pre>
<p>sadly after repeated password prompts I had no luck. Initially I thought I was just getting my password wrong &#8211; something I occasionally do with the amount of passwords I have to remember. However, after repeated attempts I came to the conclusion that something else was wrong.</p>
<p>I looked at the logs to see if they would show anything useful:</p>
<p>﻿</p>
<pre>Apr 14 11:49:28 leo sudo:   benjsc : 1 incorrect password attempt ; TTY=pts/3 ; PWD=/owners/benjsc/home ; USER=root ; COMMAND=/bin/tcsh
Apr 14 11:51:09 leo sudo:   benjsc : 1 incorrect password attempt ; TTY=pts/4 ; PWD=/owners/benjsc/home ; USER=root ; COMMAND=/bin/tcsh
Apr 14 11:58:03 leo sudo:   benjsc : 1 incorrect password attempt ; TTY=pts/4 ; PWD=/owners/benjsc/home ; USER=root ; COMMAND=/bin/tcsh
Apr 14 11:58:16 leo sudo:   benjsc : 1 incorrect password attempt ; TTY=pts/4 ; PWD=/owners/benjsc/home ; USER=root ; COMMAND=/bin/tcsh</pre>
<p>Once again nothing obvious showed up. At this point I started <a href="http://www.google.com/">Googling</a> to try and find the answer. There was a lot of articles about people trying the root password rather than the user password, but I wasn&#8217;t doing that. There was articles about people stuffing up the syntax of the sudoers file (you should use visudo to edit this). However, nothing had changed but the version of sudo. Eventually I found a <a href="http://www.mail-archive.com/freebsd-questions@freebsd.org/msg228360.html">post that solved the issue.</a></p>
<p>It turns out that the latest versions of sudo break pam support. Whilst the article refers to OPIE (One Time Keys), I&#8217;ve since confirmed that this issue affects machines without OPIE setup. Hence for anyone who tries to upgrade sudo to a later version and has problems with their password not being accepted, and the password prompt just continuing to reappear. Then you&#8217;ll need to patch sudo to work.</p>
<p>How, copy and paste the following on the console:</p>
<pre>cd  /usr/ports/security/sudo
make extract
cd work/sudo*
patch &lt;&lt; END
--- auth/pam.c.orig     2010-02-04 10:43:28.635212518 -0600
+++ auth/pam.c  2010-02-04 10:43:34.194558424 -0600
@@ -107,13 +107,6 @@
     }

     /*
-     * Set PAM_RUSER to the invoking user (the "from" user).
-     * We set PAM_RHOST to avoid a bug in Solaris 7 and below.
-     */
-    (void) pam_set_item(pamh, PAM_RUSER, user_name);
-    (void) pam_set_item(pamh, PAM_RHOST, user_host);
-
-    /*
      * Some versions of pam_lastlog have a bug that
      * will cause a crash if PAM_TTY is not set so if
      * there is no tty, set PAM_TTY to the empty string.

END
cd ../..
make build
make deinstall
make install
</pre>
]]></content:encoded>
			<wfw:commentRss>http://www.clearchain.com/blog/posts/freebsd-sudo-upgrade-gone-wrong-password-no-longer-working-with-sudo-1-7-2p2-1-7-2p3-sudo-broken/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Using Serial Devices in FreeBSD / How to set a terminal baud rate</title>
		<link>http://www.clearchain.com/blog/posts/using-serial-devices-in-freebsd-how-to-set-a-terminal-baud-rate</link>
		<comments>http://www.clearchain.com/blog/posts/using-serial-devices-in-freebsd-how-to-set-a-terminal-baud-rate#comments</comments>
		<pubDate>Fri, 08 Jan 2010 00:33:56 +0000</pubDate>
		<dc:creator>Benjamin Close</dc:creator>
				<category><![CDATA[FreeBSD]]></category>
		<category><![CDATA[UniSA]]></category>
		<category><![CDATA[baud rate]]></category>
		<category><![CDATA[baudrate]]></category>
		<category><![CDATA[ftdi]]></category>
		<category><![CDATA[serial]]></category>
		<category><![CDATA[stty]]></category>

		<guid isPermaLink="false">http://www.clearchain.com/blog/?p=674</guid>
		<description><![CDATA[Recently I was working on a php command line program that required access to a serial port. Initially developed under Linux the program was then shifted to it&#8217;s permanent location on a FreeBSD server. This is where we first started having problems. Initially we discovered the server didn&#8217;t have a native serial port. We fixed [...]]]></description>
			<content:encoded><![CDATA[<p>Recently I was working on a php command line program that required access to a serial port.</p>
<p>Initially developed under Linux the program was then shifted to it&#8217;s permanent location on a FreeBSD server. This is where we first started having problems. Initially we discovered the server didn&#8217;t have a native serial port. We fixed this using a USB to serial converter/dongle (FTDI Chipset). This was fine as FreeBSD has the ufdti kernel module. Upon loading the module new devices appears in /dev</p>
<pre>crw-rw----  1 uucp  dialer    0, 157 Oct  6 08:39 /dev/cuaU0
crw-rw----  1 uucp  dialer    0, 158 Oct  6 08:39 /dev/cuaU0.init
crw-rw----  1 uucp  dialer    0, 159 Oct  6 08:39 /dev/cuaU0.lock
crw-rw-rw-  1 root  wheel     0, 154 Jan  8 10:50 /dev/ttyU0
crw-------  1 root  wheel     0, 155 Oct  6 08:39 /dev/ttyU0.init
crw-------  1 root  wheel     0, 156 Oct  6 08:39 /dev/ttyU0.lock</pre>
<p>We attempted to connect to our device using screen (screen /dev/ttyU0 115200) and everything worked as expected. We could send AT commands to the device all ok.<br />
We then stopped screen and ran our php program. It ended up hanging on a fgets call to the serial port. This is really strange we though.<br />
Next we queried the port to find out what baud rate it was set at:</p>
<pre>&gt;stty -f /dev/ttyu0
speed 9600 baud;
lflags: echoe echoke echoctl
oflags: tab0
cflags: cs8 -parenb</pre>
<p>Strange we thought as we&#8217;d just connected with screen at 115200. Under linux we use screen to set the baud rate, all other programs accessing the port use the port at 115200. So what had set it back to 9600 baud?<br />
We tried to use stty to set the speed:</p>
<pre>&gt;stty -f /dev/ttyU0 speed 115200</pre>
<pre>&gt;stty -f /dev/ttyu0
speed 9600 baud;
lflags: echoe echoke echoctl
oflags: tab0
cflags: cs8 -parenb</pre>
<p>What on earth was happening? We set the speed to 115200 but directly quering the port again indicated it was still at 9600 baud? At this point we were perplexed.<br />
Eventually we found the solution. The newer FreeBSD terminal drivers provide the *.init devices, in this case /dev/ttyU0.init . These devices indicate the terminal settings to be applied to the terminal when the device is closed. Whilst Linux leaves the device in the same state the last program put the port into, FreeBSD restores the terminals state to what ever is specified in the init file. So a quick command:</p>
<pre>&gt; stty -f /dev/ttyU0.init -icanon -isig -echo echoe echok echoke echoctl -icrnl -ixany -imaxbel ignpar -opost -onlcr -oxtabs cs8 -parenb -hupcl clocal</pre>
<p>And then to check:</p>
<pre>&gt; stty -f /dev/ttyU0
speed 115200 baud;
lflags: -icanon -isig -echo echoe echok echoke echoctl
iflags: -icrnl -ixany -imaxbel ignpar
oflags: -opost -onlcr -oxtabs
cflags: cs8 -parenb -hupcl clocal</pre>
<p>Excellent. The terminal was now configured exactly how we wanted. We ran the program and it worked like a charm!</p>
]]></content:encoded>
			<wfw:commentRss>http://www.clearchain.com/blog/posts/using-serial-devices-in-freebsd-how-to-set-a-terminal-baud-rate/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>mythtv on FreeBSD: The beginning</title>
		<link>http://www.clearchain.com/blog/posts/mythtv-on-freebsd-the-beginning</link>
		<comments>http://www.clearchain.com/blog/posts/mythtv-on-freebsd-the-beginning#comments</comments>
		<pubDate>Wed, 01 Apr 2009 11:50:26 +0000</pubDate>
		<dc:creator>Benjamin Close</dc:creator>
				<category><![CDATA[Mythtv]]></category>
		<category><![CDATA[cx88]]></category>
		<category><![CDATA[dvb]]></category>
		<category><![CDATA[dvb-t]]></category>
		<category><![CDATA[FreeBSD]]></category>
		<category><![CDATA[linux]]></category>
		<category><![CDATA[multimedia]]></category>
		<category><![CDATA[television]]></category>
		<category><![CDATA[tv]]></category>

		<guid isPermaLink="false">http://www.clearchain.com/blog/?p=311</guid>
		<description><![CDATA[This documents my progress settting up mythtv on FreeBSD.]]></description>
			<content:encoded><![CDATA[<p>This article is the first in a series of blog entries which documents my progress getting FreeBSD 7.1-Stable working a both a MythTV backend and frontend. There&#8217;s very little information out there talking about this process, probably as FreeBSD&#8217;s multimedia drivers are not as mature or as abundant as Linux&#8217;s . However there is some information out there alluding to clues that is it possible.  Below is the specs of the computer I&#8217;m using for this setup.</p>
<h2>Hardware</h2>
<ul>
<li><strong>CPU: </strong>Core2Duo  E8200  @ 2.66GHz</li>
<li><strong>HDD:</strong><br />
ad0: 114472MB &lt;WDC WD1200JB-00FUA0 15.05R15&gt; at ata0-master UDMA33<br />
ad4: 305245MB &lt;WDC WD3200AAKS-00B3A0 01.03A01&gt; at ata2-master SATA150<br />
ad6: 190782MB &lt;Seagate ST3200822AS 3.01&gt; at ata3-master SATA150<br />
ad7: 190782MB &lt;Seagate ST3200822AS 3.01&gt; at ata3-slave SATA150</li>
<li><strong>Video Card:</strong><br />
NVideo GeForce 7300 LE</li>
<li><strong>Audio:</strong><br />
Intel 82801G (ICH7 Family) High Definition Audio</li>
<li><strong>Capture Cards:</strong></li>
<li>
<ul>
<li>CX2388x TV Capture Chip (DVB-T)</li>
<li>Conexant (Was: Brooktree Corp)<br />
&#8217;7610144D&amp;REV_02\4&amp;1F7DBC9F&amp;0&amp;09F0 TV Video Capture</li>
</ul>
</li>
</ul>
<p>With the hardware set and not likely to change (I refuse to buy hardware due to an O/S not working with what I&#8217;ve got), it was time to try and get things working. Whilst there is a mythtv port, it&#8217;s the old stable release of 0.18. There has been a lot of changes since then. Including the new libmythui library where groovy graphics features are available. I must admit I&#8217;m not coming in to this blind. I&#8217;ve been running mythtv under Linux for quite some time.  Hence I&#8217;m quite aware what needs to be done under Linux to get a working Mythtv setup. Hence I&#8217;ll break this article up into a number of different steps as below. Each one being a different blog entry.. some of these steps are going to take a while to get working!</p>
<ol>
<li>Setting up required ports</li>
<li>Setting up capture cards</li>
<li>Setting up audio</li>
<li>Setting up Xorg</li>
<li>Installing Mythtv</li>
<li>Configuring Mythtv</li>
<li>Tweaking Mythtv</li>
</ol>
<p>For anyone who wishes to follow this drama of getting things working below I provide some links I&#8217;ve found which useful in determining what might be possible. I also provide a little justification as to why I want Mythtv working under FreeBSD.</p>
<h2>Why the Switch?</h2>
<p>After having mythtv successfully running under various versions of ubuntu, I finally reached a point where Linux annoyed me enough to try and get rid of it in favour of FreeBSD. It&#8217;s not that Linux didn&#8217;t work, it&#8217;s just the amount of stuffing around I had to do to get things working was CRAZY! Sure installing mythtv was relatively easy but it&#8217;s all the little things that FreeBSD does so well that Linux doesn&#8217;t that made me want to change. Thinks like power management, cpu throttling, wireless that actually works!</p>
<p>These things are just easier under FreeBSD, there&#8217;s no config, overiding some config, linked to some default, using some crazy symlink farm. There&#8217;s not &#8216;volatile&#8217; kernel modules which must go through crazy loading scripts because they are not GPL compliant. FreeBSD also is much easier to upgrade in place and has the ZFS filesystem. This is the main reason I wanted to switch. I use the same machine as a backup server with 2 disks in raid 1. The ability to daily snapshot at the filesystem level is just soooo nice!</p>
<h2>FreeBSD Mythtv Links</h2>
<p>Below are some links that I found useful when getting mythtv working under FreeBSD.</p>
<ul>
<li>http://mythtv.son.org/tiki-index.php</li>
<li>http://wiki.freebsd.org/MythTV</li>
<li>http://www.lemis.com/grog/HOWTO/mythtv-on-FreeBSD-setup.html</li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://www.clearchain.com/blog/posts/mythtv-on-freebsd-the-beginning/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Frox &amp; PF</title>
		<link>http://www.clearchain.com/blog/posts/frox-pf</link>
		<comments>http://www.clearchain.com/blog/posts/frox-pf#comments</comments>
		<pubDate>Fri, 07 Nov 2008 04:17:30 +0000</pubDate>
		<dc:creator>Benjamin Close</dc:creator>
				<category><![CDATA[Computers]]></category>
		<category><![CDATA[FreeBSD]]></category>
		<category><![CDATA[ftp]]></category>
		<category><![CDATA[networking]]></category>
		<category><![CDATA[pf]]></category>
		<category><![CDATA[proxy]]></category>

		<guid isPermaLink="false">http://www.clearchain.com/blog/?p=62</guid>
		<description><![CDATA[This article describes how to setup Frox to perform transparent proxying and caching via pf under FreeBSD. Contents  [hide] 1 Background 2 The Problem 3 The Setup 4 Frox PF Support 4.1 Normal Connection (No transparent proxying) 4.2 rdr connection (Transparent Proxying) 4.2.1 With Squid backend 4.2.2 Without Squid Backend 4.3 Correcting the problem 5 Installation 6 Frox PF Transparent Proxy Patch 7 Frox Config File Background Frox is a groovy [...]]]></description>
			<content:encoded><![CDATA[<p>This <a title="Article" href="http://www.clearchain.com/wiki/Article">article</a> describes how to setup Frox to perform transparent proxying and caching via pf under <a title="FreeBSD" href="http://www.clearchain.com/blog/categories/computers/freebsd">FreeBSD</a>.</p>
<p><span id="more-62"></span></p>
<table id="toc" class="toc" border="0" summary="Contents">
<tbody>
<tr>
<td>
<div id="toctitle">
<h2>Contents</h2>
<p> <span class="toctoggle">[<a id="togglelink" class="internal" href="javascript:toggleToc()">hide</a>]</span></div>
<ul>
<li class="toclevel-1"><span class="tocnumber">1</span> <span class="toctext">Background</span></li>
<li class="toclevel-1"><span class="tocnumber">2</span> <span class="toctext">The Problem</span></li>
<li class="toclevel-1"><span class="tocnumber">3</span> <span class="toctext">The Setup</span></li>
<li class="toclevel-1"><span class="tocnumber">4</span> <span class="toctext">Frox PF Support</span>
<ul>
<li class="toclevel-2"><span class="tocnumber">4.1</span> <span class="toctext">Normal Connection (No transparent proxying)</span></li>
<li class="toclevel-2"><span class="tocnumber">4.2</span> <span class="toctext">rdr connection (Transparent Proxying)</span>
<ul>
<li class="toclevel-3"><span class="tocnumber">4.2.1</span> <span class="toctext">With Squid backend</span></li>
<li class="toclevel-3"><span class="tocnumber">4.2.2</span> <span class="toctext">Without Squid Backend</span></li>
</ul>
</li>
<li class="toclevel-2"><span class="tocnumber">4.3</span> <span class="toctext">Correcting the problem</span></li>
</ul>
</li>
<li class="toclevel-1"><span class="tocnumber">5</span> <span class="toctext">Installation</span></li>
<li class="toclevel-1"><span class="tocnumber">6</span> <span class="toctext">Frox PF Transparent Proxy Patch</span></li>
<li class="toclevel-1"><span class="tocnumber">7</span> <span class="toctext">Frox Config File</span></li>
</ul>
</td>
</tr>
</tbody>
</table>
<p><a name="Background"></a></p>
<h1><span class="mw-headline">Background</span></h1>
<p><a class="external text" title="http://frox.sourceforge.net/" rel="nofollow" href="http://frox.sourceforge.net/">Frox</a> is a groovy little ftp-proxy which has the advantage of being able to cache the files that it proxies. Whilst there is lots of ftp proxies that help ftp through a firewall, frox is the only ftp-proxy I have found that supports caching of files.</p>
<p>Even better than that, Frox has the ability to use an external cache. Hence it&#8217;s possible to setup frox so it passes all ftp transfers to squid. This allows a dedicated cache (squid) to do the hard work with frox being merely a relay.</p>
<p>Frox also has the ability to transparently provide ftp proxying. Hence you can provide cached transparent ftp proxying without the users even knowing about it. This proves to be a great benefit in a lab where many people use ubuntu and often do <code>apt-get update</code>. The first user grabs the data, the second gets it from the cache.</p>
<p><a name="The_Problem"></a></p>
<h1><span class="mw-headline">The Problem</span></h1>
<p>Sadly whilst frox has all these features, no on has really worked on it for a number of years. Hence somethings don&#8217;t work as well as expected. Take for instance the fact I wanted transparent proxying using <em>pf</em> the [<a class="external text" title="http://www.openbsd.org" rel="nofollow" href="http://www.openbsd.org/">OpenBSD</a>] packet filter. Sadly frox doesn&#8217;t support pf.. till now</p>
<p><a name="The_Setup"></a></p>
<h1><span class="mw-headline">The Setup</span></h1>
<p>I wanted a transparent ftp proxy setup which would use my existing squid setup in order to provide caching ftp. I use pf for my firewall (FreeBSD supports: ipfw, ipfilter and pf) so it had to work with my existing firewall setup.</p>
<p>Initially I setup frox-0.7.18 and tried with both ipfw and ipfilter options enable to get transparent redirects working. I setup the following pf rule to redirect to frox:</p>
<pre># Redirect to frox on port 2121
rdr on xl0 proto tcp from $local_net to any port 21 \
        -&gt; $my_gatewaybox port 2121</pre>
<p>and the frox config file as given below. Sadly frox kept replying</p>
<pre>421 Proxy tried to loop. Closing connection</pre>
<p>I tried lots of things to no avail to fix this. Finally I sat down and looked at the code.</p>
<p><a name="Frox_PF_Support"></a></p>
<h1><span class="mw-headline">Frox PF Support</span></h1>
<p>It turns out that frox was complaining about the loop due to the destination address being the localhost/gateway box rather than actual ftp server we wanted to contact. This was due to the pf redirect. Basically the following happens:</p>
<p><a name="Normal_Connection_.28No_transparent_proxying.29"></a></p>
<h2><span class="mw-headline">Normal Connection (No transparent proxying)</span></h2>
<pre>internalhost -&gt; frox -&gt; &lt;tooltip&gt;XQXFTPXQX|XQXFile Transport ProtocolXQX&lt;/tooltip&gt; Server</pre>
<p>Frox gets a connection request:</p>
<p>Connect:</p>
<ul>
<li>From: My internal Address</li>
<li>To: This <span class="glossary" title="File Transport Protocol">FTP</span> Server</li>
</ul>
<p>All is good</p>
<p><a name="rdr_connection_.28Transparent_Proxying.29"></a></p>
<h2><span class="mw-headline">rdr connection (Transparent Proxying)</span></h2>
<p><a name="With_Squid_backend"></a></p>
<h3><span class="mw-headline">With Squid backend</span></h3>
<pre>internalhost -+ rdr
              |
              +- ftp-proxy (gateway box)
                      |
                      | External Cache (ie squid) -&gt; Ftp Server</pre>
<p>Frox gets a connection request:</p>
<p>Connect:</p>
<ul>
<li>From: internal host</li>
<li>To: gatewaybox host</li>
</ul>
<p><a name="Without_Squid_Backend"></a></p>
<h3><span class="mw-headline">Without Squid Backend</span></h3>
<pre>internalhost -+ rdr        +-&gt; &lt;tooltip&gt;XQXFTPXQX|XQXFile Transport ProtocolXQX&lt;/tooltip&gt; Server
              |            |
              +- ftp-proxy +
                      |
                      | Frox Internal cache</pre>
<p>Frox gets a connection request: Connect:</p>
<ul>
<li>From: internal host</li>
<li>To: gateway box</li>
</ul>
<p><a name="Correcting_the_problem"></a></p>
<h2><span class="mw-headline">Correcting the problem</span></h2>
<p>Now the problem is simple. Frox never sees the ftp server address that the client intended to visit if we use the pf redirect. For ipfw, this is not the issue you can use something like:</p>
<pre>ipfw fwd INTERNALGWADDRESS,2121 tcp from INTERNALNETWORK to any dst-port 21 out keep-state</pre>
<p>and ipfw only does the redirect on the &#8216;out&#8217; traffic. Hence frox sees valid information for the ftp server.</p>
<p>IPFilter works as in <code>bsd.c</code> frox has code that asks ipfilter for the external address. But frox has no code to do the same for pf.</p>
<p>Hence I worked on the code to provide the same functionality to frox for pf. The below patch is what I came up with and it works!</p>
<p><a name="Installation"></a></p>
<h1><span class="mw-headline">Installation</span></h1>
<p>To use this code:</p>
<ul>
<li>Download frox-0.7.18.tar.gz from <a class="external free" title="http://frox.sourceforge.net/" rel="nofollow" href="http://frox.sourceforge.net/">http://frox.sourceforge.net/</a></li>
<li>Extract the code <code>tar xvzf frox-0.7.18.tar.gz</code></li>
<li>Run configure <code>./configure</code></li>
<li><code>cd src</code></li>
<li>Download the patch below to the file <code>bsd.diff</code></li>
<li><code>patch &lt; bsd.diff</code></li>
<li>Compile: <code>make</code></li>
</ul>
<p>Now your done, you can use a rule like:</p>
<pre># Redirect to frox on port 2121
rdr on xl0 proto tcp from $local_net to any port 21 \
        -&gt; $my_gatewaybox port 2121</pre>
<p>in <code>pf.conf</code>, and load the rule with <code>pfctl -f pf.conf</code> to make it work.</p>
<p>How you set frox running is up to you!</p>
<p>Hope this helps someone. &#8211;<a title="User:Benjsc" href="http://www.clearchain.com/blog/people/benjamin-close" class="broken_link">Benjsc</a> 10:25, 23 May 2007 (EIT)</p>
<p> </p>
<p><a name="Frox_PF_Transparent_Proxy_Patch"></a></p>
<h1><span class="mw-headline">Frox PF Transparent Proxy Patch</span></h1>
<p>The following patch allows frox to be used as a transparent ftp proxy with the <a class="external text" title="http://www.openbsd.org" rel="nofollow" href="http://www.openbsd.org/">OpenBSD</a> pf packet filter.</p>
<p>The full patch is available at <a class="external free" title="http://www.clearchain.com/~benjsc/download/frox/pf.patch" rel="nofollow" href="http://www.clearchain.com/~benjsc/download/frox/pf.patch">http://www.clearchain.com/~benjsc/download/frox/pf.patch</a></p>
<pre>--- bsd.c.orig  Fri Feb  4 20:54:55 2005
+++ bsd.c       Wed Jul 25 01:25:16 2007
@@ -30,6 +30,16 @@
 #error --enable-transparent-data not supported under BSD
 #endif

+#ifdef PF
+#include &lt;fcntl.h&gt;
+#include &lt;sys/ioctl.h&gt;
+#include &lt;net/if.h&gt;
+#include &lt;net/pfvar.h&gt;
+
+static int natfd;
+#endif
+
+
 #ifdef IPFILTER
 #include &lt;fcntl.h&gt;
 #include &lt;sys/ioctl.h&gt;
@@ -51,6 +61,11 @@
        if(natfd &lt; 0)
                write_log(ERROR, "Unable to initialise IPFilter");
 #endif
+#ifdef PF
+       natfd = open("/dev/pf", O_RDWR);
+       if (natfd == -1)
+               write_log(ERROR, "Unable to initialise PF");
+#endif
        return 0;
 }

@@ -61,6 +76,11 @@
 int get_orig_dest(int fd, struct sockaddr_in *addr)
 {
        socklen_t len;
+#ifdef PF
+    struct pfioc_natlook nl;
+    struct sockaddr_in from;
+    int r2;
+#endif
 #ifdef IPFILTER
        struct natlookup nat;
        struct sockaddr_in from;
@@ -99,6 +119,31 @@
                addr-&gt;sin_family = AF_INET;
                return r2;
        }
+#endif
+#ifdef PF
+       getpeername(fd, (struct sockaddr *) &amp;from, &amp;len);
+       memset(&amp;nl, 0, sizeof(struct pfioc_natlook));
+       memcpy( &amp;nl.daddr.v4, &amp;to.sin_addr.s_addr, sizeof( nl.saddr.v4 ));
+       memcpy( &amp;nl.saddr.v4, &amp;from.sin_addr.s_addr, sizeof( nl.daddr.v4 ));
+       nl.dport = to.sin_port;
+       nl.sport = from.sin_port;
+       nl.af = AF_INET;
+       nl.proto = IPPROTO_TCP;
+       nl.direction = PF_INOUT;
+
+       if ( natfd &gt; 0 ){
+           if (ioctl(natfd, DIOCNATLOOK, &amp;nl)==-1){
+               write_log(ERROR, "Failed to lookup address");
+           }
+           else {
+               memset(addr, sizeof(*addr), 0);
+               memcpy(&amp;addr-&gt;sin_addr.s_addr, &amp;nl.rdaddr.v4.s_addr, sizeof(struct sockaddr_in));
+               addr-&gt;sin_len = sizeof(struct sockaddr_in);
+               addr-&gt;sin_port = nl.rdport;
+               addr-&gt;sin_family = AF_INET;
+               return r2;
+                  }
+          }
 #endif
        memcpy(addr, &amp;to, len);
        return r1;</pre>
<p><a name="Frox_Config_File"></a></p>
<h1><span class="mw-headline">Frox Config File</span></h1>
<p>The config file to use Frox as a transparent ftp proxy with pf.</p>
<pre># $ClearChain: machines/aquila/usr/local/etc/frox.conf,v 1.2 2006/05/23 11:29:15 benjsc Exp $
# Configuration file for frox transparent ftp-proxy.

# Send SIGHUP after editing and it will be reread. This will fail
# completely if we are chrooted and the config file isn't within the
# dir we have chrooted to, or if we have dropped priveleges and no
# longer have permission to read the config file! Some options cannot
# be reread - namely those which require special privelidges (ie.
# BindToDevice, Listen, Port, TransparentData) and the caching stuff.

####################################################################
# Network Options                                                  #
####################################################################

# Address to listen on - default is 0.0.0.0 If you are using an OS other
# than Linux and are doing transparent proxying then you will need to set
# this to the IP of a local interface. If using linux you could leave it
# commented out to listen on all local IPs.
#
# Listen firewall.localnet
# Change it with your ip!
Listen 192.168.154.1

# Port to listen on. Must be supplied.
#
Port 2121

# Whether to run from inetd. You should still define Port above, but
# it isn't used for much.
#
# FromInetd yes

# Stop frox from putting itself into the background. Use this if you want
# to run frox from supervise from djb's daemontools
#
#NoDetach yes

# A hack that should allow you to get away without putting resolver libraries
# into the chroot jail. The default is fine unless for some reason you have
# this hostname in /etc/hosts. If this sort of thing offends you, you may
# comment this out and copy resolver libraries into the chroot jail instead.
# See FAQ section 3.2 for details.
#
#ResolvLoadHack wontresolve.doesntexist.abc

# Another ftp proxy to forward on to. Frox will contact this ftp
# proxy, and send it a login name of the form "user@host:port" where
# host and port are the server frox should contact. If you set
# FTPProxyNoPort then frox will send logins of the form user@host
#
# FTPProxy 192.168.2.9:2222
# FTPProxyNoPort yes

# Pick the IP frox should use for outgoing connections. You probably don't
# need this, and it is not well tested.
#
#TcpOutgoingAddr 192.168.154.1

# Pick the IP that frox should send in PASV replies to the client. Defaults
# to the address frox received the control connection on which you shouldn't
# need to change unless you are doing NAT between frox and your clients, or
# are trying to tunnel connections using frox. See FAQ.
#
#PASVAddress 192.168.0.2

####################################################################
# General Options                                                  #
####################################################################
# User and group to drop priveliges to. This must be specified - if
# you really want to run as root (not a good idea) you must say so
# specifically, and have compiled with --enable-run-as-root.
#
User nobody
Group nogroup

# This is frox's working directory - it must be specified. Temporary
# files and sockets will be created here. If you are using local
# caching then the cache will be stored in this directory too. It
# should be owned by frox with permissions 700. By default frox will
# also chroot to this dir on startup. To avoid this you must specifically
# set DontChroot to Yes.
#
WorkingDir /tmp
DontChroot Yes

# Logging level. 0=No logging. 5=Critical errors only. 10= All errors.
# 15=Errors, other important stuf. 20= Errors, connections, cache
# hits/misses 25=Debug info including text of control session. By
# default frox will log through syslog as facility daemon. If you want
# frox to log to a file instead specify this in LogFile below. You may
# set LogFile to "stderr" if you wish it to log there. XferLogging
# defaults to on, and results in a one line log entry for each file
# transferred irrespective of the log level. You can turn this off
# below.
#
# LogFile /tmp/frox.log
# XferLogging no
#LogLevel 15

# File to store PID in. Default is not to. If this file is not within
# the Chroot directory then it cannot be deleted on exit, but will
# otherwise work fine.
#
PidFile /var/run/frox.pid

####################################################################
# Ftp Protocol Options                                             #
####################################################################

# Active --&gt; Passive conversion. If set then all outgoing connections
# from the proxy will be passive &lt;tooltip&gt;XQXFTPXQX|XQXFile Transport ProtocolXQX&lt;/tooltip&gt;, regardless of the type of the
# connection coming in. This makes firewalling a lot easier. Defaults
# to no.
#
APConv yes

# Passive --&gt; Active conversion. If set then all outgoing connections
# from the proxy will be active &lt;tooltip&gt;XQXFTPXQX|XQXFile Transport ProtocolXQX&lt;/tooltip&gt;, regardless of the type of the
# connection coming in. Defaults to no.
# DO NOT USE WITH APConv!
#
#PAConv yes

# Block PORT commands asking data to be sent to ports&lt;1024 and
# prevent incoming control stream connections from port 20 to
# help depend against ftp bounce attacks. Defaults to on.
#
BounceDefend yes

# If true then only accept data connections from the hosts the control
# connections are to. Breaks the rfc, and defaults to off.
#
# SameAddress yes

# Normally frox strips out nonprintable characters from the control
# stream. This makes buffer overflow attacks on clients/servers much more
# difficult. If you download files that contain non english characters
# this may cause you problems (especially for big charsets like Chines).
# In that case turn on this option.
#
# AllowNonASCII yes

# Try to transparently proxy the data connections as well. Not
# necessary for most clients, and does increase security risks. N.V.
# You probably do _NOT_ need this option. It increases the complexity
# of what frox has to do, increases the difficulty of setting frox up
# correctly, and increases potential security risks. This has nothing
# to do with whether your clients will be transparently proxied. If
# you still want to use this option then read README.transdata for
# details.
#
# TransparentData yes

# Specify ranges for local ports to use for outgoing connections and
# for sending out in PORT commands. By default these are all between
# 40000 and 50000, but you might want to split them up if you have
# complicated firewalling rules.
#
# ControlPorts 40000-40999
# PassivePorts 41000-41999
# ActivePorts  42000-42999

# SSL/AUTH support. Frox must have been linked to the openssl libraries.
# This is currently experimental, and only tested against vsftpd
#
# UseSSL yes
# DataSSL no

####################################################################
# Caching Options                                                  #
####################################################################

# Caching options. There should be at most one CacheModule line, and
# Cache lines to give the options for that caching module. CacheModule
# is &lt;tooltip&gt;XQXHTTPXQX|XQXHyperText Transfer ProtocolXQX&lt;/tooltip&gt; (rewrites ftp requests as &lt;tooltip&gt;XQXHTTPXQX|XQXHyperText Transfer ProtocolXQX&lt;/tooltip&gt; and sends them to a &lt;tooltip&gt;XQXHTTPXQX|XQXHyperText Transfer ProtocolXQX&lt;/tooltip&gt;
# proxy like squid), or local (cache files locally). The relevant
# module needs to have been compiled in at compile time. See FAQ for
# details. If there are no CacheModule lines then no caching will be
# done. "CacheModule None" explicitly requests no caching, and is
# useful to turn off caching within a subsection (below).
#
# CacheModule local
# CacheSize 400
#
CacheModule http
HTTPProxy 127.0.0.1:3128

# MinCacheSize 65536
# ForceHTTP no  # Set to yes to force http file retreiving even if
#               # file is not cacheable
#
# StrictCaching no  # Read FAQ for details.
# CacheOnFQDN yes   # Read FAQ for details.
#
# CacheAll no   # Set to yes to cache non anonymous ftp downloads

# Virus scanning -- see FAQ
#
# VirusScanner '"/usr/bin/viruscan" "--option" "%s"'
# VSOK 0
# VSProgressMsgs 30

####################################################################
# Access control                                                   #
####################################################################

# Allow non-transparent proxying support. The user can connect
# directly to frox, and give his username as user@host:port or
# user@host. Defaults to no. NTPAddress gives the address to which
# incoming connections must be addressed if the client is to be offered
# non-transparent proxying. For most people using this it will be the same
# as the Listen address above. If not given then all connections will be
# offered non transparent proxying. If you are not using transparent
# proxying at all then you should leave NTPAddress commented out.
#
#DoNTP yes
#NTPAddress 192.168.155.1:2121

# Number of seconds of no activity before closing session
# Defaults to 300
#
# Timeout 300

#Maximum number of processes to fork.
#
# MaxForks 0 # For debugging -- only one connection may be served.
MaxForks 10

# Maximum number of connections from a single host (IP address).
MaxForksPerHost 4

# Maximum number of bytes/second to be transferred over the data
# connection for each client. MaxTransferRate limits downloads and
# MaxUploadRate uploads. CacheDlRate is the rate for downloads of files
# that are cached locally - if not set these files will be downloaded at
# full speed.
#
# MaxTransferRate 4096
# CacheDlRate 8192
# MaxUploadRate 4096

# Access control lists:
# The format is: "ACL Allow|Deny SRC - DST [PORTS]"
# a dns name, or * to match everything.
#
# PORTS is a list of ports. If specified then the rule will only match
# if the destination port of the connection is in this list. This is
# likely only relevant if you are allowing non-transparent proxying of
# ftp connections (ie. DoNTP is enabled above). Specifying * is equivalent
# to not specifying anything - all ports will be matched
#
# Any connection that matches no rules will be denied. Since there are
# no rules by default you'll need to add something to let any
# connections happen at all (look at the last example if you are
# feeling lazy/not bothered by security).
#
# # Examples:
# # Allow local network to ftp to port 21 only, and block host ftp.evil
# ACL Deny * - ftp.evil
# ACL Allow 192.168.0.0/255.255.0.0 - * 21
#
# # Allow local network to ftp anywhere except certain dodgy ports. Network
# # admin's machine can ftp anywhere.
# ACL Allow admin.localnet - *
# ACL Deny * - * 1-20,22-1024,6000-6007,7100
# ACL Allow 192.168.0.0/16 - * *
#
# # You don't really believe in this security stuff, and just want
# # everything to work.
ACL Allow * - *

# Command control program: A bit like the idea of a squid redirector.
# By default the old interface is used so as not to break existing
# installations. The new interface is much more powerful, and is
# reccommended for new scripts -- set UseOldCCP to false to use it.
# See the FAQ for details.
#
# CCProgram /usr/local/lib/frox/bin/ccp
# UseOldCCP no

####################################################################
# Subsections                                                      #
####################################################################
# Matching rules the same as ACLS. Only some options can be specified
# in a subsection (currently the yes/no options, timeout, and caching
# options).
#
# SubSection * - ftp.dodgy.server
#  StrictCaching yes
# EndSection
#
# SubSection * - 10.0.0.0/24 # A low latency high bandwidth connection
#  MinCacheSize 4096
# EndSection
#
# Subsection * - ftp.localnetwork
# # To disable caching if it has been turned on in a parent section
#  CacheModule None
# EndSection</pre>
]]></content:encoded>
			<wfw:commentRss>http://www.clearchain.com/blog/posts/frox-pf/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>FreeBSD &amp; WINDOWS VISTA</title>
		<link>http://www.clearchain.com/blog/posts/freebsd-windows-vista</link>
		<comments>http://www.clearchain.com/blog/posts/freebsd-windows-vista#comments</comments>
		<pubDate>Fri, 07 Nov 2008 03:43:22 +0000</pubDate>
		<dc:creator>Benjamin Close</dc:creator>
				<category><![CDATA[FreeBSD]]></category>
		<category><![CDATA[bcdedit]]></category>
		<category><![CDATA[bootloader]]></category>
		<category><![CDATA[dual boot]]></category>
		<category><![CDATA[grub]]></category>
		<category><![CDATA[mbr]]></category>
		<category><![CDATA[vista]]></category>

		<guid isPermaLink="false">http://www.clearchain.com/blog/?p=44</guid>
		<description><![CDATA[Dual Booting Windows Vista &#38; FreeBSD / Linux / Some other OS The Problem After installing Windows Vista Enterprise Edition, I very quickly wanted to get back to FreeBSD. As per previous versions of Windows, Vista does a great job of overwriting the Master boot record (MBR). Unlike previous versions of windows, you cannot just [...]]]></description>
			<content:encoded><![CDATA[<p><big>Dual Booting Windows Vista &amp; FreeBSD / Linux / Some other OS</big></p>
<h2><span class="mw-headline">The Problem</span></h2>
<p>After installing Windows Vista Enterprise Edition, I very quickly wanted to get back to FreeBSD. As per previous versions of Windows, Vista does a great job of overwriting the Master boot record (MBR). Unlike previous versions of windows, you cannot just install a different boot loader in the MBR &#8211; so I found out the hard way. (It used to be sooo easy fdisk /mbr would fix any broken boot sectors, then just install your favourite boot loader).<span id="more-44"></span></p>
<p>Vista writes a unique disk id in the MBR. This unique id (UID) is used by Vista to determine what disk is what. It does make some sense, Hardware can shift around, but the UID should always be the same. This allows Vista to always know where it&#8217;s files are and to appropriate label drive C: as the correct drive.</p>
<p>Installing another boot loader, however (ie Grub, lilo, the FreeBSD boot0 / boot loader /boot manager) will overwrites the UID in the MBR and Vista fails to load with an error:</p>
<pre>"unable to access \windows\winload.exe"</pre>
<p>The error message is semi appropriate but very misleading. What it really should say is &#8221;I can&#8217;t work out which of my the drives has my files on it hence I can&#8217;t find winload.exe&#8221;.</p>
<ul>
<li>&#8216;Full details about the UID can be found at: <a class="external free" title="http://multibooters.co.uk/mbr.html" rel="nofollow" href="http://multibooters.co.uk/mbr.html">http://multibooters.co.uk/mbr.html</a></li>
</ul>
<p><a name="Existing_Solutions"></a></p>
<h3><span class="mw-headline">Existing Solutions</span></h3>
<p>Out on the web there is many solutions to the dreaded winload.exe. Many of them are misleading, some I believe are not even tested. Also many apply to Vista Release Candidate 1 (rc1) which I believe didn&#8217;t required the UID to be present in order to successfully boot. Below is some of the solutions that people say work (but Ifound didn&#8217;t).</p>
<p><a name="Using_Grub"></a></p>
<h4><span class="mw-headline">Using Grub</span></h4>
<ul>
<li>Ref: <a class="external free" title="http://ubuntuforums.org/showthread.php?t=358175" rel="nofollow" href="http://ubuntuforums.org/showthread.php?t=358175">http://ubuntuforums.org/showthread.php?t=358175</a></li>
<li>Ref: <a class="external free" title="http://blogs.sun.com/moinakg/entry/vista_and_solaris_express_dual" rel="nofollow" href="http://blogs.sun.com/moinakg/entry/vista_and_solaris_express_dual">http://blogs.sun.com/moinakg/entry/vista_and_solaris_express_dual</a></li>
</ul>
<p>Some say grub loading windows with something like:</p>
<pre>Title Vista
  root (hd0,0)
  makeactive
  chainloader +1</pre>
<p>will work &#8211; but grub still over writes the MBR hence the same issue will occur &#8211; though you may be lucky as the grub MBR is really small (and might leave the UID) untouched.</p>
<p><a name="Using_gag"></a></p>
<h4><span class="mw-headline">Using gag</span></h4>
<p>There&#8217;s reports on a FreeBSD mailing list that gag will work, thought I&#8217;m running FreeBSD/amd64 which gag or grub for that matter won&#8217;t compile on. I know I could always install the lib32 compatability distribution to use it but I wanted the default FreeBSD boot loader.</p>
<p><a name="Using_the_Vista_Boot_Loader"></a></p>
<h4><span class="mw-headline">Using the Vista Boot Loader</span></h4>
<ul>
<li>Refs: <a class="external free" title="http://www.tech-recipes.com/rx/2014/vista_using_bcdedit_boot_up_options_dual_boot_xp_prof'" rel="nofollow" href="http://www.tech-recipes.com/rx/2014/vista_using_bcdedit_boot_up_options_dual_boot_xp_prof'">http://www.tech-recipes.com/rx/2014/vista_using_bcdedit_boot_up_options_dual_boot_xp_prof&#8217;</a></li>
</ul>
<p>Many people have given up on trying to use a normal boot loader, and instead use the Vista boot loader.<br />
The WinXP/NT bootloader (ntldr &amp; config file boot.ini) have been replaced with files winboot.exe and bcedit.exefor configuration.</p>
<p>Theses commands could be setup to boot other operating systems though your milege may vary.</p>
<p><a name="Commercial_Software"></a></p>
<h4><span class="mw-headline">Commercial Software</span></h4>
<p>Many people have decided it&#8217;s all too hard and gone and purchased software to handle it for them &#8211; there&#8217;s lots out there</p>
<ul>
<li>VistaBoot (<a class="external free" title="http://vistabootpro.org" rel="nofollow" href="http://www.vistabootpro.org/">http://vistabootpro.org</a>)</li>
<li>EasyBCD</li>
</ul>
<p><a name="Utilities"></a></p>
<h4><span class="mw-headline">Utilities</span></h4>
<ul>
<li>Ref: <a class="external free" title="http://www.sysint.no/en/Download.aspx" rel="nofollow" href="http://www.sysint.no/en/Download.aspx">http://www.sysint.no/en/Download.aspx</a></li>
</ul>
<p>There is many utilities that claim to fix the issue. One such util is MBRFix.exe, this fixes the fact that vista won&#8217;t boot but it will clobber any boot loader you have got installed.</p>
<p><a name="The_Fix_.28That_Worked.29"></a></p>
<h2><span class="mw-headline">The Fix (That Worked)</span></h2>
<ul>
<li>Obtained from: <a class="external free" title="http://forum.onmac.net/showthread.php?t=1324" rel="nofollow" href="http://forum.onmac.net/showthread.php?t=1324">http://forum.onmac.net/showthread.php?t=1324</a></li>
</ul>
<p>The simple fix is to tell Vista that the drive it boots off of will always be the drive it can find its files on. This way you can clobber the UID in the MBR as much as you want and Vista won&#8217;t care. To do this you run:</p>
<pre>BCDEDIT /set {bootmgr} device boot
BCDEDIT /set {default} device boot
BCDEDIT /set {default} osdevice boot</pre>
<p>This can be run from either the Vista repair cd, from within Vista, or from something like<a class="external free" title="http://www.ultimatebootcd.com" rel="nofollow" href="http://www.ultimatebootcd.com/">http://www.ultimatebootcd.com</a> (For Windows).</p>
<p><a name="Conclusion"></a></p>
<h2><span class="mw-headline">Conclusion</span></h2>
<p>Hence it IS possible to run Vista with any boot loader that you like &#8211; in my case the FreeBSD boot loader is the one of choice.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.clearchain.com/blog/posts/freebsd-windows-vista/feed</wfw:commentRss>
		<slash:comments>11</slash:comments>
		</item>
	</channel>
</rss>
