Cannot connect to Kodi by IP (but same Kodi works on another phone)
Closed this issue · 12 comments
Bug report
Describe the bug
I am trying to set up Kore on a new phone. I works fine (in the same network for the same Kodi) on another phone.
I first tried to automatically search for Kodi, which showed no results. Then I tried adding Kodi by hand by giving its IP, but the connection test failed and then it refuses to add the device.
Curiously, on the other phone where Kodi works fine, the connection test also fails. The connection works though! Looks like the connection test is broken?
Steps to reproduce:
- Enter the IP and port of the Kodi device: 192.168.178.38, port 80
- click "test connection"
Expected Behavior
It should add the device
Actual Behavior
It says that the connection test failed
Possible Fix
To Reproduce
(see above)
Debuglog
Kodi or Kore debug logs?
It doesn't even connect to Kodi, and I see no "debug log" option in Kore
Your Environment
Used Operating system:
- Mobile device: Sony Xperia
- Android version: 13
- Kodi version and platform: 20.2, OSMC 2023.12
- Kore version: v3.0.0 (F-Droid)
note: Once the issue is made we require you to update it with new information or Kodi versions should that be required.
Team Kodi will consider your problem report however, we will not make any promises the problem will be solved.
Interesting -- I noticed that the HTTP remote control is disabled in the Kodi settings. After enabling it, connecting the new phone works fine. And then I can disable it again and Kore still works. Looks like the HTTP part is needed to set up new connections but not for actually operating the remote?
That smells like a bug. If HTTP is turned off by user it should be turned off. Can you please disable HTTP in Kodi and show output of netstat -pan | grep LISTEN from OSMC's ssh session?
My assumption was that Kore uses some TCP/UDP based protocol to talk directly to Kodi, and doesn't need the HTTP channel any more. But I don't actually know. 🤷
Regarding the open ports, here's what I get for IPv4:
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:1726 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:36666 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:9090 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:1424 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:50152 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:1505 0.0.0.0:* LISTEN -
No port 80 indeed. But the Kore settings also say "use TCP" (port 9090), and that one is indeed still open.
Just the connection test fails even when "use TCP" is enabled, so no new connections can be set up it seems.
AFAIK, kore uses a combination of EventServer & JSON-RPC to control Kodi. I think though that the initial network discovery is done via http, hence needing the webserver on. The EventServer is UDP based and on port 9777 as default.
There is some information in the wiki -> https://kodi.wiki/view/Settings/Services/Control
@basilgello Not a bug on Kodi, it's just the way Kore works.
When saving new connections Kore requires an HTTP connection to Kodi, as all images are fetched by HTTP. If HTTP is not possible new connections aren't saved.
But... Kore also works through TCP (and UDP via the Event Server) (for responsiveness), so if on a previously saved connectionto Kodi, HTTP is disabled on Kodi, Kore can keep working (minus the images) if TCP/UDP connections are allowed on Kodi.
Ah, if 9090 is listening on all interfaces, then the behavior is indeed correct.
It's certainly frustrating to have a perfectly working connection that I cannot edit because according to Kore, the media center cannot be reached... maybe the connection test should fall back to TCP port 9090 the same way the actual app logic does?
Well, as i said, Kore assumes that HTTP is mandatory for a connection, otherwise images won't be shown.
Is there any reason for you not to have the HTTP port on Kodi open, but have 9090 open? You can change the http port to something else, if 80 is too "obvious" for your network.
No specific reason, just thinking "the fewer services are enabled the better". I didn't know the HTTP port was even used; when I disabled it and the remote continued working (which was a long time ago), I assumed the remote didn't need HTTP. So when, a year later, I tried to setup a new remote, I had entirely forgotten about this.
Ok. If you want to disable something, it should be the setting "Allow remote control on other systems", which disables TCP and the EventServer. Leaving HTTP on, with a user/password is the safest option.
Closing this, as it is not really a bug.