Kyle Rose
Last modified: 2008-Jun-21
Last modified: 2008-Jun-21
From the README:
I wrote SquTUN (pronounced "skew-ton") over the course of two days in order to solve a problem that had been plaguing me for two years: CIPE. CIPE is bad in two ways: evidently, it has some security problems that are covered on numerous web pages; and it has implementation problems that are really, really irritating.
The primary implementation issue is that CIPE reqiures a complex custom kernel module that has very annoying logging which can't be shut off without modifications to the source. Furthermore, since it's in the kernel and isn't used by that many people, it is possible that it has a heretofore unknown vulnerability that could allow an attacker to DoS the machine with a packet-of-death, or grant an attacker root access to a machine on which it is running.
A secondary implementation issue is the complexity of its configuration: it has lots of options that I simply won't use in the course of setting up a VPN.
Both of these beg for a simpler VPN solution.
The source for version 1.1 can be found here. The change log can be found here. Feel free to mail me comments and especially information about potential vulnerabilities. Any requests for help in configuring networking will go to /dev/null.
I never understood the fascination with black-on-white text displays, and honestly I still hate them. Furthermore, I can't be the only one who hates that unsubscribed parent folders in Mozilla Thunderbird that have subfolders with new mail are bold/italic and therefore hard to distinguish from those that are simply italic. Below are links to my userContent.css and userChrome.css files, which resolve both of these issues. Study them to figure out how they work.
FWIW, I am amazed at the configurability of Thunderbird (and Firefox) simply through the use of style sheets. Making simple changes like this becomes trivial when you know where to look (get a jar binary and look in messenger.jar and classic.jar from the Thunderbird distribution); and I suspect that with a little practice, designing an entirely new theme wouldn't be that hard either. I think the GTK+ guys could learn a lot from the extensibility of XUL.
Here are my userContent.css and userChrome.css files.
I ran into a problem in which I was getting frequent blockiness in the image and frequent audio cut-outs in MPEG from the HD-2000 while also recording from PVR's or HD-3000's in the same machine. This was due at least in part to buffer overruns in the relatively short (256K) buffer allowed by the driver distributed by the pcHDTV folks.
In response to this, I did two things:
The first is easy; search for "pci latency" and "setpci" and you'll find plenty of instructions on how to tweak PCI latency.
The second is more interesting because it involves a gross hack to get around limitations in the Bt878 RISC engine. I wanted to try a longer buffer in the bttv driver, so I grabbed the data sheet from Conexant's site and had a look. Unfortunately, they don't make it easy: it appears that 256K is as long a buffer as one can determinstically support with the given microcode, because there are only 4 bits for the status field in communication from the RISC processor to the interrupt handler, and each block is limited to 16384 bytes due to other field limitations in the audio DMA status words. (As pfile noted in a posting to me, the HD-2000 uses the audio DMA system in the Bt878 to transfer digital video to main memory.)
Well, it turns out one can *kind* of support larger buffers by estimating where the RISC processor is currently writing: you can do this by reading the RISC processor's program counter. I wrote a first pass at a patch (above) that does just this: buffers above 256K will be divided into "megablocks" of 16 blocks of 16K each. At a high level, the irq handler will attempt to make a guess as to the current megablock based on the PC, and adjust dma_block to be that megablock * 16 + the block reported in the status field.
Unfortunately, there is another more critical problem: the relatively short hardware FIFO (O(1KB)) in the Bt878, due to the HD-2000 using the Bt878's audio DMA to transfer digital video to RAM. Some drivers may have top halves (synchronous interrupt handlers) that consume too much time, effectively resulting in the FIFO overrunning. If you are using the megablocks driver and still are losing data, I recommend first trying a newer kernel; and if that doesn't work, try eliminating drivers and devices until you see the problem go away, which might help pinpoint the driver with the problematic top half.
It would be helpful to know if the megablocks driver helps others seeing the same symptoms I encountered. Email me either way.
Click here to save a C implementation of the original Rijndael proposal, programmed originally by Dr. Brian Gladman and modified by me in my work at Ak4ma1 Technologies. The changes from Dr. Gladman's work are cosmetic: instead of producing the transformation tables on-the-fly when running the encryption routine the first time, compiling with -DGENTABS will produce a program that writes as output a C program containing the tables. This file must then be included or linked into the final program.