XBMC/ Kodi headless on a recent Debian

After struggeling for some time with random segfaults of a headless XBMC, pardon Kodi, in libxbmc.so I found this forum post:


which fixed it for me. I made a diff that applies to a recent git checkout from XBMC Gotham 3.2 and includes the fix as well as all other patches for the headless mode. So you can just follow the nice HowTo from Fma965.


but use this patch:


For the reference, the segfaults looked like

Sep 8 19:17:17 kernel: [4101574.165138] EventServer[18820]: segfault at 0 ip 00007fc3bc61f27d sp 00007fc3a67332b0 error 4 in libxbmc.so[7fc3bbc73000+1897000] 

while the logfile stopped with

19:17:17 T:140478287922944 NOTICE: Thread EventServer start, auto delete: false
19:17:17 T:140478287922944 NOTICE: ES: Starting UDP Event server on
19:17:17 T:140478287922944 NOTICE: UDP: Listening on port 9777 19:17:17 T:140478279530240 NOTICE: Thread TCPServer start, auto delete: false

or after disabling all server services

09:04:03 T:139805209810688 NOTICE: Thread AlarmClock start, auto delete: false
09:04:04 T:139805727848320 DEBUG: LogindUPowerSyscall - Received unknown signal NameAcquired
09:04:04 T:139805727848320 DEBUG: Checking repositories for updates (triggered by XBMC.org Add-ons) 09:04:04 T:139805201417984 NOTICE: Thread JobWorker start, auto delete: true 

Using Sachesi with Debian

In order to update my BlackBerry Q5 I wanted to use the handy Sachesi program to install all the .bar files. It proved to be more complicated than I thought.

Problem is that Sachesi does in fact use a USB connection to communicate with the BB10 device but not via some serial protocol but instead IP. Therefor the device registers itself as a USB network device and acts as a dhcp server providing the computer with a link local IPv4 in a /30 network. And here lies the problem. Sachesi doesn’t recognize your BB if there are other Network connections going.

Long story short, I disconnected LAN and Wireless, put usb0 as

iface usb0 inet manual

into /etc/network/interfaces, restarted the network-manager service and run dhclient manually

sudo dhclient -v -d usb0

Make sure that Tethering and USB mass storage are off and the device is set to Windows Mode instead of Auto or Mac.

Sometimes it does work with WiFi enabled, but I have to stick with manual dhclient.

Update 2:
If you get random crashes with Sachesi and XFCE just disable the xfwm4 compositor while using it.

Where is my server?

Today I noticed that we lost a server. Actually we new the place but not the Switchport it is connected to. You might say: just look for the MAC address — yeeesss, but it is connected via LACP, the first link was up, but the 2nd one — the one I was interested in — not. Or better to say, it was up but disabled by the lacp algorithm on the Linux machine.

What happened? Someone rewired the switch and changed the 2nd port of the server to some other Switchport. Sadly he wasn’t at hand to be send to the offside Datacenter to follow the cables.

Luckily I got the idea to check for the LLDP messages the Switch sends out on every port and catch it with tcpdump. A short google away was this wonderful website from Darren:

## Switch:
tcpdump -i eth0 -s 1500 -XX -c 1 'ether proto 0x88cc'

## Port and CDP Neighbor Info:
tcpdump -v -s 1500 -c 1 '(ether[12:2]=0x88cc or ether[20:2]=0x2000)' 

An output might look like

16:25:10.589903 LLDP, length 329
Subtype Local (7): Eth155/1/27
Port Description TLV (4), length 16: Ethernet155/1/27
System Name TLV (5), length 11: S1425-B2-01
Management Address length 5, AFI IPv4 (1):
Port VLAN Id Subtype (1)
port vlan id (PVID): 991

As you can see, among others, we get the Switch, Port and VLAN information. Yeehaw!

First steps with Open vSwitch and a comparison to the Linux bridge

Some weeks ago we finally found the time to install our new workhorse server “muli”. It’s meant to host some VMs of former tutors and utilize libvirt therefor. Instead of the traditional network bridge device we thought about experimenting with Open vSwitch (ovs). While the integrated Linux is pretty fast and featureful ovs brings remote programming possibilities, vxlan, OpenFlow, GRE, integrated QoS, NetFlow and many, many more. And it might also be interesting later on for my PHD thesis. But first things first.

There seems to be a misunderstanding sometimes: The Linux bridge is in no way a hub, it is a full featured bridge with a forwarding database, ageing times and even STP support. You don’t need ovs for this!

We are on Debian Wheezy (stable at the time of writing). There is only ovs 1.4 but to get a taste of it, it seemed to be enough:

apt-get install openvswitch-switch openvswitch-datapath-dkms

Our setup is a 2 times 1G LACP-trunk carrying 2 tagged and an untagged VLAN with shall make up the uplink interface of the switch. On the downlink side we thought about one virtual interface per vlan per VM plus one interface in the untagged vlan for the Debian Linux. Obviously there is a third physical network card which gives us an oob path — just in case :-).

The UI and Documentation of ovs is — how to say it in a friendly way — a mess. I suppose this stems from the target as a SDN bridge. In the end most of the useful documentaion ended up to be in the FAQ.

At first we create a new open vSwitch (aka bridge) and add the LACP trunk (aka bond aka etherchannel) to it

ovs-vsctl add-br br0
ovs-vsctl add-bond br0 bond0 eth1 eth2
ovs-vsctl set port bond0 bond_mode=balance-tcp
ovs-vsctl set port bond0 vlan_mode=native-untagged trunks=[1,3] tag=2
ovs-vsctl list port bond0

this gives us

_uuid : 889e1057-d6fb-45bf-a3cc-582be1e7b4b8
bond_downdelay : 0
bond_fake_iface : false
bond_mode : balance-tcp
bond_updelay : 0
external_ids : {}
fake_bridge : false
interfaces : [2cc3b8dd-ecae-41cc-a67c-d92764713eac, bfc1c7a7-fa16-493d-b76d-8459bca7ea46]
lacp : active
mac : []
name : "bond0"
other_config : {}
qos : []
statistics : {}
status : {}
tag : 2
trunks : [1, 3]
vlan_mode : native-untagged

There are quite a lot of configuration options for bonds. They are documented in ovs-vswitchd.conf.db(5). One might also use “tagged” or “access” as vlan_mode. The untagged vlan might or might
not appear in the “trunks” list but always has to be set with “tag”.

Now we can list interfaces and ports:

ovs-vsctl list br
ovs-vsctl list-ifaces br0
ovs-vsctl list interface
ovs-vsctl list port
ovs-vsctl show

To add a new virtual (internal) interface we use

ovs-vsctl add-port br0 hv-vlan2 tag=2 type=internal

This port is meant to be the interface of the hypervisor (ie the Linux host aka muli) and can get an IP in /etc/network/interfaces:

auto hv-vlan2
iface hv-vlan2 inet dhcp

# we also have to make sure to bring up all the other
# interfaces (/ifconfig up/ them):
auto eth1
iface eth1 inet manual
up ifconfig $IFACE up
down ifconfig $IFACE down

auto eth2
iface eth2 inet manual
up ifconfig $IFACE up
down ifconfig $IFACE down

auto br0
iface br0 inet manual
up ifconfig $IFACE up
down ifconfig $IFACE down

Finally devices for all 3 VLANs that might be used by virtual machines:

ovs-vsctl add-port br0 vm-vlan1 vlan_mode=access tag=1 type=internal
ovs-vsctl add-port br0 vm-vlan2 vlan_mode=access tag=2 type=internal
ovs-vsctl add-port br0 vm-vlan3 vlan_mode=access tag=3 type=internal 

Once again one should not forget to add them to /etc/network/interfaces in order to bring them up while booting the host!

For the integration into libvirt we decided it would be most simple to use the passthrough mode to the virtual port:

<interface type='direct'>
      <mac address='XX:XX:XX:XX:XX:XX'/>
      <source dev='vm-vlan2' mode='passthrough'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03'

Easy, wasn’t it?

TCP offloading and Linux

When doing a tcpdump on recent hardware you get wrong information about single packets. You first have to do sth. like


case "${IF_NO_TOE,,}" in

if [ "$MODE" = start -a "$RUN" = true ]; then
TOE_OPTIONS="rx tx sg tso ufo gso gro lro rxvlan txvlan rxhash" for TOE_OPTION in $TOE_OPTIONS; do
/sbin/ethtool --offload "$IFACE" "$TOE_OPTION" off &amp;&gt;/dev/null || true done

Thanks to