Closed KennethWilke closed 8 years ago
Ah, Adi informed me this happens if you don't use cookies. It seems a bit odd that the server doesn't return anything for this. Would probably be more appropriate to return a 401 error in response to the unauthorized request.
I started getting this error after a Debian update. After running autoremove, which removed a lot of old libs including an old version of GnuTLS, everything started working again. It occurred whether or not curl was accessing a site with a cached cookie. It happened not only with curl but also with Chromium, which uses gnutls. Since GIT uses libcurl, it was also affecting GIT cloning from Github.
@KennethWilke assuming I change the response to 401 as discussed in https://github.com/openbmc/phosphor-rest-server/issues/25 is there any additional issue to be addressed here you think?
I think the issue here is a little different, a 401 would be good as in #25, but in this issue there's no response from the server whatsoever, it just terminates the connection without any response.
I guess maybe I fixed it somewhere along the line:
[toshiba:openbmc]$ /bin/curl -vk https://192.168.254.77/
* About to connect() to 192.168.254.77 port 443 (#0)
* Trying 192.168.254.77...
* Connected to 192.168.254.77 (192.168.254.77) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* skipping SSL peer certificate verification
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
* subject: CN=localhost,O=openbmc.org,L=Default City,C=XX
* start date: Nov 06 20:35:06 2015 GMT
* expire date: Nov 05 20:35:06 2016 GMT
* common name: localhost
* issuer: CN=localhost,O=openbmc.org,L=Default City,C=XX
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 192.168.254.77
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< Content-Length: 111
< Content-Type: application/json
< Date: Thu, 08 Sep 2016 15:49:39 GMT
<
{
"data": {
"description": "Login required"
},
"message": "401 Unauthorized",
"status": "error"
* Connection #0 to host 192.168.254.77 left intact
}[toshiba:openbmc]$
@KennethWilke go ahead and reopen if it pops up again.
I'm trying to take another crack at consuming this API. So far I'm not getting any responses from my BMCs. My test below:
This BMC is running the v0.6-stable branch of OpenBMC, the host I'm trying to hit has been up about 45 minutes. How should I go about troubleshooting this further?