Long-term Memory

Place: Halle
Tanks flown: 2
Time flown: 1h00 (cumulative model timer: 30h52)
Rx battery recharged with: 272+392+overnight trickle mAh (again)
Tx battery recharged with: 489+overnight trickle mAh
Glow heater battery recharged with: 1473 mAh
Starter battery recharged with: 498 mAh

Comment:
Before this flight, I adjusted the pitch and throttle curves and activated the IdleUp2 position. This is the updated table from before:

Today was the first day with reasonable weather. It was still windy, but almost no gusts.

Had some trouble starting the engine. Turns out there was some dirt in the needle of the carburator. Simply turning the needle a bit (5 ticks) open, starting the engine and returning the needle to its original position solved this issue (although it took me more than 30 minutes to figure it out).

No spectacular flight for this first time, just some hoovering in different directions. The second flight was a bit more entertaining: I rehearsed my stall-turns and tried some standard patterns, which was quite a challenge in these (cross)wind conditions.

I just found a very nice post describing nice things to do with Bluetooth. By using the Proximity tool, my MacBook Pro can monitor the precense of my cell phone. Proximity will run an AppleScript when a selected device enters and/or leaves Bluetooth range. Most  phones are class 2 Bluetooth devices, which gives a range of 10m (outdoors). This allows you to automatically lock your desktop when you leave and unlock when you come back.

Continue reading ‘Useful things to do with Bluetooth’ »

I was looking around to get my VIDEO_TS-directory burned to a DVD-R disc. Apparently, Burn does not support this. This hint seems to work:

hdiutil makehybrid -udf -udf-volume-name DVD_NAME -o MY_DVD.iso /path/to/VIDEO_TS/parent/folder

Cisco switches are very verbose in their layer 1 error reporting as shown in the output below:

FastEthernet0/1 is down, line protocol is down
  Hardware is Fast Ethernet, address is 0030.94bd.4041 (bia 0030.94bd.4041)
  MTU 1500 bytes, BW 0 Kbit, DLY 100 usec, rely 255/255, load 1/255
  Encapsulation ARPA, loopback not set, keepalive not set
  Duplex setting unknown, Unknown Speed, 100BaseTX/FX
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input never, output 00:35:31, output hang never
  Last clearing of "show interface" counters never
  Queueing strategy: fifo
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     1 packets input, 64 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     0 watchdog, 0 multicast
     0 input packets with dribble condition detected
     3 packets output, 444 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

On this page on the Cisco website, there is a table listing all error counters and their meaning for Ethernet interfaces.

Xkcd.com has a very true comic on the practical side of security.

I just read an interesting article on how HFS+ deals with fragmentation. Not only will it take proactive steps to avoid fragmentation, apparently it will defragment some files on-the-fly.

This forensics-site has a very detailed article on the hex-dumps you can get from an HFS+ partition.

Our weather station has a serial connection and comes with Windows-software to view the weather data on your PC. The app is very eye-candy, but doesn’t do anything more than displaying the data. I’m more interested in long-term trending. So I wrote my own application to talk to the weather station and store the result in an rrdtool database.

Continue reading ‘Reverse engineering the Oregon WMR928NX weather station’ »

When troubleshooting a slow network connection I wanted to get an idea of the link load. Usually I power up my linux-based Virtual Machine which polls the SNMP interface counters and draws nice graphs. But I was working remotely over an RDP connection, so SNMP was not possible.

So I had to use the build-in tools of the ProCurve switch. The “show interface” output looks like this:

Status and Counters - Port Counters for port 24

  Name  :
  Link Status     : Up
  Totals (Since boot or last clear) :
   Bytes Rx        : 819,265,344        Bytes Tx        : 1,217,179,587
   Unicast Rx      : 4,052,391          Unicast Tx      : 5,062,876
   Bcast/Mcast Rx  : 1,142,020          Bcast/Mcast Tx  : 7,390,717
  Errors (Since boot or last clear) :
   FCS Rx          : 0                  Drops Rx        : 0
   Alignment Rx    : 0                  Collisions Tx   : 0
   Runts Rx        : 0                  Late Colln Tx   : 0
   Giants Rx       : 0                  Excessive Colln : 0
   Total Rx Errors : 0                  Deferred Tx     : 0
  Rates (5 minute weighted average) :
   Total Rx  (bps) : 501944             Total Tx  (bps) : 504256
   Unicast Rx (Pkts/sec) : 0            Unicast Tx (Pkts/sec) : 0
   B/Mcast Rx (Pkts/sec) : 0            B/Mcast Tx (Pkts/sec) : 4
   Utilization Rx  : 00.04 %            Utilization Tx  : 00.04 %

Note the values on the bottom indicating the “Rates”? They’re not what they claim to be! This particular interface has approximately 1kbps input (Rx) and 3kbps output (Tx); not exactly the 500kbps the output claims. Also, try to explain how to receive 502kbps of data with less than 1 packet per second…

This particular switch is a 2610-24PWR with firmware R.11.16; but it’s probably a more general problem.

Everyone with some basic knowledge on the TCP/IP protocol knows that TCP can cope with lost packets. The lost packet is retransmitted, the send-rate is throttled back a bit and on it goes. I just found this usenet-post by stanislav shalunov giving a formula to calculate just how much bandwidth remains after all that “throttling back”:

Standard TCP has throughput that’s limited by approximately MSS/(RTT*sqrt(loss)). Therefore, if your MSS is 1460B and RTT 70ms (typical for a cross-continent path), you need no more no more than 0.0003% packet loss to get 100Mb/s or 0.03% to get 10Mb/s. Note that, because of that square root, every doubling of required throughput means dividing permissible packet loss by four.

Recently Bruce Schneier has posted some very good and readable posts on biometrics and impersonation, explaining the difficulties with security systems. Recommended reading for everyone in security!