Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test failed:null with proxy #2045

Closed
gerroon opened this issue Jun 26, 2016 · 8 comments · Fixed by #5151
Closed

Test failed:null with proxy #2045

gerroon opened this issue Jun 26, 2016 · 8 comments · Fixed by #5151
Labels
Type: Possible bug Issues that seem to be a bug, but haven't been confirmed yet

Comments

@gerroon
Copy link

gerroon commented Jun 26, 2016

App version: 1.x (from Google Play/F-Store/Custom build)
F-droid

Android version: 5.x [Please mention if you are using a custom rom!]
5.1.1

Devide model:
Samsung Note

Expected behaviour:
Working proxy

I put my working Privoxy proxy in the setting and pres test and all I am getting is "test failed:null". When I watch the logcat for activity, I see no activity when I press the test button. Nothing is printed afterwards as if Apod is not doing anything except "D/WifiWatchdogStateMachine(20590): isPackageRunning - top:de.danoeh.antennapod.activity.PreferenceActivity
". I am not sure if there is a way to debug the proxy here.

My proxy works in my browsers.

Maybe there should also another buttong that just says "save" so the user can save regardless of what this testing is trying to do. I suspect that it is trying to connect to some google ip to do some testing.

thanks

@gerroon gerroon changed the title Test faıledŞnull wıth proxy Test failed:null with proxy Jun 26, 2016
@mfietz
Copy link
Contributor

mfietz commented Jun 26, 2016

When I watch the logcat for activity

Release builds don't contain logging...

Maybe there should also another buttong that just says "save" so the user can save regardless of what this testing is trying to do.

If it does not work, it doesn't make sense to let the user go forward anyway. It won't suddenly start working.

@mfietz
Copy link
Contributor

mfietz commented Jun 26, 2016

Also, please add steps to reproduce. What are the privoxy settings (only if not default) and what are you putting in that dialog?
(Steps to reproduce are the most important part of any bug report, really. I can live without most of the other information - but how am I supposed to debug an issue if I cannot reproduce it locally?)

@mfietz
Copy link
Contributor

mfietz commented Aug 6, 2016

Closed because I do not have enough information to reproduce this.
I would also have to investigate whether privoxy is a socks or a http proxy, android only supports the later.

@draeklae
Copy link

draeklae commented Feb 19, 2019

I am having this error using the latest version (1.6.4.5) and an HTTP proxy which requires authentication (i.e., user/password). It seems the proxy "test" works as long as the user field is not set; otherwise, it produces the mysterious "null" error.

Therefore, this seems not restricted to privoxy and can be reproduced (and debugged) using a standard HTTP proxy which supports basic authentication (e.g., squid). Please reopen.

@ByteHamster
Copy link
Member

1.6.4.5 was released more than a year ago. The latest version in 1.7.1. I don't think there have been any changes to proxy handling, but just to be sure: please update to the latest version and check if you can still reproduce the error.

@draeklae
Copy link

Whoops, sorry for that (it seems updates weren't working on my device... weird).

After installing 1.7.1, however, I can confirm the error still occurs.

@ByteHamster ByteHamster reopened this Feb 19, 2019
@matdb
Copy link
Contributor

matdb commented Mar 9, 2019

I was able to reproduce this, for me it looks like there is no attempt to authenticate if a username and password are provided, so something about the connection setup and authentication must be wrong. I'll try to fix it, but I don't know much about Okhttp and HTTP proxies, so this might take some time. While I'm at it I'll see if I can make extended ASCII passwords work if those are allowed in HTTP proxies (as with #3054 the Credential object is made with the default LATIN1 charset)

@keunes keunes added the Type: Possible bug Issues that seem to be a bug, but haven't been confirmed yet label Oct 2, 2020
@antennapod-bot
Copy link

This issue has been mentioned on AntennaPod Forum. There might be relevant details there:

https://forum.antennapod.org/t/proxy-settings-not-working/946/1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Possible bug Issues that seem to be a bug, but haven't been confirmed yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants