bkil vs. programming

I collect none of your personal information other than the comments that you type in response to a post. You retain your copyright to your comments, but I reserve the right to remove any or all of your comments without reason. I also reserve the right to reply. :) Google is hosting this blog for me via the Blogger infrastructure. Note that I am given access to limited statistics from some of the basic data, like the web browser you use and such. Please refer to Google's privacy policy for more information on the kind of information they gather. http://www.google.com/intl/en/policies/privacy/

Installing a Huawei E352 HSPA+ dongle took ages under Windows. I had to abort it halfway through because I was running out of time. In retrospective, it was probably caused by a conflict with the previous modem's connection dashboard. I was shocked when I wanted to resume next time. Some time after inserting the device, the system asked for a .sys file from a driver disk. Neither modem worked anymore. As usual for this kind of dongle, no vendor download is available as the device itself contains all drivers on a virtual CD-ROM. However, that is only accessible before it's  switched to modem mode  by the parts already installed. Chicken and egg problem. Puppy Linux to the rescue! Thankfully, I had it on my USB flash along with DSL and SliTaz . The system loaded to RAM rapidly. I copied over the drivers from the modem to another USB flash. As a plaything, I enjoyed the command line and the responsivity, also browsing the web a bit over 3G. After rebooting to Windows, reinstal

I've just discovered that newer devices and networks probably don't need my latency hack anymore described in  making your 3G cellular mobile Internet 10x faster for free . According to this overview , the following features introduced for Evolved HSPA (or HSPA+) in 3GPP Release 7 could theoretically fix the issues I've uncovered: Continuous packet connectivity :   With much of the data traffic being in the form of IP data, continuous connectivity is an increasing requirement. To achieve this the HS-DSCH and E0DCH channels have been reconfigured to enable them to be rapidly able to transmit user data. Enhanced CELL_FACH operation:   This enhanced operation is required to assist in maintaining the always-on packet connectivity during periods when there have been little or no activity.

The described method should work on even simple desktop environments. If I don't already have an xorg.conf for editing, I first generate it by  Xorg -config xorg.conf.new . To make the screen easier to read, you need to  scale DPI by setting Displaysize in the respective "Monitor" section of xorg.conf proportionally larger than it physically is. A native driver outputs the original image size in Xorg.0.log. You need to type in the real size values times the magnification factor. So if the real active area of your display is 200mm wide and 100mm high and want 1.5x larger text, you insert  Option DisplaySize 300 150 . Unfortunately, not all applications honor this setting. You need to increase the default zoom by hand in  Chromium . You need to update the hexadecimal "LogPixels" dpi setting in ~/.wine/system.reg for  Wine . Otherwise if you are using Gnome, you could also try to increase the text scaling factor with the Gnome Tweak Tool, Universal Access or

It worked easily with the VESA driver, however the legacy mode tables don't have any of today's fancy aspect ratios. OpenChrome, the default driver, just gave a blank screen. Reviewing Xorg.log revealed an abort by signal 11, segmentation fault (segfault). Let me share the process of fixing it. I went on to generate a new xorg.conf for editing by Xorg -config xorg.conf.new . I then proceeded to add as much fail-safe options as possible from the driver documentation : Section "Device" Option "ModeSwitchMethod" "legacy" # or blank & segfault Option "SWCursor" "true" # unsure Option "EnableAGPDMA" "True" # unsure Option "NoAccel" # or starts to lag after some time Identifier "IGP" Driver "openchrome" BusID "PCI:1:0:0" EndSection Section "Module" # unsure Disable &

Works perfectly with two smarter routers using default settings, but does the well known Android Ice Cream Sandwich dance on a legacy one. It sometimes connects on first attempt, other times after a dozen loops, in the rest of the cases not at all. A loop consists of saved, connecting, authenticating, obtaining IP and scanning. The signal strength goes very low in the authenticating and obtaining IP phases. It spends most of the time displaying obtaining IP address, which takes a few seconds. Lowering the beacon interval does help a bit. Altering channel selection, RTS, TKIP, MAC filtering, preamble type, IAPP, data rate or G-only vs. B/G doesn't make much of a difference. A timing issue related bug in the wireless driver is probable, as loading the router CPU sometimes helps. The router log is filled with the following actions 3 second apart: "syslog: wlan0: WPA2-AES PSK authentication in progress.." Sprinkled with authentication failed and "udhcpd Received a