It is perfectly possible to configure a linux server (or workstation if you wish) to talk IPsec. The Linux Advanced Routing & Traffic Control site has a page describing it. Since IPsec is a standard protocol, I wanted to get a tunnel up and running between a linux host and a Cisco router: with success! Here are the config files that I used in this test:
Place: Halle
Tanks flown: 2
Time flown: 0h30 (cumulative model timer: 31h49)
Rx battery recharged with: 1244 mAh
Tx battery recharged with: 491 mAh
Glow heater battery recharged with: 1397 mAh
Starter battery recharged with: 54 mAh
Comments:
A very windy but beautiful day. Did some basic flying around (stall turn, circuit). Also retried flying inverted for several seconds with success.
Added 1 turn of pitch to the “black” blade to adjust the tracking
IPsec is becomming the Internet standard for securing IP packets. Instead of manually configuring all the encryption parameters, the keys are usually negatiated between the peers using an ISAKMP (Internet Security Association and Key Management Protocol)/Oakley protocol: IKE (Internet Key Exchange). This post goes into its details.
10base-T is the oldest Ethernet standard that runs over regular twisted pair cable. 10base-T requires UTP cables of Cat3 or higher, with a total length of maximum 100m. I wanted to figure out if you can generate “hard” packets for Ethernet; packets that somehow may expose problems in the hardware: signals with DC offsets, high frequency signals, low frequency signals, signals where the clock might be hard to track, … This post describes the journey of an ethernet frame from memory to wire.
When looking for documentation on Ethernet, one can easily find that the frame includes a Frame Check Sequence. This is a bunch of bits that allow the receiver to verify the frame. If the frame somehow got corrupted on its way from sender to receiver, the FCS will not match the frame data and the receiver will discard the corrupt frame. Exactly how this FCS is calculated is not that easy to find.
When doing some network engineering, it’s sometimes necessary to tunnel across IP-clouds. There are multiple reasons why one would use a tunnel:
- Security: You don’t want the carrier-network to see your data
- IP conflicts and/or routing issues: You want to carry private IP addresses (eg 10.0.0.0/8 in IPv4) across a public segment (eg the Internet)
- Workarounds: for whatever reason you whised that there was a connection between A and B
Technically, a tunnel consists of taking a bunch of bytes and re-packaging it. The well knows GRE-tunnel takes IP packets and encapsulates them in another IP packet. The outer IP-layer is used to carry the packet across to the other endpoint, where the inner IP-layer reappears. Other tunnels operate at different layers. SSH for example encapsulates TCP segments inside its TCP-connection; SSL-based VPN encapsulate IP packets inside their TLS-session.
Especially in the third case, workarounds, it would be very practical to be able to build a layer 2 tunnel: transport raw ethernet frames, including IEEE802.1q VLAN tags. This is called the L2TP, Layer 2 tunneling protocol. The current version (3) is defined in RFC 3931.
I got another toy to play with: A digital multimeter with RS232 interface and True RMS power measurement. Sadly, it comes with Windows-only software, which I interpreted as a challenge!
Continue reading ‘VoltCraft VC-940 protocol reverse engineered’ »
When hosts have a dynamic IP, it’s very convenient to have its DNS-name follow that dynamic IP. There are several services on the net that do this. However, the regular DNS already provides this feature. The nsupdate tool (comes with BIND) allows you to send an update to the DNS servers. By default, a DNS server does not allow updates for security reasons.
To keep the whole world from updating your zone, there are several possibilities to restrict who can update what. The easiest to setup is an IP restriction: specify from which IPs updates are to be accepted. In my setup, however, I’d like the host to update its own record. Since the host’s IP is dynamic, this is not an option.
Place: Halle
Raptor
Tanks flown: 2
Time flown: 0h27 (cumulative model timer: 31h19)
Rx battery recharged with:
Tx battery recharged with: 559 mAh
Glow heater battery recharged with: 1300 mAh
Starter battery recharged with: 1250 mAh
miniTitan
Flights: 2
Time flown: 0h21 (cumulative model timer: 3h17)
Heli battery recharged with: (1) balanced 1934 mAh; (2) balanced 2137 mAh;
Tx battery recharged with: see above
Comments:
Went flying after work. It was fairly windy, but the wind was fairly constant. I practiced the maneuvers I’ve been doing in the sim lately: autorotation and inverted flight, both successful!
Inverted flight worked out fairly well. I started by doing backflips. Next I stopped halfway through the backflip and tried to keep it stable. I only need to work on my reflexes to get me out of inverted trouble. Obviously pushing the throttle/pitch up is not the best idea… Luckily I had (just) enough height to correct my peculiar situation.
The miniTitan held up fairly well in the winds, although I was more busy fighting the wind than flying. I increased the CCMP-mixing from 50% to 75% on the elevator and ailerons. Now it is more vivid, just like my raptor. I tried some backflips as well, but the wind made this a challange.
When doing some research on the different tables in iptables, I was trying to figure out in what order what tables are traversed. Obviously PREROUTING happens before POSTROUTING, but it becomes more difficult to figure out if mangle happens before are after nat.
I found a post which links to this overview (local copy):
Recent tests on kernel 3.13.0 (Ubuntu Trusty 14.04) show that tcpdump captures before mange-PREROUTING and after nat-POSTROUTING.
