Monthly Archives: December 2006

12/19/06

Libnet… dead?

Just got an email from Freshmeat saying that they’ve de-listed the libnet library from their database. Sure enough, www.packetfactory.net is offline. Anyways, I’ve emailed Mike to see what’s going on. Until then I’ve uploaded my last copy of the source code to here: libnet-1.1.3-RC-01.tar.gz

UPDATE: The email to Mike bounced and the libnet mailing list has been basically dead for over a year. Starting to smell like abandon-ware. Also, I could of sworn libnet-ng had an actual web page, but looks like that was taken offline or I was horribly confused.

12/15/06

When UPS’s fail

Yes, synfin.net was offline for about 8-1/2 hours due to my UPS failing. Oh the irony! Not sure why it’s dead, but it won’t even supply power when plugged into AC. So, everything hooked up to my UPS (my firewall and server) went offline just after midnight.

Anyways, everything is back up… guess I know what to spend my Fry’s gift certificate on!

12/14/06

Brazil

So earlier this week I couldn’t sleep, so I read email and watched the movie Brazil. I didn’t know much about the movie before seeing it, other then it being an Orwellian look at the future and was considered to be a really good movie.

Brazil didn’t disappoint. The special effects were that of an art student film, but visually stunning never the less. What I found most interesting was how many parallels I found in todays world with the film. Clearly there is some strong social/political commentary in Brazil, specifically dealing with how the government’s use of information and of media leads to controlling it’s citizens. Additionally how people are easily manipulated with consumerism.

One of the tightest parallels however in my mind was how the gov’t in Brazil used the “Ministry of Information” and classified laws and regulations to not only keep secrets from people, but used that information against it’s own citizens- often with horrible consequences. This sounds very much like our “do not fly lists” which ordinary citizens can’t view and have no means of clearing their names off of, secret TSA regulations and the federal governments attempt at creating a large databases covering many aspects of law abiding citizens in order to ferret out possible terrorists (interestingly, the exact same reason used in Brazil) is almost too creepy.

12/10/06

RIAA Petitions

Currently there are two petitions going on with regards to the RIAA:

First the EFF is asking people to sign a petition to be sent to Congress to ask them to do something about the RIAA’s heavy handed tactics towards children, parents and the elderly.

The second, is the RIAA petitioning some federal judges to reduce the royalty payments they make to artists. Apparently, while they’re filing lawsuits against 12 year olds for stealing Brittney Spears from file sharing sites, the RIAA wants to lower Brittney’s royalty payments for legal downloads.

While I guess “something is better then nothing”, it sure seems rather hypocritical don’t ya think?

12/10/06

Treating users vaguely

So last night I’m playing with iDVD to make well, a DVD. So, long story short, you can choose to format your DVD for 4:3 or 16:9. I wish there was a way to gracefully support both, but that’s another rant. Anyways… so there’s this feature to show you the “safe area”, which is the area of the screen which is most likely to actually be displayed on someone’s TV; apparently iDVD isn’t a WYSIWYG tool.

Now some key things about safe area this:

  • No explaination why an NTSC formatted DVD on an NTSC screen won’t show the whole thing.
  • This is an approximation. iDVD doesn’t apparently actually know what is safe.
  • There is no hint like “after testing we found this appropriate for 90% of TV’s”, so I have no idea how accurate it really is.
  • It reduces the available screen area by like 20% WTF????
  • There’s no documentation telling you how you might go about determining the actual viewable area on a given TV.
  • Even if you figured that out on your own, you can’t adjust the safe area accordingly.

Now I suppose that if you’re using iDVD you’re not a DVD authoring or TV display area expert, hence I would appear to be iDVD’s target market. But I think this is a good case of treating your customers like idiots. I can understand hiding some advanced features by default (actually I think many applications like Word, Excel, Photoshop need an option to “Hide/Show Advanced Options”) so that non-power users aren’t overwhelmed by the vast number of options, but don’t dumb thing’s down so much that you’re only making things more confusing by your vagueness.

Of course what is most frustrating is that Apple knows what the resolution of an NTSC TV screen is… there shouldn’t be this issue in the first place. Sure, some cheaper TV’s may cut off a little at the edges, but not 20%!

12/4/06

libpcap is broken

So one of the tcpreplay users has pointed out that it sometimes it doesn’t send the entire packet. I thought this was very odd since tcpreplay is actually quite simple relatively speaking so there’s not much room for bugs like this to sneak in. After some research I figured out the problem was a broken pcap capture file.

Specifically:
The libpcap specification stores multiple instances of the packet length:

  1. Maximum stored packet size per file (snaplen)
  2. Original packet size per packet (len)
  3. Stored packet size per packet (caplen)

The issue becomes when the snaplen is less then the caplen. This shouldn’t happen, but it may due to bugs in code. The result is that the libpcap library lies and returns the lesser of the two numbers (snaplen) and truncates the packet- even though libpcap advances the file descriptor caplen bytes. This clearly violates Postel’s Law.

Of course the maximum stored packet size is rather redundant- no reason you couldn’t pick a reasonable default buffer size (say 65535 bytes) and realloc the buffer if the stored packet size is larger then that. But libpcap doesn’t do that, and doesn’t provide an API to let you know that this is happening. The result is that tcpreplay only has access to incorrect information and fails to send the entire packet.