Into.the.Void.

I reported this bug on November 2012 but as of February 2013 it still hasn’t been fixed.

My initial report on oss-security and kernel netdev mailing lists reported it as an ‘information disclosure’ problem but then I found out that the issue is more severe and it can lead to the complete corruption of Linux kernel’s IPv6 stack until reboot. My second report wasn’t public, I thought it would be better not to make any public disclosure until the kernel people had enough time to respond, and was only sent to a number of kernel developers but I’m making it public now since the CVE is already out.

If someone wants to read all the publicly exchanged emails the best resource is probably this: http://marc.info/?t=135291265200001&r=1&w=2

Here’s the initial description of the problem:

Due to the way the Linux kernel handles the creation of IPv6 temporary addresses a malicious LAN user can remotely disable them altogether which may lead to privacy violations and information disclosure.

By default the Linux kernel uses the ‘ipv6.max_addresses’ option to specify how many IPv6 addresses an interface may have. The ‘ipv6.regen_max_retry’ option specifies how many times the kernel will try to create a new address.

Currently, in net/ipv6/addrconf.c,lines 898-910, there is no distinction between the events of reaching max_addresses for an interface and failing to generate a new address. Upon reaching any of the above conditions the following error is emitted by the kernel times ‘regen_max_retry’ (default value 3):

[183.793393] ipv6_create_tempaddr(): retry temporary address regeneration
[183.793405] ipv6_create_tempaddr(): retry temporary address regeneration
[183.793411] ipv6_create_tempaddr(): retry temporary address regeneration

After ‘regen_max_retry’ is reached the kernel completely disables temporary address generation for that interface.

[183.793413] ipv6_create_tempaddr(): regeneration time exceeded - disabled temporary address support

RFC4941 3.3.7 specifies that disabling temp_addresses MUST happen upon failure to create non-unique addresses which is not the above case. Addresses would have been created if the kernel had a higher
‘ipv6.max_addresses’ limit.

A malicious LAN user can send a limited amount of RA prefixes and thus disable IPv6 temporary address creation for any Linux host. Recent distributions which enable the IPv6 Privacy extensions by default, like Ubuntu 12.04 and 12.10, are vulnerable to such attacks.

Due to the kernel’s default values for valid (604800) and preferred (86400) lifetimes, this scenario may even occur under normal usage when a Router sends both a public and a ULA prefix, which is not an uncommon
scenario for IPv6. 16 addresses are not enough with the current default timers when more than 1 prefix is advertised.

The kernel should at least differentiate between the two cases of reaching max_addresses and being unable to create new addresses, due to DAD conflicts for example.

And here’s the second, more severe report about the corruption of the IPv6 stack:

I had previously informed this list about the issue of the linux kernel losing IPv6 privacy extensions by a local LAN attacker. Recently I’ve found that there’s actually another, more serious in my
opinion, issue that follows the previous one. If the user tries to disconnect/reconnect the network device/connection for whatever reason (e.g. thinking he might gain back privacy extensions), then the device gets IPs from SLAAC that have the “tentative” flag and never loses that. That means that IPv6 functionality for that device is from then on completely lost. I haven’t been able to bring back the kernel to a working IPv6 state without a reboot.

This is definitely a DoS situation and it needs fixing.

Here are the steps to reproduce:

== Step 1. Boot Ubuntu 12.10 (kernel 3.5.0-17-generic) ==
ubuntu@ubuntu:~$ ip a ls dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:8b:99:5d brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.96/24 brd 192.168.1.255 scope global eth0
    inet6 2001:db8:f00:f00:ad1f:9166:93d4:fd6d/64 scope global temporary dynamic 
       valid_lft 86379sec preferred_lft 3579sec
    inet6 2001:db8:f00:f00:5054:ff:fe8b:995d/64 scope global dynamic 
       valid_lft 86379sec preferred_lft 3579sec
    inet6 fdbb:aaaa:bbbb:cccc:ad1f:9166:93d4:fd6d/64 scope global temporary dynamic 
       valid_lft 86379sec preferred_lft 3579sec
    inet6 fdbb:aaaa:bbbb:cccc:5054:ff:fe8b:995d/64 scope global dynamic 
       valid_lft 86379sec preferred_lft 3579sec
    inet6 fe80::5054:ff:fe8b:995d/64 scope link 
       valid_lft forever preferred_lft forever

ubuntu@ubuntu:~$ sysctl -a | grep use_tempaddr
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
net.ipv6.conf.eth0.use_tempaddr = 2
net.ipv6.conf.lo.use_tempaddr = 2

ubuntu@ubuntu:~$ nmcli con status
NAME                      UUID                                   DEVICES    DEFAULT  VPN   MASTER-PATH
Wired connection 1        923e6729-74a7-4389-9dbd-43ed7db3d1b8   eth0       yes      no    --
ubuntu@ubuntu:~$ nmcli dev status
DEVICE     TYPE              STATE
eth0       802-3-ethernet    connected

//ping6 2a00:1450:4002:800::100e  while in another terminal: tcpdump -ni eth0 ip6

ubuntu@ubuntu:~$ ping6 2a00:1450:4002:800::100e -c1
PING 2a00:1450:4002:800::100e(2a00:1450:4002:800::100e) 56 data bytes
64 bytes from 2a00:1450:4002:800::100e: icmp_seq=1 ttl=53 time=70.9 ms

--- 2a00:1450:4002:800::100e ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 70.994/70.994/70.994/0.000 ms

# tcpdump -ni eth0 host 2a00:1450:4002:800::100e
17:57:37.784658 IP6 2001:db8:f00:f00:ad1f:9166:93d4:fd6d > 2a00:1450:4002:800::100e: ICMP6, echo request, seq 1, length 64
17:57:37.855257 IP6 2a00:1450:4002:800::100e > 2001:db8:f00:f00:ad1f:9166:93d4:fd6d: ICMP6, echo reply, seq 1, length 64

== Step 2. flood RAs on the LAN ==

$ dmesg | tail
[ 1093.642053] IPv6: ipv6_create_tempaddr: retry temporary address regeneration
[ 1093.642062] IPv6: ipv6_create_tempaddr: retry temporary address regeneration
[ 1093.642065] IPv6: ipv6_create_tempaddr: retry temporary address regeneration
[ 1093.642067] IPv6: ipv6_create_tempaddr: regeneration time exceeded - disabled temporary address support

ubuntu@ubuntu:~$ sysctl -a | grep use_tempaddr
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
net.ipv6.conf.eth0.use_tempaddr = -1
net.ipv6.conf.lo.use_tempaddr = 2

//ping6 2a00:1450:4002:800::100e  while in another terminal: tcpdump -ni eth0 ip6

ubuntu@ubuntu:~$ ping6 2a00:1450:4002:800::100e -c1
PING 2a00:1450:4002:800::100e(2a00:1450:4002:800::100e) 56 data bytes
64 bytes from 2a00:1450:4002:800::100e: icmp_seq=1 ttl=53 time=77.5 ms

--- 2a00:1450:4002:800::100e ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 77.568/77.568/77.568/0.000 ms

# tcpdump -ni eth0 host 2a00:1450:4002:800::100e
17:59:38.204173 IP6 2001:db8:f00:f00:5054:ff:fe8b:995d > 2a00:1450:4002:800::100e: ICMP6, echo request, seq 1, length 64
17:59:38.281437 IP6 2a00:1450:4002:800::100e > 2001:db8:f00:f00:5054:ff:fe8b:995d: ICMP6, echo reply, seq 1, length 64

//notice the change of IPv6 address to the one not using privacy extensions even after the flooding has finished long ago.

== Step 3. Disconnect/Reconnect connection  ==
// restoring net.ipv6.conf.eth0.use_tempaddr to value '2' makes no difference at all for the rest of the process

# nmcli dev disconnect iface eth0
# nmcli con up uuid 923e6729-74a7-4389-9dbd-43ed7db3d1b8

ubuntu@ubuntu:~$ ip a ls dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:8b:99:5d brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.96/24 brd 192.168.1.255 scope global eth0
    inet6 2001:db8:f00:f00:5054:ff:fe8b:995d/64 scope global tentative dynamic 
       valid_lft 86400sec preferred_lft 3600sec
    inet6 fdbb:aaaa:bbbb:cccc:5054:ff:fe8b:995d/64 scope global tentative dynamic 
       valid_lft 86400sec preferred_lft 3600sec
    inet6 fe80::5054:ff:fe8b:995d/64 scope link tentative 
       valid_lft forever preferred_lft forever

//Notice the "tentative" flag of the IPs on the device

//ping6 2a00:1450:4002:800::100e  while in another terminal: tcpdump -ni eth0 ip6

ubuntu@ubuntu:~$ ping6 2a00:1450:4002:800::100e -c1
PING 2a00:1450:4002:800::100e(2a00:1450:4002:800::100e) 56 data bytes
^C
--- 2a00:1450:4002:800::100e ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

# tcpdump -ni eth0 host 2a00:1450:4002:800::100e
18:01:45.264194 IP6 ::1 > 2a00:1450:4002:800::100e: ICMP6, echo request, seq 1, length 64

Summary:
Before flooding it uses IP: 2001:db8:f00:f00:ad1f:9166:93d4:fd6d
After flooding it uses IP: 2001:db8:f00:f00:5054:ff:fe8b:995d –> it has lost privacy extensions
After disconnect/reconnect it tries to use IP: ::1 –> it has lost IPv6 connectivity

The problem currently affects all Linux kernels (including the latest 3.8), that have IPv6 Privacy Extensions enabled. The only distribution that has IPv6 Privacy Extensions enabled by default is Ubuntu starting from version 12.04. So Ubuntu 12.04 and 12.10 are currently vulnerable to this attack and can have their IPv6 stack corrupted/disabled by a remote attacker in an untrusted network.

Kernel developers and people from RedHat Security Team are trying to fix the issue which in my opinion involves changing parts of the logic of IPv6 addressing algorithms in the Linux kernel.

No mitigation currently exists apart from disabling IPv6 Privacy Extensions.

You can play with this bug using flood_router26 tool from THC-IPv6 toolkit v2.1.
Usage: # ./flood_router26 -A iface

P.S. I can’t tell if the stack corruption could also lead to other kernel problems, that would probably need some professional security researchers to look into it.

Filed by kargig at 16:27 under Internet,IPv6,Linux,Networking
Tags: 12.04, 12.10, bug, cve, CVE-2013-0343, ipv6, kernel, Linux, Networking, Privacy, privacy extensions, security, slaac, temporary addresses, ubuntu, vulnerability
No Comments | 22,358 views

When you have a misbehaving system and you are not sure what the problem is, always bet on a poorly written application.

Here’s a small example of how another poorly written web application caused system issues.

I was sitting at my office today I when I got this nagios alert for a host.

Date/Time: Tue Nov 6 19:15:11 EET 2012
Additional Info:
SWAP CRITICAL – 0% free (0 MB out of 509 MB)

Logging in actually showed all the swap’s been used and so was RAM, 0.95/1Gb. Lots of apache2 server instances were running. I did a netstat and I saw a lot of ESTABLISHED connections:

tcp6       0      0 2001:DB8:f00::1:35571 2001:DB8:bar::100:80 ESTABLISHED 9631/apache2    
tcp6       0      0 2001:DB8:f00::1:35777 2001:DB8:bar::100:80 ESTABLISHED 9656/apache2    
tcp6       0      0 2001:DB8:f00::1:36531 2001:DB8:bar::100:80 ESTABLISHED 11578/apache2   
tcp6       0      0 2001:DB8:f00::1:36481 2001:DB8:bar::100:80 ESTABLISHED 11158/apache2   
tcp6       0      0 2001:DB8:f00::1:36295 2001:DB8:bar::100:80 ESTABLISHED 11115/apache2   
tcp6       0      0 2001:DB8:f00::1:34831 2001:DB8:bar::100:80 ESTABLISHED 8312/apache2  

2001:DB8:f00::1 -> my server
2001:DB8:bar::100 -> dst server

As one can easily see my server is connecting to port 80 of dst, possibly asking for something over HTTP.

# netstat -antpW | grep 2001:DB8:bar::100 | wc -l
111

# dig -x 2001:DB8:bar::100 +short                                 
crl.randomcertauthority.com.

tailing the log files didn’t show anything weird happening. I run a tcpdump for that dst server but there wasn’t at that time any traffic going on.

So, I took a look at munin to see when this problem started developing.

As it’s obvious from the above graphs, the problem started around 14:00. So I took another look at the apache logs and I saw a bot crawling a specific url from my server. I visited that url on my server using curl and I saw traffic flowing through tcpdump going from my server to dst server. So visiting that URL was definitely causing problems. But why?

I restarted apache, swap and memory were released, all the stale ESTABLISHED connections went away and I saw hundreds of FIN/RST packets going back and forth at tcpdump.

I tried to open a few concurrent connections from my PC to my server’s url using curl. After a couple of tries netstat showed that I had managed to create stale ESTABLISHED connections towards dst server. It was an HTTP connection asking for a crl. So I was both able to reproduce the problem and I also knew the specific url of the dst server that caused the connection hanging issues.
Next thing I did was to try to open direct HTTP connections from my server to the dst url using curl. After a few concurrent connections I managed to make curl hang. So the problem was definitely not on my server, but at the dst server.

Since it was already quite late, my first (re)action was to install mod_evasive to try and minimize the problem so I could take a better look the next day.

# aptitude install libapache2-mod-evasive
# a2enmod mod_evasive
### edit /etc/apache2/sites-enabled/site-name and add the following
       <IfModule mod_evasive20.c>
            DOSHashTableSize    3097
            DOSPageCount        1   
            DOSSiteCount        50  
            DOSPageInterval     1   
            DOSSiteInterval     1   
            DOSBlockingPeriod   10  
            DOSEmailNotify myemail@mydomain.gr
        </IfModule>
# /etc/init.d/apache2 reload

I tried to curl my server’s URL from my PC and I got blocked after the second concurrent try. But after some repetitions I was still able to create one or two stale ESTABLISHED connections from my server to the dst server. Far fewer than before but the problem was still somewhat reproducible.

Then I decided to take a look at the site’s PHP code. Finding the culprit was quite easy, I just had to find the code segment where PHP requested the dst server’s url.
Here’s the code segment:

$ch = curl_init($this->crl_url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER,true);
$crl_content = curl_exec($ch);

The developer had never thought that the remove server might keep the connection open for whatever reason (rate limiting anyone?)

Patching it was quite simple:

$ch = curl_init($this->crl_url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER,true);
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT,'60');
curl_setopt($ch, CURLOPT_TIMEOUT,'60');
$crl_content = curl_exec($ch);

After this everything worked fine again. Connections were getting ESTABLISHED but after 60 seconds they got torn down, automagically. No more stale ESTABLISHED connections. Hooray!

A letter to every developer:

Dear developer,

please test your code before shipping. Pretty please take corner cases into account. We know you’re competent enough, don’t be lazy.

Your kind sysadmin

Filed by kargig at 22:36 under Internet,IPv6,Linux,Networking
Tags: apache2, bug, curl, debian, HTTP, libcurl, Linux, mod_evasive, munin, nagios3, php, tcpdump
1 Comment | 8,329 views

This post is about a friend who had a faulty (firmware bug) hard disk replaced by Seagate…

A few months ago she bought a Seagate Barracuda 7200.11 500 GB loaded with firmware SD15. This specific firmware is known to be buggy and Seagate has provided a firmware upgrade for them, but of course she had no idea about that bug. Everything was OK until one day, suddenly, the BIOS couldn’t detect the disk. It didn’t take her long to find out the cause of the problem…

After several failed attempts to upgrade her firmware following the instructions placed at Seagate’s site she decided to send her disk to Greek companies that specialized on data recovery. One of them broke the seals of her disk but failed(!!) to do anything else. The other companies, asked a serious amount of money, 200-1000 Euros(!!!) in order to handle her case/take a preliminary look at the disk.

Fed up with those companies she finally decided to contact Seagate herself and she was given instructions via telephone to complete the online application form for technical support and data recovery.

The very next day, a courier took her disk, delivered it to Seagate Labs at Amsterdam and within a week, she had her disk brought back, totally repaired, with all her data intact(!!). Everything was free and her data was saved.

So the next time you have a hard disk problem, especially if it is a Seagate disk, contact Seagate before contacting these “specialized data recovery companies”. sigh.

Filed by kargig at 11:06 under General,Greek,Internet
Tags: barracuda 7200.11, bios, bug, crash, data recovery, firmware sd15, hard disk, recovery, sd15, seagate
4 Comments | 7,336 views

Lately I noticed some image distortion appearing on some websites using my laptop with Debian squeeze. Menus on swiftfox did not appear as they should, some logos appeared out of their place and there were artifacts and other annoying things. For example Planet Gnome looked like this:

When using iceweasel 3.0.12 everything looked fine. Then I followed a guide to install Iceweasel 3.5 from experimental to my system. Images looked distorted again. So there must have been a problem with the latest xulrunner….

After some googling I bumped into Debian bug #491871 – [965GM EXA] display corruption with xulrunner 1.9. Following post #67 on that thread I was able to repair my xorg.conf to something that fixed the image distortion. Now Planet Gnome looks like this:

Some info:

# apt-cache policy iceweasel xserver-xorg-video-intel xulrunner-1.9.1
iceweasel:
Installed: 3.5.1-1
Candidate: 3.5.1-1
Version table:
*** 3.5.1-1 0
1 http://ftp.debian.org experimental/main Packages
100 /var/lib/dpkg/status
3.0.12-1 0
500 http://ftp.de.debian.org squeeze/main Packages
99 http://ftp.de.debian.org sid/main Packages
xserver-xorg-video-intel:
Installed: 2:2.3.2-2+lenny6
Candidate: 2:2.3.2-2+lenny6
Version table:
2:2.8.0-2 0
99 http://ftp.de.debian.org sid/main Packages
*** 2:2.3.2-2+lenny6 0
500 http://ftp.de.debian.org squeeze/main Packages
100 /var/lib/dpkg/status
xulrunner-1.9.1:
Installed: 1.9.1.1-2
Candidate: 1.9.1.1-2
Version table:
*** 1.9.1.1-2 0
1 http://ftp.debian.org experimental/main Packages
100 /var/lib/dpkg/status

Filed by kargig at 19:21 under Linux
Tags: 3.5, bug, bugzilla, debian, distortion, driver, exa, firefox, iceweasel, image, intel, Linux, problem, swiftfox, xaa, xorg
No Comments | 9,200 views

One of the things that good Linux applications should have is uniformity. Just like Mac OS X does. All applications should use the same keybindings to perform the same tasks. For example, on _every_ OS X application, in order to quit it you have to press “CMD+Q”, it’s that simple and everybody follows it. Everybody. On Linux though there are some applications that simply don’t care about uniformity. One of these applications is smplayer.

While it is almost standard for Linux applications to quit using Ctrl+Q, smplayer simply doesn’t have this option. It has the option of closing the current video with Ctrl+X but it doesn’t have the simple option of quitting using a keyboard shortcut.

So, the next (oneliner actually) patch does simply what I described above. It makes smplayer quit using “Ctrl+Q”.

The screenshot that shows what the patch does:

smplayer-0.6.8-quit.patch:
--- smplayer-0.6.8/src/baseguiplus.cpp 2009-08-13 16:07:04.000000000 +0300
+++ smplayer-0.6.8/src/baseguiplus.cpp 2009-08-13 16:08:22.000000000 +0300
@@ -67,8 +67,7 @@
tray->setToolTip( "SMPlayer" );
connect( tray, SIGNAL(activated(QSystemTrayIcon::ActivationReason)),
this, SLOT(trayIconActivated(QSystemTrayIcon::ActivationReason)));
-
- quitAct = new MyAction(this, "quit");
+ quitAct = new MyAction(QKeySequence("Ctrl+Q"), this, "quit");
connect( quitAct, SIGNAL(triggered()), this, SLOT(quit()) );
openMenu->addAction(quitAct);

And a patched ebuild for smplayer-0.6.8 to use this minor patch (only one line is added to the ebuild):
smplayer-0.6.8-r1.ebuild

P.S. Keybindings in smplayer can be set through Preferences, and someone could actually put Ctrl+Q as the quit shortcut but I think that this should be the default setting like most other applications have it. Uniformity matters.

Filed by kargig at 16:19 under Gentoo,Linux
Tags: bug, bugfix, ebuild, Gentoo, Linux, Mac, MacOSX, media player, patch, smplayer
5 Comments | 10,900 views

On my Macbook (4,1) I am currently using Debian with kernel 2.6.30-1-686-bigmem. This Macbook has Broadcom 4328 wireless chipset installed (02:00.0 Network controller: Broadcom Corporation BCM4328 802.11a/b/g/n (rev 03)) and unfortunately the necessary kernel module provided by Broadcom is pretty unstable. Or very unstable. Oh well…it’s totally unstable.

I had random freezes, usually when I first booted and tried to modprobe the module. After some searching around the net and a lot of experiments I’ve managed to create a kernel module that looks quite stable. At least I stopped getting any more lockups and freezes…To reproduce the module with the patches I’ve used follow the directions bellow step by step.

Find your kernel version:
mybox:~# uname -r
2.6.30-1-686-bigmem

Install kernel header files related to the kernel version you found (on the above example it is: 2.6.30-1-686-bigmem):
mybox:~# aptitude install linux-headers-2.6.30-1-686-bigmem

Remember to replace the version (2.6.30-1-6-bigmem) with the output of your mybox:~# uname -r

Create necessary dirs:
mybox:~# mkdir hybrid_wl
mybox:~# cd hybrid_wl

Download Linux drivers package from Broadcom:
802.11 Linux STA 32-bit Driver
(Driver info site: 802.11 Linux STA driver)
mybox:~/hybrid_wl# wget http://www.broadcom.com/docs/linux_sta/hybrid-portsrc-x86_32-v5_10_91_9.tar.gz

Download a few more patches from Archlinux and Gentoo:
hidden-essid patch
2.6.30 patch 1
2.6.30 patch 2
hybrid-portsrc-x86_32-v5_10_91_9-convert_to_net_device_ops.diff
mybox:~/hybrid_wl# wget http://aur.archlinux.org/packages/broadcom-wl/broadcom-wl/hidden-essid.patch
mybox:~/hybrid_wl# wget http://aur.archlinux.org/packages/broadcom-wl/broadcom-wl/broadcom-sta-5.10.91.9-linux-2.6.30.patch
mybox:~/hybrid_wl# wget http://aur.archlinux.org/packages/broadcom-wl/broadcom-wl/broadcom-sta-5.10.91.9-linux-2.6.30-2.patch
mybox:~/hybrid_wl# wget -O hybrid-portsrc-x86_32-v5_10_91_9-convert_to_net_device_ops.diff http://bugs.gentoo.org/attachment.cgi?id=195182

Extract package:
mybox:~/hybrid_wl# tar -xzf /path/to/hybrid-portsrc-x86_32-v5_10_91_9.tar.gz

Start Patching:
mybox:~/hybrid_wl# sed -i hidden-essid.patch -e 's|5.10.79.10|src/wl/sys|g'
mybox:~/hybrid_wl# patch -p0 < hidden-essid.patch
patching file src/wl/sys/wl_iw.c
mybox:~/hybrid_wl# sed -i broadcom-sta-5.10.91.9-linux-2.6.30.patch -e 's|hybrid-portsrc-x86_32-v5_10_91_9.orig/||g'
mybox:~/hybrid_wl# sed -i broadcom-sta-5.10.91.9-linux-2.6.30.patch -e 's|hybrid-portsrc-x86_32-v5_10_91_9/||g'
mybox:~/hybrid_wl# patch -p0 <broadcom-sta-5.10.91.9-linux-2.6.30.patch
patching file src/wl/sys/wl_iw.c
Hunk #1 succeeded at 611 (offset 1 line).
Hunk #2 succeeded at 640 (offset 1 line).
Hunk #3 succeeded at 1119 (offset 1 line).
Hunk #4 succeeded at 1147 (offset 1 line).
Hunk #5 succeeded at 1807 (offset 1 line).
Hunk #6 succeeded at 1942 (offset 1 line).
patching file src/wl/sys/wl_linux.c
patching file src/wl/sys/wl_linux.h
mybox:~/hybrid_wl# patch -p0 < broadcom-sta-5.10.91.9-linux-2.6.30-2.patch
patching file src/wl/sys/wl_linux.c
mybox:~/hybrid_wl# sed -i hybrid-portsrc-x86_32-v5_10_91_9-convert_to_net_device_ops.diff -e 's|a/src/|src/|g'
mybox:~/hybrid_wl# sed -i hybrid-portsrc-x86_32-v5_10_91_9-convert_to_net_device_ops.diff -e 's|b/src/|src/|g'
mybox:~/hybrid_wl# patch -p0 < hybrid-portsrc-x86_32-v5_10_91_9-convert_to_net_device_ops.diff
patching file src/wl/sys/wl_linux.c
Hunk #1 succeeded at 225 (offset 6 lines).
patching file src/wl/sys/wl_iw.c

Compile the kernel module:
mybox:~/hybrid_wl# make -C /lib/modules/2.6.30-1-686-bigmem/build M=`pwd` clean
make: Entering directory `/usr/src/linux-headers-2.6.30-1-686-bigmem'
make: Leaving directory `/usr/src/linux-headers-2.6.30-1-686-bigmem'
mybox:~/hybrid_wl# make -C /lib/modules/2.6.30-1-686-bigmem/build M=`pwd`
make: Entering directory `/usr/src/linux-headers-2.6.30-1-686-bigmem'
LD /root/hybrid_wl/built-in.o
CC [M] /root/hybrid_wl/src/wl/sys/wl_linux.o
CC [M] /root/hybrid_wl/src/wl/sys/wl_iw.o
CC [M] /root/hybrid_wl/src/shared/linux_osl.o
LD [M] /root/hybrid_wl/wl.o
Building modules, stage 2.
MODPOST 1 modules
WARNING: modpost: missing MODULE_LICENSE() in /root/hybrid_wl/wl.o
see include/linux/module.h for more information
CC /root/hybrid_wl/wl.mod.o
LD [M] /root/hybrid_wl/wl.ko
make: Leaving directory `/usr/src/linux-headers-2.6.30-1-686-bigmem'

Install the new module:
mybox:~/hybrid_wl# cp wl.ko /lib/modules/2.6.30-1-686-bigmem/kernel/drivers/net/wireless/
mybox:~/hybrid_wl# depmod
mybox:~/hybrid_wl# modprobe wl

Check if everything loads correctly:
mybox:~/hybrid_wl# dmesg |tail
[ 66.229797] lib80211: common routines for IEEE802.11 drivers
[ 66.229805] lib80211_crypt: registered algorithm 'NULL'
[ 66.301793] wl: module license 'unspecified' taints kernel.
[ 66.301802] Disabling lock debugging due to kernel taint
[ 66.305919] wl 0000:02:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 66.305933] wl 0000:02:00.0: setting latency timer to 64
[ 66.406146] lib80211_crypt: registered algorithm 'TKIP'
[ 66.408646] eth1: Broadcom BCM4328 802.11 Wireless Controller 5.10.91.9
[ 76.524135] eth1: no IPv6 routers present

You can also chek the iwconfig output. Hopefully everything will be fine…
I hope this saves a few hours of searching and experimenting for some people…

References:
1) 802.11 Linux STA driver
2) AUR broadcom-wl 5.10.91.9-2
3) Gentoo Bug: 284450 (New ebuild: net/wireless/broadcom-sta)

Filed by kargig at 00:22 under Linux
Tags: 2.6.30, Archlinux, broadcom, bug, bugfix, debian, Gentoo, kernel, Linux, module, patch, wireless
9 Comments | 30,496 views

I’ve recently migrated on my debian from iceweasel (firefox) 3.0.X to swiftfox (firefox) 3.5b99 and I noticed that I could not import any new certificate authority root files. When I used a new profile everything worked as expected, so it was something that had to do with the migration of my old version 3.0.X profile to the new, version 3.5. It looks like there has been a modification in the way firefox 3.0.X and firefox 3.5 handles cert8.db file inside the profile directory. As soon as I deleted the file and restarted firefox I could import new certificate authority root files just fine. Of course I lost the old ones I had imported in the past…

Filed by kargig at 03:26 under Linux
Tags: bug, debian, firefox, Linux, migration, swiftfox
No Comments | 5,989 views

I’ve bumped into an Iceweasel + adblock plus bug: iceweasel: AdBlock Plus (1.0.2) custom element hiding filters does not work
It looks like Iceweasel from the stable branch of debian (version 3.0.6-1) has a problem hiding elements from websites. That makes some parts of adblock plus useless and ads start appearing on various websites.
What’s weird is that the problem only appears on Iceweasel and not on official Firefox (as the bug report says).

My options were to either a) switch to a testing/unstable version of Iceweasel from debian, b) get a binary package from firefox website or c) get another custom version. I chose method c) and I got swiftfox. Since Swiftfox provides a nice debian repo it was really easy to install and test. The whole experiment got even more interesting since swiftfox provides builds for firefox version 3.5…

After a update-alternatives --config x-www-browser I was ready to test it.
Swiftfox 3.5b4 works great with adblock plus and it even feels a bit faster. I can’t really tell for sure though. The only addon I had to reinstall was firegpg.

My impressions are great so far and I think I will keep it, at least until the bug mentioned gets resolved somehow on the stable branch.

Filed by kargig at 11:39 under Linux
Tags: adblock plus, browser, bug, debian, firefox, iceweasel, Linux, swiftfox
No Comments | 12,392 views

Firefox has the feature of keeping links to downloaded files as urls using the file:// pattern. For example: file:///home/user/downloads/test.zip. If you choose ROX-Filer (/usr/bin/rox) to open these files you will get an error:

File doesn’t exist, or I can’t access it: file:///home/user/downloads/test.zip

One way to correct the error is to follow the instructions of http://lovingthepenguin.blogspot.com/2008/08/use-rox-filer-to-open-containing.html

Another way for Gentoo users, and much proper I guess, is to use /usr/bin/roxuri. roxuri is actually a shell script that uses the “-U” option for ROX:

-U, –url=URL open file or directory in URI form

For the non-Gentoo users, /usr/bin/roxuri is:
#!/bin/sh
exec "/usr/lib/rox/ROX-Filer/AppRun" -U "$@"

Create it and make it executable.

Go to Firefox Preferences/Applications/Content Type -> file and select /usr/bin/roxuri as the default application.

Now files from firefox downloads are handled correctly by rox which uses the proper applications to open them and containing folders open up with ROX-Filer. That means that while “file” is handled by roxuri, a .pdf will be opened by epdfview or whatever else you have chosen ROX to open pdf files with.

Both solutions work on ROX version 2.8.

Filed by kargig at 18:17 under Gentoo,Linux
Tags: bug, file://, firefox, Gentoo, Linux, rox, tip
1 Comment | 6,949 views

It’s been a while since ivman stopped working on my Gentoo box but I never had the time nor the willingness to take a look into it. It appears that ivman is incompatible with some newer versions of hal and dbus. The good thing is that there’s an alternative, it’s called halevt and as far as I’ve taken a look into it the configuration options look quite straightforward.
For Gentoo, there are ebuilds for halevt on Gentoo bugzilla, which install just fine.

In my point of view there’s an issue here for Gentoo. Latest ivman (sys-apps/ivman-0.6.14) compiles just fine against all of its dependencies, but then it does nothing at all when a deviced is plugged in. If the devices are present when ivman starts then it can detect and mount them, if you plug the devices after ivman is started, then ivman does nothing at all. I think ivman is broken since hal 0.5.9.X versions. Gentoo developers stll keep ivman in the stable tree though. I find no real logic to this decision. Ivman is buggy with current stable hal and dbus. I would prefer a de-stabilization of ivman or even a package mask for it. What’s the point in keeping a package (ivman) in the stable tree since it requires not the latest stable but an older version of another package (hal) ? IMHO, since they correctly decided to stabilize hal 0.5.11-r8, which subsequently rendered ivman useless, ivman should be wiped from the stable tree.
Some bugs on ivman reported on Gentoo Bugzilla: http://bugs.gentoo.org/buglist.cgi?quicksearch=ivman

I once used ivman with a couple of custom scripts to create/remove icons of automounted devices on my ROX desktop. I think I can make these scripts work again with halevt…I am in the process of rewriting them. More on that in the following days…

Filed by kargig at 01:06 under Gentoo,Linux
Tags: automount, bug, bugzilla, Gentoo, hal, halevt, ivman, Linux, rox
7 Comments | 11,359 views

I am writing this post to provide some statistics on athcool + sata_sil usage. The results are horrible.

Athcool is a small utility, enabling/disabling Powersaving mode for AMD Athlon/Duron processors.
The homepage of the utility has a big fat warning as well:

WARNING: Depending on your motherboard and/or hardware components, enabling powersaving mode may cause:

* noisy or distorted sound playback
* a slowdown in harddisk performance
* system locks or instability

The Gentoo ebuild also has these warnings:

ewarn “WARNING: Depending on your motherboard and/or hardware components,”
ewarn “enabling powersaving mode may cause:”
ewarn ” * noisy or distorted sound playback”
ewarn ” * a slowdown in harddisk performance”
ewarn ” * system locks or unpredictable behavior”
ewarn ” * file system corruption”
ewarn “If you met those problems, you should not use athcool. Please use”
ewarn “athcool AT YOUR OWN RISK!”

Ignoring all these warning I was using athcool for years on my old desktop box filled with 2 IDE disks. Never had any real problem at all, except for a some performance loss. The problem appeared when I first used a sata disk on motherboard’s, Gigabyte GA-7VAXP-A Ulta, sata controller which uses the sata_sil module.
(more…)

Filed by kargig at 10:47 under Gentoo,Linux
Tags: athcool, bug, bug-report, bugzilla, dd, ext3, Gentoo, IDE, Linux, performance, powesaving, sata, sata_sil, vmstat
No Comments | 8,965 views