Forum

Full Version: Always use eth0 for xbmc
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hi,

Situation:
-----------
I have a setup where I'm trying to use both eth0 and wlan0 network interfaces.
- eth0 (192.168.1.15) will be used for xbmc and has internet connection via router 192.168.1.1
- wlan0 (192.168.2.10) will be used for something else, has no internet connection via 192.168.2.1
Both interfaces can ping to their individual routers, so far so good, on a network level everything seems to be ok.

Now the problem.
--------------------
Once wlan0 is enabled, xbmc 'automatically' selects wlan0 as the interface to be used as some sort of default behavour.
What I want is to use eth0 for xbmc regardless of whatever happens to wlan0.
If I bring wlan0 down using ifdown, xbmc switches back to using eth0 which is what I want, but it also means I can not use wlan0 anymore.
If I enable wlan0 using ifup, xbmc switches back to using wlan0 interface.

Questions:
------------
- how can I force xbmc to always use eth0 (while wlan0 is enabled)?
- how can I configure that so that it also happens at boot time?
@Roy Terhaar

this is for sure XBMCs internal "intelligence" ... (and even probably useful on stupid systems).
I see few options how to avoid that:
- patch the code, should not be that difficult to find the relevant line of code and disable the logic
- try reverse order of activating the interfaces - could be that the logic of XBMC is the easiest one - THE LAST activated interface is considered the correct/actual ... that means put eth0 into manual, let RPI + XBMC boot with wlan0, activate eth0 only after manually. maybe I'm right and you have solution
- use OWNER iptable matching module.

linux's network stack allows you to use so called SOURCE routing, that means routing traffic based on SOURCE conditions, not destination. that is easy to setup, but by default designed to work with IPs (from which the pkts are originating). so you will use OWNER matching module which allows you TAG pakets based on process name, uid(owner) etc.
so the point would be create match target for uid xbian (or even PID of running XBMC), mark it and route with source routing conditions via eth0.

it should be like 2-3 lines of commands, google is your friend.

decide, check the 2), tell back. if you would consider the 3) too complicated, ask again - as last resort I can open the man pages and tell you the commands.
@mk01

First of all thanks for your help. Most appreciated.

I have tried option 2 before with no succes, but this evening I tried again. But it's giving me the same result. xbmc shows wlan0 as the active interface. A bit strange however is that it shows the DNS settings of eth0 (!?!).
But I am pretty sure it uses wlan0; it does not show the correct time on the screen as it does not have internet connection via wlan0 and also any other network service fails.

Option 1 is something that should work, but I have never compiled xbmc before and the setback is on version updates you have to recompile, so I am not very eager to do this time after time again.

I have never heared of option 3. With a bit of google-ing I found out that you might run into security issues and also I would like to keep things as standard as possible.

In the end it's a bit of a design issue of xbmc. I don't understand that there is a nice xbian-config gui and xbian-config command line interface that shows your network interfaces, but does not let you select which interface you want to use and instead uses 'smart' logic which ends up in using wlan0. But I guess that's the way it is now.

Maybe I should buy another RPi and use the one I currently have dedicated for xbmc (on eth0) and use the new one for all the other stuff (on wlan0).

But if anyone found an easy way to get my problem solved, please let me know.

For now thanks again for your time to help.
I have never reported back on my workaround that seems to work so here it is, just in case it could help someone else with a similar problem. Smile

1. Via Xbian-config menu I have disabled starting Kodi at boot time

2. I created a script (start_kodi) that automatically runs at boot time and placed it in the xbian home directory executing following commands:
sudo ifdown eth0
sudo ifup eth0
sudo service xbmc start

Now I am sure that the eth0 interface starts after wlan0 (and kodi is following shortly)

3. I created the rc.local script that fires start_kodi script using following content:
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
/home/xbian/start_kodi
exit 0
@Roy Terhaar ,
thanks for feedback.

Ps below is what I do to delay Kodi starting before wlan is up:

Terminal
sed -i "s/start on started mountall/start on started mountall and started networking and net-device-up wlan0/" /etc/init/xbmc-preload.conf
Another approach could be setting eth0 to manual and start device after wlan0 is up in file /etc/network/interface

Code:
auto lo
iface lo inet loopback

#allow-hotplug eth0 # <-- comment out
#auto eth0 # <-- comment out
iface eth0 inet static
       address 192.168.2.24
       netmask 255.255.255.0
       network 192.168.2.0
       broadcast 192.168.2.255

allow-hotplug wlan0
auto wlan0
iface wlan0 inet static
       address 192.168.1.24
       netmask 255.255.255.0
       network 192.168.1.0
       broadcast 192.168.1.255
       gateway 192.168.1.10
       wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
       post-up  /sbin/ifup eth0 # <-- add
@deHakkelaar and@Nachteule,

Thanks for the response, but my problem was a bit different I guess, because I am running Kodi on eth0, so basically I don't care if wlan0 is up or not before starting Kodi. However Kodi seems to always choose the last interface that's activated. I also noticed that sometimes it loses settings of the eth0 interface and uses the settings of the wlan0 instead (gateway configuration) which makes no sense.
But my workaround seems to be working most of the times... Cool
Reference URL's