Fail on http post request to router. about goupnp HOT 12 CLOSED

This is a bit of an odd one. It sounds like the router might be responding with a malformed HTTP header when responding to the POST.

To check, you could use a packet sniffer while running your code to look at network traffic between the computer making the SOAP call to the router and the router itself. Maybe filter for traffic to/from 192.168.0.1. You should be able to find an HTTP request that goes to the router.

I suspect from the error that the router is returning a first line response that looks something like:

HTTP1.1 200 OK
<some HTTP headers ...>

The 200 OK bit is irrelevant for this specific error. The HTTP1.1 is what I am focusing on, and it should be HTTP/1.1 (i.e with a slash). If that's the case, then the router's SOAP implementation is buggy. That might be something you can work around, though but first we should confirm if that's the case.

If that's not the case, would you be able to share the HTTP request (and response if there is one) from that single SOAP request?

from goupnp.

Hello @huin :)
Thanks for kind replying!

Picture 2 (Get response on InternetGatewayDevice)

Picture 3 (HTTP Post)

Picture 4 (Bad request ...??)

Can you give an advice based on these information?
I will call my router company to figure out whether my router model is supported SOAP response or not tomorrow(today is holiday in Korean time)

from goupnp.

Interesting. So it confirms my suspicion that the router is returning a badly formed HTTP response. That might be something that could be worked around by injecting a transport into the SOAP client's HTTPClient, but it sounds like it wouldn't be worth doing so because we're getting a 400 bad request anyway. I'm guessing that it's their error response handler that's producing the bad HTTP header, presumably they only tested the success paths.

In terms of getting something working for you, this is tricky: it would be necessary to work out what the router doesn't like about the SOAP request sent by the library. Unfortunately all we've got to go on is "Bad Request". This could mean something that the router didn't like about the HTTP headers or the XML body, it's not clear. Working this out would presumably be trial and error with manually constructed SOAP requests. If that was worked out, then there's the question of how the goupnp library might be adapted to being able to send them. Unfortunately, without knowing exactly what the router is unhappy about there's not much more I can add here :(

from goupnp.

Okay... I have last 2 questions :

1. You mean that this problem is relevant with my router implementation(specifically, my router vendor?)?

2. I have no experience how your library works because your library functions don't work in my environment. so my question is your 'AddPortMapping' function performs that my router force to open the port given? If so, is this not illegal? is this standard? I know that Ethereum, Bitcoin, Bittorrent have tech like this.

from goupnp.

1. Answer: half yes, half unknown.

• The half yes bit is just about the malformed "HTTP1.1 400 Bad Request" bit, which is malformed, and the Go HTTP library is rejecting it.
• The half unknown bit leads onto the next answer.

2. Answer: I don't know that there's anything wrong with the library, as far as I know, others have managed to use it (or other SOAP functions) for their routers. It's possible that your router doesn't support it - you could check the response XML from http://192.168.0.1:1780/InternetGatewayDevice.xml to see if it's one of the supported methods. Check if that XML contains "AddPortMapping". If not, then it's probably not supported (the goupnp library doesn't actually check the XML). If it is present, then I suspect that it's a problem with how the router parses the HTTP request or the SOAP envelope inside it.

from goupnp.

Oh! absolutely there is no 'AddPortMapping' in http://192.168.0.1:1780/InternetGatewayDevice.xml

It means that my router no support AddPortMaping which is standard in UPnP?

I was wondering that AddPortMapping function in your library performs that my router force to open given port? (please answer about this.. I really want to know..! )

from goupnp.

Ah, that explains it then. I'm not 100% sure, but I think that routers don't have to implement all the features provided. The goupnp library assumes that all the features are provided.

Unfortunately if the router doesn't offer that SOAP method, then the goupnp library won't be able to forward the port.

from goupnp.

OK, alright.

The last question that I did is not related to whether your library works well or not.

I know that "AddPortMaping" is a standard function that force router to open given port.

Is your library also implemented this feature?

from goupnp.

The goupnp library does implement it, yes.

from goupnp.

Thanks..

This is really last question...

Do you know why this feature is standard?
Some people may dislike that their port is automatically opened by third-party application.
I searched about this but there is no reason anywhere.

Sorry for hassle.

from goupnp.

Oh! Jesus! I have found the solution :)

The solution is 'miniupnp'

Very cool :)

Thanks for very kind replying @huin :)

from goupnp.

I hope it helped :)

from goupnp.