Thursday, October 1, 2009

Ethernet link drop when unlocking Vista

Oddly, my Vista laptop was dropping the wired Ethernet link each time that I unlocked the computer. Very frustrating as all my apps would have to reconnect, etc.

After some quick poking around in the power settings, I've uncovered in the properties of the Intel 82567LM network card:
- Reduce link speed during battery operation
- Reduce link speed during system idle


Uncheck these, and the issue goes away : )



It has to be said, Intel does have some stupid "default" settings on this card. Here's a registry hack to be able to see 802.1p/q headers, which for some reason Intel, by default, doesn't want us to see... bizarre.

http://www.intel.com/support/network/sb/CS-005897.htm

Sunday, September 13, 2009

vmware raw disks

Here's an odd setup... but I want to have only one computer turned on 24/7 in my house, this is what I'm doing:

Hardware:
  • Asus P5Q3 with 4gb RAM & Intel core 2 duo
  • 4 x 1.5TB drives (1.36 REAL terrabytes... damn you harddrive industry)

Vista 64-bit on "bare metal"... why Vista? because of the TV Tuner cards (Windows 2003 is no good for this task).

Responsibilities:
  • MediaPortal TV server
  • Printer Server
  • VMware host (VMware Server 2.0)

On this I run 3 x OpenSuSE 11 systems hosted in VMware server, each for a different purpose:
  • Asterisk PBX
  • Fileserver
  • General use host for fun

The crazyness of this system comes about through use of Vista as the base OS, and the fileserver as Linux. I want the linux fileserver to have direct access to each drive.

The drives are partitioned like so:

64gb NTFS partition
1333gb Data partition (ext3) (md software raid5)


Annoyingly VMware server 2 'apparently' removes the feature of raw disks... that is, drives that show up in the VMware without the need to create an intermediate VMware file-based disk.

To get around this, I installed the demo of VMware Workstation 6.5 and created the VMware machines.

Here's the definition of the rawdisk's in the .vmdk files:

# Disk DescriptorFile
version=1
encoding="windows-1252"
CID=a1a071cd
parentCID=ffffffff
createType="fullDevice"

# Extent description
RW 2930277168 FLAT "\\.\PhysicalDrive0" 0

# The Disk Data Base
#DDB

ddb.toolsVersion = "7458"
ddb.adapterType = "lsilogic"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "16"
ddb.geometry.cylinders = "16383"
ddb.uuid = "60 00 C2 9a 4e e3 4f 90-5f 74 f9 c8 0f 2b c1 f0"
ddb.virtualHWVersion = "7"


That makes the drive appear as a SCSI drive in the VMware, despite it being an IDE drive.


To give another example:

# Disk DescriptorFile
version=1
encoding="windows-1252"
CID=b362ecc3
parentCID=ffffffff
createType="fullDevice"

# Extent description
RW 2930277168 FLAT "\\.\PhysicalDrive3" 0

# The Disk Data Base
#DDB

ddb.toolsVersion = "7458"
ddb.adapterType = "lsilogic"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "16"
ddb.geometry.cylinders = "16383"
ddb.uuid = "60 00 C2 9b 2f e0 b6 75-8a da b5 7c 6c eb 0a 96"
ddb.virtualHWVersion = "7"



Then in the .vmx file:

scsi1.present = "TRUE"
scsi1.virtualDev = "lsilogic"

scsi1:0.present = "TRUE"
scsi1:0.fileName = "vm_fileserver_d0.vmdk"
scsi1:0.deviceType = "rawDisk"
scsi1:1.present = "TRUE"
scsi1:1.fileName = "vm_fileserver_d1.vmdk"
scsi1:1.deviceType = "rawDisk"
scsi1:2.fileName = "vm_fileserver_d2.vmdk"
scsi1:2.present = "TRUE"
scsi1:2.deviceType = "rawDisk"
scsi1:3.present = "TRUE"
scsi1:3.fileName = "vm_fileserver_d3.vmdk"
scsi1:3.deviceType = "rawDisk"

Wednesday, August 19, 2009

SSL countries don't match?

Problem:

server:~/myCA # openssl ca -out certs/server.cert.pem -days 1461 -keyfile private/myCA.key.pem -extensions v3_ca_has_san -config ./openssl.cnf -infiles requests/server.req.pem

Using configuration from ./openssl.cnf
Enter pass phrase for private/myCA.key.pem:
Check that the request matches the signature
Signature ok
The countryName field needed to be the same in the
CA certificate (AU) and the request (US)

server:~/myCA #


Uh-oh? Why can't I sign a certificate with my CA setup in Australia, for a server in the USA?

Simple, the CA's openssl.cnf is required to "match" the country name (and other parameters).
(i.e. requested cert's much match parameters in the signing CA)

Alter these in the CA's openssl.cnf to "supplied" instead:

[ policy_match ]
countryName = supplied
stateOrProvinceName = supplied
organizationName = supplied

SSL keys for a webserver

Here's how I generate SSL keys for a webserver.

In particular I want name-based vhosts with SSL - this can only be done with multiple DNS names in the certificate...

Most of my openssl setup has been guided by:
http://www.phildev.net/ssl/opensslconf.xhtml
http://www.phildev.net/ssl/creating_ca.xhtml
http://www.phildev.net/ssl/managing_ca.xhtml

with a little info from here:
http://wiki.cacert.org/wiki/VhostTaskForce#A1.Way.3ASubjectAltNameOnly


step 1.... get openssl.cnf as you want it

step 2.... add multiple dns names as required
[alt_names]
DNS.1 = example.net
DNS.2 = www.example.net
DNS.3 = example.com
DNS.4 = www.example.com
DNS.5 = mms.example.com
DNS.6 = fancy.example.org


step 3.... generate key:
openssl genrsa -out example.net.key.pem 4096


step 4.... generate cert
openssl req -config ./openssl.cnf -new -key example.net.key.pem -out example.net.req.pem


use one of the names as the CN..
usually I'd say use the DNS A record as the CN (i.e. if example.net -> a specific IP, and that IP's PTR is example.net)... and then put all the C-names in as DNS (as well as the A-rec) (i.e. the DNS aliases, www.example.net = example.net)


step 5.... transfer the req to the CA and sign it
openssl ca -out certs/example.net.cert.pem -days 1461 -keyfile private/theCA.key.pem -extensions v3_ca_has_san -config ./openssl.cnf -infiles requests/example.net.req.pem




how does it end up?

One CN:
Subject: C=AU, ST=Victoria, O=example, OU=example dot net, CN=example.net/emailAddress=security@example.net

Multiple DNS's
X509v3 Subject Alternative Name:
DNS:example.net, DNS:www.example.net[...]

Saturday, August 15, 2009

Wii and the Edimax 7206-APg

Tonight I upgraded the Edimax 7206-APg from the somewhat unstable 1.22 firmware, to the newer 1.31. I am surprised they are still developing for this particular model - 1.26 firmware was available for a long long time before 1.31 came out this year.

Anyway, I tried setting "Authentication Type" to shared key, instead of open system... not that it should make a different in a WPA2 environment, but I had a theory that a laptop I have might stop dropping out and then saying "insecure" if I changed it.

On shared key however, the Wii refused to connect (51030). So I tried the auto setting. No good either. Back to open system - now it works.

While thinking about the Wii + wireless, another annoying thing about the Wii is that it requires a B+G wireless environment. Pure G does not work. It has to be both B and G. Frustrating.

My observations are that the Wii starts on 802.11b and then negotiates its' way up the speeds until 11mbit is going, at which point it negotiates its' way onto 802.11g and faster again through all the speeds. Quite bizarre. Why not start at 55mbit and work its' way down if it has to?...