Decripple OpenSSL on Fedora

I have grown tired of the travesty which is Redhat's inability to get secp256k1 enabled on the OpenSSL package. This has been a problem since 2007. That's 8 years as of now. This elliptic curve is needed for most if not all cryptocurrencies to build and run correctly. The recommended way to deal with this problem has been linking the binaries directly to a separate version of OpenSSL that people usually install from Ringing Liberty repositories. I'm now recommending that you should just patch the shipped version of OpenSSL whenever there's an update to OpenSSL available from Fedora repositories. I know this is bothersome, but it's the easiest way to deal with this issue until Redhat's lawyers get this shit sorted out whenever that may be.

First you need to get the source rpm:

yumdownloader --source --noplugins openssl

then you install the source rpm (version may and probably will differ):

rpm -ivh openssl-1.0.1j-1.fc21.src.rpm

Fetch the files, patch and build:

cd ~/rpmbuild/SPECS/
wget http://sebastianmaki.fi/files/openssl-1.0.1j-decripple-secp256k1.patch http://sebastianmaki.fi/files/openssl.spec.secp256k1.patch
mv openssl-1.0.1j-decripple-secp256k1.patch ../SOURCES/
patch < openssl.spec.secp256k1.patch
rpmbuild -bb openssl.spec

Then replace the installed openssl-packages on your system:

cd ~/rpmbuild/RPMS/$(uname -p)
yum reinstall ./openssl-*

Now you can build bitcoind, litecoind, potcoind and so on normally by following the building instructions in the sources.
No more fiddling with LD_LIBRARY_PATH, OPENSSL_OPTIONS, LDFLAGS and so on

If you happen to walk in the vicinity of a patent office with a canister of gasoline and the desire to burn buildings, do take pictures. I'd like to hang them on my wall. If you happen to be in a position to vote for abolishing the patent system, please do so. Vote for a political candidate that promises to destroy the patent office. The patent system as it is today does nothing to promote the development of new ideas. In fact it hinders innovation.

Configuring a 4-port Sun Happy Meal card

Some time ago I rescued a pair of 4 port Oracle/SUN Happy Meal 10/100 Ethernet cards and I decided it was time to play with them. There was an issue with the sunhme driver, so I created an akmod package for Fedora 18 to patch the bug on my system so that the patch would be picked up automatically on every kernel update as well. The akmod package is available on github.

There's another quirk to these cards as well. At least on my system there is an issue with renaming the interface names that leads to one of the interfaces being renamed inconsistently(interface name ends up being something like "rename6"). I wanted to rename the interfaces nicely so that I could tell the sunhme interfaces from other interfaces in my system.

In addition to weird renames these cards have only one shared mac-address assigned to each interface, so you can't just match the interfaces by their mac-address, since they're the same.

These quirks made getting the udev rules to match rather challenging. Eventually I found a nice script that scans for the interfaces and creates a template for a proper matching udev rule.

In order to be able to use just on interface without having packets disappearing on the other interfaces, which might not be physically connected I also set unique mac-addresses for all the interfaces.

/etc/udev/rules.d/30-sun-hme.rules

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNELS=="0000:06:00.1", \
    KERNEL=="eth*", NAME="hme0", RUN+="/usr/local/bin/sunmacchanger %k 00:03:ba:a8:58:e5"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNELS=="0000:06:01.1", \
    KERNEL=="eth*", NAME="hme1", RUN+="/usr/local/bin/sunmacchanger %k 00:03:ba:a8:58:e6"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNELS=="0000:06:02.1", \
    KERNEL=="eth*", NAME="hme2", RUN+="/usr/local/bin/sunmacchanger %k 00:03:ba:a8:58:e7"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNELS=="0000:06:03.1", \
    KERNEL=="eth*", NAME="hme3", RUN+="/usr/local/bin/sunmacchanger %k 00:03:ba:a6:58:e8"

/usr/local/bin/sunmacchanger

#!/bin/bash

#make sure the interface is down, otherwise setting the mac will fail
/sbin/ifconfig $1 down
/usr/bin/macchanger --mac=$2 $1

After the changes I just needed to unload the driver, reload the rules and load the driver again and udev magic would happen

chmod +x /usr/local/bin/sunmacchanger
rmmod sunhme
udevadm control --reload-rules
#loading my patched version of sunhme driver
modprobe sunhme2g

Now I have 4 100M interfaces on one card. It'll come handy when routing traffic outside my LAN and I could have redundancy in case one WAN connection goes down.

Unless I spesifically tell NetworkManager not to bring up interfaces hme1-hme3, NetworkManager will bring those interfaces up. This causes some log spam:

output of dmesg

[ 6438.361078] hme1: Auto-Negotiation unsuccessful, trying force link mode
[ 6438.369059] hme2: Auto-Negotiation unsuccessful, trying force link mode
[ 6438.373052] hme3: Auto-Negotiation unsuccessful, trying force link mode
[ 6447.974274] hme1: Link down, cable problem?
[ 6447.982269] hme2: Link down, cable problem?
[ 6447.986242] hme3: Link down, cable problem?
[ 6459.990561] hme1: Auto-Negotiation unsuccessful, trying force link mode
[ 6459.998551] hme2: Auto-Negotiation unsuccessful, trying force link mode
[ 6460.002549] hme3: Auto-Negotiation unsuccessful, trying force link mode
[ 6469.603795] hme1: Link down, cable problem?
[ 6469.611764] hme2: Link down, cable problem?
[ 6469.615756] hme3: Link down, cable problem?

You can prevent NetworkManager from needlessly bringing up these interfaces by adding the macs to the unmanaged-devices parameter in [keyfile] section and checking that keyfile plugin is loaded in [main] section's plugins parameter.

/etc/NetworkManager/NetworkManager.conf

[main]
plugins=ifcfg-rh,keyfile

[keyfile]
unmanaged-devices=mac:00:03:ba:a8:58:e6;mac:00:03:ba:a8:58:e7;mac:00:03:ba:a8:58:e8

It's not exactly plug and play, but playing with these cards is a good learning opportunity. It wouldn't hurt to have some kind of graphical configuration tools for doing some of this stuff. It requires some knowledge about udev and NetworkManager + a search engine to do this "manually".