Disable HDMI Audio

Hey guys, I ran into another issue today that took me a few hours of troubleshooting before I came to a solution. I thought I'd share it with you guys today.

So after updating to 14.2 (64), I discovered that my default audio device was set to Nvidia HDMI. This is not what I want. I actually have a Sabretech 7.1 USB sound card, which I use to connect to my receiver via S/PDIF.

Sound was working correctly in Deadbeef (where you can manually set your soundcard in the application preferences), however that was the only application working as expected.

First, I went to the wiki and followed the instructions in the following article,"Sound problems in Sackware." As mentioned in the article, I added the following options in /etc/asound.conf:

# ALSA system-wide config file
# By default, redirect to PulseAudio:
#pcm.default pulse
#ctl.default pulse
  pcm.!default {
    type hw
    card 1
    device 0
    }
  ctl.!default {
    type hw
    card 1
    }

Note: the first two lines redirecting to pulse were already there. I decided to comment them out, since I don't want to use pulse audio.

This corresponds to my USB soundcard--card1, device 0. However, this did not result in any change. I added the same options to ~/.asound.rc in my users home directory. This did not result in any changes either.

Finally I stumbled up the following blog post. This basically explains that the Nvidia sound module depends on an Intel module being loaded--specifically, snd_hda_intel.

Upon checking lsmod, I confirmed that the snd_hda_intel module was indeed being loaded. I added an entry in /etc/modprobe.d/blacklist.conf to blacklist the module:

blacklist snd_hda_intel

Finally after rebooting, my sound was working as expected!

SSH not working across bonded hosts; notes on bonding

Hey guys I know its been a while since I post. I apologize about that. I moved into a new apartment, that took some adjustment. I'd like to make more posts as I'm working on quite a few new things.

Anyways, the purpose of this post is to share my notes on bonding. Previously I shared that I was using a dlink switch. Well, i've since upgraded to a Dell PowerConnect 2710. We use a few of these at my work--I was so impressed with how small and quiet the 2710's are, that I decided to use one at home. I bought a used one at Westech Recycler's for $10 bucks.

According to some research that I've preformed (I think its mentioned in the PowerConnect's documentation), the 2710 supports 802.3ad Link Aggregation Groups. So, for bonding purposes, thats mode=4.

As mentioned in the kernel's network bonding documentation. (In slackware64-current thats: '/usr/src/linux/Documentation/networking/bonding.txt'.)
        802.3ad or 4

                IEEE 802.3ad Dynamic link aggregation.  Creates
                aggregation groups that share the same speed and
                duplex settings.  Utilizes all slaves in the active
                aggregator according to the 802.3ad specification.

                Slave selection for outgoing traffic is done according
                to the transmit hash policy, which may be changed from
                the default simple XOR policy via the xmit_hash_policy
                option, documented below.  Note that not all transmit
                policies may be 802.3ad compliant, particularly in
                regards to the packet mis-ordering requirements of
                section 43.2.4 of the 802.3ad standard.  Differing
                peer implementations will have varying tolerances for
                noncompliance.

                Prerequisites:

                1. Ethtool support in the base drivers for retrieving
                the speed and duplex of each slave.

                2. A switch that supports IEEE 802.3ad Dynamic link
                aggregation.

                Most switches will require some type of configuration
                to enable 802.3ad mode.

So, I went ahead and used the ifenslave package I created (I will submit this to Slackbuilds as soon as the submissions are back up). Basically it just includes ifenslave.c (which as I mentioned in a previous post, ifenslave is no longer included in the current kernel due to the developers dropping it in support of a sysfs interface), and an rc.bond startup script I created:

#!/bin/sh
# rc.bond
#
# Diego Pineda
# 03/27/16

ip='192.168.0.211'
gw='192.168.0.1'
m1='00:16:3e:aa:aa:ab'
nmg='0.0.0.0'
        case "$1" in
          'start')
            echo "start bond0"
            #modprobe bonding mode=balance-alb miimon=100
            modprobe bonding mode=4 miimon=100
            modprobe tg3
            ifconfig bond0 up
            ifenslave bond0 eth0
            ifenslave bond0 eth2
            #TODO need to be changed
            ifconfig bond0 hw ether "$m1"
            ifconfig bond0 "$ip"
            route add default gw "$gw" netmask "$nmg" dev bond0
          ;;
          'stop')
            ifconfig bond0 down
            rmmod bonding
            rmmod tg3
          ;;
          *)
            echo "Usage: $0 {start|stop}"
          ;;
        esac

I've set this up before several times (as I've logged in my blog), but seeing as its been a few months, I was a little rusty. Everything seemed to be working fine, with the exception of some serious packet loss whenever I pinged the other bonded hosts. The packet loss would stop though against the gateway and normal web hosts. It was really bizarre, it was as if there was something going on with the bonding configuration I used.

I didn't stop to thnk that the problem could actually lie with my bonding configuration, until I started to jog my memory. I realized that I had actually solved this problem before, and the problem lies with my script.

Apparently, 00:16:3e:aa:aa:aa is the XenSource MAC prefix. Xen recommends its use because it will not conflict w/ any known hardware mac address. I feel this reason merits leaving the prefix here.

What I neglected to realize, in using the same scritpt, even though my two hosts each used different ip addresses (192.168.0.200 & 192.168.0.211 respectively), the script I used set each host to the same HW mac address:

00:16:3e:aa:aa:aa

I felt this merrited being mentioned, because the solution is so simple: I simply modified the mac address of the 2nd host to:

00:16:3e:aa:aa:ab

I'm ashamed to admit, it took me a good 4-5 hours to figure this out :)

Using a scanner in Slackware64-current: Lexmark x1270

So,

I have some books that need to go back to the library. I can't renew until I replace 2 books that got water damage (I spilled my drink in my backpack). So, all of my items are going to come due real soon.

The only problem: I got a bunch of cool (programming), books from the library--and I'm not ready to give them up!

Except I must return them--especially if I don't want to accrue any more fines.

__

I've been wanting to get a scanner for a while. I had no intention of paying full price for one at amazon.

In the united states, there exists a type of store known as: "Thrift stores." They specialize in the sale of used goods. However, in the United States, they have a special contract with the state government in which they operate, where individuals may recieve a "Tax refund," when they "donate," items which they no longer want.

This is an ingenious business model. The thrift store gets a inexhaustible supply of inventory, essentially for free. Furthermore, the population (generally middle-class and up), have incentive to donate (and thereby provide the supply), in order to receive a "Tax refund." (The person who donates gets a refund slip, come tax time, they can get the monetary value of there donated items back.)

So, I went to my local thrift store (Goodwill), and picked up a Lexmark x1270. I didn't realize until a few moments ago that this thing was made 9 years ago. However, my requirements were slim: I did not require the printer functionality, only the scanner.

The process is ridiculously simple: I simply plugged it in, loaded xsane, and I was able to scan!

$5 well spent :)

Diego

How to root QMV7A

Hello everyone!

I just recently obtained a semi-new/used tablet, which I have become quite fond of. I tried rooting the device using differnt methods I found online, but encountered some trouble in the process. Hopefully this guide will clarify the process.

Here is my device info (with the important info in bold font):

Model number: QMV7A
Android version: 
4.4.2
Baseband version:
ALT3100_04_05_06_00_94_TF
Kernel version: 3.4.67
wormboss@midgard #1
Sat Dec 20 01:00:16 CST 2014
Build number:
ALPS.KK1.MP5.V1
SW Version:
MV7A_41D37_442A
HW Version:
D3A

I utilized kingoroot for my method.

1.  Enable the "Unknown Sources," option in the following menu:
 - Settings > Security > Device Administration > Unknown Sources

2. Download the KingoRoot APK from the following link:
 - d.kingoapp.com/website/KingoRoot.apk

3. Open the downloads widget from the app menu and select the KingoRoot.apk file (confirm installation of file)

4. Select the Root button and start the rooting process

If rooting was succesfull, the progress bar should fill to %100 and you should see a message stating the device was succesfully rooted!

You can download an external app called "Root Checker Basic," or you can also verify root by installing a terminal app and attempting to SU to root :)

Diego

Linux Bonding Channel Driver, on Slackware P3

Basically, the bonding driver included in the stock 14.1 Slackware kernel (3.10.17), still supports using the ifenslave tool.

Unfortunately, there isn't a current slackbuild in either's Slackware official package repo nor the slackbuilds repository which has a Slackbuild for ifenslave.

So, you're left building it from scratch as described in the source file ifenslave.c (/usr/src/linux/Documentation/networking/ifenslave.c):

compile-command: "gcc -Wall -Wstrict-prototypes -O -I/usr/src/linux/include ifenslave.c -o ifenslave"

When I was initially attempting to use the bonding driver, it was on my Poweredge 750 (arch: i686). For whatever reason, I could never get this source file to actually compile the binary ifenslave w/o encountering a build error.

This prompted me to look for an alternative. All the documentation I've seen in setting up bonding in Slackware walk you through this step first. In the major distros, ifenslave is either already included in the official repository, or bonding is integrated into the init script.

After some searching I finally came across an alternative: Vincent Batts posted a Slackbuild for ifenslave! It was hidden in the discarded directory, I believe it was for Slackware 12. It built just fine on my system!

(I later discovered what Vincent employed in his Slackbuild that actually allowed me to build ifenslave properly on my 14.1 x86 poweredge: the arch variable wasn't set via a case statement tied to uname--as is normally done-- it was hardcoded to 386.)

I was able to load the binary, initialize a bonded interface w/ ifconfig, and successfully utilized ifenslave to set the slave interfaces under the bond.

I've received Vincents permission to become the maintainer of the Slackbuild for the current release. I've modified it w/ enough core functionality to enable a Slackware installation to easily configure bonding. My difficulties in my journey to enable bonding in Slackware compelled me to create a solution that would bring this much needed functionality into Slackware into a simple installable package.

However, there is a caveat. Mainly, the current version of the Linux Bonding Driver (in the current stable kernel), no longer officially supports ifenslave--its use is now considered obsolete. This is sad, because the dev's reasoning is that a) most distro's include bonding functionality in the init scripts (a la RHEL), or b) in lack of such support you can always rely on creating a bond via the sysfs interface (/sys/class/net/bondX).

That being said, Slackware 14.1's kernel (3.10.17), still uses the older bonding driver, which supports ifenslave.

In fact--the current bonding driver doc mentions ifenslave will still function w/ the bonding driver and can be utilized. They just no longer support it and are in favor of the sysfs interface instead (which actually does provide more functionality in the bond initialization process).

So, I realize there is a need for this Slackbuild, although it will only be useful to a small audience (14.1). I'm not sure which kernel current is using, or if the bonding driver in that release still supports ifenslave or not.

Edit: I just checked kernel 3.14.29 (utilized at the moment in current); this kernel utilizes the updated bonding driver which does not officially support ifenslave.

To continue on though, ifenslave isn't the only thing we need to overcome in slackware. Sure, you could create a bond manually by simply:

 - initializing the bond via ifconfig
 - designating the slave interfaces via ifenslave
 - adding the route for the bonded interface into kernel routing table manualy

However, if you want a bonded interface to be created during the boot/startup process--because rc.inet1 includes no functionality for bonded interfaces--you will need to either add the bond initialization commands into rc.local, or the better solution in my opinion, create another rc.d init script. (Note: this will require executable permissions, i.e. chmod 775.)

#!/bin/sh
# rc.bond

        case "$1" in
          'start')
            echo "start bond0"
            #modprobe bonding mode=balance-alb miimon=100
            modprobe bonding mode=0 miimon=50
            modprobe tg3
            ifconfig bond0 up
            ifconfig bond0 192.168.0.210 netmask 255.255.255.0
            ifenslave bond0 eth0
            ifenslave bond0 eth1
            #TODO need to be changed
            ifconfig bond0 hw ether 00:16:3e:aa:aa:aa
        route add default gw 192.168.0.1 metric 1 bond0
          ;;
          'stop')
            ifconfig bond0 down
            rmmod bonding
            rmmod tg3
          ;;
          *)
            echo "Usage: $0 {start|stop}"
          ;;
        esac
#EOF

Credit for the original rc.bond script goes to Mehdi Sadighian.

The bonds' IP & Netmask, and the gateway IP, will need to be changed to reflect your network.

My only modifications were adding the route command to add the default gw.

Also: make sure you modify the HW mac address if you intend to:
 - make multiple bonds on the same system w/ this script
 - utilize this rc.bond script on multiple systems in the same LAN (or VLAN).

When I first tested this out, I had just initialized a bonded interface on both of my servers in my lan, however I was stumped when my attempt to ssh into either system would time out. After digging I realized the HW mac address was the same for both systems in each LAN. Once I ensured each system had a unique MAC, ssh returned to normal and everything was right once again in the LAN.

Apparently, 00:16:3e:aa:aa:aa is the XenSource MAC prefix. Xen recommends its use because it will not conflict w/ any known hardware mac address. I feel this reason merits leaving the prefix here.

I've experimented w/ modifying rc.inet1.conf to include a bonding statement but... it doesn't quite work right. For one, that isn't the proper file to modify, since its sourced by rc.inet1 (which is the rc script that should be modified). 2, every time you run the rc.inet1 script--to start, stop, restart, doesn't matter--because rc.inet1 always sources rc.inet1.conf, it will call rc.bond regardless of the subcommand you pass to it. So when I shutdown my network the rc.bond script would initiate.

I suppose a work around would be to modify the case statement to only source rc.inet1.conf during network initialization.. this may be something to consider, still its really only a hack. 

Honestly, even if the network stack stops, it isn't a problem if the rc.bond script initializes.. This can be seen as a good thing, you'll know none of the slave interfaces will accidentally be initialized w/ a ip address and route attached. (BTW--the documentation does list that as a known problem to watch for.)

However, as you've seen from my previous modifications to rc.inet1.conf, I've added sections for dns and hosts file settings, which now makes rc.inet1.conf more valuable to me. Valuable enough to not want initialize a bond w/o these settings being enabled.

So for now, if you want your system to startup w/ a bonded interface, the simplest solution is to create the rc.bond script I showed above, modify the bond to reflect your network (or add additional bonds), and finally add the following to rc.local:

/etc/rc.d/rc.bond start

In the slackbuild, I plan to include ifenslave tool, a sample rc.bond script to modify (like the one above), and a readme explaining the above.

In the future I will create a slackbuild that will actually utilize the sysfs interface instead, and thus be a supported method of bond creation, which will hopefully bring some cool features too.

Linux Bonding Channel Driver, on Slackware P2

So, I've been trying to get this to work for.. shit since October 2014, no success until now.

First, I tried bonding interfaces w/ my unmanaged HP Procurve2724 16 port gigabit switch. No Luck.

I figured I should look into a managed switch, hopefully LACP functionality will be present.

So I headed to my favourite place (Westech Recyclers--Resell Electronics), and picked up a D-Link DGS-1248T for a whopping 10 buckaroos. (Apparently a steal, this thing retailed for 300-600 new, holy cow.)

So I had a made a big misunderstanding in my research: the "trunking functionality" being described in the Linux Bonding Driver documentation as , well, compatible w/ 802.3ad!

What I didn't realize in my eagerness, I looked at the modes and chose 802.3ad (mode=4), as the one I wanted to use.

What I didn't realize, 802.3ad--which utilizes LACP--is a IEEE draft specification completely different than trunking.

In fact, I didn't know what Trunking really meant. I knew it was described in the Bonding Driver documentation, and that it was supported by my switch (DGS 1248T). When I reffered to the switches documentation, it wasn't descriptive in the least bit:

"The Trunk function enables the Switch to cascade two or more devices with larger bandwidths."

Devices? You Mean ports? Or Devices as in switches? Is this meant to trunk switches or ports? I was royally confused.

So here I was, spinning my wheels, for weeks, trying to get mode=4 w/ the DGS-1248T. I wasn't using VLANs, I simply enabled two groups of ports: one for my main system, and one for my other storage server.

Whenever I enabled the bond, I added the default gw route on the bond, but it would never reach the gateway. The command would time out. Actually it did work twice, but it would not work after reboots nor after disableing and re-enabling the bonded interface.

I was stumped. What is going on?

Finally, after reading a post on LQ forums regarding another users experience w/ this switch and bonded interfaces--specifically, his bonds were working! I thought--no way, how?

He wasn't using mode=4. He was using mode=2 (Balance-xor).

I decided to try it. In my system, I decided to use mode=0--Balance-rr. I was now able to add the default gw route on the bond! And I could communicate to the lan and internet!

I determined that the bond was initalized correctly and functioning on both of my servers (HP G5 ML350, and a poweredge 1850). Both bonded interfaces could send and recive on the lan and internet.

I still didn't understand why. It wasn't until I was looking at the Bonding Driver documentation this evening, that I realized why:

Requirements for specific modes:

... The Switch must be configured for "etherchannel," or "trunking," on the appropriate ports.

As I later discovered, etherchannel is Cisco's proprietary implementation of link aggregation which predated the 802.3ad spec. Furthermore, because etherchannel is cisco proprietary technology, the trunking variants seen in other mfg's switches must be that manufacturers implementation/etherchannel variant.

In other words, the only things they really lose is support for ISL and VTP, both Cisco proprietary technologies anyways.

The main reason I went through all this trouble was to determine first hand whether there was any measurable speed increase in using bonding.

I made a simple test, basically I transfered a large file over a single gigabit (via mounted nfs directory and using a simple copy).

As I've read--and discovered in my own experience--although the theoritical maximum transfer rate for a gigabit interface is 125MB/s, the real transfer rate is much slower. The reasons vary considerably, but generally mechanical drives are the main cause of the bottleneck (followed by system load or network traffic). In other tests that I've seen test a true gigabit transfer rate on a system, they utilized a ramdrive. So, for this test I created a 2 GB ramdisk via the newer tmpfs. I then copied the large file (1.5GB mp4), over the NFS mounted locally (hosted of second server also using bonded interface), to the mounted ramdisk filesystem (mounted as tmpfs and using tmpfs filesystem).

I then reran the same test, using the bonded interface w/ mode=2 (balance-rr).

The results did not dissapoint!

Transferred 1.5GB mp4 file over locally mounted nfs (hosted on secondary server), to tmpfs mounted filesystem:

1GB NIC Transfer:  50 MB/s

Bond0 (dual 1G NIC slaves): 94 MB/s

The bond transferred nearly twice as fast!

Linux Ethernet Bonding Driver, on Slackware P1

I've been wanting to utilize the Linux Ethernet Bonding Driver in my lab since I got my hands on a few managed switches that would support trunking. However, although I've bonded fiberchannel HBA network interfaces for our clients servers when I was a Linux Admin (all of the systems in the Phoenix AZ co-location were internetworked using 8g Fiberchannel interfaces. (Storage array's utilized 16G FC, as well as the core infrastructure switches which the clients environments were hosted on.)

However, this was mostly on RHEL 6 systems, some SLES, one (or two Ubuntu servers), and Oracle Enterprise Linux--Oracle's RHEL clone which now goes by Oracle Linux (probably to avoid confusion).

I have to say the majority of the systems I managed w/ RHEL, w/ Oracle Linux coming second. Most of the Oracle Linux systems were actually full blown virtualization servers, utilizing Oracle's proprietary virtualization platform--Oracle VM Server. (Unlike the opensource VirtualBox, VM Server is Oracle's customized version of Xen. In fact all of the Oracle Linux systems were running VM Server to host the clients systems.

Anyways, enough reminiscing. That didn't really help in my current endeavor. Although RHEL has functionality in the /etc/sysconfig/network file to recognize and initiate bonded interfaces, Slackware is not quite there.

In fact according to my findings, there is no built in functionality at all in the network init script--/etc/rc.d/rc.inet1.

So, taking a look at /etc/rc.d/rc.inet1, we can figure out what is going on when the network is initialized. Basically, the author created a few main functions: read network config file (rc.inet1.conf), create logs in system logfile (/var/log/messages), determine interface list (while loop w/ incremental array variable to differentiate between eth0 or eth1), loopback functions (initialize loopback interface), interface functions (the real enchilada of the script--br_open, br_close, if_up, and if_down), gateway function (route command initializes gateway defined in rc.inet1.conf), and finally the main function (case statement which defines the network scripts subcommands: start, restart, up, down, etc...

So, we have to look into the interface functions, specifically if_up. We really don't have to look at the whole thing line by line, simply skimming it will reveal that there is no functionality inherent in this script to initialize a bonded interface as is done in RHEL.

If Slackware is going to really be considered a Server OS, we need to modify this as soon as possible. I've hacked up my own work around, but am not confident in modifying the rc.inet1 network script enough that it will be fullproof (error free, or prone to wacky behavior). I'm willing to try (believe me I've started), but I feel this issue needs to be evaluated by Slackware team (Pat, Rob, Eric, Sudayo, I hope someones reading this.) This could easily be solved by adding function specifically for initializing a bonded interface in the interface functions, and even more important, that rc.inet1.conf can recognize a bonded interface and pass those variables to the main enchilada (rc.inet1).

I've been tried adding my own functions, but I keep overlooking some important steps.. mainly, how to differentiate between whether the script defines a bridge interface (must be created first), or a bonded interface, or if it wishes to bridge a set of bonded interfaces, or if there are no bridges and only bonds are used, to initialize those first while ensuring the slave interfaces are left disabled.

I've considered looking at redhats network init script for ideas, but as I've confessed, I am not confident any modifications I create would work properly.

I really hope the Slackware team considers this suggestion, and realize that it would benefit a large target audience--servers specifically--and aid in Slackware's adoption as a server OS. Especially w/ the RHEL crowd.

____

To be continued...

modifications to /etc/rc.d/rc.inet1.conf

Hey everyone, just thought I'd share my modifications to /etc/rc.d/rc.inet1.conf. These are pretty simple, but very effective in my opionion.

Basically, I really had to learn the hard way the importance of /etc/resolv.conf, and how to set a hostname. I really don't like how you have to hunt in order to get these settings in place. In my opinion, editing a textfile by hand is fine, but doing it all in one place is simpler than going to different files.

Then again, people may view this as an abomination, and respond by saying things should be kept the old way. Take a look and let me know what you think :)

# /etc/rc.d/rc.inet1.conf
.

.

.


# Set hostname

# This will set your hostname as defined in /etc/hosts.
# This only works if you have a properly defined /etc/hosts file.
# In order for these settings to take effect, after properly modifying
# /etc/hosts, you must restart network (/etc/rc.d/rc.inet1 restart),
# exit your current shell, and log back in--or log in to a new shell.
# Please refer to man /etc/hosts for more information.

hsts=$(cat /etc/hosts | grep 127.0.0.1 | egrep -v 'localhost|Arnt' | cut -f 2)
if [ -n $hsts ]; then
        HOSTNAME=$hsts
    hst=$(echo $hsts | sed 's/\..*//')
    echo $hsts > /etc/HOSTNAME
    echo $hst > /etc/HOSTNAME_S
    hostname -F /etc/HOSTNAME_S
fi

# Config information for eth0:
.

.
# Default gateway IP address:
GATEWAY=""

# DNS Settings

# Either run dhcpd once to create a temp /etc/resolv.conf and copy values
# below, or get the values from your ISP / Router / Modem.
# Uncomment nameservers as necessary for your network.
domain=ph.cox.net
nameserver1=192.168.0.1
#nameserver2=68.105.28.11
#nameserver3=68.105.29.11

# Create resolv.conf

# Uncomment nameservers as necessary for your network.
if [ -x /etc/resolv.conf ]; then
 echo "" > /etc/resolv.conf
else
 touch /etc/resolv.conf
 echo "domain $domain" > /etc/resolv.conf
 echo "nameserver $nameserver1" >> /etc/resolv.conf
#echo "nameserver $nameserver2" >> /etc/resolv.conf
#echo "nameserver $nameserver3" >> /etc/resolv.conf
fi


So basically, to summarize, skip the comments and the ethernet section (those are still there but you know what it looks like). The parts I added was the hostname section, the DNS settings, and creating resolv.conf. These easily make resolv.conf for you when rc.inet1 is being run--in other words when network is being brought up. The hostname according to the hostname manpage is supposedly also setup when rc.inet1 is ran, but it doesn't accept changes to /etc/hosts on the fly. I didn't like this, which is why I modified rc.inet1.conf as such.

This script requires you to have a properly modified /etc/hosts, like such:

# For loopbacking.
127.0.0.1    localhost
# This next entry is technically wrong, but good enough to get TCP/IP apps
# to quit complaining that they can't verify the hostname on a loopback-only
# Linux box.
127.0.0.1          bpm37093.centauri.net          bpm37093  
192.168.0.200   beta.centauri.net                    beta
192.168.0.210   v766.centauri.net                    v766
192.168.0.220   bpm37093.centauri.net          bpm37093    

The nice thing about adding this section is that, you can have your hostname update on the fly, all you have to do is restart the network (/etc/rc.d/rc.inet1 restart), and then make sure to exit and log back in to your shell/ log in to a new shell. And viola! Your hostname will now show up :)

The DNS settings, well ... the easiest way to get those is to either run dhcpd once--which will auto generate a resolv.conf for you. Once you have those settings  you can populate the DNS settings sections with what is suitable for your network.

Alternatively you don't have to run dhcpd. You can just get the settings from your router, or modem, and go from there.

Also, you may not need as many nameservers. Simply uncomment the appropriate nameserver variables/ echo statements as neccessary for your network. Also, you can add additional nameservers, you just have to add another nameserver line in the dns section and an extra echo statement in the resolv.conf section. However 3 is more than enough (2 is generally what most ISP's use, the 3rd is for your router if it supports it).

Below are links to the modified /etc/rc.d/rc.inet1.conf file and an accompanying md5 file (so you can sure what youre downloading isn't some bullshit garbage:b).
 - rc.inet1.conf - modified: http://www.datafilehost.com/d/57b5c9f0
 - rc.inet1.conf - md5sum: http://www.datafilehost.com/d/86fc1021

Mozilla Firefox 35: Profile Guided Optimization

While inspecting the Firefox SlackBuild, I noticed it had an elif statement dedicated to PGO (Profile Guided Optimization):

if [ "$ARCH" = "x86_64" ]; then
  PGO=${PGO:-yes}
else
  PGO=${PGO:-no}
fi

This feature is mentioned in the SlackBuild bundled w/ the 24.1.0 extended support release (i.e. the stock 14.1 package). I decided to investigate and see what this fuss is about.

From Mozilla's FAQ:

"The Mozilla build system contains support for building with Profile-Guided Optimization (PGO) with GCC 4 or newer and Microsoft Visual C++ 2005 (Professional Edition) or newer. A PGO build consists of two passes: a first pass to build instrumented binaries, then a second pass to re-build optimized binaries using profile information gleaned from running the instrumented binaries. The Mozilla build system will run both passes for you, as well as a profile generation script in between."

From Wikipedia's page on PGO:

"Optimization techniques based on analysis of the source code alone are based on general ideas as to possible improvements, often applied without much worry over whether or not the code section was going to be executed frequently though also recognizing that code within looping statements is worth extra attention.

The first high-level compiler, introduced as the FORTRAN Automatic Coding System in 1957, broke the code into blocks and devised a table of the frequency each block is executed via a simulated execution of the code in a Monte Carlo fashion in which the outcome of conditional transfers (as via IF-type statements) is determined by a random number generator suitably weighted by whatever FREQUENCY statements were provided by the programmer. ^[3]

Rather than programmer-supplied frequency information, profile-guided optimization uses the results of profiling test runs of the instrumented program to optimize the final generated code.^[4][5] The compiler is used to access data from a sample run of the program across a representative input set. The results indicate which areas of the program are executed more frequently, and which areas are executed less frequently. All optimizations benefit from profile-guided feedback because they are less reliant on heuristics when making compilation decisions. The caveat, however, is that the sample of data fed to the program during the profiling stage must be statistically representative of the typical usage scenarios; otherwise, profile-guided feedback has the potential to harm the overall performance of the final build instead of improving it."

I decided to compile Mozilla Firefox 35 w/ PGO enabled. It took approximately 4 solid hours to compile along with 8GB of disk space.

I decided to run some tests of my own to determine the validity of this optimization hype. A quick Google search for the term "browser benchmark," led me to futuremark's peacekeeper browser benchmark:

 http://peacekeeper.futuremark.com/

Peacekeeper tests a variety of operations, including:

 > Rendering: manipulate DOM tree in real-time.
 > HTML5 - WebGL: MJS Matrix/Vector package.
 > HTML5 - Video: tests supported video formats.
 > HTML5 - Web Worker: tests javascripts multithreading.
 > HTML5 - Game: 2D sprite game (modified version of Crafty). Sprites increase as test progresses to increase load.
 > Canvas: HTML5 Canvas.
 > Data test suite:
 > DOM operations: the Document Object Model Javascript API.
 > Text Parsing:

(A detailed explanation of the tests ran in the benchmark suite can be found at the following link.)

The results were very revealing! 

 - Mozilla-Firefox-35.x86_64:                             3521 Points
 - Mozilla-Firefox-35.x86_64.pgo-enabled:       3724 Points

(The above links provide the detailed results for each package.)

That settles the argument: Firefox compiled w/ profile guided optimization has a measurable performance gain.

I am currently using the pgo-enabled Firefox build and will continue to do so unless it: creates a security risk, introduces regressions, or breaks future builds.

I have provided a PGO-enabled Firefox package for those of you who want to try it out and don't want to invest the time (and disk space), to compile:

 -> mozilla-firefox-35.0.pgo-x86_64-1.txz
 -> mozilla-firefox-35.0.pgo-x86_64-1.md5

I encourage you guys to try out the PGO-enabled build on your systems and run through the peacekeeper benchmark! I'm very curious to see any differences in performance! Also, I know I haven't provided a x86 (32bit), build yet, that will follow soon for both the vanilla firefox-35 and the PGO-enabled build!

*Also, I am asking my readers a huge favor: if anyone has an ftp, a repository, or server where I can upload these packages, I would greatly appreciate any input! These packages deserve a proper home!*

Diego

Mozilla Firefox 35

Mozilla is currently on version 35 of firefox, and slackware current is on 34. I was aghast when I realized that I was still using version 24, and even more so when I realized that 14.1 had officially upgraded to 31 (extended support release).

I compiled version 34 and installed it in my system (14.1 x86_64), and then decided to try out 35. I grabbed the source from mozilla's ftp and built it against the slackbuild provided in current for version 34.

So far it works great! No issues whatsoever. I am currently re-compiling w/ pgo support enabled. Although pgo was enabled in the slackbuild by default in version 24 (stock 14.1 release), it has since been disabled in current. As mentioned in the comments it has definetely more than doubled the compile time, but I'm sticking it out to see if there is any performance enhancement with pgo enabled.

Below is a link I've provided for the lazy who wish to try out the latest (& greatest), Mozilla Firefox release 35 on there systems (and don't want to wait the hour or 2 to compile)!:

mozilla-firefox-35.0-x86_64-1.txz:
 - http://www.datafilehost.com/d/3ebe4440

mozilla-firefox-35.0-x86_64-1.md5:
 - http://www.datafilehost.com/d/2bd93007


I will build an x86 for on my poweredge later this evening. Stay tuned!

My first commit to Slackbuilds

This is my first commit to Slackbuilds! Not a very big contribution, but very cool nonetheless! Every little bit counts!

Robby Workman commit a2ecf74a7618ecd1341a70006af9d50bbb8bcf05
Author: Robby Workman <rworkman@slackbuilds.org>
Date: Wed Oct 15 16:39:32 2014 -0500

multimedia/flashplayer-plugin: Updated for version 11.2.202.411.

Thanks to Diego Pineda.

Modification to rsync_slackware_patches.sh

On the Slackware docs page, in the beginners_guide--Watching for updated packages section--I noticed a flaw/feature/something I didn't like in the example script provided. Just a simple mod really. The script by default has the arch hardcoded, when honestly it would be better pulled from the system.

There is the option to set the arch to something different, which is fine if you want to rsync for a different arch than whats on your system (say have a local copy for another machine at your employ), but I believe it should have been set to the following:

# What architecture will we be mirroring? The default is 'x86' meaning 32bit.
# Alternatively you can specify 'x86_64' meaning 64bit. The value of SARCH
# determines the name of the slackware directories.
# This value can be overruled via the '-a' commandline parameter;
SARCH=${SARCH:-"x86"}

It should be changed to this:

SARCH=$(arch)

This will set the correct arch according to what your system has. Using the case statement -a switch will also allow you to set it should you need to still.


Links:

http://docs.slackware.com/slackware:beginners_guide

rsync_slackware_patches.sh - original

rsync_slackware_patches.sh - modified

Regular Expressions

I suck with regular expressions.

I'm always finding myself in the situation where I am using google to try and find a solution to an answer.

So, today I was trying to figure out an expression to use in a script when, I stumbled upon the following site:

http://www.regexr.com/

The nice feature of this site: it allows you to test your expression on the fly, and show you your results on the site.

Interactive learning at its best. I was actually able to figure out the regex I needed after testing a few combinations.

Diego

Updating timestamp across filesystem

So my poweredge 750 still believed it was 2004. After updating the system time, I realized my x86 Slackware 14.1 install had all of the files installed with timestamps from 10 years ago. This is not good, and will make your computer blow up with a bunch of wierd errors. So I had to resolve to the ancient fighting art of bash fu to resolve it:

boot to install disk:

mkdir /foo

mount root partition to foo (in my case R0 array)

mount /dev/md1 /foo

mount dev, proc, and sys via bind mountpoints. First define temporary variable:

a='dev proc sys'


and then apply the following for loop:

for i in $a; do mount --bind /$i /foo/$i; done

I almost forgot to add this; you need to chroot into foo:

chroot /foo

Since we want to update all directories with the exception of dev, proc, and sys, we can make another variable containing all root sub directories except the ones we've mounted via --bind, and update the timestamps on the results.

I wrote the following script to accomplish this task:

#!/bin/bash
# update timestamp.sh

b=$(ls / | egrep -v "dev|proc|sys")
for i in $b; do
cd /$i && find . -exec touch -h {} \;; \
done

exit 0
‪#‎EOF‬

Notes:

It is important to update the hwclock of the system prior to running this script, otherwise it will keep whatever time was on the BIOS. If your system can access the rtc device, you can update via hwclock:

hwclock --set --date "11/23/2014 13:50:30"

at which point you can update the system time via:

hwclock -s

I've tried this script once before w/o the -h switch, but it screwed up my system. It updated all the timestamps on files great, with the exception of the important ones--symlinks. Think vmlinuz.. right. 

With the -h switch however it ran great and everything was good to go.

(I originally shared this in late august on my fb page, but realized it would be better served here since I only have like 4 friend in RL that understand Linux.)

Links:

http://www.linuxquestions.org/questions/linux-general-1/update-time-stamp-during-mount-4175520145/

Notes:

 - November 23, 2014: I realized that the script wouldn't run as it was written. The for loop needs to be changed from:

for i $b; do 
cd /$i \
find . -exec

to:

for i in $b; do
cd /$i && find . -exec touch -h {} \;; \

the 2nd iteration forces the find/touch command to be executed upon completion of the initial change directory command.

CCISS on Slackware 14.1

So I'm going to fast forward a bit, I want to share this because its important. I needed a decently modern system for work, and this time I was willing to shell out extra for it. I found a Gen5 HP ML 350, a dual proc mobo w/ 1 quad core X5355 Xeon, 8Gb Ram, 2x 15k 3G SAS drives, which I got for 150. I had to use Windows 7 on it for work purposes, but I finally was able to get rid of it and load up Slackware 14.1 x64.

After I bought the system I bought a couple extra SAS drives. I currently have 4x 15k 73.4 GB 3G SAS drives. This system has a HP Smart Array E200i SAS Controller. Although the huge kernel loads both hpsa and cciss, the system auto defaulted to using cciss.

I wanted to try out hardware raid in this install. So in the Smart Array ROM BIOS, I created a single logical array (drive), using all four disks, into a single RAID 0 array. No redundancy at all in this scenario--I know, but thats ok.

(I have a few emulex adapters I'm planning to setup a SAN with and setup a chron to periodically rsync to my storage server throughout the day, so i'm not concerned.)

CCISS is HP's deprecated block driver, which has since been replaced by HPSA which is a SCSI driver.

So, when you see your devices in the system, they are shown under /dev/cciss as such:

bash-4.2# cat /proc/partitions
major minor  #blocks  name

 104        0  286617757 cciss/c0d0
 104        1    8388608 cciss/c0d0p1
 104        2    4194304 cciss/c0d0p2
 104        3  274033821 cciss/c0d0p3

So c0d0 is the 1st logical drive the controller sees, and the partitions are listed as such.

bash-4.2# fdisk -l

Disk /dev/cciss/c0d0: 293.5 GB, 293496583168 bytes
255 heads, 32 sectors/track, 70249 cylinders, total 573235514 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x73841e94

           Device Boot      Start         End      Blocks   Id  System
/dev/cciss/c0d0p1            2048    16779263     8388608   82  Linux swap
/dev/cciss/c0d0p2        16779264    25167871     4194304   83  Linux
/dev/cciss/c0d0p3        25167872   573235513   274033821   83  Linux



So when I run through the installer, I used the partition layout shown above, and thought everything was peachy until I got to the end, after rebooting, was stuck in an infinite loop where my system didn't know what to boot.

This comes down to a lilo configuration issue.

I essesntially followed the directions given by Nasser here:
http://linax.wordpress.com/2009/09/26/slackware-boot-on-cciss-dev/

but, the layout he describes didn't work for me. In his directions, he designates the boot= directive to a partition.

I found you have to designate the boot directive to the logical disk. In other words:

boot = /dev/cciss/c0d0

Afterwards simply follow the steps as given by Nasser. Here is a step by step:

1. Run through setup as normal. Partition disks as you see fit.
2. Setup Lilo as normal. We will edit it after installation is complete.
3. Post Install--Modify Lilo:

chroot /mnt

and edit lilo.conf to ensure boot designates the logical disks your partitions reside on, i.e. 

boot = /dev/cciss/c0d0

4. Install Lilo

lilo -M /dev/cciss/c0d0 mbr
lilo

Here is my lilo.conf which got my system to finally boot (I am in fact using this system to make this very post):

# LILO configuration file
# generated by 'liloconfig'
#
# Start LILO global section
boot = /dev/cciss/c0d0

#compact        # faster, but won't work on all systems.

# Standard menu.
message = /boot/boot_message.txt

# Append any additional kernel parameters:
append="root=/dev/cciss/c0d0p3 vt.default_utf8=0"
#prompt
#timeout = 5
# Normal VGA console
vga = normal
# Ask for video mode at boot (time out to normal in 30s)
#vga = ask
# VESA framebuffer console @ 1024x768x64k
# vga=791
# VESA framebuffer console @ 1024x768x32k
# vga=790
# VESA framebuffer console @ 1024x768x256
# vga=773
# VESA framebuffer console @ 800x600x64k
# vga=788
# VESA framebuffer console @ 800x600x32k
# vga=787
# VESA framebuffer console @ 800x600x256
# vga=771
# VESA framebuffer console @ 640x480x64k
# vga=785
# VESA framebuffer console @ 640x480x32k
# vga=784
# VESA framebuffer console @ 640x480x256
# vga=769
# ramdisk = 0     # paranoia setting
# End LILO global section
# Linux bootable partition config begins
image = /boot/vmlinuz
  root = /dev/cciss/c0d0p3
  label = s14164
  read-only  # Partitions should be mounted read-only for checking
# Linux bootable partition config ends

Further reading:

http://cciss.sourceforge.net/

Adventures in 2014

So when I decided to move back into my folks place, it was the smartest move I've made at that point in 2014. Its expensive living on ones own. Furthermore I've been making plans on finally making use of my A.S. degree and transferring to a 4 year degree program. I've already hashed out the details with a guidance counselor at ASU's Ira A. Fulton School of Engineering. Basically I'm going to go for a B.S in Computer Science, or a B.E in Computer Engineering, or both. Really its the difference in the theory of computer science or a few applied courses in microcontroller programming. Honestly both sound awesome. (Thats been my biggest problem in school--I want to learn everything.)

In light of my plans of continuing my education, living off of my folks--I meant, living with my folks! Makes plenty of sense. Ahem.

While mosing about on my travels unfortunately I had to sell most of my possesions just to get by (its expensive living on ones own, and especially hard when your unemployed). So, first item on my agenda was obtaining a decent computer of sorts. So I hit craigslist with a bloodthirst.

(Up to this point I had been doing my programming stuff via a shell account I purchased at xshellz at Tempe Library via putty. This actually worked out quite well. The shell account cost 4 buckaroos.)

I've been hooked on the idea of getting a server since I first purchased a Gen3 HP ML350. The thing was a monster, it had dual core 32 bit Xeon processors (it was the last line of processors Intel made prior to including emt64), but it supported up to 12 GB of ram (which I maxed out--and made use w/ PAE). It also had a 6 bay SCSI bay. The system I bought actually came loaded w/ 6 SCSI drives. I bought it at the time (2010-11ish?), for a whopping 50 bucks. The dude I bought it from was some 20 year old kid who was most likely was cleaning old stuff out of his parents garage and was eager to figure out how to afford his next 8th of kind buds. I've seen the same server, and ones w/ similar specs, being sold for up to 200 bucks on craigslist. After spending 50 on the Gen3, I'm looking at their asking price thinking, "these guys are nuts."

I was hoping to get an HP. However after my stint at GoDaddy I had some hands on experience w/ Poweredge servers. So I decided to widen my horizens and look into Dell's stuff. My price range: 50-100 bucks.

I finally found a guy that had an awesome deal: Poweredge 1850, dual proc, 4Gb Ram, $75. That is a great deal. However I only had 50 bucks to spend. I sent the guy an email, and thankfully he was willing to work with me. But get this, that wasn't even the coolest part. I bought the server, and it came fully loaded w/ 6 10k7 SCSI drives! Before I left he also threw in a Poweredge 750!

So I got two servers, at the discounted price of 50 bucks! I don't think I can ever beat that! Thanks to the awesome dude who shall remain anonymous, rest assured he is indeed awesome!

Wireless Repeater via DD-WRT

Currently listening to: Deftones, Diamond Eyes album 2010.

For those of you who just want the meat of how to setup ddwrt, and don't give a damn about my little story, scroll down until you see the screenshot and start reading the paragraph above that. (Oh, and screw you!)

So, the turion lappy (who I've happily named neptune64), is temporarily being held hostage by a group of mexican thugs (no, seriously). (Well not quite hostage but they've requested a ransom--at a modest price, so I can't complain. Ah the perils of the physical world).

This leaves me entirely dependent on my old celeron lappy (which was meant to be purposed as a server; in fact, this was the system I setup to host a pxe server and nfs). My Celeron lappy, which I've happily named centauri, has a Family 15 cpu, Model 2, Stepping 9, 128KB cache, 2790.8 mhz, which I recently upgraded from 256MB of PC2700 ddr, to 512 MB at PC2100 (sure 2700 is faster, but twice the ram is much faster!). When I have money I'll upgrade this sucker to 4GB. Too bad there aren't more ram slots or I could use Physical Address Extension (PAE).

As I somewhat explained in a previous blogpost, centauri has a problem with the internal wireless adapter (bcm4306). Whereas before the BIOS would boot stating a IRQ resource conflict with the bcm4306 as the culprit, now lspci -v fails to even show the device present in the system). So, attempting any software hacks will definetely not work at this point--we need a new physical solution.

So, sometime in the past 7 years I came across a Linksys WRT54GL. I rarely used it, as I would rely on my 5-port gigabit airlink switch instead (and later my asus 8-port gigabit switch). Eventually, I used slackware to setup my own router via gigabit interfaces using a bridge (in conjunction with the 8-port-gigabit-asus), I decided to let the Linksys go to my parents where they could use it in the house. Since I am currently unemployed and living with my parents (bummer!), I had to fix the network a couple of times. I am the IT admin/ lackey/ janitor here, and my pay is no rent plus food (not a bad deal if you ask me, although when I do find work I'd love to upgrade the dsl connection to something > than 1.5 MB).

So, I was told the Linksys no longer worked. My family went and purchased a wireless N capable Dlink. However, they were having a host of other problems. Turns out the actiontec modem/ap was broadcasting one ssid, and the dlink was broadcasting an entirely different network. Little did they know even though they purchased the dlink, they weren't in fact actually using it. All of the clients would connect to the airlink, that is, everyone except the little netflix streaming roku, which I have yet to explain why.

So I had to consolidate everything to one network, disable the ssid on the actiontec, and bingo everything works on the dlink (while of course setting the dlink on a seperate lan, 192.168.1.x).

Note: do not read the next paragraph unless you are absolutely curious as to the process of what I had to endure in order to fix my home network. If you truly don't care, I promise I wont be upset. Also, it may confuse most of you. Those of you who are interested purely for the challenge, feel free to comment on my gimped setup (i.e. seasoned *nix users, I welcome your input).

(That was the shortened instruction set. Most people would disable dhcp entirely on the first router, or place it in bridge mode (I seriously think only 2wire routers have this option). And, since most instructions would have you connect the first ap to the 2nd ap via the lan ports, I was having trouble passing NAT and DNS via the 2nd ap's wifi. Since there is no bridge mode on the actiontec, I opted to simply leave dhcp on in the first ap/modem while disabling the ssid, set the 2nd ap on a seperate lan, while connecting ap 1 to ap 2 via the wan port. Although a bit convoluted, I no longer have issues with dns. Well, mostly. Most of the windows clients, except my little sisters laptop and mine, which I had to hardcode dns in /etc/resolv.conf, oh and her ipod. Oh, and get this, the actiontec will randomly re-enable the ssid, simply because it feels compelled to be the boss. I've seriously had to disable it like 5 times already. It's frustrating.)

If anyone needs help with a similar setup, feel free to comment / Email me.

So anyways, I was told the Linksys no longer works. I called bullshit (especially considering the mess my family of computer geniuses left everything in). I perused the settings to see if there was anything remote to using the AP as a repeater, or set it up via a wifi wpa2 bridge, but nothing was in the linksys firmware. Now, I had originally intended to use openwrt for this project, however although I am certainly not opposed to the *nix style environment (I'd actually prefer this), according to the wiki there are a host of packages you need to download in order to get a wpa2 bridge going:
http://wiki.openwrt.org/oldwiki/wirelessbridgewithwpahowto?s[]=wireless&s[]=repeater .

Furthermore, the setup isn't exactly straightforward. That and considering I have a deadline on some projects I'm working on (note: submitting resumes to find jobs--there is a contract I'm trying to settle as we speak), I figured I'd settle for a working solution for now until I have the time to setup the environment I'd prefer (this is a trade-off I did when I first started using linux--my first home distro was fedora. That plus my redhat training made my transition to slack much smoother).

So, my instructions were gleamed from Brian Purdy's post on lifehacker. I will do you folks the favor of simplifying his post. It looks like he had to do a lot of extra work, my setup was actually pretty simple.

First, go to ddwrt's site http://www.dd-wrt.com/site/index . Next, lookup your router in the router DB, and browse to the appropriate link. According to Brian, the micro firmware will suit our purposes just fine. (This is acceptable, since my next upgrade will be openwrt). He mentions that you should powercycle the hell out of your router, although I found I had no such need to do so. Simply go your routers homepage and find the appropriate link: mine was Linksys > Administration > firmware link, and begin the upgrade by loading the micro.bin firmware. (Note, if your router doesn't have a webgui option to load firmware, you may have to utilize tftp. Consult the dd-wrt wiki for more info). You should see a "Upgrade is Successful," message appear (sorry guys I didn't take a screenshot, but it is a very simple webpage). Afterwards, your router will reboot, and you'll need to re-authenticate with the following credentials:

username: root
password: admin

(It took me a couple tries to figure it out.. I know I ride the short bus, bare with me.)

Next, comes for the configuration:

A. Edit Wireless: Wireless Tab (Basic Settings)
 > Switch wireless mode to repeater
 > For wireless network name, input the SSID of the network you will be rebroadcasting (or repeating).
 >> Save settings (do not apply just yet)
 > Below the main section you edited is a Virtual Interfaces section. Add 1 virtual interface
 > Add a NEW name for your repeater (i.e., the original SSID appended with a 2, which is what I did. Or you can use an entirely different SSID).
 >> Save settings (do not apply just yet)
 >> Head to wireless security subtab
 > Ensure you use the same security settings your primary router/wifi access point utilizes in both the primary and virtual interfaces. For WPA2, take care to notice whether you use TKIP, AES, or both.
  >> Save settings (do not apply just yet)

B. Network configuration: Network setup tab (Basic Configuration)
 >  Alter the routers Local IP Address to something different than the primary access point. I.e. if your main router uses 192.168.1.1, you can use 192.168.2.1 (which is what I did).
 >> Save settings (do not apply just yet)
 >> Switch to the Security subtab (Still under Main Network Setup tab)
 > disable SPI firewall
 > Under Block WAN requests, disable the following:
 - Block Anonymous WAN Requests (ping)
 - Filter WAN NAT Redirection
 - Filter IDENT (Port 113)
 > Leave Filter Multicast disabled
(Note: the above settings are to ensure the simplest configuration in case anything goes wrong. If you feel compelled to re-enable them after your configuration is working, feel free to do so and report your results).
 >> Save settings (and for the love of god don't apply yet!)
 > Head over to the administration, and for Pete's sake--change the password to something you can remember (if you haven't already done so).
 >> Once again, save settings. Now you can Apply!

So first things first, since you changed the lan ip your ap is using, you will need to renew your dhcp lease for your interface. Now in my configuration, this ap repeater is providing internet over ethernet to my gimped celeron lappy. For those of you who are using this over wireless, configure your wireless as normal.

Best thing is to simply bring down the interface, and re-initialize it. This way, the routing table will be reset. When I first tried it I noticed it was still trying to use 192.168.1.1 as the primary gateway under route -a.

After you have established a link over your desired interface, perform a basic network check:
 > ping your accesspoint, i.e. in my case 192.168.2.1. Also a good time to see if you can browse to your repeater ap, and to test your new login credentials.
 > if this is good, now try pinging the primary access point (in my case 192.168.0.1)
 > if this is good, you should also be able to browse to the primary ap's interface (a good check).
 > Now, hold your breath, a real WAN test. Ping the following IP (which i'm told is a DNS for Verizon): 4.2.2.2
 > If the above works, you are online! Now, for a dns test: ping your favorite website, i.e. slugman01.blogger.com
 > if you receive replies, you are golden. If not, you may need to hardcode the dns listed in your modem/primary ap's page in /etc/resolv.conf

At this point you should be able to browse the interwebs. Note: if you had your browser open prior to this point, you may need to restart it if you have problems loading webpages. For some reason, even after the above network test confirmed I was online, firefox hung on loading basic webpages. Restarting it did the trick.

If you experience any problems, feel free to post here and I'll do the best I can to help. Important points to remember are:
 > ensure your physical interface is working properly. If it isn't, you'll fail right off the bat when you try to ping your access points.
 > if you can ping your repeater access point, but not the primary, doublecheck your routing table to ensure it is using the correct primary gateway. A simple ifconfig interface down; ifconfig interface up will clear the routing table. If you are statically assigning your addresses you can setup via ifconfig and add the gateway via route as normal. Otherwise, if you are using a dhcp lease then make sure to kill the process id (or killall -9), the process for the dhcp application (in my case, dhcpcd), prior to re-initializing the interfaces, or it may screw up when it tries to grab the new lease.
 > if you can ping & browse your primary access point, but can't ping WAN (4.2.2.2), make sure your primary access point doesn't have ping requests blocked, or has its firewall disabled. (Remember, in my case I have 3 access points, the modem/ap, the dlink ap, and my repeater. The dlink provides the firewall.) Or, it may be possible you temporarily lost internebs while seting up: check the status page of your modem/ primary ap to doublecheck.

If you are fortunate enough to have a linux system connected to the primary ap/ or a windows system with putty, or any *nix environment with ssh, try making sure they can ping said IP- 4.2.2.2 . If they can't ping it, but can still browse, its likely ping requests have been disabled from the primary ap. I recommend re-enabling ping just to make sure you can perform the "ping a domain name," test afterwards. It really helps to narrow down if you are having a WAN or DNS issue.

Good hunting!

- Slug

Wierd issues with RTL-8185

I'll make this one short.

So I finally got Slack14.64 going on the Turion lappy. I could see that the interface was recognized, but attempting to scan failed:

iwlist wlan0 scan

interface doesn't support scanning

Upon further inspection, I noticed the following in /var/log/messages:

Jan  3 08:22:23 darkstar kernel: [  689.812525] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Jan  3 08:24:33 darkstar kernel: [  819.813053] rtl8180 0000:06:09.0: PCI INT A disabled
Jan  3 08:24:44 darkstar kernel: [  830.320068] rtl8180 0000:06:09.0: PCI INT A -> Link[LNK1] -> GSI
 11 (level, high) -> IRQ 11
Jan  3 08:24:44 darkstar kernel: [  830.445461] ieee80211 phy1: hwaddr 00c0a8d3d0da, RTL8185vD + rtl
8225
Jan  3 08:25:00 darkstar kernel: [  846.314529] ADDRCONF(NETDEV_UP): wlan0: link is not ready

The above shows that the kernel module rtl8180 is initializing the device via interupt request 11. However, following the NETDEV_UP wlan0:link is not ready, we should see a NETDEV_CHANGE showing the link is ready. I was puzzled why the rtl-8185 was getting stuck.

Upon perusing LQ.org's forums, I decided to give the function keys on the keyboard a try. This didn't work on my lappy server, which is older and utilizes a bcm4306 (the bios indicates a resource conflict, which I'll explain in another blogpost sometime).

The function keys actually initialized wlan0 successfully. Immediately, the wifi led lit on the lappy, and I could see the following in messages:

Jan  3 20:04:55 darkstar kernel: [42842.155104] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Jan  3 20:04:55 darkstar kernel: [42842.155650] cfg80211: Calling CRDA for country: US
Jan  3 20:04:55 darkstar kernel: [42842.162047] cfg80211: Regulatory domain changed to country: US
Jan  3 20:04:55 darkstar kernel: [42842.162056] cfg80211:     (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Jan  3 20:04:55 darkstar kernel: [42842.162064] cfg80211:     (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
Jan  3 20:04:55 darkstar kernel: [42842.162071] cfg80211:     (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
Jan  3 20:04:55 darkstar kernel: [42842.162078] cfg80211:     (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jan  3 20:04:55 darkstar kernel: [42842.162085] cfg80211:     (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jan  3 20:04:55 darkstar kernel: [42842.162091] cfg80211:     (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jan  3 20:04:55 darkstar kernel: [42842.162098] cfg80211:     (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)

Note: ignore the timestamp. This actually occured last night, although it wasn't untill this morning that I updated the system's time in the BIOS.

So I could not successfully scan networks via wlan0. However, attempting to authenticate with my network failed. This is a simple, wpa2 network (no md5 challenge or authenticating with RADIUS), setup in our house. My attempts to use wpa_supplicant failed. All attempts eventually timed out.

At this point I was really frustrated. I abandoned the lappy until the morning, assuming I would somehow need to try and find a different version module (either new or old), to test. According to Realtek's support site, the last released linux driver for the RTL-8185 was sometime in 2007 and has 2.6.x support. This would be okay except Slack14 is a modern OS utilizing long term stable kernel 3.2.29.

The solution turned out to be much more simple than that. This morning, I was messing around and found the following worked:

ifconfig wlan0 down
<function key sequence for wifi> #disable RTL-8185
rmmod rtl8180
<function key sequence for wifi> #enable RTL-8185
modprobe rtl8180
ifconfig wlan0 up
wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant.conf

And suddenly I magically authenticated with my access point.

Confusingly enough, after a reboot I was able to authenticate without having to malarky around with removing and modprobing the module.

That was after I modified my BIOS time. I did notice weird behavior as a result of my system being so far back in time (things like x would hang and firefox was being weird), but I can't say for certain if that would also affect this kernel module. When I have the time, I'll devise an experiment to test this hypothesis.

- Slug
 

PXE Installation Notes

I recently discovered my siblings old laptop. Note: this unit is newer than mine, and has a turion 64 processor. Enough said; I can load slack64 and multi-lib this sucker. (Plus my current slack-lappy-server, has a whopping 256mb of ram--wow!--and a celeron, okay i'll just stop i can hear you laughing.)

The only problem is that the newer system has no HD, and no optical drive. What can one do?

Never fear! In 1999 Intel and Systemsoft developed the Pre Execution Boot environment, aka PXE. This makes use of IPv4, DHCP, and a TFTP server.

So, we use a variation of a PXE boot environment to install over the slack14-32 usb environment I previously had, and upgrade it to slack14-64.

Although I've shamelessly (and without permission I might add), have borrowed previous authors material to repost on this blogspace, I will not do so to the awesome contributors of slackware. I believe Eric Hamleers (aka the amazing Alien Bob), is the author of the current Slackware README_PXE.txt file. So, I refer everyone to the aforementioned readme, which can be found in your slackware installation disk, under the /USB-AND-PXE-INSTALLERS directory. (A link is also provided at the end of this post under Sources.)

What I wanted to add is some notes from my experience. Now, I've actually setup this at least.. oh 4-7 times in my life, so I'm already very familiar with the process. If anyone needs any help--feel free to ask me and I'll be happy to comment. Otherwise, join and post your question on LQ.

a. I used the simple setup. Note: this is appropriate for most home /SOHO users. If you have a corp network/ laboratory, or systems that you do NOT want to boot linux, use the advanced setup. The difference in configuring dhcpd.conf is not that great, it simply allows you to define which systems to boot via MAC address.

a1. The readme does not explicitly state this, however my first time took me about a day to figure this simple thing out, so I'll be nice and share.

The sample configuration defines the DHCP & TFTP server as 192.168.0.1. So, when you start dhcpd (after having defined your /etc/dhcpd.conf of course), make sure to:

# bring up the interface you will use to serve pxe, i.e. Duh.

ifconfig eth0 up                           
ifconfig eth0 192.168.0.1
dhcpd

And then you should see a response stating dhcp is being served on 192.168.0.0/24.

b. Usually after getting everything setup, I usually just plugged in my ethernet cable from the server system to the target installation system. Although technically you should be using a crossover cable, in my experience with newer gigabit interfaces, the negotiation is handled automatically by the interface firmware. This was not the case in my current setup.I sat dumbfounded as the target system had a big fat no on screen after booting to pxe-boot mode:

Check Interface
Operating System not found

So I was like, wtf? I was about to consider buying a pcmcia gigabit nic, when I remembered I have a 5port asus gigabit switch. I figured, I can connect the server to the switch, check if the port activates, and do the same with the target system. Note: the target system's ethernet lights do NOT work, and neither did the servers activity lights activate, so it was a reasonable assumption to consider that one of the nics was fucked.

However, when I connected each nic to seperate ports on the switch, I finally got activity on the nics (except the target system). I figured, if the switch shows activity, I'll give it a shot. PHY (OSI level 1), troubleshooting is very straightforward, but a necessary step (sometimes).

Boot the target system into PXE-Boot and BAM, I hit jackpot. When this shit works, you'll know right away: you should see your system grap a dhcp lease almost immediately, and you'll be greated by the slackware installation screen:

So if you see this, that means your DHCP and TFTP server is successfully serving, and if you can boot, your kernels and initrd.gz from the installation disk are intact.

Part2

c. Installation via NFS:

Now, in the past I usually opted for samba installation (simply because I had roomates that use windblows and wanted access to my goods), however I've also used http installation (recommended if you have the time), but nfs is pretty damn simple. My error in this configuration was

/mirror/slackware       192.168.0.0/24(ro,sync,insecure,all_squash)

Now, that is the default recommended config. However, I was trying to be fancy. Instead of populating the installation in /mirror/slackware as mentioned above, (say like /mirror/slackware/slackware-14.64), I populated it in /iso and created a soft-link to the dir (ln -s /iso /mirror/slackware/slackware-14.64).

The install did not like this. It kept coming up with errors, and essentially told me to fuck off. I'm know that somewhere in man exports I can determine the option which will facilitate softlinks to work, however instead I just modified exports to the actual mirror dir:

/iso       192.168.0.0/24(ro,sync,insecure,all_squash)

And the installation was off!

Reasons to recommend PXE/TFTP installation:
a. 100mb ethernet interface is much faster than typical CD/DVD rom read speads. (A typical install from DVD takes a while. If you've done this a couple times, you'll be surprised how fast a 100mb install is. A gigabit install is LIGHTNING fast (dont even get me started on fiber channel links, when I have the hardware I will revisit this post). 

b. You can host more than just slackware. In fact, at Intel I used this setup to host our RHEL6 installs. Any Linux can be hosted. In fact--I used a slack pxe/server to host Windows7! This requires configuring pxelinux.cfg/default a little differently than what is included in the installation disk. I remember I had to do this when a friend handed me a semi-new Sony Vaio laptop, which for some reason did NOT want to boot any of the win7 burned iso's I had (probably Sony dicking us with some bullshit firmware hacks). When I have the time, I'll make another post exclusively on Slack PXE serving Windows.

c. For shear practice. Seriously its good for the soul (or masochistic if your not technically inclined, but hey whatever you call it you'll be happy when it works--trust me).

Sources:

1. Slackware USB-AND-PXE-INSTALLERS/README_USB.txt: http://taper.alienbase.nl/mirrors/slackware/slackware64-14.0/usb-and-pxe-installers/README_PXE.TXT