<?xml version="1.0" encoding="utf-8"?>
<feed version="0.3" xmlns="http://purl.org/atom/ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xml:lang="en">
<title>Spiffed&apos;s Computing Notebook</title>
<link rel="alternate" type="text/html" href="http://spiffie.org/computing/" />
<modified>2009-02-24T06:02:38Z</modified>
<tagline></tagline>
<id>tag:spiffie.org,2009:/computing//2</id>
<generator url="http://www.movabletype.org/" version="4.23-en">Movable Type</generator>
<copyright>Copyright (c) 2009, spiffed</copyright>

<entry>
<title>The cord for PowerEdge 6650, Proliant DL580 G2, and other high powered devies.</title>
<link rel="alternate" type="text/html" href="http://spiffie.org/computing/archives/2009/02/the_cord_for_po.html" />
<modified>2009-02-24T06:02:38Z</modified>
<issued>2009-02-24T05:14:21Z</issued>
<id>tag:spiffie.org,2009:/computing//2.93</id>
<created>2009-02-24T05:14:21Z</created>
<summary type="text/plain">Almost all servers, desktops, UPSs, and other computing hardware uses an IEC C14 socket (which mates with an IEC C13 plug) (like the ones below). Larger devices which draw more current, however, use a C20 socket (and C19 plug). They...</summary>
<author>
<name>spiffed</name>

<email>spiffed@spiffie.org</email>
</author>
<dc:subject>Hardware</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://spiffie.org/computing/">
<![CDATA[<p>Almost all servers, desktops, UPSs, and other computing hardware uses an IEC C14 socket (which mates with an IEC C13 plug) (like the ones below).</p>

<p><img src="/computing/archives/2009/02/24/200px-IEC60320_C14.jpg" alt="" title="" /> <img src="/computing/archives/2009/02/24/200px-IEC60320_C13.jpg" alt="" title="" /></p>

<p>Larger devices which draw more current, however, use a C20 socket (and C19 plug). They look like an angry slit-eyed C19 plug, they&#8217;re also square (see below).</p>

<p><img src="/computing/archives/2009/02/24/PXO596_400px.jpg" alt="" title="" /> <img src="/computing/archives/2009/02/24/2007731144253762.jpg" alt="" title="" /></p>

<p>Almost certainly, you&#8217;re now thinking the hardware manufacturer hates you. If this is used equipment, the cord is never included, and if it&#8217;s new equipment, the cord is usually a C20 to C19 cord - and you likely don&#8217;t have a C20 outlet handy.</p>

<p><ul><li>If you do have C20 outlets in your PDU or UPS available, you want a (or more likely two) C20 to C19 cord(s) like the one below.<br>
<a href="http://www.infinitecables.com/pop/cb_pw-125.htm"><img src="/computing/archives/2009/02/24/cb_pw-125.jpg" alt="" title="" /></a>
<li>If you don&#8217;t have a C20 outlet available, and your equipment draws less than 15 amps, you likely want either a NEMA 5-15P to C19 or C14 to C19 cord<br>
<a href="http://www.infinitecables.com/pop/cb_pw-121.htm"><img src="/computing/archives/2009/02/24/cb_pw-121.jpg" alt="" title="" /></a> <a href="http://www.infinitecables.com/pop/cb_pw-120.htm"><img src="/computing/archives/2009/02/24/cb_pw-120.jpg" alt="" title="" /></a>
<li>If you&#8217;re crazy, you can swap out the C20 for C14 sockets. They generally have the same tooling. This is of course wildly out of spec.
<li>If you&#8217;re equipment draws more than 15 amps, and you don&#8217;t have C20 outlets handy, you likely want some form of &#8216;twist-lock&#8217; style NEMA plug (like an L5 or L6 or maybe, but not likely, an L7) to C19 cord.
<li>If you&#8217;re equipment draws more than 15 amps, and you don&#8217;t have C20 outlets, and you don&#8217;t have NEMA &#8216;twist-lock&#8217; outlets, then you maybe want a NEMA 5-20R or TT-30 to C19 cord.
<li>Finally, if you&#8217;re equipment draws more than 15 amps, and you don&#8217;t have C20 outlets, and you don&#8217;t have NEMA &#8216;twist-lock&#8217; outlets, and you don&#8217;t have either of the (barely) normal non-locking NEMA connectors, you likely need an electrician. Either you have odd high-amperage outlets and need new outlets or an adapter or you have no high-amperage outlets and you either need new outlets or a new circuit.</p>
]]>


</content>
</entry>

<entry>
<title>Fixing bad MSS discovery across iptables based firewalls</title>
<link rel="alternate" type="text/html" href="http://spiffie.org/computing/archives/2009/02/fixing_bad_mss.html" />
<modified>2009-02-18T02:32:19Z</modified>
<issued>2009-02-18T02:16:48Z</issued>
<id>tag:spiffie.org,2009:/computing//2.92</id>
<created>2009-02-18T02:16:48Z</created>
<summary type="text/plain">If you have an iptables based firewall with differing MTUs on it&apos;s public and private interfaces, you may need to use iptables TCPMSS target to force proper MSS discovery....</summary>
<author>
<name>spiffed</name>

<email>spiffed@spiffie.org</email>
</author>
<dc:subject>Linux</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://spiffie.org/computing/">
<![CDATA[<p>If you have an <code>iptables</code> based firewall with differing MTUs on it's public and private interfaces, you may need to use <code>iptables</code> <code>TCPMSS</code> target to force proper MSS discovery.</p>
]]>
<![CDATA[<p>First, check to see if you have differing MTUs using <code>ip link show [interface]</code>. If they have the same MTU (generally 1500 for ethernet) or your external MTU is the larger value, then you most likely don't need MSS correction. If you're having trouble with MSS, you'll see things like web browsers that connect but then hang with no data received, and ssh connecting properly, but scp hangs after the initial handshake.</p>

<pre><code>    spiffed@ring:~$ ip link sh eth0
    2: eth0: &lt;BROADCAST,MULTICAST,UP,10000&gt; mtu 576 qdisc pfifo_fast qlen 1000
        link/ether 00:0c:41:87:82:9b brd ff:ff:ff:ff:ff:ff
    spiffed@ring:~$ ip link sh eth1
    3: eth1: &lt;BROADCAST,MULTICAST,UP,10000&gt; mtu 1500 qdisc pfifo_fast qlen 1000
        link/ether 00:b0:d0:96:6a:c9 brd ff:ff:ff:ff:ff:ff
</code></pre>

<p>Here you can see that my external interface (eth0) has a much smaller MTU of 576. Use a line like the following to magically clamp the MSS to 40 bytes below the MTU.</p>

<p><code>sudo   iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth1 -j TCPMSS --clamp-mss-to-pmtu</code></p>

<p>Largely based on the <a href="http://www.linuxtopia.org/Linux_Firewall_iptables/x4700.html">"Linux Packet Filtering and iptables"</a> guide.</p>
]]>
</content>
</entry>

<entry>
<title>Use molly-guard and stop rebooting the wrong server</title>
<link rel="alternate" type="text/html" href="http://spiffie.org/computing/archives/2009/02/use_molly-guard.html" />
<modified>2009-02-11T05:04:38Z</modified>
<issued>2009-02-11T04:28:41Z</issued>
<id>tag:spiffie.org,2009:/computing//2.90</id>
<created>2009-02-11T04:28:41Z</created>
<summary type="text/plain">Molly-guard is the unix admin analog to Gmail&apos;s mail goggles. Named after the physical molly-guard, the molly-guard command wraps various commands (by default the halt/reboot/shutdown/poweroff group) and performs various actions before calling them (by default, asking you which host this...</summary>
<author>
<name>spiffed</name>

<email>spiffed@spiffie.org</email>
</author>
<dc:subject>Linux</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://spiffie.org/computing/">
<![CDATA[<p><a href="http://packages.debian.org/etch-backports/molly-guard">Molly-guard</a> is the unix admin analog to Gmail's <a href="http://gmailblog.blogspot.com/2008/10/new-in-labs-stop-sending-mail-you-later.html">mail goggles</a>.</p>

<p>Named after the <a href="http://catb.org/jargon/html/M/molly-guard.html">physical molly-guard</a>, the molly-guard command wraps various commands (by default the halt/reboot/shutdown/poweroff group) and performs various actions before calling them (by default, asking you which host this is). <em>It's a life saver when you've nearly powered down the production database server in a $250/incident datacenter 2000km away thinking it was the print server in the other room.</em></p>
]]>
<![CDATA[<p>I'm installing the package in Debian Etch, but there are packages for other Debian releases and, of course, Ubuntu. Normally you'd only need to do <code>sudo apt-get install molly-guard</code>, but Etch's version is very old. Grab from back-ports and install with <code>dpkg</code>.</p>

<ul>
<li><code>wget http://www.mirrorservice.org/sites/backports.org/pool/main/m/molly-guard/molly-guard_0.4.4-2%7ebpo40%2b1_all.deb</code></li>
<li><code>sudo dpkg -i molly-guard_0.4.4-2~bpo40+1_all.deb</code></li>
</ul>

<p>Now that it's installed, try it out (<em>on a non production box</em>). Here you can see it save me from rebooting the box <code>enterprise</code> that I thought was <code>marathon</code>. Obviously this is of no use if you thought that <code>enterprise</code> was the nethack server.</p>

<pre><code>    Enterprise:~$ sudo reboot
    W: molly-guard: SSH session detected!
    Please type in hostname of the machine to reboot: marathon
    Good thing I asked; I won't reboot Enterprise ...
    W: aborting reboot due to 30-query-hostname exiting with code 1.
    Enterprise:~$
</code></pre>

<p>By default you're only protected on sessions that <em>look</em> like SSH sessions (have <code>$SSH_CONNECTION</code> set). If, like us, you use alot of virtual machines and RILOE cards, edit <code>/etc/molly-guard/rc</code> and uncomment <code>ALWAYS_QUERY_HOSTNAME=true</code>. Now you should be prompted for any interactive session.</p>
]]>
</content>
</entry>

<entry>
<title>Removing EXIF data with find and jhead</title>
<link rel="alternate" type="text/html" href="http://spiffie.org/computing/archives/2008/08/removing_exif_d.html" />
<modified>2008-08-25T19:18:07Z</modified>
<issued>2008-08-25T18:33:04Z</issued>
<id>tag:spiffie.org,2008:/computing//2.85</id>
<created>2008-08-25T18:33:04Z</created>
<summary type="text/plain">Let&#8217;s imagine you&#8217;ve got a load of pictures on a *nix box somewhere, and you&#8217;d prefer they didn&#8217;t have EXIF data attached? You&#8217;d need a way to find all the jpeg files and a way to strip their EXIF data....</summary>
<author>
<name>spiffed</name>

<email>spiffed@spiffie.org</email>
</author>
<dc:subject>Unix</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://spiffie.org/computing/">
<![CDATA[<p>Let&#8217;s imagine you&#8217;ve got a load of pictures on a *nix box somewhere, and you&#8217;d prefer they didn&#8217;t have <a href="http://en.wikipedia.org/wiki/Exchangeable_image_file_format">EXIF</a> data attached? You&#8217;d need a way to find all the jpeg files and a way to strip their EXIF data. Thankfully, both tasks are easily solved, one with find and one with <a href="http://www.sentex.net/~mwandel/jhead/">jhead</a>.</p>

<h3>Using jhead</h3>

<p>A look at the <a href="http://www.sentex.net/~mwandel/jhead/">jhead page</a> shows the <code>--purejpg</code> argument will strip any EXIF data.</p>

<h3>Building the find query</h3>

<p>We need to find files who&#8217;s name ends in <code>.jpg</code>, <code>.jpeg</code>, <code>.JPG</code>, or <code>.JPEG</code> in a given directory tree. A quick look at the <a href="http://unixhelp.ed.ac.uk/CGI/man-cgi?find">find man page</a> shows us the <code>-iregex</code> parameter accepts a case insensitive regexp. <code>.*\.jpe?g$</code> looks for the following parameters:</p>

<ul>
<li><code>.*</code> - any number of characters</li>
<li><code>.jp</code> - the literal characters <code>.</code> <code>j</code> and <code>p</code></li>
<li><code>e?</code> - one or no <code>e</code> characters.</li>
<li><code>g</code> - a litteral <code>g</code> character</li>
<li><code>$</code> - and these must all be at the very end of the string</li>
</ul>

<p>The parameter <code>-exec</code> will execute a command on any matching files, substituting the actual filename for <code>{}</code>, and we must end the command with a <code>;</code>.</p>

<h3>The final command</h3>

<p><code>find . -iregex '.*\.jpe?g$' -exec jhead -purejpg '{}' \;</code></p>

<p>This will find any file with a .jpg or .jpeg extension (in any case) in the current directory (recursively) and strip it&#8217;s exif data.</p>

<h3>One step further</h3>

<p>Maybe you didn&#8217;t name all your JPEG files <code>something.jpg</code>. Maybe you named them foo_picture; how ever will you find them? Enter the unix &#8216;file&#8217; command, it reads a files contents and looks for keys to it&#8217;s file type. We&#8217;ll use it here to build a command that searches the tree looking for files that look like binary jpeg files.</p>

<ul>
<li><code>find . -type f -exec file -i -F \0 '{}' \;</code> - Find actual files (<code>-type f</code>) and execute the file command on them, but set file to seperate it&#8217;s data with NULLs (since you&#8217;re unlikely to have a NULL in your filename) and output the results as a mime type (because it&#8217;s easier to parse later).</li>
<li><code>awk -F\0 '$2 == " image/jpeg" {printf "%s\0",$1}'</code> - use awk to check the type feild for the jpeg mime type, then only print the file path (followed by a NULL).</li>
<li><code>xargs -0 -n 1 jhead -purejpg</code> - use xargs to split the input on NULLs and feed one path at a time to the jhead command.</li>
</ul>

<p>Putting it all togeather, we get <code>find . -type f -exec file -i -F \0 '{}' \;|awk -F\0 '$2 == " image/jpeg" {printf "%s\0",$1}'|xargs -0 -n 1 jhead -purejpg</code></p>

<p>This is, of course, much slower than the pattern matching find command above.</p>

<pre><code> time find ./public_html/ -type f -exec file -i -F \0 '{}' \; \
    |awk -F\0 '$2 == " image/jpeg" {printf "%s\0",$1}'|xargs -0 -n 1 jhead -purejpg
 real    0m21.299s
 user    0m4.214s
 sys     0m16.290s

 time find ./public_html/ -iregex '.*\.jpe?g$' -exec jhead -purejpg '{}' \;
 real    0m7.819s
 user    0m0.548s
 sys     0m2.565s
</code></pre>

<p>And that&#8217;s after the entire directory tree has been pulled into memory cache!</p>
]]>


</content>
</entry>

<entry>
<title>Unfreezing Screen</title>
<link rel="alternate" type="text/html" href="http://spiffie.org/computing/archives/2008/08/unfreezing_scre.html" />
<modified>2008-08-20T15:04:55Z</modified>
<issued>2008-08-20T14:57:13Z</issued>
<id>tag:spiffie.org,2008:/computing//2.81</id>
<created>2008-08-20T14:57:13Z</created>
<summary type="text/plain">I&#8217;m sure many people have done this: typed a command, then realized they&#8217;ll need root, so they hit ctrl-a for the beginning of the line, then started typing sudo. And this works wonderfully, unless your in a screen session, in...</summary>
<author>
<name>spiffed</name>

<email>spiffed@spiffie.org</email>
</author>
<dc:subject>Unix</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://spiffie.org/computing/">
<![CDATA[<p>I&#8217;m sure many people have done this: typed a command, then realized they&#8217;ll need root, so they hit <tt>ctrl-a</tt> for the beginning of the line, then started typing <tt>sudo</tt>. And this works wonderfully, unless your in a screen session, in which case it locks up completely.</p>

<p>From the <a href="http://www.manpagez.com/man/1/screen/">screen manpage</a> we see that <tt>ctrl-a</tt> puts screen into command mode, and the <tt>s</tt> of <tt>sudo</tt> sends an &#8216;xoff&#8217; to the terminal.</p>

<p>What does xoff do? It&#8217;s a control signal in xon/xoff handshaking that says &#8216;stop sending data to me&#8217;, so the machine stops sending your terminal data.</p>

<p>To get your screen session back, send <tt>ctrl-a</tt> then <tt>q</tt>. This sends the matching xon. Xon ofcourse says &#8216;go ahead, send data, I&#8217;m ready&#8217;.</p>

<p>To avoid the issue in the first place, use <tt>ctrl-a</tt> followed by <tt>a</tt> to jump to the beginning of the line.</p>
]]>


</content>
</entry>

<entry>
<title>Printing Canada Post CN22 Labels</title>
<link rel="alternate" type="text/html" href="http://spiffie.org/computing/archives/2008/03/printing_canada.html" />
<modified>2008-03-25T18:37:16Z</modified>
<issued>2008-03-25T18:27:04Z</issued>
<id>tag:spiffie.org,2008:/computing//2.64</id>
<created>2008-03-25T18:27:04Z</created>
<summary type="text/plain">If you do alot of cross-border shipping, you no doubt have a whack of CN22 customs forms to fill-out everyday. This template should make your life just a little easier....</summary>
<author>
<name>spiffed</name>

<email>spiffed@spiffie.org</email>
</author>
<dc:subject>Online Sales</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://spiffie.org/computing/">
<![CDATA[<p>If you do alot of cross-border shipping, you no doubt have a whack of CN22 customs forms to fill-out everyday. This template should make your life just a little easier.</p>
]]>
<![CDATA[<p>The <a href="http://spiffie.org/computing/archives/2008/03/25/CN22%20Template.doc">word template is a mail-merge master</a> designed for 5-up customs form printing (they come packaged in strips of 5). If you don't fill out a value or weight, it will leave them blank. If you do, it'll add <code>$</code> and <code>KG</code> as appropriate. I've provided a <a href="http://spiffie.org/computing/archives/2008/03/25/CN22%20Data%20Source.doc">sample Word data-source</a>, but you can feed it from anything you like.</p>

<p><img src="http://spiffie.org/computing/archives/2008/03/25/CN22%205-up%20printed.jpg" alt="" title="" /></p>

<p>As you can see, it's not perfect, but it's not bad either. It's certainly easier than filling them out by hand!</p>
]]>
</content>
</entry>

<entry>
<title>DIY Antistatic wrap</title>
<link rel="alternate" type="text/html" href="http://spiffie.org/computing/archives/2008/03/diy_antistatic.html" />
<modified>2008-03-12T15:16:41Z</modified>
<issued>2008-03-12T15:13:55Z</issued>
<id>tag:spiffie.org,2008:/computing//2.62</id>
<created>2008-03-12T15:13:55Z</created>
<summary type="text/plain"> Some people are more resourceful then others. I received these as a return, complete with tin-foil/aluminium-foil to fight static (or ward off mind rays?)....</summary>
<author>
<name>spiffed</name>

<email>spiffed@spiffie.org</email>
</author>
<dc:subject>Hardware</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://spiffie.org/computing/">
<![CDATA[<p><script src="/script/flickrnotes.php?2328424099"></script></p>

<p>Some people are more resourceful then others. I received these as a return, complete with tin-foil/aluminium-foil to fight static (or ward off mind rays?).</p>
]]>


</content>
</entry>

<entry>
<title>Packaging and Shipping eBay Items.</title>
<link rel="alternate" type="text/html" href="http://spiffie.org/computing/archives/2008/03/packaging_and_s.html" />
<modified>2008-03-03T20:08:57Z</modified>
<issued>2008-03-03T19:28:45Z</issued>
<id>tag:spiffie.org,2008:/computing//2.60</id>
<created>2008-03-03T19:28:45Z</created>
<summary type="text/plain"> This is a short tutorial on going from PayPal payment emails to packaged products....</summary>
<author>
<name>spiffed</name>

<email>spiffed@spiffie.org</email>
</author>
<dc:subject>Online Sales</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://spiffie.org/computing/">
<![CDATA[<p><script src="/script/flickrnotes.php?2308379336"></script></p>

<p>This is a short tutorial on going from PayPal payment emails to packaged products.</p>
]]>
<![CDATA[<p><script src="/script/flickrnotes.php?2307573693"></script></p>

<p>The journey starts with my inbox full of PayPal instant payment emails. At this point, some-one has already dealt with the WebStore purchases and PayPal eChecks. (We file eChecks away until they clear, then the "you're received a cleared eCheck payment" emails are processed with the instant payments. There are none today.)
Personally, I now move all the payment emails into their own temporary folder; other people work in-situ.</p>

<p><script src="/script/flickrnotes.php?2308379154"></script></p>

<p>All of the emails are opened (one-at-a-time) and I open each the PayPal link in a new tab of one Firefox window. (The paypal link begins with "https://www.paypal.com".) The email can now be closed, we'll come back to them later.
From here, you should work moderately quickly to avoid PayPal logging you out.</p>

<p><script src="/script/flickrnotes.php?2307573767"></script></p>

<p>Once all the payment emails are open in tabs, I print the transaction details page for each tab. These serve as the payment records and get filed into the accounting filing-cabinet. This will be a two-page document, so either print two-up or use a duplex printer.</p>

<p>Once you've printed a page, scroll to the bottom and click 'Packing Slip'.</p>

<p><script src="/script/flickrnotes.php?2308379222"></script></p>

<p>Now you have a window with packing slips in tabs. Print each packing slip. These are only one page.</p>

<p><script src="/script/flickrnotes.php?2308397178"></script></p>

<p>We have a template for our shipping labels. Both Avery and Uline provide downloadable templates on their website. We've modified our template to use a mono-space font with an appropriate size.
From each email, copy the shipping address and paste it into a blank area on your label template. If, like us, you re-use partial sheets of labels, ensure you skip any used cells. I find the <a href="http://www.stevemiller.net/puretext/">PureText tool</a> is great for enforcing your own formatting on copied text.
Go ahead and print the labels now.</p>

<p>Depending on your postal system, you may now need to print shipping labels for oversized or international shipments. In the US, stamps.com and click-n-ship are popular; in Canada, Canada Post's ePost/OBC is your only option. If correctly setup, PayPal offers access to online shipping tools through a link called 'Shipping Label' at the bottom of the transaction details page (near the 'packing slip' link). Sadly, this step is left as an exercise to the reader.</p>

<p><script src="/script/flickrnotes.php?2307573925"></script></p>

<p>Now it's time to do the actual work. Gather up your tools and supplies.</p>

<ul>
<li>Boxes and Anti-Static Cushioning. You'll need these for any items larger than an envelope.</li>
<li>Envelopes. These are great for small/flat objects. We have small, medium, and jinormous sizes.</li>
<li>Stamps. If you're using the conventional postal service, you'll need appropriate stamps. I cut my rolls of stamps up into strips of of 10, then staple them into books.</li>
<li>Return Address Labels. These are much easier than writing your address in the corner of every envelope and cheaper than pre-printed envelopes. You may either print your own or buy them preprinted. We put these on everything, even packages with packing labels. You want these to be <em>really</em> sticky; if all else fails you want your package back.</li>
<li>Packing Slips and Transaction Details. The packing slip is inserted into every envelope, and the transaction detail page is used to confirm we've packaged the correct items. Later the transaction details are filed away for accounting.</li>
<li>Anti-Static Bags and Warning Labels. We package everything in these poly-anti-static bags. The yellow anti-static stickers are very professional looking.</li>
<li>Address Labels. These are the printed address labels we made previously. We use pink, yellow, blue, and white address labels to separate our outgoing mail. You should use whatever is right for you.</li>
<li>Printed Shipping Labels. (Not Pictured) Printed address labels are used for anything that can't be sent regular/first-class mail.</li>
<li>Scissors and Tape. Trust us, you'll need them. You'll need to tape any non-adhesive packing labels; additionally, we tape the flaps of the envelopes closed.</li>
<li>Scale. Everything will need to be weighed. Simply guessing the weight is a recipe for overpayment or returned packages.</li>
</ul>

<p><script src="/script/flickrnotes.php?2308379336"></script></p>

<p>Fold, stuff, stuff, seal, label, label, stamp, tape, done.
Pack your items as appropriate, I have nothing to add here.</p>

<p><script src="/script/flickrnotes.php?2307573991"></script> <script src="/script/flickrnotes.php?2308379404"></script></p>

<p>Now back to your computer! Reply to each of your payment emails (the reply-to should automatically be the customer). In the reply, you can safely delete everything above "Item# blahblah" and everything below "Total: blahblah". You should also shorten the title to "Re: Item #blahblahblah".</p>

<p>Now add a nice blurb to the top explaining you've shipped their item and how long you expect it will take. I use <a href="http://www.nagarsoft.com/directaccess/overview/">Direct Access</a> to save typing, but you can copy and paste. There's a separate blurb for overseas, US, and Canadian shipping. There's also special emails for FedEx/DHL/UPS packages.</p>

<p>Take the packages to their drop-off location, and you're all set.</p>
]]>
</content>
</entry>

<entry>
<title>Markdown and flickrnotes</title>
<link rel="alternate" type="text/html" href="http://spiffie.org/computing/archives/2008/02/markdown_and_fl.html" />
<modified>2008-03-07T06:14:50Z</modified>
<issued>2008-02-26T18:30:31Z</issued>
<id>tag:spiffie.org,2008:/computing//2.58</id>
<created>2008-02-26T18:30:31Z</created>
<summary type="text/plain">Markdown makes writing in Movable Type painless and flickrnotes makes embedding flickr images relatively easy, but together, they make embedding flickr images completely painless....</summary>
<author>
<name>spiffed</name>

<email>spiffed@spiffie.org</email>
</author>
<dc:subject>Software Problems</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://spiffie.org/computing/">
<![CDATA[<p><a href="http://daringfireball.net/projects/markdown/">Markdown</a> makes writing in Movable Type painless and <a href="http://www.ladyada.net/rant/2007/02/you-have-defeated-ie6-you-gain-12-exp-and-4-gold/">flickrnotes</a> makes embedding flickr images relatively easy, but together, they make embedding flickr images completely painless.</p>
]]>
<![CDATA[<p>I won't go into how to install both packages, so go make them both work, then come back.</p>

<p>I use the format <em>&#37;(flick-image-number)</em> to engage flickrnotes from within markdown. To do this: open your <code>Markdown.pl</code> file (usually in the movable type plugin directory). Scroll down to <code>sub _DoImages {</code>. At the very end of the subroutine insert the following code (you will need to change the path to flickrnotes from <code>/script/flickrnotes.php</code>:</p>

<pre><code># Next, handle inline flickr images:  %(flickr_image_number)

$text =~ s{
    (               # wrap whole match in $1
      %\(           # literal paren
        [ \t]*
        &lt;?(\S+?)&gt;?  # src url = $2
        [ \t]*
      \)
    )
}{
    my $result;
    my $whole_match = $1;
    my $url         = $2;

    $result = "&lt;script src=\"/script/flickrnotes.php?$url\"&gt;&lt;/script&gt;";

    $result;
}xsge;
</code></pre>

<p>Alternately, you can <a href="http://spiffie.org/computing/archives/2008/02/26/Markdown.zip">download my pre-modified Markdown.pl file</a> and simply replace your existing one.</p>

<p>Now try it out. Before markdown, linking to flickr was something like this: <code>&lt;a href="http://flickr.com/photos/spiffed/2283833703/"&gt;&lt;img src="http://farm3.static.flickr.com/2362/2283833703_bd86b1477c.jpg?v=0"&gt;</code>.</p>

<p>After markdown, it looked something like this: <code>[![](http://farm3.static.flickr.com/2362/2283833703_bd86b1477c.jpg?v=0)](http://flickr.com/photos/spiffed/2283833703/)</code></p>

<p>With flickrnotes, it looked something like: <code>&lt;script src="/script/flickrnotes/?2283833703"&gt;&lt;/script&gt;</code></p>

<p>Now it just looks like this:</p>

<pre><code> %(2283833703)
</code></pre>
]]>
</content>
</entry>

<entry>
<title>Installing Windows 3.1 in VMWare</title>
<link rel="alternate" type="text/html" href="http://spiffie.org/computing/archives/2007/09/installing_wind.html" />
<modified>2007-09-01T05:09:13Z</modified>
<issued>2007-09-01T04:39:54Z</issued>
<id>tag:spiffie.org,2007:/computing//2.46</id>
<created>2007-09-01T04:39:54Z</created>
<summary type="text/plain">If you plan on installing Windows 3.1 or even just DOS in VMWare, you&apos;ll need a few extra things. I have prepared a floppy image containing utilities for DOS in VMWare. It contains the following: DOSIDLE.EXE - A small TSR...</summary>
<author>
<name>spiffed</name>

<email>spiffed@spiffie.org</email>
</author>
<dc:subject>Software Problems</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://spiffie.org/computing/">
<![CDATA[<p>If you plan on installing Windows 3.1 or even just DOS in VMWare, you'll need a few extra things. I have prepared a <a href="http://spiffie.org/computing/archives/2007/09/01/VMWare4Dos.zip">floppy image containing utilities for DOS in VMWare</a>.</p>

<p>It contains the following:</p>

<ul>
<li><code>DOSIDLE.EXE</code> - A small TSR utility that puts the processor into idle mode; without this, your VM will use 100% of the host CPU, all the time. Retreived from <a href="http://www.jradconsulting.com/download/index.html">http://www.jradconsulting.com/download/index.html</a> as <code>dosidle210.zip</code>. (c) Marton Balog and widely distributed by VMWare.</li>
<li><code>CDROM</code> directory - Contains a setup application for Hitachi IDE CDROM drives, this also conveniently supports the VMWare emulated CDROM drive (and likely any other ATAPI drive).</li>
<li><code>PCNET</code> directory - AMD's DOS/NDIS2 driver files for the PCNet family of network interfaces. This will come in handy if you plan to install Windows 3.x. Simply point the installer to these files.</li>
</ul>
]]>


</content>
</entry>

<entry>
<title>Via Velocity VT6122 Unstable in Linux</title>
<link rel="alternate" type="text/html" href="http://spiffie.org/computing/archives/2007/08/vt6122_unstable_linux.html" />
<modified>2007-08-28T00:05:33Z</modified>
<issued>2007-08-27T22:53:01Z</issued>
<id>tag:spiffie.org,2007:/computing//2.44</id>
<created>2007-08-27T22:53:01Z</created>
<summary type="text/plain">After much experimenting in Debian Etch and Slackware 11, with various 2.6.x kernels up to and including 2.6.22, the VT6122 gigabit ethernet chipset, combined with either the built in via_velocity driver or the via supplied velocityget driver, results in an...</summary>
<author>
<name>spiffed</name>

<email>spiffed@spiffie.org</email>
</author>
<dc:subject>Linux</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://spiffie.org/computing/">
<![CDATA[<p>After much experimenting in Debian Etch and Slackware 11, with various 2.6.x kernels up to and including 2.6.22, the VT6122 gigabit ethernet chipset, combined with either the built in <code>via_velocity</code> driver or the via supplied <code>velocityget</code> driver, results in an unstable link under load.</p>

<p>When the network is under heavy use (copying a file over samba/netatalk counts), the following appears multiple times in syslog indicating the continual reset of the network.</p>

<pre><code>Aug 27 14:31:13 Enterprise kernel: eth0: failed to detect cable link
Aug 27 14:31:16 Enterprise kernel: eth0: Link auto-negotiation speed 1000M bps full duplex
</code></pre>

<p>Based on this, I do not recomend the use of Velocity based cards in Linux computers.</p>
]]>


</content>
</entry>

<entry>
<title>Via Velocity velocityget module with kernel 2.6.22</title>
<link rel="alternate" type="text/html" href="http://spiffie.org/computing/archives/2007/08/velocityget_2622.html" />
<modified>2007-08-28T01:08:08Z</modified>
<issued>2007-08-27T00:05:57Z</issued>
<id>tag:spiffie.org,2007:/computing//2.45</id>
<created>2007-08-27T00:05:57Z</created>
<summary type="text/plain">The latest velocityget Via Velocity driver does not compile under kernel 2.6.22....</summary>
<author>
<name>spiffed</name>

<email>spiffed@spiffie.org</email>
</author>
<dc:subject>Linux</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://spiffie.org/computing/">
<![CDATA[<p>The latest <code>velocityget</code> Via Velocity driver does not compile under kernel 2.6.22. </p>
]]>
<![CDATA[<p>To build the driver without pulling your hair out, you'll need the <a href="http://www.viaarena.com/Driver/velocityget.tgz">velocityget 1.23 sources</a> from <a href="http://www.viaarena.com/default.aspx?PageID=420&amp;OSID=25&amp;CatID=2590&amp;SubCatID=130">Via Arena</a> and <a href="http://spiffie.org/computing/archives/velocityget_1.23_for_2.6.22.patch">my patch</a>.</p>

<ol>
<li><p>Download everything</p>

<pre><code>  wget http://www.viaarena.com/Driver/velocityget.tgz
  wget http://spiffie.org/computing/archives/velocityget_1.23_for_2.6.22.patch
</code></pre></li>
<li><p>Extract the sources:</p>

<pre><code>  tar xzf velocityget.tgz
  cd 1.23
</code></pre></li>
<li><p>Apply the patch:</p>

<pre><code>  cat ../velocityget_1.23_for_2.6.22.patch |patch -p1
</code></pre></li>
<li><p>Build everything and install:</p>

<pre><code>  make
  sudo make install
</code></pre></li>
</ol>

<p>At this point, you'll need to load the module. This could entail any of the following:</p>

<ul>
<li>No modules are loaded: just load velocityget (<code>modprobe velocityget</code>)</li>
<li>The module supplied with the kernel is loaded: you'll need to unload the existing module and load velocityget (<code>modprobe -r via_velocity;modprobe velocityget</code>). You will also need to find a way to ensure the correct module loads during startup.</li>
<li>The via<em>velocity driver was compiled into the kernel: you need to rebuild the kernel either without the via</em>velocity driver, or with via_velocity built as a module.</li>
</ul>
]]>
</content>
</entry>

<entry>
<title>Install VMWare ESX Server 3 in VMWare Workstation</title>
<link rel="alternate" type="text/html" href="http://spiffie.org/computing/archives/2007/07/install_vmware.html" />
<modified>2007-07-21T04:45:06Z</modified>
<issued>2007-07-21T04:44:38Z</issued>
<id>tag:spiffie.org,2007:/computing//2.43</id>
<created>2007-07-21T04:44:38Z</created>
<summary type="text/plain"> If you install ESX Server 3 into a VMWare Workstation virtual machine, you&#8217;ll find it installs perfectly fine, but the VMWare network adapter is not supported by ESX Server. Thankfully, the adapter is modeled after the AMD PCNet32 adapter...</summary>
<author>
<name>spiffed</name>

<email>spiffed@spiffie.org</email>
</author>
<dc:subject>Software Problems</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://spiffie.org/computing/">
<![CDATA[<p><img alt="VMWare Virtual Infrastructure ESX Server" src="http://spiffie.org/computing/archives/2007/07/21/vi_esx.gif" width="104" height="49" align="right" />
If you install <a href="http://vmware.com/products/vi/esx/">ESX Server 3</a> into a <a href="http://vmware.com/products/desktop/workstation.html">VMWare Workstation</a> virtual machine, you&#8217;ll find it installs perfectly fine, but the VMWare network adapter is not supported by ESX Server. Thankfully, the adapter is modeled after the AMD PCNet32 adapter and VMWare server is based on Linux.</p>
]]>
<![CDATA[<h3>Start VMWare ESX Server</h3>

<p><img alt="Choose the Service Console from the boot menu" src="http://spiffie.org/computing/archives/2007/07/21/Service%20Console.png" width="720" height="400" align="right" />
Start your VMWare ESX Server virtual machine. When prompted by the Grub boot loader, choose the third option to enter &#8220;Service Console only&#8221;. This will start Linux, and place us at the root prompt.</p>

<p><img alt="Logging in as root" src="http://spiffie.org/computing/archives/2007/07/21/Root%20Login.png" width="720" height="196" align="right" />
Login as root (or login as another user and su to root). You should now be at the shell prompt.</p>

<h3>Get the Kernel Modules</h3>

<p><img alt="Floppy device configuration page" src="http://spiffie.org/computing/archives/2007/07/21/Floppy%20Config.png" width="308" height="410" align="right" />
While you could re-compile the kernel to enable the PCNet32 module and the mii module it depends on, I&#8217;ve already gone to the trouble. Just <a href="http://spiffie.org/computing/archives/2007/07/21/pcnet32-modules-ESX3.tar">download the tar archive</a> containing the modules.</p>

<p>After downloading the tar file, we&#8217;re going to mount the tar file as the floppy image for the virtual machine. Simply open the floppy configuration window (VM &#8212;&gt; Removable Devices &#8212;&gt; Floppy &#8212;&gt; Edit), open the tar file under &#8220;Use floppy image&#8221;, and ensure the device is connected.</p>

<p>This bit of trickery allows us to read the tar image from the /dev/fd0 device. In reality, any smaller-than-a-floppy file can be read this way.</p>

<h3>Install the Modules</h3>

<p><img alt="extracting and chmod'ing the files" src="http://spiffie.org/computing/archives/2007/07/21/Extract%20and%20own.png" width="720" height="149" />
Finally, we need to execute the following commands to execute and extract the files into the modules directory.</p>

<pre><code>cd /lib/modules/2.4.21-37.0.2.ELvmnix/kernel/drivers/net
tar -xvf /dev/fd0
chmod 644 pcnet32.o mii.o
</code></pre>

<p>To confirm they&#8217;re really there, a quick directory listing of <code>ls -l mii.o pcnet32.o</code>.</p>

<h3>Reboot</h3>

<p>Finally simply reboot to enable the modules. If you have more to do in the service console, load the mii driver then the pcnet driver with:</p>

<pre><code>insmod mii
insmod pcnet
</code></pre>
]]>
</content>
</entry>

<entry>
<title>o2.c</title>
<link rel="alternate" type="text/html" href="http://spiffie.org/computing/archives/2006/12/o2c.html" />
<modified>2006-12-23T20:44:59Z</modified>
<issued>2006-12-23T20:16:33Z</issued>
<id>tag:spiffie.org,2006:/computing//2.42</id>
<created>2006-12-23T20:16:33Z</created>
<summary type="text/plain">o2.c is an ethernet &amp; ip packet grabber for linux adapted from Sean Walton&apos;s snooper.c....</summary>
<author>
<name>spiffed</name>

<email>spiffed@spiffie.org</email>
</author>
<dc:subject>Code</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://spiffie.org/computing/">
o2.c is an ethernet &amp; ip packet grabber for linux adapted from Sean Walton&apos;s snooper.c.
<![CDATA[This code was written in a college networking course to capture packets off the wire. I'd like to think it's a decent example of how to handle raw packets under Linux (granted there are newer methods now available).<br>
The <a href="http://spiffie.org/computing/o2.tgz">full source</a> and very short documentation can be downloaded.<br><br>

<pre><font color="#B22222">/*
o2.c - v2.4
 * Portions copyright (c) 2005 Kevin Bralten and Ryan Smit
 * Copyright (c) 2000 Sean Walton and Macmillan Publishers.
 *  
 * Use may be in whole or in part in accordance to the General Public
 * License (GPL).
 *
 * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.

*/</font>
<font color="#B22222">/******************************
 * Version History
 * 
 * Dec. 1st 2005 v2.4
 * Added The 2 pages of comments that are seen after this History
 *
 * Nov. 24th 2005 v2.3
 * Added RTP functionality
 *
 * Nov. 10th 2005 - v2.2
 * Added TCP funtionality
 * Added the PrintAdderPlus function
 *
 * Nov. 3rd 2005 - v2.1
 * Added UDP functionality
 * Added frame limiter
 * Added Basic Help Option
 *
 * Oct. 21st 2005 - v2.0
 * Added Proper IP functionality
 * Added ARP packets
 * Added intial fixes to given code
 * 
 ********************************/</font>

<font color="#B22222">/*******************************
 * An Introduction to this code
 *
 * [cue music]
 *
 * Where The Data Goes
 * In the process of being adapted from the
 * limited functionality of the original
 * snooper.c to the new and improved o2.c
 * many many things have become interesting.
 * This overview attempts to teach you as much
 * about the code as we've discovered.
 *
 * In general, packets are captured by main and sent
 * up through the tree of dumpPacket style methods.
 *
 * Each dump packet method receives a void* pointer
 * to a block of memmory, in this memmory is everything
 * that belongs to this layer of encapsulation.
 * That would be headers + data. It also receives the
 * length of the data block.
 *
 * Each method then disects (in coperation with the
 * matching struct) it's block of data, prints
 * a summary header, and passes the data section
 * of the packet to the next layer of methods.
 *
 * eg: DumpPacket-&gt;DumpIP-&gt;DumpUDP-&gt;DumpRTP
 *
 * Some Naming Conventions
 * In general, you'll need to look up the name of
 * variables, structs, and methods you want to refer
 * to within this code. Apparently there is no standard.
 * Most methods start with Capital letters and have
 * studly caps throughout. Except the bunch that start
 * with lower case letters and have underscores,
 * or the ones taht start with lowercases and have
 * studly caps. Basicly, look it up first.
 * Most variables start with lower case and continue
 * with underscores, expect the ones without underscores,
 * or the ones with studly caps; look it up.
 *
 * Some Coding Conventions
 * Through out the stucts, members are defined as
 * type var_name:size;
 * the :size defines the number of bits reserved for this
 * variable. This is used to define things smaller then the
 * size of the type (but not larger).
 * This is used when you don't have a 3 byte char handy.
 * We had to look this one up, so we thought we'd helpo
 * you.
 * Frequently, structs are ended with 'uchar data[0];'.
 * This is _basicly_ a pointer to the data remaining
 * to be unencapsulated. Or, everything the first part
 * of the header didn't fit.
 *
 * About printf() Style
 * For consistency, values that count something are printed as
 * integers, of no predefined length. Values that represent arbitrary
 * peices of binary data (checksums, some sequence numbers, etc) are
 * printed in capital hex digits, preceded by an 0x and padded with
 * the correct number of leading 0s for the maximum size of the field.
 * 
 * Some Common Types
 * These all asume your c is like ours. Or most peoples.
 * You should know better if it isn't.
 * These are used to hold values in structs. Good for
 * all sorts of things.
 * ulong unsinged long, about 32 bits
 * uint unsigned int, about 16 bits
 * uchar unsigned char, 8 bits give or take
 * uchar[] an array of bytes, data.
 * 
 * Some Hints
 * You'll find a need to call ntohs, and ntohl fairly often.
 * Most of the data you find will be in the wrong order and
 * would look much better in host order (the little endian
 * morons). Sometimes data is already in host order, ntohs
 * here would be ugly and sometimes the data isn't in any
 * real order at all (eg echo sequence). Basicly, season
 * to taste and style.
 * For 8 bits and smaller, no ntohs needed.
 * For regular 16bit style data, ntohs is good.
 * For extra spicy cajun style 17bit and bigger data,
 * ntohl is the recomended spice.
 *
 * Comments have been added, mostly where they seem needed.
 * Some point out unobvious bits of network headers/decoding,
 * while others point out bits that seemed especially scary
 * when we wrote them or bits that seemed especially odd
 * when we read them. 
 *************************/</font>

 <font color="#B22222">/* code left from snooper.c
  * alot of code has changed, you _could_ run a diff
  * against snooper.c, this is a nice rundown.
  *
  * All of the includes have been maintained, but stdlib.h,
  * unistd.h, segfault.h, and ports.h are added.
  *
  * Much of the ip_packet struct remains, but the hardware
  * portion has been stripped and made into ether_packet.
  *
  * Dump is largely unchanged but the printf()s have
  * been revised to look prettier and work better.
  *
  * PrintAddr is intact, but is depreciated.
  * PrintAddrPlus does everything PrintAddr did, but
  * much more flexibly.
  *
  * GetProtocol is intact, but only used by the DumpIP
  * procedure.
  *
  * Panic remains.
  *
  * Main has been largely unchaged with the exception of
  * adding code to count frames and accept options.
  * 
  * In various methods sprinkled throughout, some lines
  * have been maintained.
  */</font>

<font color="#A020F0">#include &lt;stdio.h&gt;</font>
<font color="#A020F0">#include &lt;sys/socket.h&gt;</font>
<font color="#A020F0">#include &lt;resolv.h&gt;</font>
<font color="#A020F0">#include &lt;arpa/inet.h&gt;</font>
<font color="#A020F0">#include &lt;errno.h&gt;</font>
<font color="#A020F0">#include &lt;sys/types.h&gt;</font>
<font color="#A020F0">#include &lt;linux/if_ether.h&gt;</font>
<font color="#A020F0">#include &lt;stdlib.h&gt;</font>
<font color="#A020F0">#include &lt;unistd.h&gt;        //needed</font>
<font color="#A020F0">#include </font><font color="#666666">"segfault.h"</font><font color="#A020F0">        //need standard segfaulting ability</font>
<font color="#A020F0">#include </font><font color="#666666">"ports.h"</font><font color="#A020F0"> //standard port numbers</font>

<strong><font color="#228B22">#define stuct struct</font></strong>

<font color="#B22222">/* someone should really adapt to things other then ethernet and IPv4 */</font>
<strong><font color="#228B22">#define IP_SIZE  4</font></strong>
<strong><font color="#228B22">#define ETH_SIZE 6</font></strong>

<font color="#B22222">/* and I really don't like the method these belong to */</font>
<font color="#B22222">/* PrintAddrPlus is the new method, less hopeing and praying
 * and assuming things are prefined sizes. */</font>
<font color="#4169E1">typedef</font> <font color="#4169E1">enum</font> { eETH_ADDR, eIP_ADDR } EAddress;

<font color="#4169E1">typedef unsigned char uchar;</font>

<font color="#B22222">/* frame number... yes, yes the frame number */</font>
int cnt=0;

char dont_print_shit=0 <font color="#B22222">/* err, don't print shit out.
                            like that c** about the frame
                            you know, that takes up pages
                            err, yeah */</font>;

<font color="#B22222">/*--------------------------------------------------------------------
 * Ethernet Frame
 *
 * This structure defines the fields within the ethernet frame. Since
 * this programs gets the lowest-level packet, fragmented packets are
 * not reassembled.  The first few fields contain the MAC addresses
 * of the source and destination. Note that this structure is set for
 * little-endian format.
 *--------------------------------------------------------------------*/</font>

<font color="#4169E1"><a name="ether_packet"></a>struct ether_packet</font>{
        uchar dst_eth[ETH_SIZE];
        uchar src_eth[ETH_SIZE];
        uchar __unknwn[2]; <font color="#B22222">/*not unknown, just misunderstood*/</font>
        <font color="#B22222">/* it's either the size of the type,
        * yes this could be looked up, but assume:
        * 0x0100 and better is type
        * 0x00FF and lesser is size
        * (big numbers are better!)
        */</font>
        uchar data[0];
};             <font color="#B22222">/* hardware header */</font>

<font color="#4169E1"><a name="arp_packet"></a>struct arp_packet </font>{
        uint hw_type:16;
        uint proto_type:16;
        uchar hw_size;
        uchar ip_size;
        uint opcode:16;
        uchar hw_src[ETH_SIZE]; <font color="#B22222">/* sender hw address */</font>
        uchar ip_src[IP_SIZE]; <font color="#B22222">/* sender IP address */</font>
        uchar hw_dst[ETH_SIZE];
        uchar ip_dst[IP_SIZE];
        uchar __padding[0]; <font color="#B22222">/* padding on the end of the packet... hmm */</font>
};

<font color="#B22222">/* UDP -- RFC 768
 * usually rides on IP packets
 */</font>
<font color="#4169E1"><a name="udp_packet"></a>struct udp_packet </font>{
        uint src_port:16;
        uint dst_port:16;
        uint len:16; //header+data (data=len-8)
        uint checksum:16;
        uchar data[0];
};

<font color="#B22222">/* ICMP Packets ride inside IP Packets
 * defined by RFC 792
 * ping/echo is usually carried inside ICMP Packets
 */</font>
<font color="#4169E1"><a name="icmp_packet"></a>struct icmp_packet </font>{
        uchar type;
        uchar code;
        uint checksum:16;
        uchar data[0];
};

<font color="#4169E1"><a name="echo_packet"></a>struct echo_packet </font>{
        <font color="#B22222">/* this may all be filled with any data the sender likes
         * id and seq_num are set aside because it looks like a good idea
         * data is just a block of data
         * the receiver when (or if) replying must duplicate this data
         *
         * from RFC:
         * The data received in the echo message must be returned in the echo
         * reply message.

         * The identifier and sequence number may be used by the echo sender
         * to aid in matching the replies with the echo requests.  For
         * example, the identifier might be used like a port in TCP or UDP to
         * identify a session, and the sequence number might be incremented
         * on each echo request sent.  The echoer returns these same values
         * in the echo reply.
         */</font>
        uint id:16;
        uint seq_num:16;
        uchar data[0];
};

<font color="#4169E1"><a name="rtp_packet"></a>struct rtp_packet </font>{
        uint flags:16;
        uint sequence:16;
        ulong timestap:32;
        ulong sync:32;
        char data[0];
};

<font color="#4169E1"><a name="ip_packet"></a>struct ip_packet </font>{
        uint header_len:4;       <font color="#B22222">/* header length in words in 32bit words */</font>
        uint version:4;          <font color="#B22222">/* 4-bit version */</font>
        uint serve_type:8;       <font color="#B22222">/* how to service packet */</font>
        uint packet_len:16;      <font color="#B22222">/* total size of packet in bytes */</font>
        uint ID:16;              <font color="#B22222">/* fragment ID */</font>
        uint frag_offset:13;     <font color="#B22222">/* to help reassembly */</font>
        uint more_frags:1;       <font color="#B22222">/* flag for "more frags to follow" */</font>
        uint dont_frag:1;        <font color="#B22222">/* flag to permit fragmentation */</font>
        uint __reserved:1;       <font color="#B22222">/* always zero */</font>
        uint time_to_live:8;     <font color="#B22222">/* maximum router hop count */</font>
        uint protocol:8;         <font color="#B22222">/* ICMP, UDP, TCP */</font>
        uint hdr_chksum:16;      <font color="#B22222">/* ones-comp. checksum of header */</font>
        uchar IPv4_src[IP_SIZE]; <font color="#B22222">/* IP address of originator */</font>
        uchar IPv4_dst[IP_SIZE]; <font color="#B22222">/* IP address of destination */</font>
        uchar data[0];           <font color="#B22222">/* message data up to 64KB */</font>
};

<font color="#B22222">/* TCP Header
 * Err, this is what TCP headers should look like
 * as taken from RFC 793
 */</font>
<font color="#B22222">/* the um, reserved bits were um, discarded
 * the RFC says these are useless and undefined
 * in the interest of making offset and flags easier
 * on the brain, they absorbed the bits from offset
 * and some crazy bitmasking madness goes on in the dump
 * method.
 *
 * So yeah, if you know of a reason to need the reserved bits
 * you'll be smart enough to get them back.
 * (Good Luck)
 */</font>
<font color="#4169E1"><a name="tcp_packet"></a>struct tcp_packet </font>{
        uint src_port:16;
        uint dst_port:16;

        <font color="#B22222">/* The sequence number of the first data octet in this segment (except
    when SYN is present). If SYN is present the sequence number is the
    initial sequence number (ISN) and the first data octet is ISN+1. */</font>
        uint sequence:32;

        <font color="#B22222">/* If the ACK control bit is set this field contains the value of the
    next sequence number the sender of the segment is expecting to
    receive.  Once a connection is established this is always sent. */</font>
        uint ack:32;
        
        <font color="#B22222">/* The number of 32 bit words in the TCP Header.  This indicates where
    the data begins.  The TCP header (even one including options) is an
    integral number of 32 bits long. */</font>
        uchar offset;
        
        <font color="#B22222">/* URG:  Urgent Pointer field significant
    ACK:  Acknowledgment field significant
    PSH:  Push Function
    RST:  Reset the connection
    SYN:  Synchronize sequence numbers
    FIN:  No more data from sender */</font>
        uchar flags;
        
        <font color="#B22222">/* The number of data octets beginning with the one indicated in the
    acknowledgment field which the sender of this segment is willing to
    accept. */</font>
        uint window:16;
        
        uint checksum:16;
        uint urgent_pointer:16;

        <font color="#B22222">/* Options and padding and data... this requires slightly more work */</font>
        uchar contents[0];
};

<font color="#B22222">/*--------------------------------------------------------------------*/</font>
<font color="#B22222">/* dump                                                               */</font>
<font color="#B22222">/*                                                                    */</font>
<font color="#B22222">/* Dump a block of data in hex &amp; ascii.                               */</font>
<font color="#B22222">/*--------------------------------------------------------------------*/</font>
<strong><font color="#4169E1"><a name="dump"></a>void dump(void* b, int len)</font></strong>
{   unsigned char *buf = b;
    int i, cnt=0;
    char str[17];
    memset(str, 0, 17);
    <font color="#4169E1">for</font> ( i = 0; i &lt; len; i++ )
    {
        <font color="#4169E1">if</font> ( cnt % 16 == 0 )
        {
            printf(<font color="#666666">"  %16s\n%3X: "</font>, str, cnt);
            memset(str, 0, 17);
        }
        <font color="#4169E1">if</font> ( buf[cnt] &lt; ' '  ||  buf[cnt] &gt;= 127 )
            str[cnt%16] = '.';
        <font color="#4169E1">else</font>
            str[cnt%16] = buf[cnt];
        printf(<font color="#666666">"%02X "</font>, buf[cnt++]);
    }
    <font color="#B22222">/* About The %*s
     * the * after the % indicated the width of this feild is
     * found by the preceding paramter in the code. In this
     * case, that scary equation before the "".
     *
     * This particular line uses some math of add enough spaces
     * to align the last line of data.
     */</font>
    printf(<font color="#666666">"  %*s%s\n"</font>, (0!=len%16?3*(16-(len%16)):0), <font color="#666666">""</font>, str);
    <font color="#B22222">/* About the spacing equation
     * The last line ends with some arbitrary number of bytes.
     * The other lines are all 16 bytes long. In order to make
     * things pretty, the above printf is used to align the
     * end of the line. Basicly, we figure out how many bytes
     * are on the last line, subtract from 16, and add that many
     * spaces * 3 (each byte needs 3 spaces).
     * An embeded if is used to check if no spaces are needed.
     * Finally, the last line of ASCII data is printed.
     *
     * The original snooper.c had a simpiler line her, but
     * one that didn't quite cut it. (Left 16 spaces sometimes)
     */</font>
}

<font color="#B22222">/*--------------------------------------------------------------------*/</font>
<font color="#B22222">/* PrintAddr                                                          */</font>
<font color="#B22222">/*                                                                    */</font>
<font color="#B22222">/* Print the different types of address (MAC or IP).                  */</font>
<font color="#B22222">/*--------------------------------------------------------------------*/</font>
<strong><font color="#4169E1"><a name="PrintAddr"></a>void PrintAddr(char* msg, uchar *addr, EAddress is_ip)</font></strong>
{        int i;
        static <font color="#4169E1">struct</font> {
                int len;
                char *fmt;
                char delim;
        } addr_fmt[] = {{ETH_SIZE, <font color="#666666">"%02X"</font>, ':'}, {IP_SIZE, <font color="#666666">"%d"</font>, '.'}};

        printf(<font color="#666666">"%s"</font>, msg);
        <font color="#4169E1">for</font> ( i = 0; i &lt; addr_fmt[is_ip].len; i++ )
        {
                printf(addr_fmt[is_ip].fmt, addr[i]);
                <font color="#4169E1">if</font> ( i &lt; addr_fmt[is_ip].len-1 )
                        putchar(addr_fmt[is_ip].delim);
        }
}

<strong><font color="#4169E1"><a name="PrintAddrPlus"></a>void PrintAddrPlus(const char* msg, const uchar * addr, const char addr_len, const char seperator, const char* format)</font></strong>{
        int i;

        printf(<font color="#666666">"%s"</font>,msg);
        <font color="#4169E1">for</font>(i=0;i&lt;addr_len;i++){
                printf(format,addr[i]);
                <font color="#4169E1">if</font>(i&lt;addr_len-1)
                        putchar(seperator);
        }
}

<font color="#B22222">/*--------------------------------------------------------------------*/</font>
<font color="#B22222">/* GetProtocol                                                        */</font>
<font color="#B22222">/*                                                                    */</font>
<font color="#B22222">/* Convert the protocol value into the alphabetic representation.     */</font>
<font color="#B22222">/*--------------------------------------------------------------------*/</font>
<strong><font color="#4169E1"><a name="GetProtocol"></a>char* GetProtocol(int value)</font></strong>
{
        <font color="#4169E1">switch</font> (value)
        {
                <font color="#4169E1">case</font> IPPROTO_IP: <font color="#4169E1">return</font> <font color="#666666">"IP"</font>;
                <font color="#4169E1">case</font> IPPROTO_ICMP: <font color="#4169E1">return</font> <font color="#666666">"ICMP"</font>;
                <font color="#4169E1">case</font> IPPROTO_IGMP: <font color="#4169E1">return</font> <font color="#666666">"IGMP"</font>;
                <font color="#4169E1">case</font> IPPROTO_IPIP: <font color="#4169E1">return</font> <font color="#666666">"IPIP"</font>;
                <font color="#4169E1">case</font> IPPROTO_TCP: <font color="#4169E1">return</font> <font color="#666666">"TCP"</font>;
                <font color="#4169E1">case</font> IPPROTO_EGP: <font color="#4169E1">return</font> <font color="#666666">"EGP"</font>;
                <font color="#4169E1">case</font> IPPROTO_PUP: <font color="#4169E1">return</font> <font color="#666666">"PUP"</font>;
                <font color="#4169E1">case</font> IPPROTO_UDP: <font color="#4169E1">return</font> <font color="#666666">"UDP"</font>;
                <font color="#4169E1">case</font> IPPROTO_IDP: <font color="#4169E1">return</font> <font color="#666666">"IDP"</font>;
                <font color="#4169E1">case</font> IPPROTO_RSVP: <font color="#4169E1">return</font> <font color="#666666">"RSVP"</font>;
                <font color="#4169E1">case</font> IPPROTO_GRE: <font color="#4169E1">return</font> <font color="#666666">"GRE"</font>;
                <font color="#4169E1">case</font> IPPROTO_IPV6: <font color="#4169E1">return</font> <font color="#666666">"IPV6/4"</font>;
                <font color="#4169E1">case</font> IPPROTO_PIM: <font color="#4169E1">return</font> <font color="#666666">"PIM"</font>;
                <font color="#4169E1">case</font> IPPROTO_RAW: <font color="#4169E1">return</font> <font color="#666666">"RAW"</font>;
<strong><font color="#FF0000">                default:</font></strong> <font color="#4169E1">return</font> <font color="#666666">"???"</font>;
        }
}

<font color="#B22222">/* decodes TCP, or atleast how I think TCP packets are structured, 
 * seems to need more then just a cast to the structure. */</font>
<strong><font color="#4169E1"><a name="DumpTCPPacket"></a>void DumpTCPPacket(char *buffer, int len)</font></strong>{
        <font color="#4169E1">struct tcp_packet</font> *tcp=(void*)(buffer);
        <font color="#B22222">/* you _are_ expected to understand this, sorry
         * 
         * tcp-&gt;offset contains (in it's upper 4 bits) the number
          * of 32bit words between the start of the TCP header and the data
         * in it. 
         * tcp points to the start of the tcp packet.
         * by casting tcp to a char*, we can add offset
         * (times 4 because it's 32bit words, and we want bytes)
          * and get a pointer to the start of the data within the 
         * tcp byte stream.
         * This way, we can pass data to any child protos as
         * their packet.
         *
         * the difference between tcp-&gt;contents and the newly calculated
         * data pointer is the options.
         */</font>
        char* data=((char*)tcp)+((tcp-&gt;offset&amp;0xF0)&gt;&gt;4)*4;

        printf(<font color="#666666">"\nSource port: %d, Destination port: %d, Sequence #: 0x%08X\n"</font>, ntohs(tcp-&gt;src_port), ntohs(tcp-&gt;dst_port), ntohl(tcp-&gt;sequence));
        printf(<font color="#666666">"Acknowledge: 0x%08X, Flags: 0x%02X, Window: %d\n"</font>, ntohl(tcp-&gt;ack), tcp-&gt;flags&amp;0x3F, ntohl(tcp-&gt;window));
        printf(<font color="#666666">"Checksum: 0x%04X, Urgent Pointer: %d\n"</font>, ntohs(tcp-&gt;checksum), ntohs(tcp-&gt;urgent_pointer));
        printf(<font color="#666666">"Data Offset: %d\n"</font>, ((tcp-&gt;offset&amp;0xF0)&gt;&gt;4)*4); <font color="#B22222">/* some scary bit shifty voodoo to make offset work, it's the top 4 bits followed by some junk */</font>
}

<font color="#B22222">/* this method takes the conservitive stance that you're looking up
 * IPv4 across Ethernet... otherwise things could get interesting
 * you could potentially redefine PrintAddr to accept more parameters and make things pritier.
 */</font>
<strong><font color="#4169E1"><a name="DumpARPPacket"></a>void DumpARPPacket(char *buffer, int len)</font></strong>{
        <font color="#4169E1">struct arp_packet</font> *arp=(void*)(buffer);

        printf(<font color="#666666">"\nARP Hardware Type: 0x%04X, Protocol Type: 0x%04X Op-code: %s (0x%04X)\n"</font>,ntohs(arp-&gt;hw_type),ntohs(arp-&gt;proto_type),(arp-&gt;opcode?<font color="#666666">"request"</font>:<font color="#666666">"reply"</font>),ntohs(arp-&gt;opcode));
        PrintAddr(<font color="#666666">"Source="</font>, arp-&gt;hw_src,eETH_ADDR);
        PrintAddr(<font color="#666666">" ("</font>,arp-&gt;ip_src,eIP_ADDR);
        printf(<font color="#666666">"), "</font>);
        PrintAddr(<font color="#666666">"Destination="</font>, arp-&gt;hw_dst,eETH_ADDR);
        PrintAddr(<font color="#666666">" ("</font>,arp-&gt;ip_dst,eIP_ADDR);
        printf(<font color="#666666">"), "</font>);
}

<strong><font color="#4169E1"><a name="DumpRTPPacket"></a>void DumpRTPPacket(buf,len)</font></strong> char *buf; int len; {
        stuct rtp_packet *rtp = (void *)(buf);
        printf(<font color="#666666">"\nFlags: 0x%04X, Sequence: %d\n"</font>,ntohs(rtp-&gt;flags),ntohs(rtp-&gt;sequence));
        printf(<font color="#666666">"Timestamp: 0x%08X Synchronization 0x%08X\n"</font>,ntohl(rtp-&gt;timestap), ntohl(rtp-&gt;sync));        
}
        
<strong><font color="#4169E1"><a name="DumpUDPPacket"></a>void DumpUDPPacket(char *buf, int len)</font></strong>{
  <font color="#4169E1">struct udp_packet</font> *udp = (void *)(buf);
  int imp_port=0;
  
  printf(<font color="#666666">"\nSource Port = %d, Dest Port = %d\n Length = %d, checksum 0x%04X\n"</font>, ntohs(udp-&gt;src_port), ntohs(udp-&gt;dst_port), ntohs(udp-&gt;len), ntohs(udp-&gt;checksum));  

  <font color="#B22222">/* more guess work
   * based on http://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html
   * "...Linux 2.4 kernel will default the range of 32768 through 61000..."
   * for ephemeral ports. We're gonna go ahead and assume this is true.
   *
   * So, based on this assumption, and assuming that the non-ephmeral
   * port is the important one, try to find the non-ephemeral port.
   */</font>
  <font color="#4169E1">if</font>(ntohs(udp-&gt;dst_port)&lt;EPHEMERAL)
          imp_port=ntohs(udp-&gt;dst_port);
  <font color="#4169E1">if</font>(ntohs(udp-&gt;src_port)&lt;EPHEMERAL)
          imp_port=ntohs(udp-&gt;src_port);
  <font color="#4169E1">switch</font>(imp_port){
        <font color="#4169E1">case</font> 0:
                  <font color="#B22222">/* we have no idea what it is */</font>
                  <font color="#4169E1">break</font>;
        <font color="#4169E1">case</font> UDP_RTP:
                  <font color="#B22222">/* RTP, I hope */</font>
                  DumpRTPPacket(udp-&gt;data,len-8);
                  <font color="#4169E1">break</font>;
  }
}

<strong><font color="#4169E1"><a name="DumpIPPacket"></a>void DumpIPPacket(char *buffer, int len)</font></strong>{
        <font color="#4169E1">struct ip_packet</font> *ip=(void*)(buffer);
printf(<font color="#666666">"\nIPv%d: header-len=%d, type=%d, packet-size=%d, ID=%d\n"</font>,
                ip-&gt;version, ip-&gt;header_len*4, ip-&gt;serve_type,
                ntohs(ip-&gt;packet_len), ntohs(ip-&gt;ID));
        printf(<font color="#666666">"frag=%c, more=%c, offset=%d, TTL=%d, protocol=%d (%s)\n"</font>,
                (ip-&gt;dont_frag? 'N': 'Y'),
                (ip-&gt;more_frags? 'N': 'Y'),
                ip-&gt;frag_offset,
                ip-&gt;time_to_live, ip-&gt;protocol, GetProtocol(ip-&gt;protocol));
        printf(<font color="#666666">"checksum=%d, "</font>, ntohs(ip-&gt;hdr_chksum));
        PrintAddr(<font color="#666666">"source="</font>, ip-&gt;IPv4_src, eIP_ADDR);
        PrintAddr(<font color="#666666">", destination="</font>, ip-&gt;IPv4_dst, eIP_ADDR);

        <font color="#4169E1">switch</font>(ip-&gt;protocol){
                <font color="#4169E1">case</font> 6:
                        DumpTCPPacket(ip-&gt;data, len-20);
                        <font color="#4169E1">break</font>;
                <font color="#4169E1">case</font> 17:
                       DumpUDPPacket(ip-&gt;data, len-20);
                       <font color="#4169E1">break</font>;         
        }
}

<font color="#B22222">/*--------------------------------------------------------------------*/</font>
<font color="#B22222">/* DumpPacket                                                         */</font>
<font color="#B22222">/*                                                                    */</font>
<font color="#B22222">/* Display the read packet with data and fields.                      */</font>
<font color="#B22222">/*--------------------------------------------------------------------*/</font>
<strong><font color="#4169E1"><a name="DumpPacket"></a>void DumpPacket(char *buffer, int len)</font></strong>
{        
        <font color="#4169E1">struct ether_packet</font> *hw=(void*)buffer;

<font color="#A020F0">        #ifdef _DEBUG_FILTER_</font>
                <font color="#4169E1">if</font>(0x00==hw-&gt;src_eth[0] &amp;&amp; 0x60==hw-&gt;src_eth[1] &amp;&amp; 0x08==hw-&gt;src_eth[2] &amp;&amp; 0x57==hw-&gt;src_eth[3] &amp;&amp; 0x06==hw-&gt;src_eth[4] &amp;&amp; 0xB7==hw-&gt;src_eth[5])
                        <font color="#4169E1">return</font>;
                <font color="#4169E1">if</font>(0x00==hw-&gt;dst_eth[0] &amp;&amp; 0x60==hw-&gt;dst_eth[1] &amp;&amp; 0x08==hw-&gt;dst_eth[2] &amp;&amp; 0x57==hw-&gt;dst_eth[3] &amp;&amp; 0x06==hw-&gt;dst_eth[4] &amp;&amp; 0xB7==hw-&gt;dst_eth[5])
                        <font color="#4169E1">return</font>;
<font color="#A020F0">        #endif</font>

        printf(<font color="#666666">"\n-------------------------------------------------\n"</font>);
        printf(<font color="#666666">"Frame: %d, Type/Size: 0x%02X%02X\n"</font>, cnt+1, hw-&gt;__unknwn[0],hw-&gt;__unknwn[1]);
        PrintAddr(<font color="#666666">"Destination MAC="</font>, hw-&gt;dst_eth, eETH_ADDR);
        PrintAddr(<font color="#666666">", Source MAC="</font>, hw-&gt;src_eth, eETH_ADDR);
        <font color="#B22222">/* SCARY
         * the __unknwn bits here (2 bytes worth) represent
         * size under 802.3 packets and apear to be less then 
         * 0x0100. Otherwise, this is the type of packet riding
         * in the ethernet frame.
         * Unfortunetly, this is a 16bit value stored in 2
         * bytes; therefore the multiplication and adding bits.
         */</font>
        <font color="#4169E1">switch</font>(hw-&gt;__unknwn[0]*0x100+hw-&gt;__unknwn[1]){
                <font color="#4169E1">case</font>(0x0806):
                        //Looks to be usually an ARP packet (we hope)
                        DumpARPPacket(hw-&gt;data,len-14);
                        <font color="#4169E1">break</font>;
                <font color="#4169E1">case</font>(0x0800):
                        //these look like IP type things
                        DumpIPPacket(hw-&gt;data,len-14);
                        <font color="#4169E1">break</font>;
<strong><font color="#FF0000">                default:</font></strong>
                        <font color="#B22222">/* an asumption: 802.3 packets look unlike ethernet II packets
                         * because 802.3 packets have their length in the LSB of the
                         * type/size field.
                         *
                         * This could be horribly wrong.
                         */</font>
                        <font color="#4169E1">if</font>((hw-&gt;__unknwn[0]*0x100+hw-&gt;__unknwn[1])&lt;0x100){
                                printf(<font color="#666666">"\nLooks like an 802.3 packet. Good Luck.\n"</font>);
                        }<font color="#4169E1">else</font>{
                                printf(<font color="#666666">"\nAnd now for something completely Different.\n"</font>);
                        }
        }
        printf(<font color="#666666">"\n"</font>);
        <font color="#4169E1">if</font>(!dont_print_shit)
                dump(buffer, len);
        <font color="#B22222">/* ryan doesn't like these :(
         printf("-------------------------------------------------\n");
         */</font>
        fflush(stdout);
}

<strong><font color="#4169E1">void PANIC(char *msg)</font></strong>;
<strong><font color="#228B22">#define PANIC(msg)        {perror(msg);exit(0);}</font></strong>

<font color="#B22222">/*--------------------------------------------------------------------*/</font>
<font color="#B22222">/* main                                                               */</font>
<font color="#B22222">/*                                                                    */</font>
<font color="#B22222">/* Open socket.  Repeatedly read and display records.                 */</font>
<font color="#B22222">/*--------------------------------------------------------------------*/</font>
<strong><font color="#4169E1"><a name="main"></a>int main(int argc, char *argv[])</font></strong>
{   int sd, bytes_read;
    int numFrames = 0, opt;                                    
    char data[65535]; //this would be a right properly large sized packet

    <font color="#B22222">/* this program operates in two modes, little endian and crash */</font>
    endian_segfault(1);

    <font color="#4169E1">while</font> ((opt = getopt(argc, argv, <font color="#666666">"f:hy"</font>)) != -1) {
             <font color="#4169E1">switch</font> (opt) {
                 <font color="#4169E1">case</font> 'f':          // Number of Frames to Read
                     numFrames = atoi(optarg);
                     <font color="#4169E1">break</font>;
                 <font color="#4169E1">case</font> 'y':
                     dont_print_shit = 1;
                     <font color="#4169E1">break</font>;
<strong><font color="#FF0000">                 default:</font></strong>
                 <font color="#4169E1">case</font> 'h':          // Print Help
                     printf(<font color="#666666">"Usage: %s [-y] [ -f frames]\n"</font>, argv[0]);
                     exit(0);

             }
    }

    sd  = socket(PF_INET, SOCK_PACKET, htons(ETH_P_ALL));
    <font color="#4169E1">if</font> ( sd &lt; 0 )
                PANIC(<font color="#666666">"o2 : You should have been root. You should be pleased you got this instead of a core dump "</font>);

    <font color="#4169E1">do</font> {
            bytes_read = recvfrom(sd, data, <font color="#4169E1">sizeof</font>(data), 0, 0, 0);
        <font color="#4169E1">if</font> ( bytes_read &gt; 0 )
                        DumpPacket(data, bytes_read);
        cnt++;
    } <font color="#4169E1">while</font> ( bytes_read &gt; 0 &amp;&amp; cnt!=numFrames);                       
    <font color="#4169E1">return</font> 0;
}


</pre>]]>
</content>
</entry>

<entry>
<title>Shared-libary build fails on AMD_64</title>
<link rel="alternate" type="text/html" href="http://spiffie.org/computing/archives/2006/02/sharedlibary_bu.html" />
<modified>2006-12-23T20:54:30Z</modified>
<issued>2006-02-25T03:56:50Z</issued>
<id>tag:spiffie.org,2006:/computing//2.25</id>
<created>2006-02-25T03:56:50Z</created>
<summary type="text/plain">While trying to link against a shared library I received the following error: relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC. The solution is quite simple, in the Makefile of the offending library, simply...</summary>
<author>
<name>spiffed</name>

<email>spiffed@spiffie.org</email>
</author>
<dc:subject>OpenBSD</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://spiffie.org/computing/">
<![CDATA[<p>While trying to link against a shared library I received the following error: <code>relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC</code>.</p>

<p>The solution is quite simple, in the <code>Makefile</code> of the offending library, simply add <code>-fPic</code> to the end of the <code>CFLAGS</code> line. Finally, rebuild and reinstall the library (<code>make clean &amp;&amp; make &amp;&amp; make install</code>).</p>

<p>I am sure there are cleaner ways (like passing the extra CFLAGS to configure), but it works for one off jobs.</p>
]]>


</content>
</entry>

</feed>