Re: Add Diffie-Hellman group negotiation to iked

2017-07-23 Thread viq
On 17-07-18 23:20:26, Tim Stewart wrote:
> viq <vic...@gmail.com> writes:
> 
> > On 17-06-25 21:44:24, Tim Stewart wrote:
> >> Hi,
> >>
> >> In this message I've tried to encode everything I've done to allow
> >> strongSwan on Android to connect with iked, including the latest patch.
> >> I have also verified that it breaks neither initial negotiation nor
> >> Child SA rekeying for OpenBSD, Windows, and strongSwan (on Android)
> >> clients.
> >
> >  This patch gets my android phone much closer to being able to negotiate
> >  a connection, but there are still issues. Paraphrasing analysis mikeb
> >  performed on IRC:
> >  android sends incorrect (for us) group, and with this patch we now send
> >  a failure message and android retries. But, we don't increment msgid
> >  "because we did sa_free and restarted, so we can assume that android
> >  thinks that negotiation continues, that's why it re-sends the
> >  IKE_SA_INIT"
> 
> I'm glad it seems to help, though it's too bad that the patch doesn't
> work completely for you.
> 
> I haven't really considered msgids--I'll do some more reading to see
> what I might be missing there.  I do know that resending an IKE_SA_INIT
> message with a different DH group is correct, however, and this does
> work on my phone.  For your reference, the first line of my strongSwan
> log tells me that I'm using strongSwan 5.5.3 and Android 7.1.1.
> 
> I see that you forwarded the iked logs in a reply to this email.  Is
> this the full log after a fresh iked startup with no existing SAs?

This is after a fresh startup, there exists an SA but for a separete
site-to-site config I have in place. If completely fresh logs are
needed I could comment that out.

> Also, would it be possible to forward an anonymized config and the
> strongSwan logs so that I can compare to mine?  (I can also post my
> logs, but I'll have to do it in the next day or two as I'm out of time
> for today.)

First, sorry for the delay with replying to this. Second, I'm not sure
how to get to the logs, seeing as I'm using the built-in VPN client that
came with Samsung S8.



Re: Add Diffie-Hellman group negotiation to iked

2017-07-14 Thread viq
And now with log.


ikev2_recv: IKE_SA_INIT request from initiator 37.47.4.5:9911 to 
31.178.147.125:500 policy 'roadwarrior' id 0, 652 bytes
ikev2_recv: ispi 0x5e13d636599e1781 rspi 0x
ikev2_policy2id: srcid FQDN/keibi.viq.im length 16
ikev2_pld_parse: header ispi 0x5e13d636599e1781 rspi 0x 
nextpayload SA version 0x20 exchange IKE_SA_INIT flags 0x08 msgid 0 length 652 
response 0
ikev2_pld_payloads: payload SA nextpayload KE critical 0x00 length 244
ikev2_pld_sa: more than one proposal specified
ikev2_pld_sa: more 2 reserved 0 length 136 proposal #1 protoid IKE spisize 0 
xforms 15 spi 0
ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC
ikev2_pld_attr: attribute type KEY_LENGTH length 256 total 4
ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC
ikev2_pld_attr: attribute type KEY_LENGTH length 128 total 4
ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA2_512_256
ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA2_384_192
ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA2_256_128
ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA1_96
ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA2_512
ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA2_384
ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA2_256
ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA1
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id 
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id ECP_384
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id ECP_256
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id MODP_2048
ikev2_pld_xform: more 0 reserved 0 length 8 type DH id MODP_1536
ikev2_pld_payloads: payload KE nextpayload NONCE critical 0x00 length 264
ikev2_pld_ke: dh group  reserved 0
ikev2_pld_payloads: payload NONCE nextpayload NOTIFY critical 0x00 length 36
ikev2_pld_payloads: payload NOTIFY nextpayload NOTIFY critical 0x00 length 28
ikev2_pld_notify: protoid NONE spisize 0 type NAT_DETECTION_SOURCE_IP
ikev2_nat_detection: peer source 0x5e13d636599e1781 0x 
37.47.4.5:9911
ikev2_pld_notify: NAT_DETECTION_SOURCE_IP detected NAT, enabling UDP 
encapsulation
ikev2_pld_payloads: payload NOTIFY nextpayload NOTIFY critical 0x00 length 28
ikev2_pld_notify: protoid NONE spisize 0 type NAT_DETECTION_DESTINATION_IP
ikev2_nat_detection: peer destination 0x5e13d636599e1781 0x 
31.178.147.125:500
ikev2_pld_payloads: payload NOTIFY nextpayload NOTIFY critical 0x00 length 16
ikev2_pld_notify: protoid NONE spisize 0 type SIGNATURE_HASH_ALGORITHMS
ikev2_pld_notify: signature hash SHA1 (1)
ikev2_pld_notify: signature hash SHA2_256 (2)
ikev2_pld_notify: signature hash SHA2_384 (3)
ikev2_pld_notify: signature hash SHA2_512 (4)
ikev2_pld_payloads: payload NOTIFY nextpayload NONE critical 0x00 length 8
ikev2_pld_notify: protoid NONE spisize 0 type REDIRECT_SUPPORTED
sa_state: INIT -> SA_INIT
ikev2_sa_negotiate: score 4
sa_stateok: SA_INIT flags 0x, require 0x
sa_stateflags: 0x -> 0x0020 sa (required 0x )
ikev2_sa_responder_dh: want dh MODP_2048, KE has 
ikev2_resp_ike_invalid_ke: rejecting with INVALID_KE_PAYLOAD
ikev2_next_payload: length 10 nextpayload NONE
ikev2_pld_parse: header ispi 0x5e13d636599e1781 rspi 0x02275a5878cc81a8 
nextpayload NOTIFY version 0x20 exchange IKE_SA_INIT flags 0x20 msgid 0 length 
38 response 1
ikev2_pld_payloads: payload NOTIFY nextpayload NONE critical 0x00 length 10
ikev2_pld_notify: protoid NONE spisize 0 type INVALID_KE_PAYLOAD
ikev2_msg_send: IKE_SA_INIT response from 31.178.147.125:500 to 37.47.4.5:9911 
msgid 0, 38 bytes
ikev2_resp_recv: failed to get IKE SA keys
sa_state: SA_INIT -> CLOSED from any to any policy 'roadwarrior'
config_free_proposals: free 0x1825d2eef480
ikev2_recv: IKE_SA_INIT request from initiator 37.47.4.5:9911 to 
31.178.147.125:500 policy 'roadwarrior' id 0, 652 bytes
ikev2_recv: ispi 0x5e13d636599e1781 rspi 0x
ikev2_recv: updated SA to peer 37.47.4.5:9911 local 31.178.147.125:500
ikev2_resp_recv: SA already exists
ikev2_recv: closing SA
sa_free: ispi 0x5e13d636599e1781 rspi 0x02275a5878cc81a8
config_free_proposals: free 0x1825d2eefe00
ikev2_recv: IKE_SA_INIT request from initiator 37.47.4.5:9911 to 
31.178.147.125:500 policy 'roadwarrior' id 0, 652 bytes
ikev2_recv: ispi 0x5e13d636599e1781 rspi 0x
ikev2_policy2id: srcid FQDN/keibi.viq.im length 16
ikev2_pld_parse: header ispi 0x5e13d636599e1781 rspi 0x 
nextpayload SA version 0x20 exchange IKE_SA_INIT flags 0x08 msgid 0 length 652 
response 0
ikev2_pld_payloads: payload SA nextpayload KE critical 0x00 length 244
ikev2_pld_sa: more than one proposal specified
ikev2_pld_sa: more 2 reserved 0 length 136 proposal #1 protoid IKE spisize 0 
xforms 15 spi 0
ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC
ikev2_pld_attr: attribute type KEY_LENGTH 

Re: Add Diffie-Hellman group negotiation to iked

2017-07-13 Thread viq
On 17-06-25 21:44:24, Tim Stewart wrote:
> Hi,
> 
> In this message I've tried to encode everything I've done to allow
> strongSwan on Android to connect with iked, including the latest patch.
> I have also verified that it breaks neither initial negotiation nor
> Child SA rekeying for OpenBSD, Windows, and strongSwan (on Android)
> clients.

 This patch gets my android phone much closer to being able to negotiate
 a connection, but there are still issues. Paraphrasing analysis mikeb
 performed on IRC:
 android sends incorrect (for us) group, and with this patch we now send
 a failure message and android retries. But, we don't increment msgid
 "because we did sa_free and restarted, so we can assume that android
 thinks that negotiation continues, that's why it re-sends the
 IKE_SA_INIT"
 
> Stuart Henderson  writes:
> 
> > On 2017/05/22 01:52, Tim Stewart wrote:
> >> Hello again,
> >>
> >> Tim Stewart  writes:
> >>
> >> > Tim Stewart  writes:
> >> >
> >> >> This patch teaches iked to reject a KE with a Notify payload of type
> >> >> INVALID_KE_PAYLOAD when the KE uses a different Diffie-Hellman group
> >> >> than is configured locally.  The rejection indicates the desired
> >> >> group.
> >> >>
> >> >> In my environment, this patch allows stock strongSwan on Android from
> >> >> the Google Play store to interop with iked.  strongSwan's logs show
> >> >> the following once iked is patched:
> >> >>
> >> >>   [IKE] initiating IKE_SA android[7] to 192.0.2.1
> >> >>   [ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) 
> >> >> N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
> >> >>   [ENC] parsed IKE_SA_INIT response 0 [ N(INVAL_KE) ]
> >> >>   [IKE] peer didn't accept DH group ECP_256, it requested MODP_2048
> >> >>   [IKE] initiating IKE_SA android[7] to 192.0.2.1
> >> >>   [ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) 
> >> >> N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
> >> >>   [ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) 
> >> >> N(NATD_D_IP) CERTREQ N(HASH_ALG) ]
> >> >>
> >> >> I'm happy to iterate on this patch to get it into proper shape for
> >> >> inclusion.
> >> >
> >> > I discovered a bug in the previous patch that broke renegotiation of
> >> > CHILD SAs.  I was ignoring "other than NONE" in the following sentence
> >> > from RFC 5996 section 3.4:
> >> >
> >> >   If the selected proposal uses a different Diffie-Hellman group
> >> >   (other than NONE), the message MUST be rejected with a Notify
> >> >   payload of type INVALID_KE_PAYLOAD.
> >> >
> >> > The new patch below repairs the flaw.
> >>
> >> After re-reading relevant parts of the RFC I'm not convinced that my fix
> >> (rejecting with INVALID_KE_PAYLOAD unless msg->msg_dhgroup is
> >> IKEV2_XFORMDH_NONE) is correct.  It happens to resolve my local issue
> >> but I think it may accidentally work due to a side effect of the code
> >> path for rekeying a child SA.
> >>
> >> I will look at it more closely this week.
> 
> My first patch did, in fact, break Child SAs rekeying.  I have a new
> patch at the end of this message that simply restricts DH group
> negotiation to IKE SAs (I *think* that DH group guessing only applies to
> IKE SAs, and perhaps only the IKE_SA_INIT exchange, but I'm still
> working through the RFC).  This may not be the ultimate solution, but it
> does allow us to move forward.
> 
> > Hi, I'm interested in this, but wasn't able to get strongswan to connect
> > with either of your patches (and had iked exiting on one attempt, though
> > I haven't been able to repeat that).
> 
> After making changes I usually rebuild all of /usr/src/sbin/iked/ (make
> clean && make).  I started doing this after experiencing similar exits
> and the problem went away.  That could just be a coincidence, though!
> 
> > If you have any updates please do send them here, it can be a bit slow
> > getting feedback on iked diffs at times but it definitely is worth sending
> > them out.
> 
> I'll summarize what I know about strongSwan (on Android) and iked
> interop.  strongSwan chooses ECP_256 for its DH group guess when it
> starts the IKE_SA_INIT exchange.  The negotiation gets pretty far if I
> specify `group ecp256' in the ikesa directive, but there there is some
> incompatibility between iked and strongSwan that causes the following:
> 
> ...
> ikev2_recv: IKE_AUTH request from initiator 5.6.7.8:49317 to 1.2.3.4:4500 
> policy 'default' id 1, 2040 bytes
> ikev2_recv: ispi 0x4a0221ee629489c0 rspi 0x2459b2780209a1c8
> ikev2_recv: updated SA to peer 5.6.7.8:49317 local 1.2.3.4:4500
> ikev2_pld_parse: header ispi 0x4a0221ee629489c0 rspi 0x2459b2780209a1c8 
> nextpayload SK version 0x20 exchange IKE_AUTH flags 0x08 msgid 1 length 2040 
> response 0
> ikev2_pld_payloads: payload SK nextpayload IDi critical 0x00 length 2012
> ikev2_msg_decrypt: IV length 16
> ikev2_msg_decrypt: encrypted payload length 1968
> ikev2_msg_decrypt: integrity checksum 

Re: Allow install from https server w/ self signed cert

2017-01-06 Thread viq
On Fri, Jan 6, 2017 at 12:33 PM, viq <vic...@gmail.com> wrote:

> I have another issue. I'm preparing OpenBSD vagrant boxes using
> https://packer.io and use it's built in http server to serve install.conf
> file and siteXY.tgz. The whole setup can be seen at
> https://github.com/viq/packer-templates/ and specifically https://github.
> com/viq/packer-templates/blob/master/openbsd-current/http/
> install_amd64.conf
> The trick is, I have to specify the port that server is listening on,
> which causes install to try to connect to that port using https, and drop
> dead there and then as that fails.
>

And no, there isn't really an option to make it serve https short of
stunnel, and that would still leave an issue of presenting a certificate.

-- 
viq


Re: Allow install from https server w/ self signed cert

2017-01-06 Thread viq
I have another issue. I'm preparing OpenBSD vagrant boxes using
https://packer.io and use it's built in http server to serve install.conf
file and siteXY.tgz. The whole setup can be seen at
https://github.com/viq/packer-templates/ and specifically
https://github.com/viq/packer-templates/blob/master/openbsd-current/http/install_amd64.conf
The trick is, I have to specify the port that server is listening on, which
causes install to try to connect to that port using https, and drop dead
there and then as that fails.


rsh vs net/ipcad - problems on 5.5

2014-05-20 Thread viq
I encountered a strange problem when trying to communicate with net/ipcad:

rsh localhost stats
rsh: poll: Undefined error: 0

Same thing on 5.1:
rsh localhost stats
connect to address ::1: Connection refused
Trying 127.0.0.1...
Interface vlan123: received 585816944, 5 m average 313 bytes/sec, 4
pkts/sec, dropped 6078
Flow entries made: 583
Memory usage: 6% (65296 from 1048576)
Free slots for rsh clients: 9
IPCAD uptime is 159 days  7:04
fw.example.com uptime is 159 days  7:04

According to sthen@ this also works fine on 5.4 and he suspects
breakage due to time_t changes. He also provided simple sample config
http://pbot.rmdir.de/iFGRSOehzxnZ1flTJqum5Q because he's awesome like
that ;)

kern.version=OpenBSD 5.5 (GENERIC.MP) #0: Fri Apr 25 13:03:34 CEST 2014

r...@stable-55-amd64.mtier.org:/binpatchng/work-binpatch55-amd64/src/sys/arch/amd64/compile/GENERIC.MP
ipcad-3.7.3p1
-- 
viq



Re: Fix for openssl bug #2240

2011-09-23 Thread viq
I was told the diff got mangled, so here's another attempt.
--
viq

Index: t1_lib.c
===
RCS file: /cvs/src/lib/libssl/src/ssl/t1_lib.c,v
retrieving revision 1.8
diff -u -d -r1.8 t1_lib.c
--- t1_lib.c10 Feb 2011 22:40:27 -  1.8
+++ t1_lib.c23 Sep 2011 19:38:13 -
@@ -1453,23 +1453,20 @@
int al = SSL_AD_UNRECOGNIZED_NAME;

 #ifndef OPENSSL_NO_EC
-   /* If we are client and using an elliptic curve cryptography cipher 
suite,
then server
-* must return a an EC point formats lists containing uncompressed.
+   /* If we are client and using an elliptic curve cryptography cipher
+* suite, then if server returns an EC point formats lists extension
+* it must contain uncompressed.
 */
unsigned long alg_k = s-s3-tmp.new_cipher-algorithm_mkey;
unsigned long alg_a = s-s3-tmp.new_cipher-algorithm_auth;
if ((s-tlsext_ecpointformatlist != NULL) 
(s-tlsext_ecpointformatlist_length  0) 
+   (s-session-tlsext_ecpointformatlist != NULL) 
(s-session-tlsext_ecpointformatlist_length  0) 
((alg_k  (SSL_kEECDH|SSL_kECDHr|SSL_kECDHe)) || (alg_a  
SSL_aECDSA)))
{
/* we are using an ECC cipher */
size_t i;
unsigned char *list;
int found_uncompressed = 0;
-   if ((s-session-tlsext_ecpointformatlist == NULL) ||
(s-session-tlsext_ecpointformatlist_length == 0))
-   {
-
SSLerr(SSL_F_SSL_CHECK_SERVERHELLO_TLSEXT,SSL_R_TLS_INVALID_ECPOINTFORMAT_LIS
T);
-   return -1;
-   }
list = s-session-tlsext_ecpointformatlist;
for (i = 0; i  s-session-tlsext_ecpointformatlist_length; 
i++)
{

[demime 1.01d removed an attachment of type application/pgp-signature]



Re: Fix for openssl bug #2240

2011-09-23 Thread viq
Argh, maybe this time...
--
viq

Index: t1_lib.c
===
RCS file: /cvs/src/lib/libssl/src/ssl/t1_lib.c,v
retrieving revision 1.8
diff -u -d -r1.8 t1_lib.c
--- t1_lib.c10 Feb 2011 22:40:27 -  1.8
+++ t1_lib.c23 Sep 2011 19:38:13 -
@@ -1453,23 +1453,20 @@
int al = SSL_AD_UNRECOGNIZED_NAME;

 #ifndef OPENSSL_NO_EC
-   /* If we are client and using an elliptic curve cryptography cipher 
suite,
then server
-* must return a an EC point formats lists containing uncompressed.
+   /* If we are client and using an elliptic curve cryptography cipher
+* suite, then if server returns an EC point formats lists extension
+* it must contain uncompressed.
 */
unsigned long alg_k = s-s3-tmp.new_cipher-algorithm_mkey;
unsigned long alg_a = s-s3-tmp.new_cipher-algorithm_auth;
if ((s-tlsext_ecpointformatlist != NULL) 
(s-tlsext_ecpointformatlist_length  0) 
+   (s-session-tlsext_ecpointformatlist != NULL) 
(s-session-tlsext_ecpointformatlist_length  0) 
((alg_k  (SSL_kEECDH|SSL_kECDHr|SSL_kECDHe)) || (alg_a  
SSL_aECDSA)))
{
/* we are using an ECC cipher */
size_t i;
unsigned char *list;
int found_uncompressed = 0;
-   if ((s-session-tlsext_ecpointformatlist == NULL) ||
(s-session-tlsext_ecpointformatlist_length == 0))
-   {
-
SSLerr(SSL_F_SSL_CHECK_SERVERHELLO_TLSEXT,SSL_R_TLS_INVALID_ECPOINTFORMAT_LIS
T);
-   return -1;
-   }
list = s-session-tlsext_ecpointformatlist;
for (i = 0; i  s-session-tlsext_ecpointformatlist_length; 
i++)
{

[demime 1.01d removed an attachment of type application/pgp-signature]



Re: Fix for openssl bug #2240

2011-09-23 Thread viq
Apologies, if it doesn't work this last time I give up...
-- 
viq


Index: t1_lib.c
===
RCS file: /cvs/src/lib/libssl/src/ssl/t1_lib.c,v
retrieving revision 1.8
diff -u -d -r1.8 t1_lib.c
--- t1_lib.c10 Feb 2011 22:40:27 -  1.8
+++ t1_lib.c23 Sep 2011 19:38:13 -
@@ -1453,23 +1453,20 @@
int al = SSL_AD_UNRECOGNIZED_NAME;
 
 #ifndef OPENSSL_NO_EC
-   /* If we are client and using an elliptic curve cryptography cipher 
suite, then server
-* must return a an EC point formats lists containing uncompressed.
+   /* If we are client and using an elliptic curve cryptography cipher
+* suite, then if server returns an EC point formats lists extension
+* it must contain uncompressed.
 */
unsigned long alg_k = s-s3-tmp.new_cipher-algorithm_mkey;
unsigned long alg_a = s-s3-tmp.new_cipher-algorithm_auth;
if ((s-tlsext_ecpointformatlist != NULL)  
(s-tlsext_ecpointformatlist_length  0)  
+   (s-session-tlsext_ecpointformatlist != NULL)  
(s-session-tlsext_ecpointformatlist_length  0)  
((alg_k  (SSL_kEECDH|SSL_kECDHr|SSL_kECDHe)) || (alg_a  
SSL_aECDSA)))
{
/* we are using an ECC cipher */
size_t i;
unsigned char *list;
int found_uncompressed = 0;
-   if ((s-session-tlsext_ecpointformatlist == NULL) || 
(s-session-tlsext_ecpointformatlist_length == 0))
-   {
-   
SSLerr(SSL_F_SSL_CHECK_SERVERHELLO_TLSEXT,SSL_R_TLS_INVALID_ECPOINTFORMAT_LIST);
-   return -1;
-   }
list = s-session-tlsext_ecpointformatlist;
for (i = 0; i  s-session-tlsext_ecpointformatlist_length; 
i++)
{



Fix for openssl bug #2240

2011-09-17 Thread viq
http://rt.openssl.org/Ticket/Display.html?id=2240user=guestpass=guest

This affects us, I noticed when I had problems connecting with gajim to
a certain server using TLS. Below patch lifted from openssl CVS fixes
this.

On a different note, we still have openssl 1.0.0a when OpenSSL 1.0.0e
is now available, including important bug and security fixes.
-- 
viq

Index: src/ssl/t1_lib.c
===
RCS file: /cvs/src/lib/libssl/src/ssl/t1_lib.c,v
retrieving revision 1.8
diff -u -d -r1.8 t1_lib.c
--- src/ssl/t1_lib.c10 Feb 2011 22:40:27 -  1.8
+++ src/ssl/t1_lib.c17 Sep 2011 20:57:50 -
@@ -1453,23 +1453,20 @@
int al = SSL_AD_UNRECOGNIZED_NAME;
 
 #ifndef OPENSSL_NO_EC
-   /* If we are client and using an elliptic curve cryptography cipher 
suite, then server
-* must return a an EC point formats lists containing uncompressed.
+   /* If we are client and using an elliptic curve cryptography cipher
+* suite, then if server returns an EC point formats lists extension
+* it must contain uncompressed.
 */
unsigned long alg_k = s-s3-tmp.new_cipher-algorithm_mkey;
unsigned long alg_a = s-s3-tmp.new_cipher-algorithm_auth;
if ((s-tlsext_ecpointformatlist != NULL)  
(s-tlsext_ecpointformatlist_length  0)  
+   (s-session-tlsext_ecpointformatlist != NULL)  
(s-session-tlsext_ecpointformatlist_length  0)  
((alg_k  (SSL_kEECDH|SSL_kECDHr|SSL_kECDHe)) || (alg_a  
SSL_aECDSA)))
{
/* we are using an ECC cipher */
size_t i;
unsigned char *list;
int found_uncompressed = 0;
-   if ((s-session-tlsext_ecpointformatlist == NULL) || 
(s-session-tlsext_ecpointformatlist_length == 0))
-   {
-   
SSLerr(SSL_F_SSL_CHECK_SERVERHELLO_TLSEXT,SSL_R_TLS_INVALID_ECPOINTFORMAT_LIST);
-   return -1;
-   }
list = s-session-tlsext_ecpointformatlist;
for (i = 0; i  s-session-tlsext_ecpointformatlist_length; 
i++)
{



Re: better cpu throttling

2010-07-01 Thread viq
On Wed, Jun 30, 2010 at 03:34:14PM -0400, Ted Unangst wrote:
 On Wed, Jun 30, 2010 at 3:23 PM, Luis Henriques luis.hen...@gmail.com
 wrote:
  Probably, a silly question, but here it goes:
 
  With this patch, I will not be able to set the perflevel to, say, 50% and
  keep the system using that performance level forever.  Is this correct?
  I guess that with current apmd we are able to do this.
 
  If both of these two statements are true (maybe they are not!), we should
  also have a mechanism to disable this code (either at runtime or compile
  time).

 You are correct, but I wonder why you would ever want a machine only
 running at 50% all the time.  When it is busy, it's still slow, and
 when it's not, it's still using power.

In my X31 it scales between 600 and 1600 MHz, or something like that.
And when I keep it around setperf 40 it avoids turning the fan on. Which
is handy when for example you're compiling something and leave it by bed
;)
I didn't say it was a very good reason ;)

 We are thinking that states
 other than 0 and 100 are not very useful.  But this is not the final
 diff.  It will probably have some means of control eventually, until
 then, it'd be nice if people evaluated if this meets their needs.

--
viq

[demime 1.01d removed an attachment of type application/pgp-signature]



New installer - initial user creation

2009-06-26 Thread viq
Since the user created during installation is somewhat marketed as root
replacement, shouldn't he be added to staff login class ?
--
viq

[demime 1.01d removed an attachment of type application/pgp-signature]