RND(tech) - Linux

LaCie brings Lightscribe to the rest of us

nospam@example.com (Khanh Tran) — Tue, 17 Oct 2006 15:16:33 -0700

LaCie announced today that they now offer a complete Lightscribe solution for all platforms. That means now Mac OS X and even Linux users can write labels to Lightscribe media with Lightscribe drives. Lightscribe is a technology that allows you to etch silk screen quality images on the label side of CD/DVD media. Up until now, the technology was limited to Windows users due to lack of software. Now with the LaCie LightScribe Labeler for MAC OS, SureThing for Windows and LaCie LightScribe Labeler for Linux, we have software available to the three major OS platforms. Did I forget to mention the software is free from LaCie? Yes, it really is.

See:
http://www.lacie.com/lightscribe http://www.lightscribe.com

using openSSH as a layer-2 ethernet bridge (VPN)

nospam@example.com (Khanh Tran) — Tue, 18 Nov 2008 21:11:40 -0700

Consider the following network setup (which I live with by the way):

[main LAN] <-----------------------------------------------------> [remote datacenter LAN]
(192.168.0.0/16) <-------- leased point-to-point ------------> (192.168.0.0/16)

Both locations also have separate connections to the public Internet with different public IP subnets. However, for this discussion it's not necessary to have different public IP subnets. Under normal circumstances the local LAN and the remote LAN are the same logical LAN via the magic of the leased point to point line.

However, today that p2p connection broke (physically between the two locations, out of our control). This outage lasted several hours, but brought out an interesting use of SSH tunneling for ethernet bridging aka Layer-2 VPN or tunneling. For this to work, you'll need to have at least openSSH 4.3, a somewhat recent linux distro and the bridge-utils package for your distro. This also assumes you have a basic knowledge of IP and the linux command line. I use openSuSE 11.0, but this should work for almost any similar linux.

Let's say for example, the main location has a linux box (router1) with two NICs:
eth0: 1.1.1.1 (the public interface)
eth1: unassigned IP, but connected to your LAN (192.168.0.0/16 in my case)

On the other box, at the remote location (router2) we also have two NICs:
eth0: 2.2.2.2 (the public interface)
eth1: unassigned IP, but connected to your LAN (192.168.0.0/16 in my case)

Both routers should be set with it's public IP gateway as the default route, working DNS, etc. You'll want to enable IP forwarding (consult your specific distro) and in my case, I disabled the distro's firewall. On the remote side (consider it the "server"), you'll need to edit your sshd config to allow remote root logins and tunnels via SSH.

/etc/ssh/sshd_config:
PermitRootLogin yes
PermitTunnel yes

The root login is necessary to allow ssh to create the TAP devices for the bridge. Because of that, you'll also want to add your local side's IPs to /etc/hosts.allow for the sshd process. Now, on the local side (IP 1.1.1.1, which you might consider the client now) you'll want to "su root" and do the following:

ssh -o Tunnel=ethernet -f -w 0:0 2.2.2.2 true

The -o switch sets client options on the command line. We're specifying the tunnel type as ethernet (bridge) as opposed to point-to-point, which it'll do by default (for Layer-3 type VPN routing). The -f switch just forks ssh in the background so we're returned to our "client's" command line and not remote's. Since we've done that, ssh will expect a remote command of some kind, so we'll just run "true", effectively doing nothing. The -w 0:0 switch actually sets up our tap devices on either side as tap0. You can do -w 1:1 for tap1, -w 0:1 for tap0 on one side and tap1 on the other, etc.

On both sides now, you should be able to see via ifconfig -a your eth0, eth1 and tap0 devices. Make sure to call ifconfig with -a, or you'll only see interfaces with defined IPs. Now that the two boxes are connected via the public Internet to each other via SSH, you can finally start to establish the bridge interface. Now we'll use the bridge-utils binary to create a bridge interface called br0:

brctl addbr br0
brctl addif br0 eth1
brctl addif br0 tap0

Then you'll want to bring up all of your interfaces, if they aren't already:

ifconfig eth1 up
ifconfig tap0 up
ifconfig br0 up

Doing so will create the br0 interface, then bridge your eth1 and tap0 together and bring up the interfaces. Don't forget, YOU MUST RUN THE brctl and ifconfig COMANDS ON BOTH SIDES!!! Once you've done this, you can check the remote side to see if it knows about the MAC addresses (from Layer-2) on the local side:

brctl showmacs br0

This will report on the known MAC address from the ARP protocol. Depending on your network, you'll see a few or many. Depending on your setup, you can get a DHCP address on the "other side" of the tunnel now or configure an appropriate IP and ping across as if you were on the same physical broadcast domain!

As a final note, there's always a downside. TCP encapsulated TCP is bad and will put a STRAIN on your hardware. Make sure it's decent for the amount of anticipated traffic and use only as a quick and dirty solution or a temporary measure. The following is good reading for why this is not a long-term, permanent solution:
http://sites.inka.de/~W1011/devel/tcp-tcp.html

disabling NetBIOS over TCP/IP in Windows via BIND DHCPD

nospam@example.com (Khanh Tran) — Thu, 27 May 2010 08:31:40 -0700

This is scarce information on the Internet, so I'm reposting!

NetBIOS can be disabled now that it's fairly ancient networking. You're using TCP/IP and DNS right?
I don't use Microsoft DHCP or DNS servers, so finding the information to set this is hard to come by. To disable NetBIOS over TCP/IP in an ISC DHCP server, add the following to your dhcpd.conf:

option vendor-encapsulated-options 01:04:00:00:00:02;

It's that easy!

compare a burned dvd or cd with iso file in linux

nospam@example.com (Khanh Tran) — Sat, 26 Mar 2011 18:06:30 -0700

This is something I've been meaning to write for a while. By using this script and md5sum, you can verify that data burned to CD/DVD matches the original ISO file in Linux. It's a bit tricky, as it's not as simple as just running md5sum against /dev/dvd (the whole disc). That's because more than just the data in the ISO is written to the media (finalizing the disc, etc.).

#!/bin/bash

#Script to check md5sum of iso file against disc in drive
#DEPENDS on md5sum existing in path
#
#script should be called like:
# ./md5check.sh file.iso /dev/dvd

ckFile=$1
ckDrv=$2

echo "Getting file extents..."
fext=$(( $(ls -l $ckFile | awk '{ print $5 }') / 2048 ))

echo "Getting md5sum of file..."
fileMD5sum=`cat $ckFile | md5sum`

echo "Getting md5sum of disc in drive..."
drvMD5sum=`dd if=$ckDrv bs=2048 count=$fext | md5sum`

echo "File md5sum: " $fileMD5sum
echo "Drive md5sum: " $drvMD5sum

if [ "$fileMD5sum" = "$drvMD5sum" ]; then
echo " "
echo "md5sum of" $ckFile "and" $ckDrv "match."
echo " "
else
echo " "
echo "********************************"
echo "******** WARNING!!! **********"
echo "********************************"
echo "** md5sum DOES NOT MATCH!!! ***"
echo "********************************"
echo "********* WARNING!!! **********"
echo "********************************"
echo " "
fi

RND(tech) - Linux

LaCie brings Lightscribe to the rest of us

using openSSH as a layer-2 ethernet bridge (VPN)

disabling NetBIOS over TCP/IP in Windows via BIND DHCPD

more MythTV and Intel G33 video performance

compare a burned dvd or cd with iso file in linux