Blocking traffic to Videostream on local network

[grahamkennery]

Videostream hits known IP addresses on your local network using HTTP on port 5556 - all of these requests are being blocked by Adblock Plus Android 1.3.

Looking at the logs on my dev build of Videostream, it is able to discover the IP addresses, but not actually retrieve the status from the local computers.

Environment

Adblock Plus Android 1.3

How to reproduce

1. Install Videostream on your Desktop: ​https://chrome.google.com/webstore/detail/videostream-for-google-ch/cnciopoikihiagdjbjpnocolokfelagl

2. Install Videostream on your Android device: ​https://play.google.com/store/apps/details?id=com.videostream.Mobile

3. Attempt to use Videostream on your Android device

Observed behaviour

Videostream cannot find the computer

Expected behaviour

Videostream can find the computer

[rjeschke]

I tried to reproduce this issue using:

PC:

• Ubuntu 14.04 64 bit
• Chrome Version 43.0.2357.65 (64-bit)

Android:

• Samsung Galaxy S2 (rooted)
• Android 4.2.2 (CyanogenMod 10.1.3-i9100)
• Adblock Plus for Android v1.3 (root access)

My results:

• pairing works
• browsing videos works
• playing videos works

So no issues here.

Could you provide some more information please? Especially the following:

• Android device name
• Android version
• rooted yes/no
• Adblock Plus configuration type (root, automatic, manual WiFi proxy)
• active filter lists

[grahamkennery]

Woah - sorry for the delay, didn't get an email update on this.

PC:

• Windows 8.1
• Chrome Version 43.0.2357.81 (64-bit)

Android:

• Samsung Galaxy Nexus
• Android 4.3
• Adblock Plus for Android v1.3
• NO ROOT ACCESS
• Default configuration: Manual WiFi proxy, EasyList

Results:

• No network requests make it to the computer
• Cannot complete onboarding
• Cannot pair
• Cannot select videos

Testing out some more phones in a few minutes

[grahamkennery]

Same results with:

Android:

• Moto G (First generation)
• Android 4.4.4
• Adblock Plus for Android v1.3
• NO ROOT ACCESS
• Default configuration: Manual WiFi proxy, EasyList

[grahamkennery]

Also same results with:

Android

• LG Nexus 5
• Android 5.1
• Adblock Plus for Android v1.3
• NO ROOT ACCESS
• Default configuration: Manual WiFi proxy, EasyList

[rjeschke]

Thank you, the key here was 'no root access'.

The bug is caused by a erroneous header that is sent (from the Android client) when the proxy is specified manually via the WiFi settings.

The requests look like this:

05-29 17:46:06.882: I/ProxyService(6167): Request 24 GET http://192.168.1.211:5556/status?keystoneId=...keystoneVersion=1 HTTP/1.1
05-29 17:46:06.882: I/System.out(6167): Content-length: 
05-29 17:46:06.887: I/System.out(6167): Accept-Encoding: identity
05-29 17:46:06.887: I/System.out(6167): Connection: close
05-29 17:46:06.887: I/System.out(6167): User-Agent: Dalvik/1.6.0 (Linux; U; Android 4.2.2; GT-I9100 Build/JDQ39E)
05-29 17:46:06.887: I/System.out(6167): Host: 192.168.1.211:5556
05-29 17:46:06.892: I/Error(6167): 411 Length Required: 

As you can see Content-length: is:

1. Wrongly capitalized
2. Empty
3. Totally misplaced, as GET should not submit any content at all

This results in our proxy sending a 411 Length Required response back, which is absolutely correct behaviour, as even an nginx will respond with a 400 Bad Request here.

This leads to some more questions:

• How do you issue those requests?
• What kind of library is sending it?
• Do you have control over the request creation?

[grahamkennery]

Woah - totally see that errant header - going to see if it's something we're doing explicitly somehow or the wrapper we're using.

[philll]

Wrongly spam-blocked posts from grahamkennery:
Whelp - there it is. Found a way to explicitly block that header from being added. I'm going to push out a build to our beta group to verify, they were the ones who tracked this down in the first place.

Thanks a million for looking into this and tracking it down! I'll let you know if the beta-brigade still has issues.