CentOS/RHEL 6.5 and CIFS mounts

It has been a long time since I wrote in here...

... but today, I just spent a good 4 hours trying to figure out why a cifs mount command that would succeed in Scientific Linux 5.4, failed in Centos 6.5 with the cryptic:

mount error(22): Invalid argument

Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Which basically means, "I failed, go figure why..."
Don't you love it when Unix tools for MS interoperability inherit the MS behaviour so closely? :D

Googling for recent reports of the same problem I mostly came up with references of security negotiation mode not setup correcly and how older kernels had ntlm as default while newer the ntmlssp mode. Nada, this wasn't the case. If I entered the wrong password or username I got a different error.

People also suggested installing cifs-utils (cifs.idmap, cifs.upcall, etc) would get rid of the error. But I already had these installed.

Enter the Linux

One reference had information on how to make the kernel CIFS filesystem driver feel more chatty:

echo "0" > /proc/fs/cifs/cifsFYI

Hurray, a boatload of log messages arrived in dmesg at the next mount attempt. Watching closely now, one could easily nail the failure:

fs/cifs/cifssmb.c: Decoding GetDFSRefer response BCC: 215 Offset 56
fs/cifs/cifssmb.c: num_referrals: 1 dfs flags: 0x3 ...

fs/cifs/dns_resolve.c: dns_resolve_server_name_to_ip: unable to resolve: PUNENTES
fs/cifs/cifs_dfs_ref.c: cifs_compose_mount_options: Failed to resolve server part of \\PUNENTES\Backup$ to IP: -11

Problem solved!

Now that was a better candidate for Google. A bug report for Fedora came up in the results, suggesting that /etc/request-key.d be populated with two entries. One was already present in my system (as part of cifs-utils rpm) the other was not:

cat > /etc/request-key.d/dns_resolver.conf

create dns_resolver * * /usr/sbin/cifs.upcall %k

And yes,  that did it.

Inspecting the Scientific Linux system further, the dns_resolver line above was present in /etc/request-key.conf (provided by keyutils rpm) but was missing in the CentOS version. Manpage for cifs.upcall also mentions that dns_resolver should be present.

Packaging oversight? Who knows...

Laters!!

Intel 5300AGN

A couple of months ago, I got hold of a second handed Dell Latitude E4300. The laptop is great, featurin the top of the line intel SP9600 processor and 6gigs of ram. Only drawback, the Broadcom 4322 based Dell WiFi card which wasn't supported natively on Linux*.

After reading a bit I decided to go for an Intel 5000 series replacement. Off to eBay, I was stunned by the plethora of Intel 5300 AGN cards from China/HongKong/Singapore costing about $19.99US including international shipping. That was dead chep so I bit their bullet...

... and about 40 days later owing to Chinese new year or whatever was going on around February 12th, I had my card onto my hands. I installed it and booted 2.6.39-rc0 but a wireless device was nowhere to be found!!

Some searching through dmesg messages couple minutes later and there comes the culprit:

iwlagn 0000:0c:00.0: Unsupported (too old) EEPROM VER=0x114 < 0x11a CALIB=0x1 < 0x4

Googling for a solution I came across several hits describing with the same problem. Everybody concluded that these were all pre-production or engineering sample devices. They were apparently carrying the correct hardware but lacked all the calibration and whatever else made the card worthy of the CE or any like certification. As everybody with such a card reported to have acquired it through some questionable channel (notably eBay oriental sellers), it was apparent that these were probably some test runs by manufacturers which should have never hit the market... in other words all these cards could be regarded as "fake".

And oh my, upon closer inspection there did appear ... from sticker alignment, to printed vs reported MAC address and copied/scanned 3d barcode images and more... see here for a good example.

What puzzled people though was that these cards were working (sufficiently?) under Windows and probably that's the reason they're still selling. It was quickly revealed that the Windows driver didn't check the EEPROM version of calibration data and therefore happily utilized the hardware. People suggested and succeeded in "patching" the Linux iwlagn driver, removing the version check which made it abort, getting a working card in return.

I wasn't successful.

The card was brought up after patching the driver but at least with the 2.6.39-rc0 included driver, or the firmware version: 8.83.5.1 build 33692 had some more troubles beside that. Soon after trying to use the wifi, Linux logged an interminent series of:

[34531.440894] iwlagn 0000:0c:00.0: Microcode SW error detected. Restarting 0x82000000.
[34531.440909] iwlagn 0000:0c:00.0: Loaded firmware version: 8.83.5.1 build 33692
[34531.440936] iwlagn 0000:0c:00.0: Start IWL Error Log Dump:
[34531.440944] iwlagn 0000:0c:00.0: Status: 0x00020224, count: 5
[34531.441198] iwlagn 0000:0c:00.0: Desc Time data1 data2 line
[34531.441211] iwlagn 0000:0c:00.0: SYSASSERT (0x0005) 0000006053 0x00000000 0x0000096E 2414
[34531.441221] iwlagn 0000:0c:00.0: pc blink1 blink2 ilink1 ilink2 hcmd
[34531.441232] iwlagn 0000:0c:00.0: 0x1B67C 0x1B678 0x1B678 0x00000 0x00000 0x00000
[34531.441241] iwlagn 0000:0c:00.0: CSR values:
[34531.441248] iwlagn 0000:0c:00.0: (2nd byte of CSR_INT_COALESCING is CSR_INT_PERIODIC_REG)
[34531.441262] iwlagn 0000:0c:00.0: CSR_HW_IF_CONFIG_REG: 0X00480301
[34531.441275] iwlagn 0000:0c:00.0: CSR_INT_COALESCING: 0X00000040
[34531.441286] iwlagn 0000:0c:00.0: CSR_INT: 0X80000000
[34531.441297] iwlagn 0000:0c:00.0: CSR_INT_MASK: 0X00000000
[34531.441309] iwlagn 0000:0c:00.0: CSR_FH_INT_STATUS: 0X40010000
[34531.441320] iwlagn 0000:0c:00.0: CSR_GPIO_IN: 0X00000000
[34531.441331] iwlagn 0000:0c:00.0: CSR_RESET: 0X00000000
[34531.441345] iwlagn 0000:0c:00.0: CSR_GP_CNTRL: 0X080403c5
[34531.441355] iwlagn 0000:0c:00.0: CSR_HW_REV: 0X00000024
[34531.441368] iwlagn 0000:0c:00.0: CSR_EEPROM_REG: 0X00000000
[34531.441379] iwlagn 0000:0c:00.0: CSR_EEPROM_GP: 0X90000004
[34531.441390] iwlagn 0000:0c:00.0: CSR_OTP_GP_REG: 0X00060000
[34531.441401] iwlagn 0000:0c:00.0: CSR_GIO_REG: 0X00080044
[34531.441413] iwlagn 0000:0c:00.0: CSR_GP_UCODE_REG: 0X00000000
[34531.441424] iwlagn 0000:0c:00.0: CSR_GP_DRIVER_REG: 0X00000000
[34531.441435] iwlagn 0000:0c:00.0: CSR_UCODE_DRV_GP1: 0X00000000
[34531.441446] iwlagn 0000:0c:00.0: CSR_UCODE_DRV_GP2: 0X00000000
[34531.441457] iwlagn 0000:0c:00.0: CSR_LED_REG: 0X00000018
[34531.441468] iwlagn 0000:0c:00.0: CSR_DRAM_INT_TBL_REG: 0X00000000
[34531.441480] iwlagn 0000:0c:00.0: CSR_GIO_CHICKEN_BITS: 0X27800200
[34531.441492] iwlagn 0000:0c:00.0: CSR_ANA_PLL_CFG: 0X00880300
[34531.441503] iwlagn 0000:0c:00.0: CSR_HW_REV_WA_REG: 0X0001001a
[34531.441514] iwlagn 0000:0c:00.0: CSR_DBG_HPET_MEM_REG: 0Xffff0000
[34531.441523] iwlagn 0000:0c:00.0: FH register values:
[34531.441546] iwlagn 0000:0c:00.0: FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X0fff6e00
[34531.441570] iwlagn 0000:0c:00.0: FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X00fff6f0
[34531.441593] iwlagn 0000:0c:00.0: FH_RSCSR_CHNL0_WPTR: 0X000000f8
[34531.441615] iwlagn 0000:0c:00.0: FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X80819104
[34531.441638] iwlagn 0000:0c:00.0: FH_MEM_RSSR_SHARED_CTRL_REG: 0X000000fc
[34531.441661] iwlagn 0000:0c:00.0: FH_MEM_RSSR_RX_STATUS_REG: 0X07030000
[34531.441683] iwlagn 0000:0c:00.0: FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X00000000
[34531.441706] iwlagn 0000:0c:00.0: FH_TSSR_TX_STATUS_REG: 0X07ff0001
[34531.441729] iwlagn 0000:0c:00.0: FH_TSSR_TX_ERROR_REG: 0X00000000
[34531.441798] iwlagn 0000:0c:00.0: Start IWL Event Log Dump: display last 4 entries
[34531.441827] iwlagn 0000:0c:00.0: EVT_LOGT:0000000000:0x0000028c:0117
[34531.441846] iwlagn 0000:0c:00.0: EVT_LOGT:0000000022:0x00000000:1208
[34531.441864] iwlagn 0000:0c:00.0: EVT_LOGT:0000002258:0x00000000:0480
[34531.441882] iwlagn 0000:0c:00.0: EVT_LOGT:0000006062:0x00000000:0125
[34531.441981] iwlagn 0000:0c:00.0: init uCode did not respond OK.
[34535.434244] iwlagn 0000:0c:00.0: START_ALIVE timeout after 4000ms.

So either my Dell, my kernel driver or firmware had something dependent on the correct production EEPROM being in the card.

I then found iwleeprom, a utility able to read and write (flash) the EEPROM image of the wifi card. That was sooo sweet... once I managed to get hold of an EEPROM dump off a legitimate 5300AGN card, I flashed it and ... yeap, you guessed it, my card works as it should!

I haven't seen this resolution in any search I made so far. So there, if you haven't tossed it already you may as well try this ...

Maybe, if there could be a legitimate way of obtaining such an EEPROM dump, all those people fooled into buying cheap Intel knock-offs on eBay or elsewhere could at least get their hardware working properly with Linux.

* In post 2.6.38 kernels the b43 driver recognizes the chipset and tries to load its firmware. The firmware can be extracted by patching the fwcutter to handle a 5.x series Windows driver image from Broadcom. Yet, at least on my computer the card would scan a couple of networks, report them all at 100% strength and then play dead. Oh well...

FrontMotion FirefoxCE

The good guys at FrontMotion publish the Community Edition (CE) of Firefox as an .msi installer package which also supports group policy settings. Great work. They also keep their builds updated.

But one size doesn't fit all so I had to use orca (an MS utility) to make some changes to their .msi package and saved a transformation. My problem was their installer completely ignored any transformation I passed it in the msiexec command line. Looking over at the log, I watched the TRANSFORMS property being erased shortly after installation start. Strange. 

Following the KISS principal though, I just produced a new .msi file with my .mst file already applied and installed that instead. Voila!

jQuery, jRails and autocomplete

Recently, I choose to switch the Rails-bundled Prototype library with jQuery/jRails for a project. All went smooth (great job guys!) save for a catch: the autocomplete plugin stopped working :(

Looking for an alternative I stumbled on jrails_auto_complete plugin. It is supposed to be a drop-in replacement for the DHH Prototype one. And it indeed was.

With the DHH plugin, I had been using multi-line formating and styling in my list elements using DIVs insile the LIs. With the new jRails thing these multil-ine elements exhibited a small problem with mouse navigation and clicking in the drop down list elements:

• Mousing over list elements, would only highlight them when the pointer was hovering on the element border. Move a bit inside and the highlight was gone.
• Clicking to select would cause all the list element titles to be pasted in the text field causing a mess and of course, no actual selection was made.

Funny though, there was no problem navigating with the keyboard.

Googling I only found one relevant post by a guy experiencing the same thing and thanks to him I got some insight on what was actually going on. The plugin is relying on the mouseover event firing from the element to make the highlight and update the internal selection index. However, in my (our) case, child objects inside the LI element fired their own mouseovers as well, which bubbled up and where intercepted too. As child objects don't get a selection index property added, the plugin code just invalidated the selection, hence no highlight anywhere.

My (naive) solution was to change jrails_autocomplete.js as follows:

    onHover: function(e) {
       var my_index = e.target.autocompleteIndex;
       if (!my_index) {
         my_index = $(e.target).closest('li').attr('autocompleteIndex');
       }
       if (this.index != my_index) {
           this.index = my_index;
           this.render();
       }
       stopEvent(e);
   },

This basically searches the closest LI parent for an autocompleteIndex property if one isn't found in the element that fired the event.

For the second problem I just glanced over the keyboard part of the code which looked similar and finally decided to just comment out the line (re)setting the index out of the element clicked:

    onClick: function(e) {
        /*this.index = e.target.autocompleteIndex;*/
        this.selectEntry();
        this.hide();
    },

Thanks to the guy over at StackOverflow who gave me the heads-up with his question. It has been some time since he posted but I hope he finds my solution of some use.

HTML5 to the rescue!

The other day I needed to find a way for a web page to request data from another site.  I had control of the "other" site, but not on the web page itself. I could however place javascript on it, accessible through a link.

So, what had to be done was write some javascript that when activated on the proper page, should fetch data from the "other" site and update some things on the web page as it is viewed in the browser. A classic example of cross-site scripting...

Try 1:  xmlhttp API

NOT! The browsers go into great lengths to prohibit xmlhttp requests directed to pages not in the same server, or at least DNS domain. So this one is a no-no.

Try 2: window.open

Well, this solution would let me open the page on the "other" site where the data would be, but again, browsers go into great length to prohibit any interaction of pages like above. Most of the created window properties would become inaccessible as soon as the page started to load.

Bottom line: there is no way for javascript on one page to peek the contents of another, nor there will ever be one, as it is a huge security hole.

Try 3: greasemonkey

At least, something that would work. But, letting aside the minor(?) security issues and browser compatibility, the web page not under my control strictly forbids any greasemonkey scripts stored. The will shoot them on sight and ban the user. So... no go again.

Try 4: PostMessage/ message event

After enough looking around on how to circumvent xmlhttprequest restictions or greasemonkey alternative, Google stumbled onto a reference for this HTML5 feature. Which was exactly what I was looking for! And it is implemented exactly to allow intercommunication of 2 browser windows belonging to different sites.

Really! Google for PostMessage specifically, there are enough examples already on the net describing the API perfectly.

Virtualization nightmares

I decided it was time I dove into virtualization.

Day 1:

Set up a Windows XP guest with VirtualBox (3.1.2) on my atom netbook under Linux was very easy but of course slow. So I went on to make a cheap virtualization testbed. Used some components I had lying around: Asus P5L-MX, Intel Celeron Dual Core E3200, 1GB memory

The Asus wouldn't recognize the processor and there was no recent BIOS update for it, but would utilize it, overclock it easily (just kicked FSB to 266MHz) and run Linux like a charm. Also noted it would enable Vanderpool.

Imported the VM from my netbook to testbed computer, fired up VirtualBox (3.0.12) and... blue screen right after the loading screen and an oops logged in the host. Played with various settings, now the VM wouldn't start at all, instead the host would oops and I'd be left with a stale VM. 

Strange...

Day 2:

So then I said "OK, fine, I am going the KVM way".

Goodness, kvm (2.6.30.5)/qemu-0.12.1.2 worked and I proceeded to install a fresh WinXP guest, using a real partition this time instead of the disk image file. Installation went smooth, machine restarted and... right, blue screen. Tryed to boot a linux image (gparted-live-0.4.6-1.iso) in the VM as well but the kernel wouldn't go further than the uncompressing stage.

Played with qemu parameters a bit:

• Disabled kvm usage: VM came up fine. Enabled it again => Freeze. 
• -smp=1, worked with kvm!!! I was happy... a few tries later, it wouldn't... bugger.
• -cpu seemed to have no difference.

So I upgraded my kernel to the latest available at the time, 2.6.32.2 and tried again. Lo and behold, this time the host system would freeze (no oops) as soon as I started the VM. Holy ...

What was even more frustrating was that Google search results wound never mention a freeze with kvm/virtual box in the host (or if they did, it would date 2 years ago...). And frankly, a host freeze because of the bad guest would have been a showstopper, wouldn't it?

Day 3:

Ripped another machine from someplace: Asus P5B-VM, Core2Duo E6300. Then I hooked the hard disks from the testbed, booted,

• fired up kvm/qemu VM:  SUCCESS!!!
• tryed VirtualBox VM: SUCCESS!!! again...

So it is the testbed hardware, rather than the software...

Flash1: testbed doesn't really enable VM-X, because the BIOS doesn't recognise the CPU correctly.
Dim1: checked the msr 0x3a, it has the correct value... and kvm module doesn't complain about VM-X being disabled in BIOS either...

Flash2: microcode?

Had:
microcode: CPU0 sig=0x1067a, pf=0x1, revision=0x0
microcode: CPU1 sig=0x1067a, pf=0x1, revision=0x0

Updated with microcode-data v. 20090927. Got:
microcode: CPU0 updated to revision 0xa07, date = 2008-04-09
microcode: CPU1 updated to revision 0xa07, date = 2008-04-09

Result:
SUCCESSS!!!!

All VMs work!!! No BSOD, no freezes, linux guest (gparted image) now boots fine as well.

3 days spent over a non-issue, that is usually taken care by the BIOS during POST. Well, now I'll know better!