Has anyone ran into an issue where the Roku does not respond to port 8060? I cannot replicate the the issue locally, but there is a user (with multiple Rokus) that cannot connect to port 8060 via the lan IP or http://127.0.0.1:8060 from within a channel. I can’t say with certainty 7.1 is when this first started, but we noticed it then since the roVideoPlayer does not reset the idle time during video playback (separate issue).
I’ve identified the issue. It seems when the Roku is assigned a non RFC 1918 ip address, the Roku locks down port 8060 (probably due to viewtopic.php?f=34&t=88160). This is great, however this also blocks access to ECP within the channel on loopback, no so great. This has been causing some havoc in our channel with the release of 7.1. Please let me know if you (Roku) need anything else.
Your channel likes talking to itself, huh.
Is it using the external IP for that? If so, try localhost instead.
“EnTerr” wrote:
Your channel likes talking to itself, huh.
Yes, it does. roScreens do not allow the use of the standard screensaver (only a black out), so if you have a custom one, you must keep the Roku non-idle. The only way to do that is to use ECP to send a keypress. Ignoring the use of a custom screensaver, another issue is a custom slideshow written using the 2D API where one must also inhibit the standard black screensaver. As you can imagine, there are other things that may use the idle time of the Roku to fire event, such as a lock screen.
“EnTerr” wrote:
Is it using the external IP for that? If so, trylocalhostinstead.
Sorry, I wasn’t clear. I am not using the external/public IP. It makes sense to block access to the public IP, but they are also blocking access to localhost/127.0.0.1. It seems they just disable or completely block port 8060. Other ports, such as 8085 continue to work.
Use CreateObject(“roDeviceInfo”).GetIpAddrs() to find your Roku’s ip address on the local network. Send your keypress ECP commands to port 8060 at the ip address(es) it returns.
“belltown” wrote:
Use CreateObject(“roDeviceInfo”).GetIpAddrs() to find your Roku’s ip address on the local network. Send your keypress ECP commands to port 8060 at the ip address(es) it returns.
Thanks Belltown, this does not work. I am familiar with the roDeviceInfo, but here is the deal. Port 8060 is disabled in firmware 7.1 when your Roku is using a non RFC 1918 IP address. The Roku will not respond to port 8060 on the local IP address assigned or on 127.0.0.1 from within a channel. You can experience this if you give your Roku any IP address outside of the RFC 1918 address space. e.g. setup your lan (incorrectly) to use something like “11.0.0.0/24”. Obviously this is wrong, but users will do this, as well as some will have their devices connected to the internet without a router/firewall (assigning real public IPs).
“ljunkie” wrote:
“belltown” wrote:
Use CreateObject(“roDeviceInfo”).GetIpAddrs() to find your Roku’s ip address on the local network. Send your keypress ECP commands to port 8060 at the ip address(es) it returns.Thanks Belltown, this does not work. I am familiar with the roDeviceInfo, but here is the deal. Port 8060 is disabled in firmware 7.1 when your Roku is using a non RFC 1918 IP address. The Roku will not respond to port 8060 on the local IP address assigned or on 127.0.0.1 from within a channel. You can experience this if you give your Roku any IP address outside of the RFC 1918 address space. e.g. setup your lan (incorrectly) to use something like “11.0.0.0/24”. Obviously this is wrong, but users will do this, as well as some will have their devices connected to the internet without a router/firewall (assigning real public IPs).
Port 8060 is disabled in firmware 7.1 when your Roku is using a non RFC 1918 IP address.
This isn’t new behavior in firmware 7.1, but has been the case for many years.
As you describe, ECP services (port 8060) are not enabled when the Roku has a non-RFC 1918 IP address, for security reasons.
If something was working for your app prior to 7.1 and stopped working, possibly it is due to other security constraints.
I can certainly understand the wish that loopback services still worked in this situation, but it isn’t set up that way as this is not a normal usage.
Do you think that some users are intentionally configuring their Rokus this way?
Perhaps the firmware should have a warning UI in the guided setup or in the settings UI if the user has this configuration.
“RokuKC” wrote:
Port 8060 is disabled in firmware 7.1 when your Roku is using a non RFC 1918 IP address.
This isn’t new behavior in firmware 7.1, but has been the case for many years.
As you describe, ECP services (port 8060) are not enabled when the Roku has a non-RFC 1918 IP address, for security reasons.
If something was working for your app prior to 7.1 and stopped working, possibly it is due to other security constraints.
Thanks for the update RokuKC. That makes sense, and after knowing this piece of info, it makes more sense. We have had other screens affected by this issue without understanding it was an issue. The fact that the video players (roVideoPlayer and roVideoScreen) no longer reset the idle time (mentioned in my initial post) was the coup de grace. We have a workaround for that now, awaiting Roku’s approval, but I’d be nice if playback rest the idle time again - is that a bug or expected?
“RokuKC” wrote:
I can certainly understand the wish that loopback services still worked in this situation, but it isn’t set up that way as this is not a normal usage.
Do you think that some users are intentionally configuring their Rokus this way?
Perhaps the firmware should have a warning UI in the guided setup or in the settings UI if the user has this configuration.
The users are not configuring their Roku this way on purpose, but they have misconfigured their network this way for whatever reason. While it’s not valid, I can understand why one may accidentally configure their network with in invalid block, i.e. 194.168.0.x/24. Set aside an invalid configuration, it’s still possible for people to have valid public IP addresses without a misconfiguration. Basically what it boils down to is finding some way to tell the Roku it’s not idle.
A quick recap
- The roVideoPlayer/roVideoScreen used to reset the idle time every 10 seconds. This no longer happens in 7.1. Can this be corrected?
- Is there a valid way to tell the Roku it’s not idle from within a channel. The ECP method was the only way, and as I take it will never work again going forward unless the Roku uses an RFC 1918 IP address. One example to clarify why this is important: A custom slide show written in an roScreen, or even roImageCanvas. Without a way to reset the idle time during playback, the Roku will initialize the the (black) screensaver rendering it useless.
“ljunkie” wrote:
- The roVideoPlayer/roVideoScreen used to reset the idle time every 10 seconds. This no longer happens in 7.1. Can this be corrected?
I can file a report, but it might help to have more information, as I haven’t heard of this issue being reported by anyone else.
“ljunkie” wrote:
- Is there a valid way to tell the Roku it’s not idle from within a channel. The ECP method was the only way, and as I take it will never work again going forward unless the Roku uses an RFC 1918 IP address. One example to clarify why this is important: A custom slide show written in an roScreen, or even roImageCanvas. Without a way to reset the idle time during playback, the Roku will initialize the the (black) screensaver rendering it useless.
We’ve documented a function in roAppManager which is UpdateLastKeyPressTime() that can be used to defer the screensaver activation.
Calling this should be preferred over the ECP fake keypress technique.
“RokuKC” wrote:
We’ve documented a function in roAppManager which is UpdateLastKeyPressTime() that can be used to defer the screensaver activation.
Calling this should be preferred over the ECP fake keypress technique.https://sdkdocs.roku.com/display/sdkdoc … PressTime(asVoid
That function was just added to docs 29 April but does not mention firmware version. What fw is it applicable to?
I lest i am told “everybody has 7.1” - somebody with lots of deployments recently was saying there is a good portion of firmware 5 out there?!
“EnTerr” wrote:
“RokuKC” wrote:
https://sdkdocs.roku.com/display/sdkdoc … PressTime(asVoid
That function was just added to docs 29 April but does not mention firmware version. What fw is it applicable to?
roAppManager UpdateLastKeyPressTime is present on all active (non-legacy) firmware versions.
“RokuKC” wrote:
“ljunkie” wrote:
- The roVideoPlayer/roVideoScreen used to reset the idle time every 10 seconds. This no longer happens in 7.1. Can this be corrected?
I can file a report, but it might help to have more information, as I haven’t heard of this issue being reported by anyone else.
We use roDeviceInfo.TimeSinceLastKeypress() to fire off various events, and it caused a nasty bug when this wasn’t reset during video playback. The probably for us is fixable on our side, now that you have mentioned we can reset this on all current gen devices with roAppManager.UpdateLastKeyPressTime().
“RokuKC” wrote:
“ljunkie” wrote:
- Is there a valid way to tell the Roku it’s not idle from within a channel. The ECP method was the only way, and as I take it will never work again going forward unless the Roku uses an RFC 1918 IP address. One example to clarify why this is important: A custom slide show written in an roScreen, or even roImageCanvas. Without a way to reset the idle time during playback, the Roku will initialize the the (black) screensaver rendering it useless.
We’ve documented a function in roAppManager which is UpdateLastKeyPressTime() that can be used to defer the screensaver activation.
Calling this should be preferred over the ECP fake keypress technique.
Thank you! That fixes our issue. Appreciate the info. I really am curious how many other undocumented features there? e.g. roAppManager.GetScreensaverTimeout()
Anyone have an example implementation of UpdateLastKeyPressTime()?
Thanks
“rjdjohnston” wrote:
Anyone have an example implementation of UpdateLastKeyPressTime()?Thanks
Here is a really basic example of it working, showing you that the Roku was idle for 71 seconds and was reset back to 0 by calling UpdateLastKeyPressTime().
BrightScript Debugger> am = CreateObject("roAppManager")
BrightScript Debugger> di = CreateObject("roDeviceInfo")
BrightScript Debugger> ?di.TimeSinceLastkeyPress()
71
BrightScript Debugger> am.UpdateLastKeyPressTime()
BrightScript Debugger> ?di.TimeSinceLastkeyPress()
0
@RokuKC -
there are 2 issues though, one with UpdateLastKeyPressTime() and one with disabling ECP when not on private IP:
-
How is a non-BrightScript (say Marmalade) app to delay screensaver, given that - well, it has no access to UpdateLastKeyPressTime()? I thought i “invented” a way by defining a private SS in B/S - but that is a no-go because “black screen” is invoked instead of SS for such apps. Using ECP to tickle the player seems like the only workaround.
-
Shutting down ECP server when non-private IP - it does “jack squat” for DMZ Rokus. If a Roku is behind a NAT and the owner has placed it in router’s DMZ (in attempt to improve streaming - which i bet is the prevailing majority of this case) - then said Roku will have IP=192.168.x.x and yet ECP will still be exposed to the Internet at large.
It is because of DMZ that i made a very specific suggestion (#1) in viewtopic.php?f=34&t=88160 - and that is to use IP firewall rules to protect 8060 from connections from outside the local network mask - not selectively shutting down ECP server. And if so, ECP could always be relied to be accessible via loopback interface (localhost or 127.0.0.1).
I guess weighing the options here depends on the statistics of “indecently exposed” Rokus: what’s the % with external IP (with no firewall!) vs % with internal IP (due to DMZ or port forwarding in firewall). I advocate that my approach will cover both cases, where Roku’s covers only one of them (see recent Variety article based on leaks)
“EnTerr” wrote:
- How is a non-BrightScript (say Marmalade) app to delay screensaver, given that - well, it has no access to UpdateLastKeyPressTime()?
I haven’t tried it myself, but it appears to me that roAppManager UpdateLastKeyPressTime() should be callable by NDK apps. Does Marmalade not allow full access?
“EnTerr” wrote:
[list=B:1v4ol5wd]- Shutting down ECP server when non-private IP - it does “jack squat” for DMZ Rokus.
ECP rejects requests from non-private request IPs… does that not apply in this situation, even if the Roku itself has a private IP?
“RokuKC” wrote:
I haven’t tried it myself, but it appears to me that roAppManager UpdateLastKeyPressTime() should be callable by NDK apps. Does Marmalade not allow full access?
Not that i know of - http://docs.madewithmarmalade.com/displ … ctionality says “No” for Roku platform on “Extension Development Kit (EDK)” and “Native toolchain access”. And the NDK i have laid my eyes on was something truly vintage - circa 2012-2013. That won’t cover these new-fangled features, would it?
“RokuKC” wrote:
“EnTerr” wrote:
[list=B:33oryyvz]- Shutting down ECP server when non-private IP - it does “jack squat” for DMZ Rokus.ECP rejects requests from non-private request IPs… does that not apply in this situation, even if the Roku itself has a private IP?
Hmmm, if by source IP - it “shoulda” blocked :?:. But if that were indeed the case for years, how come certain someone is able through scanning to identify and interrogate thousands of Roku’s on the Net? Current data apparently.
“EnTerr” wrote:
Not that i know of - http://docs.madewithmarmalade.com/displ … ctionality says “No” for Roku platform on “Extension Development Kit (EDK)” and “Native toolchain access”. And the NDK i have laid my eyes on was something truly vintage - circa 2012-2013. That won’t cover these new-fangled features, would it?
That sounds like something to ask the Marmalade support about. I don’t have any visibility into that.
“EnTerr” wrote:
Hmmm, if by source IP - it “shoulda” blocked :?:. But if that were indeed the case for years, how come certain someone is able through scanning to identify and interrogate thousands of Roku’s on the Net? Current data apparently.
I don’t see much there. Without researching it specifically, I would guess those are legacy devices.
Hi everyone,
Since update to OS 12.0, the ECP commands are not working within the dev app (in-app testing). Response code is now 403 whereas in OS 11.5 and before it was always 200.
'cmd = [ECP command]
'RokuIP = [local IP of Roku device, RFC1918 address]
request = CreateObject("roUrlTransfer")
m.port = createObject("roMessagePort")
request.setMessagePort(m.port)
urlString = "http://" + RokuIP + ":8060/" + cmd
request.SetUrl(urlString)
if request.AsyncGetToString() then
'if request.AsyncPostFromString("") then
msg = m.port.waitMessage(0)
print msg.GetResponseCode()
end if
If instead an ECP command is sent from a local pc, the same Roku device on OS 12.0 executes it and the response code is 200. So definitely this new blocking is affecting the dev app.
>~ curl -w "%{http_code}" -d '' "http://"$RokuIP":8060/"$cmd
200
I have the same problem trying to restart my app so that it takes some configuration changes.
