i should be working (but i'm fixing my computer).

now back to our regularly scheduled whining.

Imagine my surprise when I fired up the laptop to tether to my android -- and it didn't work.  So, I looked around the room at all the people happily browsing the net on their ipads.  Yes, they are spending $$$ I don't have.  But, they are not staring at a blank screen, either.  And then my Blackberry Tour commenced its new process of endlessly displaying the "wait" icon which -- as far as I can figure out -- requires the battery to be pulled and [another] 15 minute reboot to be resolved.  Which fairly well renders the thing useless, except as a doorstop, paperweight or the like.

...

So, I found myself in a race of Android -v- Blackberry to see which of my useless tech toys would become productive first.

There is probably a simple solution to the Blackberry problem.  Some RIM engineer is probably reading this saying to himself, "stupid moron, just do 'X' and it will solve the problem."

Unfortunately, not only do I NOT know whatever it is the engineer knows, I also have no resource by which to find out this information. (Efforts to obtain tech support always end in referral to the OTHER vendor.  Eg., RIM says contact Verizon, Verizon says it's a RIM issue.  And I say, "it's a waste of time."  Ultimately, cheaper to replace the phone.  Not with a Blackberry.)   I've removed all of the apps that I don't actually need, including games that came with the original install and Blackberry Messenger which I have never used.  I've turned Google Sync to manual.  What else can I do???

Well, I had some theory that maybe it was a full "cache" -- though that suggests the OS does not manage the cache well.  This evening I did find some cache settings and cleared them all.  Too soon to say whether the problem is solved -- I thought it was solved when I removed the apps, and that did not turn out so well.

In any event, clearing the caches was my dinner project while I was over at Karl Strauss' having an Oktoberfest beverage and some nachos.

And then later I turned my attention to wasting the REST of my evening trying to figure out what's what with the Android/Acer.

As previously mentioned, I can't get NetworkManager to work on the Acer.  I think I have a garbled up install that needs to be rescued by a clean install, which I don't much feel like doing.  And don't have access to an external drive for the CD at the moment anyway.

And, who knows, maybe a clean install would solve the Easytether problem as well.  In addition (further aggravations), when I first log into my account, I get to give my password to the KDE Wallet about four times and for some reason I don't know, my encrypted drive demands a password -- even though I already gave it the password in order to boot the computer which has always worked fine in the past.

There are just things with software, especially scrambled software, that defy logical analysis.

But, I initially got sidetracked, as I was wondering why I do not have the 3.0 kernel on this computer, seeing as I am running Tumbleweed, so it should have been installed.

So I installed it from YAST, but [fortunately] it is now added as an alternative to 2.6.37.  My theory is that because I have a VirtualBox kernel module compiled for the old kernel, Tumbleweed elects not to update the kernel to 3.0.

In any event, I then had four kernels, actually -- "default 3.0", "desktop 3.0", "default 2.6.37" and "desktop 2.6.37".  (Hope I am getting that version number correct, I never can remember what it is without looking at it.)  Then with some irony, "desktop 3.0" is missing some modules and won't run correctly; whereas "default 2.6.37" won't run, but "desktop 2.6.37" will.  Don't ask me, I just work here.

In any event, I noticed during the boot sequence that udev was complaining about the easytether.rule.  There is an invalid ENV attribute.  What?

I did not change anything, it's the same rule file that was working fine.  Just to double-check, I removed and reinstalled easytether.

No luck.

Then I spent hours trying to set up the Android SDK system so that I could use - - well, I forget, some other tethering system.  I never actually got that far.  The important step was setting up the rule files.

Now, different websites told me to name them with different numbers: 70? 50? 91?  How do I know which to use or whether it is an issue?  I began to suspect I could put both rules in the same android file, but I haven't tested that yet.  I kept making typos and a lot of re-booting to see if  udev could recognize the Huawei Ascend modem or not.

And then there was the, "that's not a bug, it's a feature" portion of the evening.  Since ostensibly I was trying to get a device response that gave me a serial number.  Whereas, as it turns out, the Huawei does not report a serial number.  I kept getting ???????? device when I ran "adb devices" (a program from the Android SDK).  So, how are you going to identify the device you want to access if instead of a serial number you get ?????????.  Which may be the point of no serial number -- makes the typical rooting of the Huawei a bit confusing.

After awhile (and after troubleshooting the stupid typos I was putting into my "rules" files), it occurred to me that maybe I was actually getting a connection and did not realize it.  "adb devices" went from reporting ?????????? no permissions to ????????? device.

At this point, it occurred to me to test something that had not, um, occurred to me earlier.  In other words, Easytether had been working just fine on the Huawei, without any serial number, so would it work now?

So, I ran "easytether connect" -- and the response was to ask whether the adb server was running because easytether could not access the device.

Actually, that sounded a bit promising.  So, I ran adb kill-server and tried again -- and easytether reported it was connecting.  Hmmm.  So I disconnected my ethernet cable and went web surfing.  Seemed to work.  So, I rebooted to see if I could repeat "success" or not.  After all, the goal here is to have this work with minimum of "start up time" under real work conditions.

Worked again.

.....

Unfortunately, I write up these notes after the fact and by then I have forgotten half of what I did.   But, I will mention some useful tools:

lsusb: reports the usb devices.

usb-devices: reports extended usb-device information.  Where one can see that there is no serial no. reported by the Huawei, for instance.  It's also possible to see whether the rules have enacted or not.  For instance, when the Huawei is not set for browsing (I think) there is only one "driver" reported -- usb-storage.  Whereas in modem mode, there is a second driver reported - usbfs.  This is apparently accomplished by the "SYSFS" entry for udev rules -- and here is more bad news, the linux kernel reports that SYSFS is being deprecated, so another disaster awaits in the future!

udevadm control --reload-rules: useful for getting the newly revised typos into udev.

The android has to be in usb debug mode for modem/tethering communication.

My /etc/udev/rules.d/70-android.rules contains the following:

SUBSYSTEM=="usb", SYSFS{idVendor}=="12d1", MODE="0666"

My /etc/udev/rules.d/50-android.rules contains the following:

SUBSYSTEMS=="usb",ATTRS{idVendor}=="12d1", MODE="0666"

Considering I am now an expert (or at least journeyman) at rules typos, I can stress that where you see TWO equal signs, it takes TWO.  Also, notice that one says SUBSYSTEM and one says SUBSYSTEMS.   The UDEV syntax gives these different meanings, since when the "S" is added to the end, it searches upwards to the parent(s) and not when the "S" is not added.  Some websites will have you add Product id, user, group, whatever -- but the extra entries don't seem necessary as these are the ones that worked for me.  Udev needs rules to set up the connection, and these provide them.  (Apparently circumventing the "Easytether" rule, or at least providing an optional setup, I don't know.) (And by the way, "easytether.rule sets up in /lib/udev/rules.d, not /etc/udev/rules.d. )

So, to summarize, udev sets up the usb connection to the Android.  The Android has to be in "usb debug" mode.  And then further, you need some further communication software or proxying.  In my instance (and until it quits working) I'm running "easytether lite" on the Android and also on the linux netbook.  And lastly, I note that there is no rpm for OpenSUSE, I used the Fedora one.

easytether is run from a command line, so that you can type <ctrl> C to stop the connection when you are done.  In an earlier article I explained how it's possible to create Kdialog system for this, which is a bit more elegant than leaving an open konsole.  And, in that system I was using NetworkManager and KNetworkManager -- but as noted here, I can't get those working at the moment.  So, instead I'm using Wicd for my ethernet connection and wireless connection.  But, as far as I can tell, these will not recognize the easythether connection the way knetworkmanager does.

So ... to complete the connection (while "easytether connect" is running in a first konsole), it's necessary to start a second konsole, go to SU and run "dhclient easytether0".  (That konsole can then be closed.) (Ubuntu users may wish to run something like "sudo dhclient easytethero") (It's also possible to set up a desktop launcher for this, but in any event, it will have to run as root and require the root password.

Are we happy yet? (I will be, the next time I venture out and this WORKS.) (I hope.)