USB networking: C860 <-> RH9

[raybert]

Hi,

I\'ve been trying to get my TCP/IP over USB working from my C860 to Red Hat 9. I\'ve read many HOWTO\'s, etc., but I\'m confused about how to proceed from here.

Many of the HOWTO\'s talk about patching the kernel but I\'m not sure that really applies to RH9. RH9 comes configured for the Zaurus (5500 and A300, at least) right out of the box. All I had to do to get my 5500 working was to create an ifcfg-usb0 file and blacklist CDCEther.

I\'ve briefly looked at the source code for usbnet.c and I can see where it has specific device configs for the 5500 and the A300. I also saw a comment indicating that the A300 entry should work for the 5600 and the C700 series. This seems to imply that there\'s some way to configure RH9 to use these device configs for the C860. But I haven\'t been able to discover how to do this. Is there some way to externally annotate this table or map a new device to these entries (i.e. such as is possible with pcmcia hotplugging)?

It looks like I could easily modify usbnet.c myself to support the C860 just by duplicating the A300 tables and renaming them (and changing the device ID). But I\'d rather not do this if I don\'t have to. Is there a way?

Thanks in advance for your help!

~ray

[mussi]

At least with the 5500, RH9 works almost right out of the box.

You can also change what stuff is detected by modifying the usb.handmap file, as you have to do on Mandrake 9.2.

Do a dmesg when you plug in your Z in networking mode (not USB mass storage), and then amend the usb.handmap file in /etc/hotplug with the line

usbnet 0x0003 0x04dd 0x8004  0x0000 0x0000 0x00 0x00 0x00 0x02 0x0a 0x00 0x00003800

while replacing the 0x04dd 0x8004 with what you see in dmesg when you plug in the Z.

Of course, you still need the usbnet script to activate networking, but I suspect the one working for a 5500 will also do the job on a C860.

[raybert]

mussi,

Thanks very much the response.  That was a big step in the right direction, but it didn\'t quite get me all the way there.  Changing usb.handmap got the kernel setting up usbnet for the c860, but it\'s still wasn\'t setting up a network interface (usb0?).

I finally decided to byte the bullet and recompile usbnet.c.  It took a while to get the modules built but it finally worked (almost; I still got a bunch of errors on /usr/src/linux-2.4.20-8/fs/ext3/balloc.c; but by this time the driver modules, including usbnet, had already built).  I had to force load usbnet because it was compiled with \"custom\" added to the version number (I\'ll have to fix this later).  Once I got it loaded though, the c860 finally worked!  

So now I\'ve just got to recompile usbnet again with the same version as my kernel (later when I have more time).  Now that I\'ve got the build environment working, is it possible to recompile just a single module?  I tried (cd drivers/usb; make usbnet.o) but it failed (no Rules.make).

The last thing I\'d like to solve is this: I want to still be able to connect my 5500 occasionally (maybe simultaneously).  Of course, they both have to have different IP addresses.  usbnet seems to want to assign the first one I connect to usb0.  Is there a way to force usbnet to always assign one as usb0 and the other as usb1??

Thanks for the help again,

~ray

[ran]

Now that I\'ve got the build environment working, is it possible to recompile just a single module?

Maybe for the truly l33t kernelhackers,  but not for us ordinary mortals.  I tried doing the same thing for some other USB modules once,  tracing through the maze of twisty little makefiles.  Fortunately,  a passer-by noticed my head starting to bulge,  and pulled me away from the screen before it exploded.

Is there a way to force usbnet to always assign one as usb0 and the other as usb1??

Alas,  no.  This is a problem that hits both USB devices,  and network interfaces in general.  It can be a real  PITA when you\'ve got a machine that can handle,  e.g.,  several different kinds of PPP interfaces (IrDA + Bluetooth + ISP dialup is not uncommon if you\'re tinkering with PDAs).  Or have both a USB Zip drive and a USB flash card reader.  There are things like network scripts and mount point permissions that expect the interface and device numbering to be stable,  but some drivers assign them dynamically.  I dunno whether this has been fixed in the 2.6 kernel (which I\'ve read got some pretty major restructuring in USB support),  but it\'s a difficult enough problem that it wouldn\'t surprise me to find out that it hasn\'t.

Ran

[raybert]

Now that I\'ve got the build environment working, is it possible to recompile just a single module?

Maybe for the truly l33t kernelhackers,  but not for us ordinary mortals.  I tried doing the same thing for some other USB modules once,  tracing through the maze of twisty little makefiles.  Fortunately,  a passer-by noticed my head starting to bulge,  and pulled me away from the screen before it exploded.

Well, I\'m glad they caught you in time.  Your exploding head would have made quite a mess on your Z.  

There must be a way to do this.  I can\'t imagine doing the edit/compile/test cycle with the full build script.  Tres painful.

In any case, there IS at least one way to do it....

I guess you would call this the brute force method: run make modules, wait for the first gcc command line to pop-up, then hit ^c.  Copy the command line, move to your module\'s directory (drivers/usb in my case), paste the command line, then edit it for your module.  Works like a charm.

Is there a way to force usbnet to always assign one as usb0 and the other as usb1??

Alas,  no.  This is a problem that hits both USB devices,  and network interfaces in general.  It can be a real  PITA when you\'ve got a machine that can handle,  e.g.,  several different kinds of PPP interfaces (IrDA + Bluetooth + ISP dialup is not uncommon if you\'re tinkering with PDAs).  Or have both a USB Zip drive and a USB flash card reader.  There are things like network scripts and mount point permissions that expect the interface and device numbering to be stable,  but some drivers assign them dynamically.  I dunno whether this has been fixed in the 2.6 kernel (which I\'ve read got some pretty major restructuring in USB support),  but it\'s a difficult enough problem that it wouldn\'t surprise me to find out that it hasn\'t.

Ran

That\'s a drag.  Hey, it could be worst though, I guess: it could work like Windoze and require you to re-install the drivers just because you plugged the device into a different USB port!

I came up with a script to handle the USB storage devices on RH9.  It\'s not totally automated (although, I\'d like to achieve that eventually), but it makes it a bit easier.  Just this week, I found a way to iterate all of the /dev/sd** devices that have something connected to them AND determine which ones are mounted already.  So, when I plug a USB MSD in, I can use this tool to figure out which sd device it was mapped to.  I can then use my script to mount it and create a link with a friendly name in /.  For example, I can mount my CF reader like this \"usbmnt cf sda1\", assuming it\'s in /dev/sda1, and I can access it with \"/cf\".  When I\'m done with it, I can umount it with \"usbmnt -u cf\", and it cleans everything up including the /cf link.  The suckiest part of it is that I have to create all of the possible sd mount points ahead of time and create entries in fstab for each so that non-root users can mount them.

I envision an app that detects when a new USB MSD is plugged in, identifies the device, and sets this stuff up automatically using a friendly name that I\'ve given it in the past, OR prompts me for the info when a new device is entered (and remembers it for future reference).  I\'m pretty close to being able to do that now; I really just need to find a way to detect when a device is inserted.  I think the cardmon applet on the Z does something very similar -- I\'ve been meaning to get a look at its source code (although I have to find it first -- anyone know if the source for Qtopia 1.5 is available somewhere?).

Unfortunately, there doesn\'t seem to be any hope of doing something similar for network interfaces.

~ray