Posts: 3
Joined: Jan 2010
Reputation:
0
2010-01-24, 01:10
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?
Posts: 4,549
Joined: Dec 2007
Reputation:
17
topfs2
Team-Kodi Developer
Posts: 4,549
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.
"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#."
Posts: 3
Joined: Jan 2010
Reputation:
0
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
Posts: 2,752
Joined: Dec 2008
Reputation:
23
bobo1on1
cheapass Team-XBMC Developer
Posts: 2,752
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?
Posts: 4,549
Joined: Dec 2007
Reputation:
17
topfs2
Team-Kodi Developer
Posts: 4,549
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.
"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#."
Posts: 138
Joined: Jun 2009
Reputation:
7
JumJum
Senior Member
Posts: 138
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.
Posts: 120
Joined: Oct 2008
Reputation:
0
rcoops
Senior Member
Posts: 120
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.
Posts: 8
Joined: Feb 2010
Reputation:
0
2010-02-05, 14:30
(This post was last modified: 2010-02-05, 14:32 by yrebrac.)
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.
Posts: 53
Joined: May 2010
Reputation:
0
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.