Christian Reis lives here
|
I know you know. But well, just in case you forgot..
|
Since 2004, I've been actively involved in
development of Launchpad, and in
2005 I became application manager for the project, together with Steve Alexander. These days
I lead a team of over 30 people at Canonical working on building a
platform for the future of open source development and
collaboration.
In 2003, I somehow managed an MSc degree from USP São Carlos, where I
wrangled out my dissertation on defining a Process Model for Free
Software Projects. My MSc project is described in two long documents (in portuguese). I
graduated in Computer Engineering from UFSCar in 1997, though most of that
time evaporated into swimming pools and bike trails.
A couple of years ago (just as I had decided I wanted nothing to do
with computers) I discovered Free Software and Unix, and I've been
working on both ever since then. I've contributed to dozens of
free software projects, and I am currently an active developer for
Bugzilla, PyGTK, ZODB, Kiwi and IndexedCatalog.
I've worked with Web development (who hasn't?) and Usability,
additionally, in the past years.
I am a partner at Async Open
Source, a company that provides development and consulting
services focused on on Free Software. I helped found Async in early
1999.
When I'm not pretending to be a software engineering manager I
engage in outdoor sports, travelling, language and vain philosophy. I've raced mountain bikes
for a couple of years now, and from 1999 to 2003 I raced a number of
national-level adventure races, including the multi-day EMA 2000 and
2001.
Getting in touch with me
| Online: |
Homepage (~kiko)
<kiko at async.com.br> |
|---|
| Phones: |
+55 16 3376 0125 work
+55 16 9112 6430 mobile |
|---|
| Home:
(map)
|
Rua Rui Barbosa 1977
Sao Carlos, SP
Brazil 13560-330
|
|---|
|
|
What he's been up to
|
25.08.2010
|
unclutter hurts
|
|
|
|
06.08.2010
|
A Logitech DiNovo Edge dongle's embedded and HCI modes
|
- I have a DiNovo edge and think it is absolutely fantastic, except when
it stopped working on my way to my Lucid upgrade. What happened? The
problem is that to Windows users the dongle normally works in embedded
mode, meaning it appears to the system as a regular USB keyboard and
mouse. Many Windows users hate that behaviour, and would rather the
dongle behaved as a regular bluetooth adapter. However, Linux users have
the flexibility of choosing in which mode they want the adapter to work,
and the magic of selecting them is done through hid2hci, which is run by
udev when the device is plugged in. Now it used to be that you could
enable or disable hid2hci by fumbling in /etc/default/bluetooth; with
the inexorable move to udev, however, on Lucid this behaviour is now
hardcoded in udev rules and by default hid2hci is run, which means the
keyboard only works if you perform a bluetooth pairing exercise. And
since it's a keyboard, that exercise can prove pretty challenging!
- The command which is run when the BT dongle is plugged in is pretty simple:
/lib/udev/hid2hci --method=logitech-hid
--devpath=/devices/pci0000:00/0000:00:1d.2/usb4/4-2/4-2.3/4-2.3:1.0/usb/hiddev0
Note the path points to the hiddev0 directory for the device in question. Note
also that it seems you can't revert back to embedded mode once the command is run, for some reason.
- People that are running into this problem on Lucid should know that it's
possible to have the dongle still work in embedded mode as long as the hid2hci
call in /lib/udev/70-hid2hci.rules for the keyboard isn't run. When embedded
mode is active, an lsusb run will list 3 devices like this:
Bus 004 Device 017: ID 046d:c714 Logitech, Inc.
Bus 004 Device 016: ID 046d:c713 Logitech, Inc.
Bus 004 Device 015: ID 046d:0b04 Logitech, Inc.
When you issue the hid2hci run, a 4th device appears, representing the
mini-receiver in HCI mode:
Bus 004 Device 024: ID 046d:c709 Logitech, Inc. BT Mini-Receiver (HCI mode)
Bus 004 Device 023: ID 046d:c714 Logitech, Inc.
Bus 004 Device 022: ID 046d:c713 Logitech, Inc.
Bus 004 Device 021: ID 046d:0b04 Logitech, Inc.
In this mode, you'll need to connect through bluetooth. Note that I haven't
found that works reliably on my powerpc mac mini, though it seemed to on
a little netbook. The simple workaround seems to be to avoid bluetooth
mode by commenting that udev rule out, and keep an eye out for changes
in that area when you upgrade.
- Embedded mode is kinda fascinating; from the OSs perspective it's just
a keyboard and mouse that are plugged into a hub; there's no bluetooth
anything. When you plug the dongle in, you get the usual dmesg spew of
USB information. Here's what dmesg is actually telling you:
- A USB hub is found; 3 ports detected (of which one is the hub,
device 046d:0b04)
- A keyboard (046d:c713) is found, though the device string
identifies it as a "Logitech Logitech BT Mini-Receiver"
- A mouse (046d:0b04) is found, with the same device string as
above.
- You can play with the dongle a bit when it is in HCI mode, by the way, with
hcitool; here's some info on Johan's macbook, and on my Nokia e51.
kiko@gasolinux:/lib/udev/rules.d$ hcitool dev
Devices:
hci0 00:07:61:E3:38:E0
kiko@gasolinux:/lib/udev/rules.d$ hcitool inq
Inquiring ...
00:23:12:39:44:1F clock offset: 0x1b9d class: 0x38010c
00:22:FC:4D:65:47 clock offset: 0x618c class: 0x5a020c
kiko@gasolinux:/lib/udev/rules.d$ sudo hcitool info 00:23:12:39:44:1F
Requesting information ...
BD Address: 00:23:12:39:44:1F
Device Name: Johan Dahlin’s MacBook Pro
LMP Version: 2.1 (0x4) LMP Subversion: 0x21b4
Manufacturer: Broadcom Corporation (15)
[...]
kiko@gasolinux:/lib/udev/rules.d$ sudo hcitool info 00:22:FC:4D:65:47
Requesting information ...
BD Address: 00:22:FC:4D:65:47
Device Name: Kiko o substituto
LMP Version: 2.0 (0x3) LMP Subversion: 0x6cc
Manufacturer: Cambridge Silicon Radio (10)
If you're in embedded mode, that won't work of course:
kiko@gasolinux:~$ hcitool dev
Devices:
- References to this problem include
[bugs.debian.org]
[www.mail-archive.com]
[www.mail-archive.com]
[bugs.edge.launchpad.net]
[bugs.edge.launchpad.net]
|
|
05.08.2010
|
RAID1 Lucid desktops
|
|
|
|
02.06.2010
|
iwlagn disconnects.. then connects.. then disconnects.. then
|
- For some reason, since I've upgraded to Karmic and through Lucid, my
x61 and Mariana's x61s have the same problem: they keep dropping their
connection to our DD-WRT WRT54G AP, with the same pattern:
[35502.041062] No probe response from AP 00:40:10:10:00:03 after 500ms, disconnecting.
[35503.958234] wlan0: direct probe to AP 00:40:10:10:00:03 (try 1)
[35503.968728] wlan0: direct probe responded
[35503.968738] wlan0: authenticate with AP 00:40:10:10:00:03 (try 1)
[35503.970691] wlan0: authenticated
[35503.970731] wlan0: associate with AP 00:40:10:10:00:03 (try 1)
[35503.973310] wlan0: RX AssocResp from 00:40:10:10:00:03 (capab=0x431 status=0 aid=1)
[35503.973318] wlan0: associated
[35622.060151] No probe response from AP 00:40:10:10:00:03 after 500ms, disconnecting.
[35623.973605] wlan0: direct probe to AP 00:40:10:10:00:03 (try 1)
[35623.976226] wlan0: direct probe responded
[35623.976234] wlan0: authenticate with AP 00:40:10:10:00:03 (try 1)
[35623.979137] wlan0: authenticated
[35623.979177] wlan0: associate with AP 00:40:10:10:00:03 (try 1)
[35623.981630] wlan0: RX AssocResp from 00:40:10:10:00:03 (capab=0x431 status=0 aid=1)
[35623.981633] wlan0: associated ad infinitum, every 120s. Seems
like the only people that have this so far are at
[permalink.gmane.org] and
[ubuntuforums.org] and
[bugs.donarmstrong.com] but
neither of them have 4965AGNs like our Thinkpads do.
- I've found a bug at
[bugzilla.intellinuxwireless.org] but it's not
really the same issue I think; at any rate there are a number of patches
attached to comment 113 there, so it might be worth looking through. And
the guy at
[bugs.launchpad.net]
seems to have the same problem (though he's posting to a bug which
doesn't describe the same symptoms) so let's try disabling ipv6 (though
it makes no sense to me) since it is my only lead... no, of course that
doesn't work. Oh well, let's keep looking.
- So it /could/ be the issue at
[bugs.launchpad.net]
which is caused by network-manager rescanning every 2 minutes and the
driver hanging while the rescan happens. But one thing that strikes me
is that it only happens with the access point we use at home -- in the
office it works just fine.
- I now think the reason this happens is because there is some oddness
with the WRT54gv6 that I have at home. It's configured in repeater
bridge mode, and that's where we have problems. I've noticed that it is
often out of memory and has difficulty answering to web requests; it
seems this is more than just a wifi adapter driver issue. I've since
replaced that AP with a WRT160NL and it is working much more reliably; I
also no longer get the driver hangs and error messages I was getting
above. It seems to be a weird interaction between the AP and the
wireless card, but it's not entirely clear what it is.
|
|
01.06.2010
|
Reverse Path Filtering
|
- We have a multi-homed server that chooses where to send traffic
depending on its content; web traffic goes through one network, VoIP
over another, and so on. One thing that has always left me surprised is
the fact that we log so many martian packets on it with rp_filter
enabled -- if reverse path filtering is desireable then why can't I use
it here.
- Turns out that I just don't understand RPF well enough. I used to
think it was just going to drop packets that are from non-routeable
RFC-1918 addresses and other obviously broken sources, but in fact it is
more than that; the router when receiving a packet does a route check on
the source address. It then will only forward the packet to another
interface /if/ the packet was received from the interface it would
return it to according to its routing tables. So if I receive a packet
on interface A from a source address S destined somewhere non-local,
that packet will only be allowed through if a packet destined to address
S would be routed to interface A.
- This works okay for "normal" routers, since there is only one path
which packets should go through. but on our traffic-balancing setup it
ends up being too simplistic. For instance, we have a default route set
up to our primary network interface, and if /any/ packet arrives on our
secondary interface, it gets dropped: the default route is on the
primary interface, and since we use firewall marking to determine the
route, the reverse path filtering check never realizes the routing table
would have decided differently. I found the answer at
[www.mail-archive.com] pretty
interesting in confirming that, and there's even a patch that fixes this
up at [bugzilla.kernel.org] but it was never
applied as there was a design concern; the feeling was that netfilter
could handle its part of rp_filter checking. If you care about how it's
implemented, check out fib_validate_source() in net/ipv4/fib_frontend.c
but it's not very easy reading unless you know that corner of the kernel
fairly well.
- Incidentally, really good commentary on forging of source addresses
and what routers should do about it can be found here:
[serverfault.com]
|
|
30.05.2010
|
DD-WRT Wireless Bridging
|
- Spent about 3h today trying to get my wifi bridge operational again.
Here are some of the stumbling blocks I ran into in the hope they are
useful to anybody using DD-WRT on a pair of WRT54g boxes from Linksys:
- I'm using DD-WRT v24-sp2 13064 on both main AP and repeater, but
the repeater is using the micro flavor, since it's a v6 box.
- I wasted about 2h on the fact that the repeater would not join the
main AP's network, and would never show up as a client in the
Wireless Nodes listing in Status_Wireless. After trying pretty
much every single configuration known to man, Johan convinced me
to do a hard reset of the main AP, and guess what? It worked!
@#!@*#*@! I would never have guessed this, because at least in
theory the main AP has nothing to do with the repeater AP, but
something was cached in the configuration that survived across
reboots. So if you find yourself stuck where the repeater just
accumulates TX errors and never finds the main AP, try doing a
hard 30/30/30 reset of the main AP. Even if the documentation
misleads you into thinking otherwise.
- WPA Personal encryption does work, but if you set the
advanced configuration option "Authentication: shared key" it
stops working, and the password MUST be the same in the main and
virtual interfaces. In WEP mode, which is what I was using before,
the passwords didn't have to match, which I really liked. There
might be something in the hardware which limits this -- I don't
understand enough about how wireless encryption and DD-WRT's
wireless bridging mode is implemented.
- I have a pair of higher gain omnidirectional antennas but I'm not
convinced they work very well, nor do I understand how or whether
DD-WRT's auto mode for the antennas works. I'm going to graph
packet loss between houses now and do one change per two evenings
over this week to figure out what can be better.
- There are many advanced config settings to tweak, but for now I'm
starting with the same configuration on both, using a G-only
network.
|
(Read older diary entries)
|