Option to bind XBMC to specific network card?
#1
Lightbulb 
Hello all.

I have XBMC setup on a box that is also acting as my home router. The box has two interfaces (one public facing, with my routable IP), and one private (internal network). XBMC seems bound and determined to bind to the public adapter, which causes it to try to serve content to the public interface and miss all of my shared content on the internal network.

Is there anyway to force XBMC to bind to a specific interface?

I am proficient with the Linux environment and I can watch the process very specifically bind to and probe on the wrong interface.

If this is a standing problem I will tackle it, but I don't want to go digging through all the code and find out I am missing an option in some settings file.

Anyone have any experience here?
Reply
#2
generally speaking xbmc's servers or clients bind to *, which is the first available interface (afaik). xbmc is really not designed to work against multiple interfaces since its designed to be used solely as a client, patches are of course welcomed.

Problem here is that how should xbmc know which interface is the correct one, both are (codewise) equally correct so the only way to know which one it should choose is to ask the user, this is something that is very unlikely to be wanted in xbmc.

Cheers,
Tobias
If you have problems please read this before posting

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.

Image

"Well Im gonna download the code and look at it a bit but I'm certainly not a really good C/C++ programer but I'd help as much as I can, I mostly write in C#."
Reply
#3
Would you guys be against a patch that defaults to * but will respect an entry in the network.xml file?

I have a feeling that as the Linux version gets stronger more and more people are going to be apt to have a setup like mine.

Either way, I will whip up a patch and you guys can decide.


Thanks
Reply
#4
Binding to * shouldn't be a problem with multiple interfaces, apart from the security issues of course.

What ip addresses/netmasks did you assign to the interfaces?
Reply
#5
I'm pretty sure that you can't do a patch that will be clean enough to do this so it will be accepted, it is very very bad to have xbmc on a gateway. Either set up your network properly with a gateway that is just that and nothing more or get yourself a router.
If you have problems please read this before posting

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.

Image

"Well Im gonna download the code and look at it a bit but I'm certainly not a really good C/C++ programer but I'd help as much as I can, I mostly write in C#."
Reply
#6
If xbmc always binds to the first interface by the name of the interface, you could just rename the interfaces with ethtool or a udev-rule.
Reply
#7
I see what you mean on the cleanliness of the required patch, this would require manual changes all over the place... Sad


Why is running this on a gateway a "very very bad thing." Its just a userland process (executing as nobody for me). The whole point of my "router" being a quad core box was so that I could condense a huge amount of functionality onto one box. Maybe the best route is to just fire it up on a virtual machine and treat it as hostile code.

EDIT:

The public interface is some random DHCP addy assigned by my cable company. The private interface is in the 10.0.0.X range. The public interface is eth99 and my private is eth0. So it seems to be going after the interface with assigned route information rather than the lowest "eth number."
Reply
#8
Why not run process X on your gateway? Simply because it is not safe enough even for a home network. I have not seen a single place where any of the XBMC devs promised that the code is safe certainly not safe enough to run on a gateway into your entire network (even is the home network is only two machines)

Any and every security and half decent network professional will tell you that a gateway should run as few processes as possible and only those that are absolutely needed. For the simple reason that if a network is attacked that is the first place that gets hit. Be is a denial of service attack or a actual I want to get root on that machine attack the gateway is the most likely point to attack. The more software it runs the more likely it is that there is a fault in one of the bits of software that provides the attacker with access.

Aside from all that I still think your request is a good one and would certainly make for a much more robust and complete package. I could for instance imagine a situation in which I have a wifi and a wired connection on my computer (I actually do) or a setup in which one uses a but crazier setup where one has multiple network cards in a computer (all high-end motherboards do these days) and you use one for user and one for backup/monitoring traffic.

The idea of having the default bind to the first card and only when specified to a specific is a decent one. The fact that the code does not support that is sad but with enough will I am sure that someone can be found that is willing and able to fix that.
If that gets done I would say make the options when setting up even more extensive and give people the option to specify a NIC for every function, http api, dlna, network storage (shares or otherwise) and so on. This would basically be moving XBMC to a more and more industrial grade solution, but as long as the defaults remain this should not hurt any of the users it just provides more options for the power users.
Reply
#9
rcoops Wrote:Aside from all that I still think your request is a good one and would certainly make for a much more robust and complete package. I could for instance imagine a situation in which I have a wifi and a wired connection on my computer (I actually do) or a setup in which one uses a but crazier setup where one has multiple network cards in a computer (all high-end motherboards do these days) and you use one for user and one for backup/monitoring traffic.

The idea of having the default bind to the first card and only when specified to a specific is a decent one. The fact that the code does not support that is sad but with enough will I am sure that someone can be found that is willing and able to fix that.
If that gets done I would say make the options when setting up even more extensive and give people the option to specify a NIC for every function, http api, dlna, network storage (shares or otherwise) and so on. This would basically be moving XBMC to a more and more industrial grade solution, but as long as the defaults remain this should not hurt any of the users it just provides more options for the power users.

Sorry to say but it will never happen, I'm gonna add code that will let the user to connect to any network but we will never add so its ok to have 2 networks on same computer, it's a HTPC we're creating nothing else. A htpc is a media player / media hub and have ZERO reason to do network monitoring.

Also adding so you can bind different services to different cards is out of the question, we want a simple gui and I bet it would be about 0.001% that wants to do what you are suggesting Smile

We do not want to be an industrial appliance, we want it to be home software, ofcourse it should contain hobbyist stuff but not on the border of insanity.

Hope I don't sound rude I just don't see any viable application were this would be needed Smile

Cheers,
Tobias
If you have problems please read this before posting

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.

Image

"Well Im gonna download the code and look at it a bit but I'm certainly not a really good C/C++ programer but I'd help as much as I can, I mostly write in C#."
Reply
#10
Don't worry no offense taken still think it would be nice to have but at the moment I see no need to have these capabilities my self.

Though a very tiny little part will happen with the work being done on the DB abstraction which will mean that the DB will have it's own port and can listen on any card you so desire. Shocked

Never say never Wink
Reply
#11
Exclamation 
I think I can add something to this debate. There is one very good reason to allow XBMC to bind to multiple interfaces that I have discovered tonight..

First though, I haven't tested the way XBMC binds yet for myself, so I am assuming the original poster is correct that only binds to the 'first' interface, however that is determined.

Anyway, many users want to access their XBMC from other networks, i.e. their work or friend's house. UPNP only works as intended (i.e. simple for users) on local networks. There is a complicated scheme involving IGDs to allow it work across network boundaries, but I have been unable to find a workable implementation of this and it looks plain ugly regardless. Thinking about this today, it seemed the easiest workaround was to set up a VPN between the XBMC server and my intended XBMC clients. A couple of unanswered posts to the XBMC forum suggest others have been thinking along these lines. In particular a bridged VPN connection would allow the multicast advertisements employed by UPNP to traverse the VPN and be received by clients wherever they were (a non-bridged VPN won't forward the multicast). Note that you must discover a UPNP server in Windows via these adverts - I am not aware of anyway to statically define one, so you need multicast to be working. After discovery, the actual media stream would be forwarded over the VPN as well.

The point about all this is that setting up such a VPN inherently involves creating another interface on the XBMC server. At the very least you need a way of choosing which interface XBMC binds to, but in most cases I believe you would want to UPNP active on the VPN-bridge interface as well as your regular interface.

Surely not much involved in this change? Binding to one non-user-specified interface seems very unusual. For example Unix services tend to listen on all interfaces by default.
Reply
#12
yrebrac Wrote:I think I can add something to this debate. There is one very good reason to allow XBMC to bind to multiple interfaces that I have discovered tonight..

First though, I haven't tested the way XBMC binds yet for myself, so I am assuming the original poster is correct that only binds to the 'first' interface, however that is determined.

Anyway, many users want to access their XBMC from other networks, i.e. their work or friend's house. UPNP only works as intended (i.e. simple for users) on local networks. There is a complicated scheme involving IGDs to allow it work across network boundaries, but I have been unable to find a workable implementation of this and it looks plain ugly regardless. Thinking about this today, it seemed the easiest workaround was to set up a VPN between the XBMC server and my intended XBMC clients. A couple of unanswered posts to the XBMC forum suggest others have been thinking along these lines. In particular a bridged VPN connection would allow the multicast advertisements employed by UPNP to traverse the VPN and be received by clients wherever they were (a non-bridged VPN won't forward the multicast). Note that you must discover a UPNP server in Windows via these adverts - I am not aware of anyway to statically define one, so you need multicast to be working. After discovery, the actual media stream would be forwarded over the VPN as well.

The point about all this is that setting up such a VPN inherently involves creating another interface on the XBMC server. At the very least you need a way of choosing which interface XBMC binds to, but in most cases I believe you would want to UPNP active on the VPN-bridge interface as well as your regular interface.

Surely not much involved in this change? Binding to one non-user-specified interface seems very unusual. For example Unix services tend to listen on all interfaces by default.

I agree that connecting over the internet between server and xbmc is a very viable thing to do, however uPnP is _not_ intended for this so its rather moot in this discussion. uPnP is to share libraries and such simply over the home network, not between networks.

If you need to share stuff over the internet or between network your better of using a protocoll that works best this way, and there are alot of them. ftp, http and nfs for instance.

This discussion is only about having more than one network card in the xbmc machine and be able to via gui tell xbmc to only connect to a specific one (not autodetect as its now)
If you have problems please read this before posting

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.

Image

"Well Im gonna download the code and look at it a bit but I'm certainly not a really good C/C++ programer but I'd help as much as I can, I mostly write in C#."
Reply
#13
topfs2 Wrote:I agree that connecting over the internet between server and xbmc is a very viable thing to do, however uPnP is _not_ intended for this so its rather moot in this discussion. uPnP is to share libraries and such simply over the home network, not between networks.

Not entirely true, this capability is part of the UPNP specification, but it's true that it doesn't do it well.

topfs2 Wrote:If you need to share stuff over the internet or between network your better of using a protocoll that works best this way, and there are alot of them. ftp, http and nfs for instance.

..but XBMC doesn't offer streaming over any other protocol. The important thing to have available is this and the media library. Files of course can be transferred in other ways.

topfs2 Wrote:This discussion is only about having more than one network card in the xbmc machine and be able to via gui tell xbmc to only connect to a specific one (not autodetect as its now)

Right, but would it be any more work to allow it to bind to all?
Reply
#14
i'm supporting this idea of having the ability to bind to an IP, commented as such on http://trac.xbmc.org/ticket/9052#comment:18
xbmc-pvr-ppa-odk68, Gentoo x86 3.0.7-pf, xorg-server-1.11.2, mesa-7.11, nvidia-drivers-290.10
Reply
#15
I think this deserves a second look now that xbmc is targeting iOS and android. How does xbmc in those cases determine whether to bind to 3g/4g device or wifi device? Perhaps media shares are accessed via wifi, but internet is through the 3g/4g. How could one set this if xbmc doesn't know which device does what?

In my case, because I have vmware installed, I get these vmnet devices that are always on even though I never run vmware and xbmc simultaneously. One of those virtual devices has the IP that shows in xbmc's network status. Fortunately xbmc can download fine. As far as server functionality, I haven't needed it, but it might bind to the wrong device and even if it doesn't, the interface reports the wrong IP, which would cause frustration on its own. I assume the same scenario could arise of any machine with multiple networks, including a dedicated android htpc.
kodi from https://github.com/eternalsword/xbmc/tree/delta, transparency 7.1.5, funtoo kernel 3.18.0
Reply

Logout Mark Read Team Forum Stats Members Help
Option to bind XBMC to specific network card?0