I'd stay away from powering a light off the link port. USB has lines dedicated to power, the link port is just for data communication.

One of the routers at my host has been getting DoS'd. I got an e-mail earlier, they said it should be solved by the end of the hour.

Expected downtime for "less than 5 minutes" at some point between a
 half hour from now and an hour from now. The quoted following
 information explains why.


 ---------- Forwarded message ----------
 From:  <[email protected]>
 Date: Mon, Oct 24, 2011 at 10:52 PM
 Subject: Fibernet Ticket Update: Ticket #78069 Billable: $0.00 Total: $0.00
 To: [email protected]


 Your Ticket #78069 has been updated by Jon Bayless:

 Customer: Barrett Anderson
 Ticket description: Connection Issues
 Ticket category: Colocation Services: Connectivity Problems
 --------------------------------------------------------------------------------------
 Monday October 24th at approximately 3:50AM Mountain Time, one of
 Fibernet's routers that provides service to our customers was the
 target of a large denial of service attack (DOS). The attack lasted
 about 25 minutes. During the attack, many customers whose service is
 provisioned on the affected router would have experienced increased
 latency and moderate or high rates of packet loss or intermittent loss
 of service. This attack also had a side effect of revealing a bug in
 the router software that we believe caused the impact of the attack to
 be amplified beyond what normally would have occurred. Due to this we
 are scheduling an emergency software upgrade on the router in question
 as soon as possible.

 The software upgrade will result in a minimal interruption in internet
 service on the affected router. The interruption is expected to last
 less than 5 minutes.
 Emergency Maintenance Window:

 30 minute duration
 Monday Oct. 24 11:30PM to Tuesday Oct 25 12AM (Midnight)

 Expected service interruption:
 Less than 5 minutes

 Another short interruption happened as you mentioned about 20 minutes
 ago. The software update should prevent any further issues.

 Sorry for the difficulties.

 Thanks

 --------------------------------------------------------------------------------------

 To respond to this update or change ticket options, please login to
 the customer section of our website:

http://www.fiber.net/

 Thanks!!

The curly brackets dereference a pointer.
http://eeems.omnimaga.org/Files/Resources/program%20readmes/Axe/Commands.htm#Das is the usage instructions.

Lets say you have the following expression: {L1}
L1 essentially always contains the number 0x86EC (or 34540 in base 10). This happens to be the address of a safe spot in RAM.

Now, the memory in any computer is laid out numerically. The 83+'s have each individual number equal to one byte of storage space in the calculator. That means that each number can essentially hold from 0 to 255. L1 can hold from 0-255, L1+1 can hold from 0-255.

{L1} would get you the value of the number at 0x86EC. {L1+1} would get you the value of the number at 0x86ED.

These numbers can then be used as a normal variable. For example:

1->{L1} would store 1 into 0x86EC, or L1. 2->{L1+1} would store 2 into 0x86ED, or L1+1.


Lemme know if this doesn't clear it up for you.

Nightly 10 right now
Yeah their new rapid release process is great ( IMHO ) it allows them to get security fixes out faster, and to get new content out to us to use way faster.

Yea, but they keep touting each release like it's a giant deal. That's been bugging me.

That vaguely reminds me of VVVVVV

As far as the zip goes (I'm no good with compression) if you remove the first 367 bytes, it looks to be a normal zip that even opens with Windows' built-in zip tool, which is extraordinarily bitchy.

The document.xml at the top appears to be a valid zip entry, once you patch the header. The rest of the zip seems to be running off of the assumption that it's not there (the central directory start is offset by -367 bytes, problem1.xml starts at 0x00, etc...) It's also compressed with the 0x0D compression type.

I repaired the central directory (Added an entry for document, corrected the offset of problem, added one to the file counters, updated the start of directory offset, updated the size of directory, searched for stupid typo for 5 minutes; I didn't update the timestamps on document.xml) in a copy of it and properly placed everything. Here's my resultant zip. Other than that 0x0D compression type, everything opens it fine.

Edit: The -367 byte offset assumes that you haven't fixed the entry for document.zip (remove first 10 bytes, add 0x50,0x4B,0x03,0x04).

I've never showed hostmasks, no. I actually don't have anything set up to track them right now, but I can probably get something set up.