A new package for Slackware 14.1 x64:
- Owncloud client 1.6.1, a sync client for your Owncloud server
Download here:
Enjoy 😉
Page 3 of 4
The problem
After upgrading an old laptop (HP nc8430) to a kernel from the 3.10 series, everything seemed to work fine, except for my wifi card (Atheros AR5418 Wireless Network Adapter [AR5008E 802.11(a)bgn]). Contrary to the previous kernels, after booting, the wifi led was dead, and I obviously had no connection with my wifi station. At first sight, I tried the wifi radio button, but that didn’t help, the wifi led stayed dead. Wicd could not find an active adapter.
Analyse this
When I ran lsmod , it showed me that all the required modules (the ath9k driver for the wifi adapter, wifi networking, 802.11, …) were loaded. When I ran iwconfig, it even showed me a wlan0 device, albeit not connected of course. WTF is going on ?
Ok, let’s see what rfkill says:
rfkill listI got a surprise: everything was blocked. I also have no idea why, but rfkill now showed me two wifi options: hp_wmi and phy0. I am pretty sure the hp_wmi thingie was never there before. Both of them were blocked (hard and soft), so I unblocked them:
rfkill unblock allNow when I ran wicd-client, it connected to my wifi station. The wifi led come on as well. Good, but now, how do we fix this permanently ?
Solution
It appears that the hp_wmi module (support for some HP keys) does not play well with the rfkill module (RFKill is a linux kernel subsystem that provides an interface through which radio transmitters in a computer can be queried, activated, and deactivated).
So, a simple fix is to prevent the hp_wmi module from loading. On a Slackware 14.0 system, this can be achieved by creating a hp_wmi.conf file, in /etc/modprobe.d/, containing the following:
############################################################################## # Do not edit this file; instead, copy it to /etc/modprobe.d/ and edit that ############################################################################## # Blacklist because interferes with wifi (wifi rf blocked at boot) blacklist hp_wmi
This solves my problem: the wifi card now works again straight after booting, just like it did before. If you’re facing the same problem, let me know if this fix also works for you.
The problem
Lately, I noticed that my el-cheapo-Chinese-Ebay-phone (Star B943) got a different IP address every time I re-enabled the Wifi connection. It never did this before (it always reused the same address, as I set the lease duration to 1 week on my server). I don’t know how or why this behaviour started, but I certainly didn’t like it. After examining the dhcp.leases file on my DHCP server, I was in for a big surprise: it appeared that my phone simply changed its own MAC address every single time, which immediately explains why the DCHP server handed out a new lease every time !
Googling the Interwebz learned me that a lot of Android users were(are) facing the same problem. Luckily, I also found a solution to the problem (muchas gracias to Damian Parsons at http://gizbeat.com/ ). This solution only works on a rooted phone.
How to fix it:
- If you don’t have it already, install a root file explorer (like Total Commander) on your phone
- Make sure to allow root privileges every time your root file explorer requests it.
- Navigate to
/data/nvram/APCFG/APRDEB - Copy the file named WIFI to your SD card
- Somehow copy this file to your computer (USB transfer, email, . . .)
- Install a hex editor (Hxd is a good one)
- Open the previously copied WIFI file in HxD. It should look similar to the following image:
- The MAC address starts at row 1, column 4 and it ends at row 1, column 9.
- In my case, the colums 4 till 9 were all zeroes, which explains the problem. When the mac address handed to the kernel at boot is empty, the kernel will start generating random mac addresses.
- Now, input your desired WLAN MAC Address in the colums 4 till 9 (see next image):
- You did not use the same MAC address I used in this example, right ? 😉
- Save the file, but preferably under a different name, or otherwise backup the original WIFI file before editing.
- Copy this new file back to the SD card of your phone.
- Navigate back to
/data/nvram/APCFG/APRDEB - Overwrite the previously existing WIFI file with your modified WIFI (renaming it back to WIFI if necessary).
- Possibly check the file permissions and change them to the same as the original WIFI file if required.
- Reboot your phone.
- Now check the mac address of the wifi card: it should the same as the one you entered in the WIFI file.
- Enable/disable the wifi connection several times to verify the mac address does not change any more.
The above fix worked for me, on a Star B94m (B943), running stock Android 4.2.1 JB (rooted). Let me know if it also works for you.
I managed to get my greedy hands on more powerfull computing gear, providing the means to upgrade this webserver. After nearly 4 years, the old hardware was still fine, but with the newer parts in place, the machine performs even better, and is somewhat more future proof.
| Part | Old server | New server |
| CPU | Intel Core2 Duo E6320 | Intel Core2 Duo E7500 |
| CPU speed | 1.86 Ghz | 2.93 Ghz |
| Memory | 2.0 GB DDR2 | 4.0 GB DDR2 |
| Chipset | Intel DQ965 | Intel Q45 |
In order to prevent a possible disk crash, the old 250 GB harddisk (already 4 years old) was cloned to a new one. The old disk was still OK, but it’s better to be safe than sorry.
The problem
Lately, I stumbled upon a minor but annoying issue with Samba on one of my file servers. There are no printers installed on this server, and probably never will be. However, smbd complains to no end in the client logfiles about not being able to connect to a CUPS server:
[david@Samba ~]$ head /var/log/samba.dfpc5 ... [2013/07/23 07:49:24.869727, 0] printing/print_cups.c:109(cups_connect) Unable to connect to CUPS server localhost:631 - Connection refused [2013/07/23 07:49:24.869790, 0] printing/print_cups.c:468(cups_async_callback) failed to retrieve printer list: NT_STATUS_UNSUCCESSFUL ...
All of the client logfiles were spammed continously by Samba with these lines. While this did not seem to harm the performance of the server, I wanted to ged rid of them. After all, I never configured this Samba server to use CUPS, so why the hell is it trying to find one ?
The cause
This file server runs Slackware Linux, and the Samba package provided by Slackware, is compiled with – – enable-cups (like it is on most distros). Consequently, unless you tell it otherwise, Samba uses CUPS as the default printing system and tries to connect to a local CUPS server. And if fails to do so, it starts spamming your log files . . .
The solution
There are several solutions to this problem:
- reconfigure your Samba installation not to use CUPS
- recompile the Samba package without CUPS support
- run CUPS anyway on that server so Samba can connect to it
I prefer the 1st solution. Just edit your smb.conf file, and look for the line that says “printing = cups”. Pay attention to the ; character at the front, which actually commnents out this line. You must remove the ; character.
; printing = cups printing = bsd
Save the file and restart the Samba service. Those pesky CUPS lines in your logfiles should be history.
Thanks to the ongoing efforts of Dyn.com (formerly known as dyndns.org) to chase away their free customers, this site will get a new hostname. I signed up with the folks at dnsExit.com, who still provide a truly free dynamic DNS update service, without the need to log in monthly, or other crappy measures like dyn.com started to impose on their free customers.
So, from now on, this site can be reached at http://freeunix.publicvm.com:8000.
Don’t worry, the old name will remain available for a few months.