getaddrinfo failed: Servname not supported for ai_socktype

Sat Aug 7 00:25:02 EDT 2010

  Sorry for clogging your mailboxes with so much mail today.. I'm just 
hoping to really put this program to use. I made a lot more progress on 
an up to date CentOS 5.5 64 bit machine. I got connected, but I still 
can't pass any traffic. It appears from the output below that it was 
trying to pass the traffic, but it wasn't making it for some reason. At 
least I made some progress. Thanks for the tips you have given so far!

[root at VM-MKLinux ~]# openconnect https://216.248.9.102 --no-cert-check 
--script /etc/openconnect.script -v
Attempting to connect to 216.248.9.102:443
SSL negotiation with 216.248.9.102
Server certificate verify failed: self signed certificate
Connected to HTTPS on 216.248.9.102
GET https://216.248.9.102/
Got HTTP response: HTTP/1.1 302 Object Moved
Server: Cisco AWARE 2.0
Content-Type: text/html; charset=UTF-8
Content-Length: 0
Cache-Control: no-cache
Pragma: no-cache
Connection: Keep-Alive
Date: Fri, 06 Aug 2010 21:11:44 GMT
Location: /+webvpn+/index.html
Set-Cookie: tg=; expires=Thu, 01 Jan 1970 22:00:00 GMT; path=/
HTTP body length:  (0)
GET https://216.248.9.102/+webvpn+/index.html
Got HTTP response: HTTP/1.1 200 OK
Server: Virata-EmWeb/R6_2_0
Transfer-Encoding: chunked
Content-Type: text/xml
Cache-Control: max-age=0
Set-Cookie: webvpn=; expires=Thu, 01 Jan 1970 22:00:00 GMT; path=/
Set-Cookie: webvpnc=; expires=Thu, 01 Jan 1970 22:00:00 GMT; path=/
Set-Cookie: webvpnlogin=1
X-Transcend-Version: 1
HTTP body chunked (-2)
Fixed options give
Please enter your username and password.
USERNAME:*******
Password:
POST https://216.248.9.102/+webvpn+/index.html
Got HTTP response: HTTP/1.1 200 OK
Server: Virata-EmWeb/R6_2_0
Transfer-Encoding: chunked
Content-Type: text/xml
Cache-Control: max-age=0
Set-Cookie: webvpnlogin=; expires=Thu, 01 Jan 1970 22:00:00 GMT; path=/
Set-Cookie: 
webvpn=708220747 at 126976@1281129142 at 5B289FC90AAA13E5BACD4E7FEEFDF1583C9D5ABD;PATH=/
Set-Cookie: 
webvpnc=bu:/CACHE/stc/&p:t&iu:1/&sh:97ADED6C8D4A2D38A220B4CD8F1B0B6138C25560&lu:/+CSCOT+/translation-table?textdomain%3DAnyConnect%26type%3Dmanifest;PATH=/
X-Transcend-Version: 1
HTTP body chunked (-2)
Got CONNECT response: HTTP/1.1 200 OK
X-CSTP-Version: 1
X-CSTP-Address: 10.70.6.102
X-CSTP-Netmask: 255.255.255.0
X-CSTP-DNS: 10.85.0.10
X-CSTP-DNS: 10.85.0.11
X-CSTP-Lease-Duration: 43200
X-CSTP-Session-Timeout: 43200
X-CSTP-Idle-Timeout: 3600
X-CSTP-Disconnected-Timeout: 3600
X-CSTP-Split-Include: 10.85.0.0/255.255.0.0
X-CSTP-Split-Include: 10.92.0.0/255.255.0.0
X-CSTP-Split-Include: 172.27.0.0/255.255.0.0
X-CSTP-Keep: true
X-CSTP-DPD: 30
X-CSTP-Keepalive: 20
X-CSTP-Smartcard-Removal-Disconnect: true
X-CSTP-Content-Encoding: deflate
X-DTLS-Session-ID: 
75D2E132842EDFE8AE9C5CD57CB11936FA9BD6ECDD8641BAA707E2F866465AEC
X-DTLS-Port: 443
X-DTLS-Keepalive: 20
X-DTLS-DPD: 30
X-CSTP-MTU: 1406
X-DTLS-CipherSuite: AES128-SHA
CSTP connected. DPD 30, Keepalive 20
DTLS option X-DTLS-Session-ID : 
75D2E132842EDFE8AE9C5CD57CB11936FA9BD6ECDD8641BAA707E2F866465AEC
DTLS option X-DTLS-Port : 443
DTLS option X-DTLS-Keepalive : 20
DTLS option X-DTLS-DPD : 30
DTLS option X-DTLS-CipherSuite : AES128-SHA
SSL_set_session() failed with old protocol version 0x100
Are you using a version of OpenSSL older than 0.9.8m?
See http://rt.openssl.org/Ticket/Display.html?id=1751
Use the --no-dtls command line option to avoid this message
Set up DTLS failed; using SSL instead
Connected tun0 as 10.70.6.102, using SSL + deflate
No work to do; sleeping for 19000 ms...
Send CSTP Keepalive
No work to do; sleeping for 10000 ms...
Send CSTP DPD
No work to do; sleeping for 15000 ms...
Got CSTP DPD response
No work to do; sleeping for 20000 ms...
Send CSTP Keepalive
No work to do; sleeping for 10000 ms...
Send CSTP DPD
No work to do; sleeping for 15000 ms...
Got CSTP DPD response
No work to do; sleeping for 20000 ms...
Sending compressed data packet of 84 bytes
No work to do; sleeping for 18000 ms...
Sending compressed data packet of 84 bytes
No work to do; sleeping for 19000 ms...
Sending compressed data packet of 84 bytes
No work to do; sleeping for 19000 ms...
Sending compressed data packet of 84 bytes
No work to do; sleeping for 19000 ms...
Sending compressed data packet of 84 bytes
No work to do; sleeping for 19000 ms...
Sending compressed data packet of 84 bytes
No work to do; sleeping for 19000 ms...
Sending compressed data packet of 84 bytes
No work to do; sleeping for 19000 ms...
Sending compressed data packet of 84 bytes
No work to do; sleeping for 19000 ms...
No work to do; sleeping for 1000 ms...
Send CSTP Keepalive
No work to do; sleeping for 1000 ms...
Send CSTP DPD
No work to do; sleeping for 15000 ms...
Got CSTP DPD response
No work to do; sleeping for 20000 ms...
Sending compressed data packet of 84 bytes
No work to do; sleeping for 17000 ms...
Sending compressed data packet of 84 bytes
No work to do; sleeping for 19000 ms...
Sending compressed data packet of 84 bytes
No work to do; sleeping for 19000 ms...
Sending compressed data packet of 84 bytes
No work to do; sleeping for 19000 ms...
Send BYE packet: Client received SIGINT

On 8/6/2010 10:24 PM, Matthew Kitchin (public/usenet) wrote:
>  On 8/6/2010 6:12 PM, David Woodhouse wrote:
>>
>> Well, you could try just creating a one-line /etc/services file with
>> just 'https 443/tcp' in it -- that would probably work around the issue
>> you're seeing.
>>
> I added the line to /etc/services
> I get a different error now. I think I'm going to get it running on a 
> desktop so I have a few more unknowns.
>
> root at OpenWrt:~# openconnect https://216.248.9.102
> getaddrinfo failed: Name or service not known
> Failed to open HTTPS connection to https://216.248.9.102
> Failed to obtain WebVPN cookie
>
>
>> But still, you *ought* to update to v2.25.
>>
>> (Btw, the reason your BlackBerry response got trapped for moderation was
>> because it's broken -- it doesn't have a References: or In-Reply-To:
>> header as RFC5322 says it SHOULD, so the threading information is lost.
>> I was about to approve it anyway, since this list isn't particularly
>> high-volume and we can live with the odd breakage, but you beat me to it
>> and cancelled it. Do file a bug report for that if you have the chance.)
>>
>