Always use eth0 for xbmc - Printable Version +- Forum (http://forum.xbian.org) +-- Forum: Hardware (/forum-7.html) +--- Forum: Network (/forum-25.html) +--- Thread: Always use eth0 for xbmc (/thread-2664.html) |
Always use eth0 for xbmc - Roy Terhaar - 18th Jan, 2015 09:42 PM 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? RE: Always use eth0 for xbmc - mk01 - 19th Jan, 2015 07:43 PM @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. RE: Always use eth0 for xbmc - Roy Terhaar - 20th Jan, 2015 07:30 AM @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. RE: Always use eth0 for xbmc - Roy Terhaar - 25th Apr, 2016 08:54 PM 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. 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 RE: Always use eth0 for xbmc - deHakkelaar - 25th Apr, 2016 10:39 PM @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 RE: Always use eth0 for xbmc - Nachteule - 25th Apr, 2016 10:46 PM Another approach could be setting eth0 to manual and start device after wlan0 is up in file /etc/network/interface Code: auto lo RE: Always use eth0 for xbmc - Roy Terhaar - 25th Apr, 2016 11:21 PM @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... |