Devices being filtered out

[Stefan Kahn]

Hi, what conditions will cause a device to be filtered out?

[Simo Kinnunen]

What exactly is the stf local (or stf provider) command you run?

On Thu, Feb 2, 2017 at 11:05 Stefan Kahn <stefa...@slingshot.co.nz> wrote:

Hi, what conditions will cause a device to be filtered out?

--
You received this message because you are subscribed to the Google Groups "OpenSTF" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openstf+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openstf/c75c7210-0701-4530-8e7b-1f0238b28406%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Stefan Kahn]

Hi Simo, Im running the provider with this.

stf provider --name auk-pdmactet01 --min-port 7400--max-port 7700 --connect-sub tcp://10.28.245.10:7114 --connect-push tcp://10.28.245.10:7116 --group-timeout 900 --public-ip 10.28.245.10 --storage-url http://10.28.245.10:7102/ --adb-host 127.0.0.1 --adb-port 5037 --vnc-initial-size 600x800

What other information would help?

[Simo Kinnunen]

Could you take a screenshot of your console that shows both the command and the output where it says the devices were filtered out?

To view this discussion on the web visit https://groups.google.com/d/msgid/openstf/7af914fa-d172-44ee-823f-5e36df49b652%40googlegroups.com.

[Stefan Kahn]

[Simo Kinnunen]

There's no space after 7400. This causes --min-port to get a value of "7400--max-port" and 7700 becomes a positional argument. Positional arguments are used to specify serial numbers you want to use STF with. Since none of the serial numbers matches 7700, everything gets filtered out.

To unsubscribe from this group and stop receiving emails from it, send an email to openstf+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openstf/df1ff56e-a529-4a4b-9698-bdc6ad0f89f9%40googlegroups.com.

[Stefan Kahn]

Thanks for pointing that out. What a small thing to miss.

On to the next question. prior to missing the space i saw this behavior.

What conditions will cause a device not to be provided?

[Simo Kinnunen]

It's not actually ignoring the device in that case. It just means that it hasn't received a reply from the processor that it was successfully registered. Meaning that it's probably unable to connect to the push and/or sub endpoint.

To unsubscribe from this group and stop receiving emails from it, send an email to openstf+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openstf/7d062496-bc0d-4960-b64d-340adb604823%40googlegroups.com.

[Stefan Kahn]

Thanks.

Are there any logs that would show that? or any way to enable further logging?

 

[Simo Kinnunen]

Not really. ZeroMQ sockets wait for a connection to be established, and keeps messages buffered until it can do that. It's not in an error state, it's just waiting. You can try connecting to the addresses over nc, socat or even telnet... maybe you'll find that they're inaccessible. Could be that your port numbers are wrong, or perhaps there's a firewall.

On Fri, Feb 3, 2017 at 4:13 AM, Stefan Kahn <stefa...@slingshot.co.nz> wrote:

Thanks.

Are there any logs that would show that? or any way to enable further logging?

 

--

You received this message because you are subscribed to the Google Groups "OpenSTF" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openstf+unsubscribe@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openstf/8c8b52d4-703e-474e-b750-745adda5eb10%40googlegroups.com.

[Stefan Kahn]

I found the issue.

The triproxy & processors was listening on 127.0.0.1, once changed to the IP of the host machine they connect.

Thanks for all your help.

On Friday, February 3, 2017 at 8:18:04 AM UTC+13, Simo Kinnunen wrote:

Not really. ZeroMQ sockets wait for a connection to be established, and keeps messages buffered until it can do that. It's not in an error state, it's just waiting. You can try connecting to the addresses over nc, socat or even telnet... maybe you'll find that they're inaccessible. Could be that your port numbers are wrong, or perhaps there's a firewall.

On Fri, Feb 3, 2017 at 4:13 AM, Stefan Kahn <stefa...@slingshot.co.nz> wrote:

Thanks.

Are there any logs that would show that? or any way to enable further logging?

 

--
You received this message because you are subscribed to the Google Groups "OpenSTF" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openstf+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

[terminalone]

Hi Stefan,

I am facing the same issue.Which host should the triproxy and processor point ???

my setup is :

master : all process + provider1 = adbd

slave provider2 and adbd

also what should be push ad pull provider point to???