Aldi’s USB Microscope

May 13th, 2010

On behalf of the Tadger, we picked up a Traveller USB Microscope this evening at our local Aldi. It looks a bit “Fisher Price”, but on the other hand, if you can capture the output of a 200x microscope for €40, that seems worth a punt. Tadge likes to promote science to the young folk, so maybe he can do some cool microbiology stuff with it for their benefit.

It basically seems to be a webcam of sorts, rigged up with a rotatable lense housing which allows you to choose between the three lenses (10x, 60x, 100x). There are a couple of buttons on it which seem

I don’t have very long with it, but I was hoping it might work with linux. It doesn’t out of the box on Ubuntu Lucid anyway, but I’m sort of wondering (probably very naively) if the UVC driver might be convinced to work with it. It would appear that if it worked, it should appear as a device in /dev/videoX which would be pretty cool.

For the sake of a record, according to lsusb, the device is as follows:

Bus 001 Device 003: ID 1871:01b0 Aveo Technology Corp.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x1871 Aveo Technology Corp.
  idProduct          0x01b0
  bcdDevice            0.05
  iManufacturer           1 AVEO Technology Corp.
  iProduct                2 AVEO Cheetah3 USB2.0 Device
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          105
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0000  1x 0 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       1
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       2
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x03fc  1x 1020 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       3
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       4
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0c00  2x 1024 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       5
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x1400  3x 1024 bytes
        bInterval               1
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0000
  (Bus Powered)

We shall hopefully see…

Give up yer aul’ iPods.

February 17th, 2010

The Anglican Church are hilarious.

An iPod is a vice now?

Does using an iPod contribute more to climate change than eating chocolate? I suppose if you count the full lifetime (including manufacture) it might, but I doubt ignoring an iPod for a day or forty will extend its useful life noticeably.

Major ext3 improvements in linux v2.6.30

June 22nd, 2009

We run a number of linux servers at work, almost all using the ext3 filesystem and seldom see any reason to complain.

One exception however is a monitoring machine we have.  It runs MRTG on about 70-80 switches and servers around the campus every 5 minutes. The MRTG instances are run by three shell scripts which start in parallel. Now and then I do a bit of text editing on that machine and (until recently) about every two minutes in five, saving a small text file can take anywhere between 5 and 20 seconds. To put it politely, this is very frustrating and makes the machine pretty unusable for other things.

I was therefore interested to read an LWN article about Solving the ext3 latency problem. Last week, I got around to compiling a 2.6.30 kernel on that machine to try see would it help. The answer is a resounding yes. At this point, you can still notice a delay saving text files, but it’s more like 0.5-1.0 secs. Our munin graphs show the load, vmstat and netstat established connections on the box all dropped hugely after the reboot.

craicstaffgcdie-vmstat-week

craicstaffgcdie-netstat-week

If you’re having trouble with filesystem delay, this kernel is a highly recommended update.

Distros, please backport these changes!!!

Dell’s OMSA tools are nice

May 6th, 2009

We have a couple of Dell servers running Ubuntu GNU/linux (hardy) with MD1000 disk arrays. I’ve always assumed there must be a way in software to create arrays, configure them, initialise them, etc. in software without rebooting but I hadn’t had need of that until now and just need .

I had previously installed the DELL OMSA suite for basic monitoring but hadn’t had time to look into it in detail. I was kind of hoping for command line utilities for everything. As it turns out, most of it is web-based. Perhaps there’s a command line tool hidden in there, but the web-based one is fine for now. I’ve just popped two extra disks into a live array and am initialising them as a RAID1 array now. I’ll be shortly deciding whether to add them to an LVM device or just use the separate block device.

These sites have enough information to get one going:

Actually, they tell you all manner of useful things about your server’s health, whether or not you have RAID arrays. I can’t believe I’m only discovering this now.

RTÉ get flashy

April 26th, 2009

First impressions on RTÉs flash-based catch-up service are pretty positive.

http://www.rte.ie/player/

Working fine on Linux (albeit requiring the Adobe flash plugin), no nasty logins, no extra software to install, no DRM. I’m sure I’ll find something to complain about, but I haven’t found it yet.

strata_dk280_dump_reader v0.02

April 6th, 2009

We needed to read in the pickup groups and the dialling restrictions from our phone system dumps so I’ve added that functionality to the code. I’ve created a small page on this now here and if you’re interested, you can get the code on that page.

Inspiring Confidence

April 5th, 2009

Last Saturday (28/03/2009), Marian Finucane interviewed Mary Coughlan who is Tánaiste (deputy leader of the Irish government) and Minister for Enterprise, Trade and Employment, on RTÉ Radio 1. On the train, I had time to listen in.

Doubts have been raised in the past few months about the Tánaiste’s credentials to take on such an important economic portfolio at a critical time. Twenty minutes into the interview, Finucane obligingly gave her moreorless uninterrupted air-time to answer those doubters. Her response was jaw-droppingly vacuous. It’s transcribed below. The full interview is available as a podcast from RTÉ.

MC:
He (Brian Cowen) said to me how many years are you in that department of agriculture and I told him and he said “I think you might need a change. What would your interests be?” and I said I would like to get into something on the economic side.
MF:
Why?
MC:
Because I think that, and I distinctly remember Mary O’Rourke saying this some time ago, she said “Women shouldn’t always be put into the soft options”. Now, I wasn’t (in a soft option) at agriculture because I was the first woman ever appointed into that. Women were kind of … they were in education and they were in health and they were in social welfare. Now it’s an honour to serve, no matter where you are but I thought “right I need another challenge” so I thought an economic challenge would be appropriate.
MF:
And what made you, and I don’t mean this in any rude way but what makes you think you’re qualified to do the economic one?
MC:
Well I’ve had twenty two, twenty three years of public life. I have been a minister for a considerable number of years. I work very hard.
MF:
I have no doubt.
MC:
I have a huge interest in the betterment of this country, creating opportunities for the generations that are coming behind it of which I have two of my own, and my view in public life and public service is that the place that you now find yourself, let’s hope you provide a good legacy for the people coming after you and that’s where I had the interest and the focus.
MF:
And, I mean, given that you, and I’m not suggesting that one needs experience of business or that one needs experience of industry to do the job but going into the Dáil at twenty one you don’t really have experience of life at that stage…
MC:
No, you didn’t, no.
MF:
…so why did you think that you were, you were up for this one?
MC:
Because at twenty one years of age I could challenge the parliamentary party and the leadership in a different way, and in a right way. I love to see young people challenging you. The one thing I said in agriculture was “Where’s the new ideas? Where’s the challenge?” That’s what young people are supposed to do, come up with new ideas and challenge you and say “well maybe you should do it this way or that way”. At twenty one years of age you’re quite right I had no political experience, I had had great stewardship from a lot of people, I served a considerable period of time in the back benches. I grew up through the back benches. I had a considerable experience of local government. And on that basis I worked through a considerable number of portfolios over the years and I was appointed as an opposition spokesperson in education with Michéal (Martin). I then went on to be a junior minister. I cut my teeth there, I worked very hard, learned a considerable amount and put a lot of effort into it. I think it’s on that basis that I was appointed as a minister and you know you get all these steep learning curves but you know if you don’t learn you’re never going to have an acumen. And there’s always been this view, “oh well, if you have lawyers, what would they know about business, if you’ve social workers what would they know about farming”. At the end of the day, nobody purports to know everything. The one thing you should never do in life is say you know it all and if you don’t know it all then you are willing to learn and to listen and that’s what you do.
MF:
The notion that there’s the Coughlan seat or the Cowan seat and that they’re family seats. Do you think that’s appropriate….

The iPhone sending wierd DHCP responses?

February 23rd, 2009

I’ve had my rogue dhcp detector script running for a while. It’s been pretty handy. However, every now and then it would detect a rogue dhcp server which would disappear again before I could track it down. I could tell it was in our building from mac address tables on the switches and it appeared to be on wifi. Strangely the response was coming from an Apple mac address with an IP of 0.0.0.0. I checked a couple of nearby iBooks but they had very different mac addresses.

This evening, before I left work, I got another email suggesting a rogue dhcp server had been detected. I’d just put my iPhone down. Ooh! That would have an Apple mac address. Surely not the iPhone? Yes indeed, my own phone has been sending me on wild goose chases.

Playing around now at home, it’s completely reproducible. I can run tcpdump on both the phone and my laptop (both on wifi). When I tell the laptop to renew its dhcp lease, I always see two replies from my wap’s dhcp server and, strangely, two from my iPhone. This is the tcpdump output:

22:01:34.195127 00:14:7f:15:2a:48 > 00:16:6f:7c:25:8a, ethertype IPv4 (0x0800), length 321: 192.168.1.254.67 > 192.168.1.70.68: BOOTP/DHCP, Reply, length 279
22:01:34.207787 00:14:7f:15:2a:48 > 00:16:6f:7c:25:8a, ethertype IPv4 (0x0800), length 321: 192.168.1.254.67 > 192.168.1.70.68: BOOTP/DHCP, Reply, length 279
22:01:34.551867 00:21:e9:23:0b:53 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
22:01:34.557164 00:21:e9:23:0b:53 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548

In fairness, it doesn’t appear to do much harm that I can see, but I’d love to understand a little better what’s going on here.

This is the full packet from my own dhcp server:

22:01:34.207792 00:14:7f:15:2a:48 > 00:16:6f:7c:25:8a, ethertype IPv4 (0x0800), length 321: 192.168.1.254.67 > 192.168.1.70.68: BOOTP/DHCP, Reply, length 279
        0x0000:  0016 6f7c 258a 0014 7f15 2a48 0800 4500
        0x0010:  0133 12e8 0000 4011 e23d c0a8 01fe c0a8
        0x0020:  0146 0043 0044 011f 91fa 0201 0600 a51d
        0x0030:  0725 0000 0000 0000 0000 c0a8 0146 0000
        0x0040:  0000 c0a8 01fe 0016 6f7c 258a 0000 0000
        0x0050:  0000 0000 0000 0000 0000 0000 0000 0000
        0x0060:  0000 0000 0000 0000 0000 0000 0000 0000
        0x0070:  0000 0000 0000 0000 0000 0000 0000 0000
        0x0080:  0000 0000 0000 0000 0000 0000 0000 0000
        0x0090:  0000 0000 0000 0000 0000 0000 0000 0000
        0x00a0:  0000 0000 0000 0000 0000 0000 0000 0000
        0x00b0:  0000 0000 0000 0000 0000 0000 0000 0000
        0x00c0:  0000 0000 0000 0000 0000 0000 0000 0000
        0x00d0:  0000 0000 0000 0000 0000 0000 0000 0000
        0x00e0:  0000 0000 0000 0000 0000 0000 0000 0000
        0x00f0:  0000 0000 0000 0000 0000 0000 0000 0000
        0x0100:  0000 0000 0000 0000 0000 0000 0000 0000
        0x0110:  0000 0000 0000 6382 5363 3501 0536 04c0
        0x0120:  a801 fe33 0400 0151 8001 04ff ffff 000f
        0x0130:  036c 616e 0604 c0a8 01fe 0304 c0a8 01fe
        0x0140:  ff

This is the one that comes from the iPhone:

22:01:34.557171 00:21:e9:23:0b:53 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
        0x0000:  ffff ffff ffff 0021 e923 0b53 0800 4500
        0x0010:  0240 0041 4000 2e11 4a6d 0000 0000 ffff
        0x0020:  ffff 0043 0044 022c 4c7a 0201 0600 a51d
        0x0030:  0725 0000 0000 0000 0000 0000 0000 0000
        0x0040:  0000 0000 0000 0016 6f7c 258a 0000 0000
        0x0050:  0000 0000 0000 0000 0000 0000 0000 0000
        0x0060:  0000 0000 0000 0000 0000 0000 0000 0000
        0x0070:  0000 0000 0000 0000 0000 0000 0000 0000
        0x0080:  0000 0000 0000 0000 0000 0000 0000 0000
        0x0090:  0000 0000 0000 0000 0000 0000 0000 0000
        0x00a0:  0000 0000 0000 0000 0000 0000 0000 0000
        0x00b0:  0000 0000 0000 0000 0000 0000 0000 0000
        0x00c0:  0000 0000 0000 0000 0000 0000 0000 0000
        0x00d0:  0000 0000 0000 0000 0000 0000 0000 0000
        0x00e0:  0000 0000 0000 0000 0000 0000 0000 0000
        0x00f0:  0000 0000 0000 0000 0000 0000 0000 0000
        0x0100:  0000 0000 0000 0000 0000 0000 0000 0000
        0x0110:  0000 0000 0000 6382 5363 3501 0636 04a9
        0x0120:  fe6f 6fff 0000 0000 0000 0000 0000 0000
        0x0130:  0000 0000 0000 0000 0000 0000 0000 0000
        0x0140:  0000 0000 0000 0000 0000 0000 0000 0000
        0x0150:  0000 0000 0000 0000 0000 0000 0000 0000
        0x0160:  0000 0000 0000 0000 0000 0000 0000 0000
        0x0170:  0000 0000 0000 0000 0000 0000 0000 0000
        0x0180:  0000 0000 0000 0000 0000 0000 0000 0000
        0x0190:  0000 0000 0000 0000 0000 0000 0000 0000
        0x01a0:  0000 0000 0000 0000 0000 0000 0000 0000
        0x01b0:  0000 0000 0000 0000 0000 0000 0000 0000
        0x01c0:  0000 0000 0000 0000 0000 0000 0000 0000
        0x01d0:  0000 0000 0000 0000 0000 0000 0000 0000
        0x01e0:  0000 0000 0000 0000 0000 0000 0000 0000
        0x01f0:  0000 0000 0000 0000 0000 0000 0000 0000
        0x0200:  0000 0000 0000 0000 0000 0000 0000 0000
        0x0210:  0000 0000 0000 0000 0000 0000 0000 0000
        0x0220:  0000 0000 0000 0000 0000 0000 0000 0000
        0x0230:  0000 0000 0000 0000 0000 0000 0000 0000
        0x0240:  0000 0000 0000 0000 0000 0000 0000

Is this some sort of peer-to-peer ip address agreement that kicks in when there’s no dhcp server?

Answers on a postcard, or preferably, in the box below.

Blocking Rogue DHCP Servers on a D-Link DES-3250TG

February 15th, 2009

As I mentioned in a prior post, we’ve had issues with rogue DHCP servers in the past. The naive approach to dealing with them is to detect them, find out what switch port they’re on and go chase them down. Depending on the frequency of the problem and the size of the network, that can be no fun at all. It’s a cliché, but prevention is most certainly better than cure.

DHCP clients issue requests usually addressed from UDP port 68 and to UDP port 67. DHCP servers usually reply from udp port 67 to UDP port 68. So, if you can configure your switches to drop packets coming from udp port 67 on all ports except those which lead back to your own dhcp servers, you’re on the pig’s back.

Sadly, many cheap and cheerful switches are not capable of this. If you’re setting up a large network where you suspect you might have users plugging in wifi routers, this feature should be on the switches you buy. For those not on a tight budget, many Cisco switches (I hear) have a feature called dhcp snooping which allow you to trust certain ports to send dhcp replies.

For the rest of us, you need to look up your manual. It seemed like you couldn’t do this on the v3 firmware of a DES-3250TG. Their access_profile feature allowed filtering of ip packets based on ip port, etc., but it seemed to be applied to all switch ports (which would break dhcp entirely). However, an upgrade to the v4 firmware allowed us to apply the filter to a range of ports. Some other D-Link switches (apparently those with a v5 firmware) seem to have an explicit dhcp filtering feature, but the general filtering does it just fine.

On each switch which faces the users, we added this two line config:


create access_profile ip udp src_port_mask 0xFFFF port 1-48 profile_id 1
config access_profile profile_id 1 add access_id 1 ip udp src_port 67 deny

The first line says we want to profile udp packets on switch ports 1-48 and that we’ll want to examine the src_port (the src_port_mask is important to tell it this). The second line configures an access rule on this profile to deny all udp port 67 packets. The uplinks are on port 49-50 so dhcp replies can still come from there, allowing our dhcp server to operate as usual.

That’s it pretty much.

A simple rogue dhcp detector

February 15th, 2009

At work, we run several relatively big networks, one of which is the college residence. This network has various problems at times, most of which stem from the users themselves. The classic, is rogue dhcp servers. This can arise on any network of course.

Where you have hundreds of students in apartments, many of them decide they’d like wireless and get themselves a wireless router. On a typical such router, there are 5 ports, one WAN port and 4 LAN ports. By default on most, the WAN port will operate as a DHCP client and the LAN port will run a DHCP server for its local computers. If they plug the WAN port in all will be well (albeit with NAT). If they plug any of the four LAN ports in, we have a rogue dhcp server.

Imagining the students’ behaviour is entirely random (there is considerable anecdotal evidence to support this), you get a rogue DHCP server four times out of five. It usually doesn’t actually work, but they seem to persist with this nonetheless. Suddenly lots of other users are seeing “the internet is down”, as they have a wrong ip address.

The first thing you need is to be able to detect this behaviour. The second thing you need is to be able to stop it. Some options for detection follow. Prevention I’ll post later.

RogueDetect is quite sophisticated at this, it makes decoy dhcp requests and checks who answers. I had a little trouble with its dependencies on an awkward linux machine, so I ended up scripting a simpler solution which just needs a shell, mail and tcpdump.

DHCP responses are usually broadcast messages, so everyone on the subnet sees them. You can simply listen anywhere on the subnet for dhcp responses which aren’t from your own dhcp servers.

#!/bin/sh

DEVICE=eth0
TCPDUMP=tcpdump
PROGNAME="rogue_dhcp_detector.sh"
SLEEPTIME=14400
ALLOWED_DHCP_SERVERS="172.18.0.2 or 172.18.0.4"
EMAIL="root"

# load up a config
if [ -e "$1" ]
then
        source $1
else
        echo "Config file '$1' not found"
        exit
fi

MESSAGE1="$PROGNAME running on `hostname` ($DEVICE) has detected what looks like a\nrogue DHCP server:"
MESSAGE2="Sorry to be the bearer of bad news.  I'll sleep now for $SLEEPTIME seconds and start detecting again\n\n-- \n$PROGNAME\n"
TCPDUMP_COMMAND="$TCPDUMP -en -c 1 -i $DEVICE (udp src port 67) and not (src host $ALLOWED_DHCP_SERVERS)"

while( true )
do
        COMMAND_OUTPUT=`$TCPDUMP_COMMAND`
        printf "$MESSAGE1\n\n$COMMAND_OUTPUT\n\n$MESSAGE2\n" | mail -s "Rogue DHCP Server Detected!!!" $EMAIL
        sleep $SLEEPTIME
done

You can run this script and pass it a config file like this one:

DEVICE=eth1
ALLOWED_DHCP_SERVERS="10.20.0.1 or 10.20.0.2"
EMAIL="somebody@somedomain.tld"

and the script will listen for dhcp responses from unauthorized hosts using tcpdump on eth1. When it spots one, it sends you a polite email, then goes to sleep for four (configurable) hours before starting detection again — you don’t want a message every time it sees a bad response, believe me. The email includes the tcpdump output, which includes the mac address of the rogue server which should help to track it down (have a look at the tables of mac addresses on your switches).