From bryan@stansell.org Fri Apr 4 16:45:28 2014 Received: from underdog.stansell.org (localhost [127.0.0.1]) by underdog.stansell.org (8.14.7/8.14.7) with ESMTP id s34GjSWs016588; Fri, 4 Apr 2014 16:45:28 GMT Received: (from bryan@localhost) by underdog.stansell.org (8.14.7/8.14.7/Submit) id s34GjSeO016587; Fri, 4 Apr 2014 16:45:28 GMT Date: Fri, 4 Apr 2014 16:45:28 +0000 From: Bryan Stansell To: announce@conserver.com, users@conserver.com Subject: conserver-8.1.20 is available Message-ID: <20140404164517.GA16362@underdog.stansell.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.16 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 16:45:28 -0000 I've finally integrated and expanded a patch that was submitted over 3 years ago (yikes!) - direct IPMI serial over LAN support. Hopefully this will work just as well as forking off an ipmi command but also allow less resource usage. I'm curious to hear about any success or horror stories - share if you can. Thanks! version 8.1.20 (Apr 4, 2014): - IPMI serial over LAN support via FreeIPMI - based on patch by Anton D. Kachalov - minor cleanup of code, removal of gcc warnings and such that should have no fuctional change Bryan Stansell From bryan@conserver.com Fri Apr 4 17:51:38 2014 Received: from shuttle.home.stansell.org (c-98-207-6-47.hsd1.ca.comcast.net [98.207.6.47]) (authenticated bits=0) by underdog.stansell.org (8.14.7/8.14.7) with ESMTP id s34Hpb4c018957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 4 Apr 2014 17:51:37 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_EAB983A6-A04B-424F-A1E8-522E37CF4FF2" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: conserver-8.1.20 is available From: Bryan Stansell In-Reply-To: Date: Fri, 4 Apr 2014 10:51:36 -0700 Message-Id: <53521EEB-6182-48B9-91AD-01FD7C370DCC@conserver.com> References: <20140404164517.GA16362@underdog.stansell.org> To: Milos Vyletel X-Mailer: Apple Mail (2.1874) X-Spam-Score: 0.164 () BAYES_00,HTML_MESSAGE,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 Cc: users@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.16 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 17:51:38 -0000 --Apple-Mail=_EAB983A6-A04B-424F-A1E8-522E37CF4FF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 There isn't a repository available. Not yet, at least. I was thinking = about going from the old-school CVS repository I have locally to git and = then shoving it into github as a public instance. There's a bit of = cleanup work I need to do to make that happen, however. You can pull previous versions from the website (need to know the name) = or hit it via ftp (to ftp.conserver.com) and get the old releases = (naming is pretty straightforward). Patches can just be sent to me directly, or more often, posted to this = list so it's archived and others get a chance to work with it before I = get around to putting it in an official release. IPv6 is certainly a missing piece, and something I was going to look = into (at some point). I'm sure I'm not the only one that would like to = see the patch! Thanks! Bryan On Apr 4, 2014, at 10:24 AM, Milos Vyletel = wrote: > Bryan, >=20 > I was wondering if there is a public source code repository with = conserver where > we can see changes made between versions. I've looked at website but = could > not find any. >=20 > Btw. is there any recommended process for patch submission? The reason = I ask > is that I have rather big patch adding IPv6 support to conserver = almost ready. I'm > still polishing code and testing it but it should be ready soon. >=20 > Thanks, > Milos >=20 >=20 > On Fri, Apr 4, 2014 at 12:45 PM, Bryan Stansell = wrote: > I've finally integrated and expanded a patch that was submitted over > 3 years ago (yikes!) - direct IPMI serial over LAN support. Hopefully > this will work just as well as forking off an ipmi command but also > allow less resource usage. >=20 > I'm curious to hear about any success or horror stories - share if you > can. Thanks! >=20 > version 8.1.20 (Apr 4, 2014): > - IPMI serial over LAN support via FreeIPMI - based on patch = by Anton > D. Kachalov > - minor cleanup of code, removal of gcc warnings and such that = should > have no fuctional change >=20 > Bryan Stansell > _______________________________________________ > users mailing list > users@conserver.com > https://www.conserver.com/mailman/listinfo/users >=20 --Apple-Mail=_EAB983A6-A04B-424F-A1E8-522E37CF4FF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 There = isn't a repository available.  Not yet, at least.  I was = thinking about going from the old-school CVS repository I have locally = to git and then shoving it into github as a public instance. =  There's a bit of cleanup work I need to do to make that happen, = however.

You can pull previous versions from the = website (need to know the name) or hit it via ftp (to ftp.conserver.com) and get the old = releases (naming is pretty = straightforward).

Patches can just be sent to = me directly, or more often, posted to this list so it's archived and = others get a chance to work with it before I get around to putting it in = an official release.

IPv6 is certainly a = missing piece, and something I was going to look into (at some point). =  I'm sure I'm not the only one that would like to see the = patch!

Thanks!

Bryan

On Apr 4, 2014, at 10:24 AM, Milos Vyletel <milos.vyletel@gmail.com> = wrote:

Bryan,

I was wondering = if there is a public source code repository with conserver = where
we can see changes made between versions. I've looked at = website but could
not find any.

Btw. is there any recommended process for patch = submission? The reason I ask
is that I have rather big patch = adding IPv6 support to conserver almost ready. I'm
still = polishing code and testing it but it should be ready soon.

Thanks,
Milos


On Fri, Apr 4, = 2014 at 12:45 PM, Bryan Stansell <bryan@conserver.com> wrote:
I've finally = integrated and expanded a patch that was submitted over
3 years ago (yikes!) - direct IPMI serial over LAN support. =  Hopefully
this will work just as well as forking off an ipmi command but also
allow less resource usage.

I'm curious to hear about any success or horror stories - share if = you
can.  Thanks!

version 8.1.20 (Apr 4, 2014):
        - IPMI serial over LAN support via FreeIPMI = - based on patch by Anton
          D. Kachalov <mouse@yandex-team.ru>
        - minor cleanup of code, removal of gcc = warnings and such that should
          have no fuctional change

Bryan Stansell
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
=


= --Apple-Mail=_EAB983A6-A04B-424F-A1E8-522E37CF4FF2-- From milos.vyletel@gmail.com Fri Apr 4 18:36:39 2014 Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by underdog.stansell.org (8.14.7/8.14.7) with ESMTP id s34IaZv4020727 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL); Fri, 4 Apr 2014 18:36:38 GMT Received: by mail-vc0-f172.google.com with SMTP id la4so3489240vcb.3 for ; Fri, 04 Apr 2014 11:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9e5POKM8x2DuaNAhgOxKJHGtSTXY7SuMG+RnKtsjcFY=; b=cadMZS3j3RV+w1UjWX23T49hJiLyofP3mqXNx0PqbE7IBokTvpEXKP1J19YkAq2nh7 QMeOR3T2yxW9xPCDTDwZmyS8l/MnjfDRIzuKxul2V5ZQl2Gk2Cgpjv4zrdDqKVBhZcRU Xv2pjatCiKXiVb78t7ETJ9vxUqo7tWAwACD0w55VDxRa4SYw9elGKUOFYVK6LqXj4dcc DtR5tgXVzgEuUbKZegkUAmsRuaY5x3Vbk1NX15J7/hnyx7irZ/9bbkHR4XtjyJrCiCum jp5fui+Ox8m2aXwbP4fHEda1WBeKtRFXWnuHMz/c4ohWH7k5V4jMGaPuyzwiFy5IHInE Qz5Q== MIME-Version: 1.0 X-Received: by 10.52.51.226 with SMTP id n2mr436911vdo.57.1396636595305; Fri, 04 Apr 2014 11:36:35 -0700 (PDT) Sender: milos.vyletel@gmail.com Received: by 10.220.132.130 with HTTP; Fri, 4 Apr 2014 11:36:35 -0700 (PDT) In-Reply-To: <53521EEB-6182-48B9-91AD-01FD7C370DCC@conserver.com> References: <20140404164517.GA16362@underdog.stansell.org> <53521EEB-6182-48B9-91AD-01FD7C370DCC@conserver.com> Date: Fri, 4 Apr 2014 14:36:35 -0400 X-Google-Sender-Auth: Xzmk6qgQyiUBRvamIjbFP3VNfWM Message-ID: Subject: Re: conserver-8.1.20 is available From: Milos Vyletel To: Bryan Stansell Content-Type: multipart/mixed; boundary=001a1136b00624d8c604f63bcc77 X-Spam-Score: -1.488 () BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,T_DKIM_INVALID X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 X-Mailman-Approved-At: Fri, 04 Apr 2014 19:23:06 +0000 Cc: users@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.16 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 18:36:39 -0000 --001a1136b00624d8c604f63bcc77 Content-Type: multipart/alternative; boundary=001a1136b00624d8c204f63bcc75 --001a1136b00624d8c204f63bcc75 Content-Type: text/plain; charset=ISO-8859-1 Alright then. I'm attaching current version for whoever want to take a look. If for some reason the attachment does not go through I've made it available here https://vyletel.eu/conserver-ipv6.patch I've been testing it on OEL 6.5 box. One thing to note. This patch was generated against 8.1.18 because I've started to work on the latest version used in fedora not knowing that 8.1.19 was released. It will require some effort to port it to 8.1.20. This is where the source repository would help a bit. As it stands right now this patch is not fully tested. I've tested some basic functionality and run unit tests and everything seems to be working. Any comments are appreciated. Milos On Fri, Apr 4, 2014 at 1:51 PM, Bryan Stansell wrote: > There isn't a repository available. Not yet, at least. I was thinking > about going from the old-school CVS repository I have locally to git and > then shoving it into github as a public instance. There's a bit of cleanup > work I need to do to make that happen, however. > > You can pull previous versions from the website (need to know the name) or > hit it via ftp (to ftp.conserver.com) and get the old releases (naming is > pretty straightforward). > > Patches can just be sent to me directly, or more often, posted to this > list so it's archived and others get a chance to work with it before I get > around to putting it in an official release. > > IPv6 is certainly a missing piece, and something I was going to look into > (at some point). I'm sure I'm not the only one that would like to see the > patch! > > Thanks! > > Bryan > > On Apr 4, 2014, at 10:24 AM, Milos Vyletel > wrote: > > Bryan, > > I was wondering if there is a public source code repository with conserver > where > we can see changes made between versions. I've looked at website but could > not find any. > > Btw. is there any recommended process for patch submission? The reason I > ask > is that I have rather big patch adding IPv6 support to conserver almost > ready. I'm > still polishing code and testing it but it should be ready soon. > > Thanks, > Milos > > > On Fri, Apr 4, 2014 at 12:45 PM, Bryan Stansell wrote: > >> I've finally integrated and expanded a patch that was submitted over >> 3 years ago (yikes!) - direct IPMI serial over LAN support. Hopefully >> this will work just as well as forking off an ipmi command but also >> allow less resource usage. >> >> I'm curious to hear about any success or horror stories - share if you >> can. Thanks! >> >> version 8.1.20 (Apr 4, 2014): >> - IPMI serial over LAN support via FreeIPMI - based on patch by >> Anton >> D. Kachalov >> - minor cleanup of code, removal of gcc warnings and such that >> should >> have no fuctional change >> >> Bryan Stansell >> _______________________________________________ >> users mailing list >> users@conserver.com >> https://www.conserver.com/mailman/listinfo/users >> > > > --001a1136b00624d8c204f63bcc75 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Alright then. I'm attaching current version for w= hoever want to take a look. If for some
reason the attachment doe= s not go through I've made it available here


I've been testing it = on OEL 6.5 box. One thing to note. This patch was generated
again= st 8.1.18 because I've started to work on the latest version used in fe= dora
not knowing that 8.1.19 was released. It will require some effort to p= ort it to 8.1.20.
This is where the source repository would help = a bit.=A0

As it stands right now this patch is not= fully tested. I've tested some basic functionality
and run unit tests and everything seems to be working.

Any comments are appreciated.

Milo= s



On Fri, Apr 4, 2014 at 1:51 PM, Bryan Stansell <bryan@conserver.com&= gt; wrote:
There isn't a repository available.= =A0Not yet, at least. =A0I was thinking about going from the old-school CV= S repository I have locally to git and then shoving it into github as a pub= lic instance. =A0There's a bit of cleanup work I need to do to make tha= t happen, however.

You can pull previous versions from the website (need to kno= w the name) or hit it via ftp (to ftp.conserver.com) and get the old releases (naming is pr= etty straightforward).

Patches can just be sent to me directly, or more often,= posted to this list so it's archived and others get a chance to work w= ith it before I get around to putting it in an official release.

IPv6 is certainly a missing piece, and something I was going= to look into (at some point). =A0I'm sure I'm not the only one tha= t would like to see the patch!

Thanks!

Bryan
<= /span>

On Apr 4, 2014, at 10:24 AM= , Milos Vyletel <milos.vyletel@gmail.com> wrote:

Bryan,

I = was wondering if there is a public source code repository with conserver wh= ere
we can see changes made between versions. I've looked at = website but could
not find any.

Btw. is there any recommended process for patch submiss= ion? The reason I ask
is that I have rather big patch adding IPv6= support to conserver almost ready. I'm
still polishing code = and testing it but it should be ready soon.

Thanks,
Milos


On Fri, Apr 4, 2014 at 12:45 PM, = Bryan Stansell <bryan@conserver.com> wrote:
I've finally integrated and expanded a p= atch that was submitted over
3 years ago (yikes!) - direct IPMI serial over LAN support. =A0Hopefully this will work just as well as forking off an ipmi command but also
allow less resource usage.

I'm curious to hear about any success or horror stories - share if you<= br> can. =A0Thanks!

version 8.1.20 (Apr 4, 2014):
=A0 =A0 =A0 =A0 - IPMI serial over LAN support via FreeIPMI - based on patc= h by Anton
=A0 =A0 =A0 =A0 =A0 D. Kachalov <mouse@yandex-team.ru>
=A0 =A0 =A0 =A0 - minor cleanup of code, removal of gcc warnings and such t= hat should
=A0 =A0 =A0 =A0 =A0 have no fuctional change

Bryan Stansell
_______________________________________________
users mailing list
users@conserver.co= m
https://www.conserver.com/mailman/listinfo/users


--001a1136b00624d8c204f63bcc75-- --001a1136b00624d8c604f63bcc77 Content-Type: application/octet-stream; name="conserver-ipv6.patch" Content-Disposition: attachment; filename="conserver-ipv6.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_htlt3p6x0 ZGlmZiAtdXByIGNvbnNlcnZlci04LjEuMTgub3JpZy9jb25zZXJ2ZXIvYWNjZXNzLmMgY29uc2Vy dmVyLTguMS4xOC5pcHY2L2NvbnNlcnZlci9hY2Nlc3MuYwotLS0gY29uc2VydmVyLTguMS4xOC5v cmlnL2NvbnNlcnZlci9hY2Nlc3MuYwkyMDA5LTA5LTI1IDA0OjM0OjI5LjAwMDAwMDAwMCAtMDQw MAorKysgY29uc2VydmVyLTguMS4xOC5pcHY2L2NvbnNlcnZlci9hY2Nlc3MuYwkyMDE0LTA0LTAz IDE0OjA5OjE0LjAyMjU5NDYwOSAtMDQwMApAQCAtNDQsMTQxICs0NCw2NCBAQAogI2luY2x1ZGUg PHJlYWRjZmcuaD4KICNpbmNsdWRlIDxtYWluLmg+CiAKLQotLyogQ29tcGFyZSBhbiBJbnRlcm5l dCBhZGRyZXNzIChJUHY0IGV4cGVjdGVkKSwgd2l0aCBhbiBhZGRyZXNzIHBhdHRlcm4KLSAqIHBh c3NlZCBhcyBhIGNoYXJhY3RlciBzdHJpbmcgcmVwcmVzZW50aW5nIGFuIGFkZHJlc3MgaW4gdGhl IEludGVybmV0Ci0gKiBzdGFuZGFyZCBgLicgbm90YXRpb24sIG9wdGlvbmFsbHkgZm9sbG93ZWQg YnkgYSBzbGFzaCBhbmQgYW4gaW50ZWdlcgotICogc3BlY2lmeWluZyB0aGUgbnVtYmVyIG9mIGJp dHMgaW4gdGhlIG5ldHdvcmsgcG9ydGlvbiBvZiB0aGUgYWRkcmVzcwotICogKHRoZSBuZXRtYXNr IHNpemUpLiBJZiBub3Qgc3BlY2lmaWVkIGV4cGxpY2l0bHksIHRoZSBuZXRtYXNrIHNpemUgdXNl ZAotICogaXMgdGhhdCBpbXBsaWVkIGJ5IHRoZSBhZGRyZXNzIGNsYXNzLiBJZiBlaXRoZXIgdGhl IG5ldG1hc2sgaXMgc3BlY2lmaWVkCi0gKiBleHBsaWNpdGx5LCBvciB0aGUgbG9jYWwgbmV0d29y ayBhZGRyZXNzIHBhcnQgb2YgdGhlIHBhdHRlcm4gaXMgemVybywKLSAqIHRoZW4gb25seSB0aGUg bmV0d29yayBudW1iZXIgcGFydHMgb2YgdGhlIGFkZHJlc3NlcyBhcmUgY29tcGFyZWQ7Ci0gKiBv dGhlcndpc2UgdGhlIGVudGlyZSBhZGRyZXNzZXMgYXJlIGNvbXBhcmVkLgotICoKLSAqIFJldHVy bnMgMCBpZiB0aGUgYWRkcmVzc2VzIG1hdGNoLCBlbHNlIHJldHVybnMgMS4KLSAqLwotaW50Ci0j aWYgUFJPVE9UWVBFUwotQWRkckNtcChzdHJ1Y3QgaW5fYWRkciAqYWRkciwgY2hhciAqcGF0dGVy bikKLSNlbHNlCi1BZGRyQ21wKGFkZHIsIHBhdHRlcm4pCi0gICAgc3RydWN0IGluX2FkZHIgKmFk ZHI7Ci0gICAgY2hhciAqcGF0dGVybjsKLSNlbmRpZgotewotICAgIGluX2FkZHJfdCBob3N0YWRk ciwgcGF0dGVybl9hZGRyLCBuZXRtYXNrOwotICAgIGNoYXIgKnAsICpzbGFzaF9wb3NuOwotICAg IHN0YXRpYyBTVFJJTkcgKmJ1ZiA9IChTVFJJTkcgKikwOwotI2lmIEhBVkVfSU5FVF9BVE9OCi0g ICAgc3RydWN0IGluX2FkZHIgaW5ldGFkZHI7Ci0jZW5kaWYKLQotICAgIGlmIChidWYgPT0gKFNU UklORyAqKTApCi0JYnVmID0gQWxsb2NTdHJpbmcoKTsKLSAgICBzbGFzaF9wb3NuID0gc3RyY2hy KHBhdHRlcm4sICcvJyk7Ci0gICAgaWYgKHNsYXNoX3Bvc24gIT0gTlVMTCkgewotCUJ1aWxkU3Ry aW5nKChjaGFyICopMCwgYnVmKTsKLQlCdWlsZFN0cmluZyhwYXR0ZXJuLCBidWYpOwotCWJ1Zi0+ c3RyaW5nW3NsYXNoX3Bvc24gLSBwYXR0ZXJuXSA9ICdcMCc7CS8qIGlzb2xhdGUgdGhlIGFkZHJl c3MgKi8KLQlwID0gYnVmLT5zdHJpbmc7Ci0gICAgfSBlbHNlCi0JcCA9IHBhdHRlcm47Ci0KLSNp ZiBIQVZFX0lORVRfQVRPTgotICAgIGlmIChpbmV0X2F0b24ocCwgJmluZXRhZGRyKSA9PSAwKQot CXJldHVybiAxOwotICAgIHBhdHRlcm5fYWRkciA9IGluZXRhZGRyLnNfYWRkcjsKLSNlbHNlCi0g ICAgcGF0dGVybl9hZGRyID0gaW5ldF9hZGRyKHApOwotICAgIGlmIChwYXR0ZXJuX2FkZHIgPT0g KGluX2FkZHJfdCkgKC0xKSkKLQlyZXR1cm4gMTsJCS8qIG1hbGZvcm1lZCBhZGRyZXNzICovCi0j ZW5kaWYKLQotICAgIGlmIChzbGFzaF9wb3NuKSB7Ci0JLyogY29udmVydCBleHBsaWNpdCBuZXRt YXNrICovCi0JaW50IG1hc2tfYml0cyA9IGF0b2koc2xhc2hfcG9zbiArIDEpOwotCWZvciAobmV0 bWFzayA9IDA7IG1hc2tfYml0cyA+IDA7IC0tbWFza19iaXRzKQotCSAgICBuZXRtYXNrID0gMHg4 MDAwMDAwMCB8IChuZXRtYXNrID4+IDEpOwotICAgIH0gZWxzZSB7Ci0JLyogbmV0bWFzayBpbXBs aWVkIGJ5IGFkZHJlc3MgY2xhc3MgKi8KLQlpbl9hZGRyX3QgaWEgPSBudG9obChwYXR0ZXJuX2Fk ZHIpOwotCWlmIChJTl9DTEFTU0EoaWEpKQotCSAgICBuZXRtYXNrID0gSU5fQ0xBU1NBX05FVDsK LQllbHNlIGlmIChJTl9DTEFTU0IoaWEpKQotCSAgICBuZXRtYXNrID0gSU5fQ0xBU1NCX05FVDsK LQllbHNlIGlmIChJTl9DTEFTU0MoaWEpKQotCSAgICBuZXRtYXNrID0gSU5fQ0xBU1NDX05FVDsK LQllbHNlCi0JICAgIHJldHVybiAxOwkJLyogdW5zdXBwb3J0ZWQgYWRkcmVzcyBjbGFzcyAqLwot ICAgIH0KLSAgICBuZXRtYXNrID0gaHRvbmwobmV0bWFzayk7Ci0gICAgaWYgKH5uZXRtYXNrICYg cGF0dGVybl9hZGRyKQotCW5ldG1hc2sgPSAweGZmZmZmZmZmOwkvKiBjb21wYXJlIGVudGlyZSBh ZGRyZXNzZXMgKi8KLSAgICBob3N0YWRkciA9IGFkZHItPnNfYWRkcjsKLQotICAgIENPTkRERUJV RygoMSwgIkFkZHJDbXAoKTogaG9zdD0lbHgoJWx4LyVseCkgYWNsPSVseCglbHgvJWx4KSIsCi0J ICAgICAgIGhvc3RhZGRyICYgbmV0bWFzaywgaG9zdGFkZHIsIG5ldG1hc2ssCi0JICAgICAgIHBh dHRlcm5fYWRkciAmIG5ldG1hc2ssIHBhdHRlcm5fYWRkciwgbmV0bWFzaykpOwotICAgIHJldHVy biAoaG9zdGFkZHIgJiBuZXRtYXNrKSAhPSAocGF0dGVybl9hZGRyICYgbmV0bWFzayk7Ci19Cisj aW5jbHVkZSA8bmV0L2lmLmg+CisjaW5jbHVkZSA8aWZhZGRycy5oPgorI2luY2x1ZGUgPHN5cy9z b2NrZXQuaD4KKyNpbmNsdWRlIDxuZXRkYi5oPgogCiAvKiByZXR1cm4gdGhlIGFjY2VzcyB0eXBl IGZvciBhIGdpdmVuIGhvc3QgZW50cnkJCQkoa3NiKQogICovCiBjaGFyCiAjaWYgUFJPVE9UWVBF UwotQWNjVHlwZShzdHJ1Y3QgaW5fYWRkciAqYWRkciwgY2hhciAqKnBlZXJuYW1lKQorQWNjVHlw ZShzdHJ1Y3Qgc29ja2FkZHJfc3RvcmFnZSAqYWRkciwgY2hhciAqKnBlZXJuYW1lKQogI2Vsc2UK IEFjY1R5cGUoYWRkciwgcGVlcm5hbWUpCi0gICAgc3RydWN0IGluX2FkZHIgKmFkZHI7CisgICAg c3RydWN0IHNvY2thZGRyX3N0b3JhZ2UgKmFkZHI7CiAgICAgY2hhciAqKnBlZXJuYW1lOwogI2Vu ZGlmCiB7CiAgICAgQUNDRVNTICpwQUN0bXA7CiAgICAgc29ja2xlbl90IHNvOwotICAgIHN0cnVj dCBob3N0ZW50ICpoZSA9IChzdHJ1Y3QgaG9zdGVudCAqKTA7Ci0gICAgaW50IGE7CisgICAgaW50 IGVycm9yOwogICAgIGNoYXIgcmV0OwotI2lmIFRSVVNUX1JFVkVSU0VfRE5TCi0gICAgY2hhciAq KnJldk5hbWVzID0gKGNoYXIgKiopMDsKLSNlbmRpZgotCi0gICAgQ09ORERFQlVHKCgxLCAiQWNj VHlwZSgpOiBpcD0lcyIsIGluZXRfbnRvYSgqYWRkcikpKTsKKyAgICBjaGFyIGhvc3RbTklfTUFY SE9TVF07CisgICAgY2hhciBpcGFkZHJbTklfTUFYSE9TVF07CiAKLSAgICByZXQgPSBjb25maWct PmRlZmF1bHRhY2Nlc3M7CiAgICAgc28gPSBzaXplb2YoKmFkZHIpOworICAgIHJldCA9IGNvbmZp Zy0+ZGVmYXVsdGFjY2VzczsKIAotI2lmIFRSVVNUX1JFVkVSU0VfRE5TCi0gICAgLyogaWYgd2Ug dHJ1c3QgcmV2ZXJzZSBkbnMsIHdlIGdldCB0aGUgbmFtZXMgYXNzb2NpYXRlZCB3aXRoCi0gICAg ICogdGhlIGFkZHJlc3Mgd2UncmUgY2hlY2tpbmcgYW5kIHRoZW4gY2hlY2sgZWFjaCBvZiB0aG9z ZQotICAgICAqIGFnYWluc3QgdGhlIGFjY2VzcyBsaXN0IGVudHJpZXMgKGJlbG93KS4KLSAgICAg Ki8KLSAgICBpZiAoKGhlID0KLQkgZ2V0aG9zdGJ5YWRkcigoY2hhciAqKWFkZHIsIHNvLAotCQkg ICAgICAgQUZfSU5FVCkpID09IChzdHJ1Y3QgaG9zdGVudCAqKTApIHsKLQlFcnJvcigiQWNjVHlw ZSgpOiBnZXRob3N0YnlhZGRyKCVzKTogJXMiLCBpbmV0X250b2EoKmFkZHIpLAotCSAgICAgIGhz dHJlcnJvcihoX2Vycm5vKSk7Ci0gICAgfSBlbHNlIHsKLQljaGFyICpobmFtZTsKLQlpZiAoaGUt PmhfbmFtZSAhPSAoY2hhciAqKTApIHsKLQkgICAgLyogY291bnQgdXAgdGhlIG51bWJlciBvZiBu YW1lcyAqLwotCSAgICBmb3IgKGEgPSAwLCBobmFtZSA9IGhlLT5oX2FsaWFzZXNbYV07IGhuYW1l ICE9IChjaGFyICopMDsKLQkJIGhuYW1lID0gaGUtPmhfYWxpYXNlc1srK2FdKTsKLQkgICAgYSAr PSAyOwkJLyogaF9uYW1lICsgKGNoYXIgKikwICovCi0JICAgIC8qIG5vdyBkdXBsaWNhdGUgdGhl bSAqLwotCSAgICBpZiAoKHJldk5hbWVzID0KLQkJIChjaGFyICoqKWNhbGxvYyhhLCBzaXplb2Yo Y2hhciAqKSkpICE9IChjaGFyICoqKTApIHsKLQkJZm9yIChobmFtZSA9IGhlLT5oX25hbWUsIGEg PSAwOyBobmFtZSAhPSAoY2hhciAqKTA7Ci0JCSAgICAgaG5hbWUgPSBoZS0+aF9hbGlhc2VzW2Er K10pIHsKLQkJICAgIGlmICgocmV2TmFtZXNbYV0gPSBTdHJEdXAoaG5hbWUpKSA9PSAoY2hhciAq KTApCi0JCQlicmVhazsKLQkJICAgIENPTkRERUJVRygoMSwgIkFjY1R5cGUoKTogcmV2TmFtZXNb JWRdPSclcyciLCBhLAotCQkJICAgICAgIGhuYW1lKSk7Ci0JCX0KLQkgICAgfQotCX0KKyAgICBl cnJvciA9IGdldG5hbWVpbmZvKChzdHJ1Y3Qgc29ja2FkZHIgKilhZGRyLCBzbywKKwkgICAgCWlw YWRkciwgc2l6ZW9mKGlwYWRkciksIE5VTEwsIDAsIE5JX05VTUVSSUNIT1NUKTsKKyAgICBpZiAo ZXJyb3IpIHsKKwlFcnJvcigiQWNjVHlwZSgpOiBnZXRuYW1laW5mbyBmYWlsZWQ6ICVzIiwgZ2Fp X3N0cmVycm9yKGVycm9yKSk7CisJZ290byBjb21tb25fcmV0OworICAgIH0KKyAgICBDT05EREVC VUcoKDEsICJBY2NUeXBlKCk6IGlwPSVzIiwgaXBhZGRyKSk7CisKKyAgICBlcnJvciA9IGdldG5h bWVpbmZvKChzdHJ1Y3Qgc29ja2FkZHIgKilhZGRyLCBzbywKKwkgICAgCWhvc3QsIHNpemVvZiho b3N0KSwgTlVMTCwgMCwgMCk7CisgICAgaWYgKGVycm9yKSB7CisJRXJyb3IoIkFjY1R5cGUoKTog Z2V0bmFtZWluZm8gZmFpbGVkOiAlcyIsIGdhaV9zdHJlcnJvcihlcnJvcikpOwogICAgIH0KLSNl bmRpZgorICAgIENPTkRERUJVRygoMSwgIkFjY1R5cGUoKTogaG9zdD0lcyIsIGhvc3QpKTsKKwor ICAgIGZvciAocEFDdG1wID0gcEFDTGlzdDsgcEFDdG1wICE9IChBQ0NFU1MgKikwOyBwQUN0bXAg PSBwQUN0bXAtPnBBQ25leHQpIHsKKwlDT05EREVCVUcoKDEsICJBY2NUeXBlKCk6IHdobz0lcywg dHJ1c3Q9JWMiLCBwQUN0bXAtPnBjd2hvLAorCQkgICBwQUN0bXAtPmN0cnVzdCkpOwogCisJaWYg KHN0cnN0cihpcGFkZHIsIHBBQ3RtcC0+cGN3aG8pICE9IE5VTEwpIHsKKwkgICAgQ09ORERFQlVH KCgxLCAiQWNjVHlwZSgpOiBtYXRjaCBmb3IgaXA9JXMiLCBpcGFkZHIpKTsKKwkgICAgcmV0ID0g cEFDdG1wLT5jdHJ1c3Q7CisJICAgIGdvdG8gY29tbW9uX3JldDsKKwl9CisJCisJaWYgKCFlcnJv ciAmJiBzdHJzdHIoaG9zdCwgcEFDdG1wLT5wY3dobykgIT0gTlVMTCkgeworCSAgICBDT05EREVC VUcoKDEsICJBY2NUeXBlKCk6IG1hdGNoIGZvciBob3N0PSVzIiwgaG9zdCkpOworCSAgICByZXQg PSBwQUN0bXAtPmN0cnVzdDsKKwkgICAgZ290byBjb21tb25fcmV0OworCX0KKyAgICB9CisjaWYg MAogICAgIGZvciAocEFDdG1wID0gcEFDTGlzdDsgcEFDdG1wICE9IChBQ0NFU1MgKikwOyBwQUN0 bXAgPSBwQUN0bXAtPnBBQ25leHQpIHsKIAlDT05EREVCVUcoKDEsICJBY2NUeXBlKCk6IHdobz0l cywgdHJ1c3Q9JWMiLCBwQUN0bXAtPnBjd2hvLAogCQkgICBwQUN0bXAtPmN0cnVzdCkpOwpAQCAt MjE2LDY5ICsxMzksMjEgQEAgQWNjVHlwZShhZGRyLCBwZWVybmFtZSkKIAkJfQogCSAgICB9CiAJ fQotI2lmIFRSVVNUX1JFVkVSU0VfRE5TCi0JLyogd2UgY2hvcCBiaXRzIG9mZiBjbGllbnQgbmFt ZXMgc28gdGhhdCB3ZSBjYW4gcHV0IGRvbWFpbgotCSAqIG5hbWVzIGluIGFjY2VzcyBsaXN0cyBv ciBldmVuIHRvcC1sZXZlbCBkb21haW5zLgotCSAqICAgIGFsbG93ZWQgY29uc2VydmVyLmNvbSwg bmV0OwotCSAqIHRoaXMgYWxsb3dzIGFueXRoaW5nIGZyb20gY29uc2VydmVyLmNvbSBhbmQgYW55 dGhpbmcgaW4KLQkgKiB0aGUgLm5ldCB0b3AtbGV2ZWwuICB3aXRob3V0IFRSVVNUX1JFVkVSU0Vf RE5TLCB0aG9zZSBuYW1lcwotCSAqIGJldHRlciBtYXAgdG8gaXAgYWRkcmVzc2VzIGZvciB0aGVt IHRvIHRha2UgZWZmZWN0LgotCSAqLwotCWlmIChyZXZOYW1lcyAhPSAoY2hhciAqKikwKSB7Ci0J ICAgIGNoYXIgKnBjTmFtZTsKLQkgICAgaW50IHdsZW47Ci0JICAgIGludCBsZW47Ci0JICAgIHds ZW4gPSBzdHJsZW4ocEFDdG1wLT5wY3dobyk7Ci0JICAgIGZvciAoYSA9IDA7IHJldk5hbWVzW2Fd ICE9IChjaGFyICopMDsgYSsrKSB7Ci0JCWZvciAocGNOYW1lID0gcmV2TmFtZXNbYV0sIGxlbiA9 IHN0cmxlbihwY05hbWUpOwotCQkgICAgIGxlbiA+PSB3bGVuOyBsZW4gPSBzdHJsZW4oKytwY05h bWUpKSB7Ci0JCSAgICBDT05EREVCVUcoKDEsICJBY2NUeXBlKCk6IG5hbWU9JXMiLCBwY05hbWUp KTsKLQkJICAgIGlmIChzdHJjYXNlY21wKHBjTmFtZSwgcEFDdG1wLT5wY3dobykgPT0gMCkgewot CQkJaWYgKHBlZXJuYW1lICE9IChjaGFyICoqKTApCi0JCQkgICAgKnBlZXJuYW1lID0gU3RyRHVw KHJldk5hbWVzW2FdKTsKLQkJCXJldCA9IHBBQ3RtcC0+Y3RydXN0OwotCQkJZ290byBjb21tb25f cmV0MjsKLQkJICAgIH0KLQkJICAgIHBjTmFtZSA9IHN0cmNocihwY05hbWUsICcuJyk7Ci0JCSAg ICBpZiAocGNOYW1lID09IChjaGFyICopMCkKLQkJCWJyZWFrOwotCQl9Ci0JICAgIH0KLQl9Ci0j ZW5kaWYKICAgICB9CisjZW5kaWYgLyogI2lmIDAgKi8KIAogICBjb21tb25fcmV0OgotICAgIGlm IChjb25maWctPmxvZ2hvc3RuYW1lcyA9PSBGTEFHVFJVRSAmJiBwZWVybmFtZSAhPSAoY2hhciAq KikwKSB7Ci0jaWYgVFJVU1RfUkVWRVJTRV9ETlMKLQlpZiAocmV2TmFtZXMgIT0gKGNoYXIgKiop MCAmJiByZXZOYW1lc1swXSAhPSAoY2hhciAqKTApCi0JICAgICpwZWVybmFtZSA9IFN0ckR1cChy ZXZOYW1lc1swXSk7Ci0jZWxzZQotCWlmICgoaGUgPQotCSAgICAgZ2V0aG9zdGJ5YWRkcigoY2hh ciAqKWFkZHIsIHNvLAotCQkJICAgQUZfSU5FVCkpICE9IChzdHJ1Y3QgaG9zdGVudCAqKTApIHsK LQkgICAgKnBlZXJuYW1lID0gU3RyRHVwKGhlLT5oX25hbWUpOwotCX0KLSNlbmRpZgotICAgIH0K LSNpZiBUUlVTVF9SRVZFUlNFX0ROUwotICBjb21tb25fcmV0MjoKLSAgICBpZiAocmV2TmFtZXMg IT0gKGNoYXIgKiopMCkgewotCWZvciAoYSA9IDA7IHJldk5hbWVzW2FdICE9IChjaGFyICopMDsg YSsrKQotCSAgICBmcmVlKHJldk5hbWVzW2FdKTsKLQlmcmVlKHJldk5hbWVzKTsKKyAgICBpZiAo Y29uZmlnLT5sb2dob3N0bmFtZXMgPT0gRkxBR1RSVUUgJiYgIWVycm9yKSB7CisJKnBlZXJuYW1l ID0gU3RyRHVwKGhvc3QpOwogICAgIH0KLSNlbmRpZgogICAgIHJldHVybiByZXQ7CiB9CiAKIHZv aWQKICNpZiBQUk9UT1RZUEVTCi1TZXREZWZBY2Nlc3Moc3RydWN0IGluX2FkZHIgKnBBZGRyLCBj aGFyICpwSG9zdCkKK1NldERlZkFjY2VzcygpCiAjZWxzZQotU2V0RGVmQWNjZXNzKHBBZGRyLCBw SG9zdCkKLSAgICBzdHJ1Y3QgaW5fYWRkciAqcEFkZHI7Ci0gICAgY2hhciAqcEhvc3Q7CitTZXRE ZWZBY2Nlc3MoKQogI2VuZGlmCiB7CiAgICAgQUNDRVNTICphOwpAQCAtMjk4LDIyICsxNzMsNDAg QEAgU2V0RGVmQWNjZXNzKHBBZGRyLCBwSG9zdCkKICAgICBDT05EREVCVUcoKDEsICJTZXREZWZB Y2Nlc3MoKTogdHJ1c3Q9JWMsIHdobz0lcyIsIHBBQ0xpc3QtPmN0cnVzdCwKIAkgICAgICAgcEFD TGlzdC0+cGN3aG8pKTsKICNlbHNlCi0gICAgd2hpbGUgKHBBZGRyLT5zX2FkZHIgIT0gKGluX2Fk ZHJfdCkgMCkgewotCWNoYXIgKmFkZHI7CisgICAgaW50IGVycm9yOworICAgIGNoYXIgYWRkcltO SV9NQVhIT1NUXTsKKyAgICBzdHJ1Y3QgaWZhZGRycyAqbXlBZGRycywgKmlmYTsKKworICAgIC8q IGdldCBsaXN0IG9mIGFsbCBhZGRyZXNzZXMgb24gc3lzdGVtICovCisgICAgZXJyb3IgPSBnZXRp ZmFkZHJzKCZteUFkZHJzKTsKKyAgICBpZiAoZXJyb3IpIHsKKyAgICAgICAgRXJyb3IoIlNldERl ZkFjY2VzcygpOiBnZXRpZmFkZHJzOiAlcyIsIHN0cmVycm9yKGVycm5vKSk7CisgICAgICAgIHJl dHVybjsKKyAgICB9CisKKyAgICBmb3IgKGlmYSA9IG15QWRkcnM7IGlmYSAhPSBOVUxMOyBpZmEg PSBpZmEtPmlmYV9uZXh0KSB7CisgICAgICAgIC8qIHNraXAgaW50ZXJmYWNlcyB3aXRob3V0IGFk ZHJlc3Mgb3IgaW4gZG93biBzdGF0ZSAqLworICAgICAgICBpZiAoaWZhLT5pZmFfYWRkciA9PSBO VUxMIHx8ICEoaWZhLT5pZmFfZmxhZ3MgJiBJRkZfVVApKQorICAgICAgICAgICAgY29udGludWU7 CisKKyAgICAgICAgZXJyb3IgPSBnZXRuYW1laW5mbyhpZmEtPmlmYV9hZGRyLCBzaXplb2Yoc3Ry dWN0IHNvY2thZGRyX3N0b3JhZ2UpLAorICAgICAgICAgICAgICAgIGFkZHIsIHNpemVvZihhZGRy KSwgTlVMTCwgMCwgTklfTlVNRVJJQ0hPU1QpOworICAgICAgICBpZiAoZXJyb3IpCisgICAgICAg ICAgICBjb250aW51ZTsKIAotCWFkZHIgPSBpbmV0X250b2EoKnBBZGRyKTsKIAlpZiAoKGEgPSAo QUNDRVNTICopY2FsbG9jKDEsIHNpemVvZihBQ0NFU1MpKSkgPT0gKEFDQ0VTUyAqKTApCiAJICAg IE91dE9mTWVtKCk7CiAJaWYgKChhLT5wY3dobyA9IFN0ckR1cChhZGRyKSkgPT0gKGNoYXIgKikw KQogCSAgICBPdXRPZk1lbSgpOworCiAJYS0+Y3RydXN0ID0gJ2EnOwogCWEtPnBBQ25leHQgPSBw QUNMaXN0OwogCXBBQ0xpc3QgPSBhOwogCiAJQ09ORERFQlVHKCgxLCAiU2V0RGVmQWNjZXNzKCk6 IHRydXN0PSVjLCB3aG89JXMiLCBwQUNMaXN0LT5jdHJ1c3QsCiAJCSAgIHBBQ0xpc3QtPnBjd2hv KSk7Ci0JcEFkZHIrKzsKICAgICB9CisgICAgZnJlZWlmYWRkcnMobXlBZGRycyk7CiAjZW5kaWYK IH0KIApPbmx5IGluIGNvbnNlcnZlci04LjEuMTguaXB2Ni9jb25zZXJ2ZXI6IC5hY2Nlc3MuYy5z d3AKZGlmZiAtdXByIGNvbnNlcnZlci04LjEuMTgub3JpZy9jb25zZXJ2ZXIvYWNjZXNzLmggY29u c2VydmVyLTguMS4xOC5pcHY2L2NvbnNlcnZlci9hY2Nlc3MuaAotLS0gY29uc2VydmVyLTguMS4x OC5vcmlnL2NvbnNlcnZlci9hY2Nlc3MuaAkyMDA5LTA5LTI1IDA0OjM0OjI5LjAwMDAwMDAwMCAt MDQwMAorKysgY29uc2VydmVyLTguMS4xOC5pcHY2L2NvbnNlcnZlci9hY2Nlc3MuaAkyMDE0LTA0 LTAzIDA5OjUzOjEzLjU2ODcwNTkzNSAtMDQwMApAQCAtNDQsNiArNDQsNiBAQCB0eXBlZGVmIHN0 cnVjdCBhY2Nlc3MgewogICAgIHN0cnVjdCBhY2Nlc3MgKnBBQ25leHQ7CS8qIG5leHQgYWNjZXNz IGxpc3QgICAgICAgICAgICAgICAgICAgICAqLwogfSBBQ0NFU1M7CiAKLWV4dGVybiBjaGFyIEFj Y1R5cGUgUEFSQU1TKChzdHJ1Y3QgaW5fYWRkciAqLCBjaGFyICoqKSk7Ci1leHRlcm4gdm9pZCBT ZXREZWZBY2Nlc3MgUEFSQU1TKChzdHJ1Y3QgaW5fYWRkciAqLCBjaGFyICopKTsKK2V4dGVybiBj aGFyIEFjY1R5cGUgUEFSQU1TKChzdHJ1Y3Qgc29ja2FkZHJfc3RvcmFnZSAqLCBjaGFyICoqKSk7 CitleHRlcm4gdm9pZCBTZXREZWZBY2Nlc3MgUEFSQU1TKCgpKTsKIGV4dGVybiB2b2lkIERlc3Ry b3lBY2Nlc3NMaXN0IFBBUkFNUygoQUNDRVNTICopKTsKZGlmZiAtdXByIGNvbnNlcnZlci04LjEu MTgub3JpZy9jb25zZXJ2ZXIvY2xpZW50LmMgY29uc2VydmVyLTguMS4xOC5pcHY2L2NvbnNlcnZl ci9jbGllbnQuYwotLS0gY29uc2VydmVyLTguMS4xOC5vcmlnL2NvbnNlcnZlci9jbGllbnQuYwky MDA5LTA5LTI2IDA1OjIwOjE1LjAwMDAwMDAwMCAtMDQwMAorKysgY29uc2VydmVyLTguMS4xOC5p cHY2L2NvbnNlcnZlci9jbGllbnQuYwkyMDE0LTA0LTAzIDExOjAzOjUzLjQyMTc5MTM1NSAtMDQw MApAQCAtNTAsNiArNTAsOCBAQCBpbnQgYWxsb3dfc2V2ZXJpdHkgPSBMT0dfSU5GTzsKIGludCBk ZW55X3NldmVyaXR5ID0gTE9HX1dBUk5JTkc7CiAjZW5kaWYKIAorI2luY2x1ZGUgPHN5cy9zb2Nr ZXQuaD4KKyNpbmNsdWRlIDxuZXRkYi5oPgogCiAvKiBmaW5kIHRoZSBuZXh0IGd1eSB3aG8gd2Fu dHMgdG8gd3JpdGUgb24gdGhlIGNvbnNvbGUJCQkoa3NiKQogICovCkBAIC01MTcsMjQgKzUxOSwx NSBAQCBDbGllbnRBY2Nlc3NPayhwQ0wpCiAgICAgaW50IHJldHZhbCA9IDE7CiAKICNpZiBVU0Vf VU5JWF9ET01BSU5fU09DS0VUUwotICAgIHN0cnVjdCBpbl9hZGRyIGFkZHI7Ci0KLSMgaWYgSEFW RV9JTkVUX0FUT04KLSAgICBpbmV0X2F0b24oIjEyNy4wLjAuMSIsICZhZGRyKTsKLSMgZWxzZQot ICAgIGFkZHIuc19hZGRyID0gaW5ldF9hZGRyKCIxMjcuMC4wLjEiKTsKLSMgZW5kaWYKLSAgICBw Q0wtPmNhY2Nlc3MgPSBBY2NUeXBlKCZhZGRyLCAmcGVlcm5hbWUpOwotICAgIGlmIChwQ0wtPmNh Y2Nlc3MgPT0gJ3InKSB7Ci0JRmlsZVdyaXRlKHBDTC0+ZmQsIEZMQUdGQUxTRSwgImFjY2VzcyBm cm9tIHlvdXIgaG9zdCByZWZ1c2VkXHJcbiIsCi0JCSAgLTEpOwotCXJldHZhbCA9IDA7Ci0gICAg fQorICAgIC8qIHdlJ3JlIG9uIGxvY2FsaG9zdCBzbyB0aGlzIGlzIG5vLWJyYWluZXIgKi8KKyAg ICBwQ0wtPmNhY2Nlc3MgPSAnYSc7CiAjZWxzZQogICAgIHNvY2tsZW5fdCBzbzsKICAgICBpbnQg Y2ZkOwotICAgIHN0cnVjdCBzb2NrYWRkcl9pbiBpbl9wb3J0OworICAgIHN0cnVjdCBzb2NrYWRk cl9zdG9yYWdlIGluX3BvcnQ7CiAgICAgaW50IGdldHBlZXIgPSAtMTsKKyAgICBjaGFyIGFkZHJb TklfTUFYSE9TVF07CisgICAgaW50IGVycm9yOwogCiAgICAgY2ZkID0gRmlsZUZETnVtKHBDTC0+ ZmQpOwogICAgIHBDTC0+Y2FjY2VzcyA9ICdyJzsKQEAgLTU2MCw3ICs1NTMsNyBAQCBDbGllbnRB Y2Nlc3NPayhwQ0wpCiAJcmV0dmFsID0gMDsKIAlnb3RvIHNldHBlZXI7CiAgICAgfQotICAgIHBD TC0+Y2FjY2VzcyA9IEFjY1R5cGUoJmluX3BvcnQuc2luX2FkZHIsICZwZWVybmFtZSk7CisgICAg cENMLT5jYWNjZXNzID0gQWNjVHlwZSgmaW5fcG9ydCwgJnBlZXJuYW1lKTsKICAgICBpZiAocENM LT5jYWNjZXNzID09ICdyJykgewogCUZpbGVXcml0ZShwQ0wtPmZkLCBGTEFHRkFMU0UsICJhY2Nl c3MgZnJvbSB5b3VyIGhvc3QgcmVmdXNlZFxyXG4iLAogCQkgIC0xKTsKQEAgLTU3Nyw5ICs1NzAs MTcgQEAgQ2xpZW50QWNjZXNzT2socENMKQogCWVsc2UKIAkgICAgQnVpbGRTdHJpbmcoIjEyNy4w LjAuMSIsIHBDTC0+cGVlcm5hbWUpOwogI2Vsc2UKLQllbHNlIGlmIChnZXRwZWVyICE9IC0xKQot CSAgICBCdWlsZFN0cmluZyhpbmV0X250b2EoaW5fcG9ydC5zaW5fYWRkciksIHBDTC0+cGVlcm5h bWUpOwotCWVsc2UKKwllbHNlIGlmIChnZXRwZWVyICE9IC0xKSB7CisgICAgICAgIGVycm9yID0g Z2V0bmFtZWluZm8oKHN0cnVjdCBzb2NrYWRkciAqKSZpbl9wb3J0LCBzbywKKyAgICAgICAgICAg ICAgICAgICAgYWRkciwgc2l6ZW9mKGFkZHIpLCBOVUxMLCAwLCBOSV9OVU1FUklDSE9TVCk7Cisg ICAgICAgIGlmIChlcnJvcikgeworCSAgICAgICAgRmlsZVdyaXRlKHBDTC0+ZmQsIEZMQUdGQUxT RSwgImdldG5hbWVpbmZvIGZhaWxlZFxyXG4iLCAtMSk7CisgICAgICAgICAgICBFcnJvcigiQ2xp ZW50QWNjZXNzT2soKTogZ2F0ZW5hbWVpbmZvOiAlcyIsIGdhaV9zdHJlcnJvcihlcnJvcikpOwor ICAgICAgICAgICAgcmV0dmFsID0gMDsKKyAgICAgICAgfQorCisJICAgIEJ1aWxkU3RyaW5nKGFk ZHIsIHBDTC0+cGVlcm5hbWUpOworICAgIH0gZWxzZQogCSAgICBCdWlsZFN0cmluZygiPHVua25v d24+IiwgcENMLT5wZWVybmFtZSk7CiAjZW5kaWYKICAgICB9Ck9ubHkgaW4gY29uc2VydmVyLTgu MS4xOC5pcHY2L2NvbnNlcnZlcjogLmNsaWVudC5jLnN3cApkaWZmIC11cHIgY29uc2VydmVyLTgu MS4xOC5vcmlnL2NvbnNlcnZlci9jbGllbnQuaCBjb25zZXJ2ZXItOC4xLjE4LmlwdjYvY29uc2Vy dmVyL2NsaWVudC5oCi0tLSBjb25zZXJ2ZXItOC4xLjE4Lm9yaWcvY29uc2VydmVyL2NsaWVudC5o CTIwMDktMDktMjUgMDQ6MzQ6MjkuMDAwMDAwMDAwIC0wNDAwCisrKyBjb25zZXJ2ZXItOC4xLjE4 LmlwdjYvY29uc2VydmVyL2NsaWVudC5oCTIwMTQtMDMtMjUgMTQ6MTU6NDUuNTI2NDQ4MzgxIC0w NDAwCkBAIC04NSw3ICs4NSw3IEBAIHR5cGVkZWYgc3RydWN0IGNsaWVudCB7CQkvKiBDb25uZWN0 aW9uIEkKICAgICBJT1NUQVRFIGlvU3RhdGU7CQkvKiBzdGF0ZSBvZiB0aGUgc29ja2V0ICAgICAg ICAgICAgICAgICAgKi8KICAgICB0aW1lX3Qgc3RhdGVUaW1lcjsJCS8qIHRpbWVyIGZvciB2YXJp b3VzIGlvU3RhdGUgc3RhdGVzICovCiAgICAgU1RSSU5HICphY2NtZDsJCS8qIHRoZSBjb21tYW5k IHRoZSB1c2VyIGlzc3VlZCAgICAgICAgICAqLwotICAgIHN0cnVjdCBzb2NrYWRkcl9pbgorICAg IHN0cnVjdCBzb2NrYWRkcl9zdG9yYWdlCiAgICAgICBjbmN0X3BvcnQ7CQkvKiB3aGVyZSBmcm9t ICAgICAgICAgICAgICAgICAgICAgICAgICAgKi8KIH0gQ09OU0NMSUVOVDsKIApkaWZmIC11cHIg Y29uc2VydmVyLTguMS4xOC5vcmlnL2NvbnNlcnZlci9jb25zZW50LmMgY29uc2VydmVyLTguMS4x OC5pcHY2L2NvbnNlcnZlci9jb25zZW50LmMKLS0tIGNvbnNlcnZlci04LjEuMTgub3JpZy9jb25z ZXJ2ZXIvY29uc2VudC5jCTIwMDktMDktMjUgMDQ6MzQ6MjkuMDAwMDAwMDAwIC0wNDAwCisrKyBj b25zZXJ2ZXItOC4xLjE4LmlwdjYvY29uc2VydmVyL2NvbnNlbnQuYwkyMDE0LTA0LTA0IDE0OjA2 OjU3LjAzNTE0NDA0OSAtMDQwMApAQCAtODUxLDk2ICs4NTEsOTMgQEAgQ29uc0luaXQocENFKQog CSAgICBicmVhazsKIAljYXNlIEhPU1Q6CiAJICAgIHsKLQkJc3RydWN0IHNvY2thZGRyX2luIHBv cnQ7Ci0JCXN0cnVjdCBob3N0ZW50ICpocDsKKyAgICAgICAgICAgIGludCBlcnJvcjsKKyAgICAg ICAgICAgIGNoYXIgaG9zdFtOSV9NQVhIT1NUXTsKKyAgICAgICAgICAgIGNoYXIgc2VydltOSV9N QVhTRVJWXTsKKyAgICAgICAgICAgIHN0cnVjdCBhZGRyaW5mbyAqYWksICpycCwgaGludHM7CiAj aWYgSEFWRV9TRVRTT0NLT1BUCi0JCWludCBvbmUgPSAxOworICAgICAgICAgICAgaW50IG9uZSA9 IDE7CiAjZW5kaWYKIAotCQl1c2xlZXAoMTAwMDAwKTsJLyogTm90IGFsbCB0ZXJtaW5hbCBzZXJ2 ZXJzIGNhbiBrZWVwIHVwICovCisgICAgICAgICAgICB1c2xlZXAoMTAwMDAwKTsJLyogTm90IGFs bCB0ZXJtaW5hbCBzZXJ2ZXJzIGNhbiBrZWVwIHVwICovCiAKLSNpZiBIQVZFX01FTVNFVAotCQlt ZW1zZXQoKHZvaWQgKikmcG9ydCwgMCwgc2l6ZW9mKHBvcnQpKTsKLSNlbHNlCi0JCWJ6ZXJvKChj aGFyICopJnBvcnQsIHNpemVvZihwb3J0KSk7Ci0jZW5kaWYKLQotCQlpZiAoKGhwID0gZ2V0aG9z dGJ5bmFtZShwQ0UtPmhvc3QpKSA9PSBOVUxMKSB7Ci0JCSAgICBFcnJvcigiWyVzXSBnZXRob3N0 YnluYW1lKCVzKTogJXM6IGZvcmNpbmcgZG93biIsCi0JCQkgIHBDRS0+c2VydmVyLCBwQ0UtPmhv c3QsIGhzdHJlcnJvcihoX2Vycm5vKSk7Ci0JCSAgICBDb25zRG93bihwQ0UsIEZMQUdUUlVFLCBG TEFHVFJVRSk7Ci0JCSAgICByZXR1cm47Ci0JCX0KLSNpZiBIQVZFX01FTUNQWQotCQltZW1jcHko JnBvcnQuc2luX2FkZHIuc19hZGRyLCBocC0+aF9hZGRyX2xpc3RbMF0sCi0JCSAgICAgICBocC0+ aF9sZW5ndGgpOwotI2Vsc2UKLQkJYmNvcHkoaHAtPmhfYWRkcl9saXN0WzBdLCAmcG9ydC5zaW5f YWRkci5zX2FkZHIsCi0JCSAgICAgIGhwLT5oX2xlbmd0aCk7Ci0jZW5kaWYKLQkJcG9ydC5zaW5f ZmFtaWx5ID0gaHAtPmhfYWRkcnR5cGU7Ci0JCXBvcnQuc2luX3BvcnQgPSBodG9ucyhwQ0UtPm5l dHBvcnQpOworIyBpZiBIQVZFX01FTVNFVAorICAgICAgICAgICAgbWVtc2V0KCZoaW50cywgMCwg c2l6ZW9mKGhpbnRzKSk7CisjIGVsc2UKKyAgICAgICAgICAgIGJ6ZXJvKCZoaW50cywgc2l6ZW9m KGhpbnRzKSk7CisjIGVuZGlmCisKKyAgICAgICAgICAgIGhpbnRzLmFpX2ZsYWdzID0gQUlfQURE UkNPTkZJRzsKKyAgICAgICAgICAgIGhpbnRzLmFpX3NvY2t0eXBlID0gU09DS19TVFJFQU07Cisg ICAgICAgICAgICBzbnByaW50ZihzZXJ2LCBzaXplb2Yoc2VydiksICIlaHUiLCBwQ0UtPm5ldHBv cnQpOworCisgICAgICAgICAgICBlcnJvciA9IGdldGFkZHJpbmZvKHBDRS0+aG9zdCwgc2Vydiwg JmhpbnRzLCAmYWkpOworICAgICAgICAgICAgaWYgKGVycm9yKSB7CisgICAgICAgICAgICAgICAg RXJyb3IoIlslc10gZ2V0YWRkcmluZm8oJXMpOiAlczogZm9yY2luZiBkb3duIiwKKyAgICAgICAg ICAgICAgICAgICAgICAgIHBDRS0+c2VydmVyLCBwQ0UtPmhvc3QsIGdhaV9zdHJlcnJvcihlcnJv cikpOworICAgICAgICAgICAgICAgIENvbnNEb3duKHBDRSwgRkxBR1RSVUUsIEZMQUdUUlVFKTsK KyAgICAgICAgICAgICAgICByZXR1cm47CisgICAgICAgICAgICB9CisKKyAgICAgICAgICAgIHJw ID0gYWk7CisgICAgICAgICAgICB3aGlsZShycCkgeworICAgICAgICAgICAgICAgIGVycm9yID0g Z2V0bmFtZWluZm8ocnAtPmFpX2FkZHIsIHJwLT5haV9hZGRybGVuLAorICAgICAgICAgICAgICAg ICAgICAgICAgaG9zdCwgc2l6ZW9mKGhvc3QpLAorICAgICAgICAgICAgICAgICAgICAgICAgc2Vy diwgc2l6ZW9mKHNlcnYpLAorICAgICAgICAgICAgICAgICAgICAgICAgTklfTlVNRVJJQ0hPU1Qg fCBOSV9OVU1FUklDU0VSVik7CisgICAgICAgICAgICAgICAgaWYgKGVycm9yKSAKKyAgICAgICAg ICAgICAgICAgICAgY29udGludWU7CisgICAgICAgICAgICAgICAgQ09ORERFQlVHKCgxLCAiWyVz XTogdHJ5aW5nIGhvc3RuYW1lPSVzLCBpcD0lcywgcG9ydD0lcyIsCisgICAgICAgICAgICAgICAg ICAgICAgICAgICAgcENFLT5zZXJ2ZXIsIHBDRS0+aG9zdCwgaG9zdCwgc2VydikpOwogCi0JCWlm ICgoY29maWxlID0gc29ja2V0KEFGX0lORVQsIFNPQ0tfU1RSRUFNLCAwKSkgPCAwKSB7Ci0JCSAg ICBFcnJvcgotCQkJKCJbJXNdIHNvY2tldChBRl9JTkVULFNPQ0tfU1RSRUFNKTogJXM6IGZvcmNp bmcgZG93biIsCi0JCQkgcENFLT5zZXJ2ZXIsIHN0cmVycm9yKGVycm5vKSk7Ci0JCSAgICBDb25z RG93bihwQ0UsIEZMQUdUUlVFLCBGTEFHVFJVRSk7Ci0JCSAgICByZXR1cm47Ci0JCX0KKyAgICAg ICAgICAgICAgICBjb2ZpbGUgPSBzb2NrZXQocnAtPmFpX2ZhbWlseSwgcnAtPmFpX3NvY2t0eXBl LCBycC0+YWlfcHJvdG9jb2wpOworICAgICAgICAgICAgICAgIGlmIChjb2ZpbGUgIT0gLTEpIHsK ICNpZiBIQVZFX1NFVFNPQ0tPUFQKLQkJaWYgKHNldHNvY2tvcHQKLQkJICAgIChjb2ZpbGUsIFNP TF9TT0NLRVQsIFNPX0tFRVBBTElWRSwgKGNoYXIgKikmb25lLAotCQkgICAgIHNpemVvZihvbmUp KSA8IDApIHsKLQkJICAgIEVycm9yCi0JCQkoIlslc10gc2V0c29ja29wdCgldSxTT19LRUVQQUxJ VkUpOiAlczogZm9yY2luZyBkb3duIiwKLQkJCSBwQ0UtPnNlcnZlciwgY29maWxlLCBzdHJlcnJv cihlcnJubykpOwotCQkgICAgQ29uc0Rvd24ocENFLCBGTEFHVFJVRSwgRkxBR1RSVUUpOwotCQkg ICAgY2xvc2UoY29maWxlKTsKLQkJICAgIHJldHVybjsKLQkJfQotI2VuZGlmCi0KLQkJaWYgKCFT ZXRGbGFncyhjb2ZpbGUsIE9fTk9OQkxPQ0ssIDApKSB7Ci0JCSAgICBDb25zRG93bihwQ0UsIEZM QUdUUlVFLCBGTEFHVFJVRSk7Ci0JCSAgICBjbG9zZShjb2ZpbGUpOwotCQkgICAgcmV0dXJuOwot CQl9CisgICAgICAgICAgICAgICAgICAgIGlmIChzZXRzb2Nrb3B0KGNvZmlsZSwgU09MX1NPQ0tF VCwgU09fS0VFUEFMSVZFLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoY2hhciAq KSZvbmUsIHNpemVvZihvbmUpKSA8IDApIAorICAgICAgICAgICAgICAgICAgICAgICAgZ290byBm YWlsOworI2VuZGlmCisgICAgICAgICAgICAgICAgICAgIGlmICghU2V0RmxhZ3MoY29maWxlLCBP X05PTkJMT0NLLCAwKSkgCisgICAgICAgICAgICAgICAgICAgICAgICBnb3RvIGZhaWw7CisKKyAg ICAgICAgICAgICAgICAgICAgaWYgKChyZXQgPSBjb25uZWN0KGNvZmlsZSwgcnAtPmFpX2FkZHIs IHJwLT5haV9hZGRybGVuKSkgPT0gMCkgCisgICAgICAgICAgICAgICAgICAgICAgICBnb3RvIHN1 Y2Nlc3M7CitmYWlsOgorICAgICAgICAgICAgICAgICAgICBjbG9zZShjb2ZpbGUpOworICAgICAg ICAgICAgICAgIH0KKyAgICAgICAgICAgICAgICBycCA9IHJwLT5haV9uZXh0OworICAgICAgICAg ICAgfQorCisgICAgICAgICAgICBFcnJvcigiWyVzXTogVW5hYmxlIHRvIGNvbm5lY3QgdG8gJXM6 JXMiLAorICAgICAgICAgICAgICAgICAgICBwQ0UtPnNlcnZlciwgaG9zdCwgc2Vydik7IAorICAg ICAgICAgICAgQ29uc0Rvd24ocENFLCBGTEFHVFJVRSwgRkxBR1RSVUUpOworICAgICAgICAgICAg cmV0dXJuOworc3VjY2VzczoKKyAgICAgICAgICAgIGZyZWVhZGRyaW5mbyhhaSk7CisgICAgICAg IH0KKworICAgICAgICBpZiAoKHBDRS0+Y29maWxlID0KKyAgICAgICAgICAgICAgICAgICAgRmls ZU9wZW5GRChjb2ZpbGUsIHNpbXBsZVNvY2tldCkpID09IChDT05TRklMRSAqKTApIHsKKyAgICAg ICAgICAgIEVycm9yKCJbJXNdIEZpbGVPcGVuRkQoJWQsc2ltcGxlU29ja2V0KSBmYWlsZWQ6IGZv cmNpbmcgZG93biIsCisgICAgICAgICAgICAgICAgICAgIHBDRS0+c2VydmVyLCBjb2ZpbGUpOwor ICAgICAgICAgICAgQ29uc0Rvd24ocENFLCBGTEFHVFJVRSwgRkxBR1RSVUUpOworICAgICAgICAg ICAgY2xvc2UoY29maWxlKTsKKyAgICAgICAgICAgIHJldHVybjsKKyAgICAgICAgfQorCisgICAg ICAgIGlmIChyZXQgPT0gMCkgeworICAgICAgICAgICAgcENFLT5pb1N0YXRlID0gSVNOT1JNQUw7 CisgICAgICAgICAgICBwQ0UtPnN0YXRlVGltZXIgPSAwOworICAgICAgICB9IGVsc2UgeworICAg ICAgICAgICAgcENFLT5pb1N0YXRlID0gSU5DT05ORUNUOworICAgICAgICAgICAgcENFLT5zdGF0 ZVRpbWVyID0gdGltZSgodGltZV90ICopMCkgKyBDT05ORUNUVElNRU9VVDsKKyAgICAgICAgICAg IGlmICh0aW1lcnNbVF9TVEFURV0gPT0gKHRpbWVfdCkwIHx8CisgICAgICAgICAgICAgICAgICAg IHRpbWVyc1tUX1NUQVRFXSA+IHBDRS0+c3RhdGVUaW1lcikKKyAgICAgICAgICAgICAgICB0aW1l cnNbVF9TVEFURV0gPSBwQ0UtPnN0YXRlVGltZXI7CisgICAgICAgIH0KKyAgICAgICAgcENFLT5m dXAgPSAxOwogCi0JCWlmICgocmV0ID0KLQkJICAgICBjb25uZWN0KGNvZmlsZSwgKHN0cnVjdCBz b2NrYWRkciAqKSZwb3J0LAotCQkJICAgICBzaXplb2YocG9ydCkpKQotCQkgICAgPCAwKSB7Ci0J CSAgICBpZiAoZXJybm8gIT0gRUlOUFJPR1JFU1MpIHsKLQkJCUVycm9yKCJbJXNdIGNvbm5lY3Qo JXUpOiAlczogZm9yY2luZyBkb3duIiwKLQkJCSAgICAgIHBDRS0+c2VydmVyLCBjb2ZpbGUsIHN0 cmVycm9yKGVycm5vKSk7Ci0JCQlDb25zRG93bihwQ0UsIEZMQUdUUlVFLCBGTEFHVFJVRSk7Ci0J CQljbG9zZShjb2ZpbGUpOwotCQkJcmV0dXJuOwotCQkgICAgfQotCQl9Ci0JICAgIH0KLQkgICAg aWYgKChwQ0UtPmNvZmlsZSA9Ci0JCSBGaWxlT3BlbkZEKGNvZmlsZSwgc2ltcGxlU29ja2V0KSkg PT0gKENPTlNGSUxFICopMCkgewotCQlFcnJvcgotCQkgICAgKCJbJXNdIEZpbGVPcGVuRkQoJWQs c2ltcGxlU29ja2V0KSBmYWlsZWQ6IGZvcmNpbmcgZG93biIsCi0JCSAgICAgcENFLT5zZXJ2ZXIs IGNvZmlsZSk7Ci0JCUNvbnNEb3duKHBDRSwgRkxBR1RSVUUsIEZMQUdUUlVFKTsKLQkJY2xvc2Uo Y29maWxlKTsKLQkJcmV0dXJuOwotCSAgICB9Ci0JICAgIGlmIChyZXQgPT0gMCkgewotCQlwQ0Ut PmlvU3RhdGUgPSBJU05PUk1BTDsKLQkJcENFLT5zdGF0ZVRpbWVyID0gMDsKLQkgICAgfSBlbHNl IHsKLQkJcENFLT5pb1N0YXRlID0gSU5DT05ORUNUOwotCQlwQ0UtPnN0YXRlVGltZXIgPSB0aW1l KCh0aW1lX3QgKikwKSArIENPTk5FQ1RUSU1FT1VUOwotCQlpZiAodGltZXJzW1RfU1RBVEVdID09 ICh0aW1lX3QpMCB8fAotCQkgICAgdGltZXJzW1RfU1RBVEVdID4gcENFLT5zdGF0ZVRpbWVyKQot CQkgICAgdGltZXJzW1RfU1RBVEVdID0gcENFLT5zdGF0ZVRpbWVyOwotCSAgICB9Ci0JICAgIHBD RS0+ZnVwID0gMTsKLQkgICAgYnJlYWs7CisgICAgICAgIGJyZWFrOwogCWNhc2UgVURTOgogCSAg ICB7CiAJCXN0cnVjdCBzb2NrYWRkcl91biBwb3J0OwpAQCAtMTEyMywxNDAgKzExMjAsNTcgQEAg QWRkcnNNYXRjaChhZGRyMSwgYWRkcjIpCiAgICAgY2hhciAqYWRkcjI7CiAjZW5kaWYKIHsKLSAg ICAvKiBzbywgc2luY2Ugd2UgbWlnaHQgdXNlIGluZXRfYWRkciwgd2UncmUgZ29pbmcgdG8gdXNl Ci0gICAgICogKGluX2FkZHJfdCkoLTEpIGFzIGEgc2lnbiBvZiBhbiBpbnZhbGlkIGlwIGFkZHJl c3MuCi0gICAgICogc2FkLCBidXQgdHJ1ZS4KLSAgICAgKi8KLSAgICBpbl9hZGRyX3QgaW5BZGRy MSA9IChpbl9hZGRyX3QpICgtMSk7Ci0gICAgaW5fYWRkcl90IGluQWRkcjIgPSAoaW5fYWRkcl90 KSAoLTEpOwotI2lmIEhBVkVfSU5FVF9BVE9OCi0gICAgc3RydWN0IGluX2FkZHIgaW5ldEFkZHIx OwotICAgIHN0cnVjdCBpbl9hZGRyIGluZXRBZGRyMjsKLSNlbmRpZgorICAgIGludCBlcnJvciwg cmV0ID0gMDsKKyAgICBzdHJ1Y3QgYWRkcmluZm8gKmFpMSwgKmFpMiwgaGludHM7CiAKICAgICAv KiBmaXJzdCB0cnkgc2ltcGxlIGNoYXJhY3RlciBzdHJpbmcgbWF0Y2ggKi8KICAgICBpZiAoc3Ry Y2FzZWNtcChhZGRyMSwgYWRkcjIpID09IDApCi0JcmV0dXJuIDE7CisgICAgICAgIHJldHVybiAx OwogCi0gICAgLyogbm93IHRyeSBpcCBhZGRyZXNzIG1hdGNoIChjb3VsZCBoYXZlIGxlYWRpbmcg emVyb3Mgb3Igc29tZXRoaW5nKSAqLwotI2lmIEhBVkVfSU5FVF9BVE9OCi0gICAgaWYgKGluZXRf YXRvbihhZGRyMSwgJmluZXRBZGRyMSkgIT0gMCkKLQlpbkFkZHIxID0gaW5ldEFkZHIxLnNfYWRk cjsKLSAgICBpZiAoaW5ldF9hdG9uKGFkZHIyLCAmaW5ldEFkZHIyKSAhPSAwKQotCWluQWRkcjIg PSBpbmV0QWRkcjIuc19hZGRyOwotI2Vsc2UKLSAgICBpbkFkZHIxID0gaW5ldF9hZGRyKGFkZHIx KTsKLSAgICBpbkFkZHIyID0gaW5ldF9hZGRyKGFkZHIyKTsKLSNlbmRpZgotCi0gICAgLyogaWYg Ym90aCBhcmUgaXAgYWRkcmVzc2VzLCB3ZSBqdXN0IG1hdGNoICovCi0gICAgaWYgKGluQWRkcjEg IT0gKGluX2FkZHJfdCkgKC0xKSAmJiBpbkFkZHIyICE9IChpbl9hZGRyX3QpICgtMSkpCi0JcmV0 dXJuICEKLSNpZiBIQVZFX01FTUNNUAotCSAgICBtZW1jbXAoJmluQWRkcjEsICZpbkFkZHIyLCBz aXplb2YoaW5BZGRyMSkpCi0jZWxzZQotCSAgICBiY21wKCZpbkFkZHIxLCAmaW5BZGRyMiwgc2l6 ZW9mKGluQWRkcjEpKQotI2VuZGlmCi0JICAgIDsKLQotICAgIC8qIGJvdGggYXJlIGhvc3RuYW1l cy4uLnRoaXMgc3Vja3MgJ2NhdXNlIHdlIGhhdmUgdG8gY29weSBvbmUKLSAgICAgKiBsaXN0IGFu ZCBjb21wYXJlIGl0IHRvIHRoZSBvdGhlcgotICAgICAqLwotICAgIGlmIChpbkFkZHIxID09IChp bl9hZGRyX3QpICgtMSkgJiYgaW5BZGRyMiA9PSAoaW5fYWRkcl90KSAoLTEpKSB7Ci0Jc3RydWN0 IGhvc3RlbnQgKmhlOwotCWludCBpLCBqLCBjOwotCWluX2FkZHJfdCAqYWRkcnM7Ci0KLQlpZiAo KGhlID0gZ2V0aG9zdGJ5bmFtZShhZGRyMSkpID09IChzdHJ1Y3QgaG9zdGVudCAqKTApIHsKLQkg ICAgRXJyb3IoIkFkZHJzTWF0Y2goKTogZ2V0aG9zdGJ5bmFtZSglcyk6ICVzIiwgYWRkcjEsCi0J CSAgaHN0cmVycm9yKGhfZXJybm8pKTsKLQkgICAgcmV0dXJuIDA7Ci0JfQotCWlmICg0ICE9IGhl LT5oX2xlbmd0aCB8fCBBRl9JTkVUICE9IGhlLT5oX2FkZHJ0eXBlKSB7Ci0JICAgIEVycm9yCi0J CSgiQWRkcnNNYXRjaCgpOiBnZXRob3N0YnluYW1lKCVzKTogd3JvbmcgYWRkcmVzcyBzaXplICg0 ICE9ICVkKSBvciBhZGRyZXNzIGZhbWlseSAoJWQgIT0gJWQpIiwKLQkJIGFkZHIxLCBoZS0+aF9s ZW5ndGgsIEFGX0lORVQsIGhlLT5oX2FkZHJ0eXBlKTsKLQkgICAgcmV0dXJuIDA7Ci0JfQotCWZv ciAoaSA9IDA7IGhlLT5oX2FkZHJfbGlzdFtpXSAhPSAoY2hhciAqKTA7IGkrKyk7Ci0JYyA9IGk7 Ci0JYWRkcnMgPSAoaW5fYWRkcl90ICopIGNhbGxvYyhpLCBzaXplb2YoaW5fYWRkcl90KSk7Ci0J aWYgKGFkZHJzID09IChpbl9hZGRyX3QgKikgMCkKLQkgICAgT3V0T2ZNZW0oKTsKLQlmb3IgKGkg PSAwOyBpIDwgYzsgaSsrKSB7Ci0jaWYgSEFWRV9NRU1DUFkKLQkgICAgbWVtY3B5KCYoYWRkcnNb aV0pLCBoZS0+aF9hZGRyX2xpc3RbaV0sIGhlLT5oX2xlbmd0aCk7Ci0jZWxzZQotCSAgICBiY29w eShoZS0+aF9hZGRyX2xpc3RbaV0sICYoYWRkcnNbaV0pLCBoZS0+aF9sZW5ndGgpOwotI2VuZGlm Ci0JfQotCi0JLyogbm93IHByb2Nlc3MgdGhlIHNlY29uZCBob3N0bmFtZSAqLwotCWlmICgoaGUg PSBnZXRob3N0YnluYW1lKGFkZHIyKSkgPT0gKHN0cnVjdCBob3N0ZW50ICopMCkgewotCSAgICBF cnJvcigiQWRkcnNNYXRjaCgpOiBnZXRob3N0YnluYW1lKCVzKTogJXMiLCBhZGRyMiwKLQkJICBo c3RyZXJyb3IoaF9lcnJubykpOwotCSAgICBmcmVlKGFkZHJzKTsKLQkgICAgcmV0dXJuIDA7Ci0J fQotCWlmICg0ICE9IGhlLT5oX2xlbmd0aCB8fCBBRl9JTkVUICE9IGhlLT5oX2FkZHJ0eXBlKSB7 Ci0JICAgIEVycm9yCi0JCSgiQWRkcnNNYXRjaCgpOiBnZXRob3N0YnluYW1lKCVzKTogd3Jvbmcg YWRkcmVzcyBzaXplICg0ICE9ICVkKSBvciBhZGRyZXNzIGZhbWlseSAoJWQgIT0gJWQpIiwKLQkJ IGFkZHIyLCBoZS0+aF9sZW5ndGgsIEFGX0lORVQsIGhlLT5oX2FkZHJ0eXBlKTsKLQkgICAgZnJl ZShhZGRycyk7Ci0JICAgIHJldHVybiAwOwotCX0KLQlmb3IgKGogPSAwOyBoZS0+aF9hZGRyX2xp c3Rbal0gIT0gKGNoYXIgKikwOyBqKyspIHsKLQkgICAgZm9yIChpID0gMDsgaSA8IGM7IGkrKykg ewotCQlpZiAoCi0jaWYgSEFWRV9NRU1DTVAKLQkJICAgICAgIG1lbWNtcCgmKGFkZHJzW2ldKSwg aGUtPmhfYWRkcl9saXN0W2pdLAotCQkJICAgICAgaGUtPmhfbGVuZ3RoKQotI2Vsc2UKLQkJICAg ICAgIGJjbXAoJihhZGRyc1tpXSksIGhlLT5oX2FkZHJfbGlzdFtqXSwgaGUtPmhfbGVuZ3RoKQot I2VuZGlmCi0JCSAgICAgICA9PSAwKSB7Ci0JCSAgICBmcmVlKGFkZHJzKTsKLQkJICAgIHJldHVy biAxOwotCQl9Ci0JICAgIH0KLQl9Ci0JZnJlZShhZGRycyk7Ci0gICAgfSBlbHNlIHsJCQkvKiBv bmUgaG9zdG5hbWUsIG9uZSBpcCBhZGRyICovCi0JaW5fYWRkcl90ICppYWRkcjsKLQljaGFyICph ZGRyOwotCXN0cnVjdCBob3N0ZW50ICpoZTsKLQlpbnQgaTsKLQotCWlmIChpbkFkZHIxID09IChp bl9hZGRyX3QpICgtMSkpIHsKLQkgICAgYWRkciA9IGFkZHIxOwotCSAgICBpYWRkciA9ICZpbkFk ZHIyOwotCX0gZWxzZSB7Ci0JICAgIGFkZHIgPSBhZGRyMjsKLQkgICAgaWFkZHIgPSAmaW5BZGRy MTsKLQl9Ci0JaWYgKChoZSA9IGdldGhvc3RieW5hbWUoYWRkcikpID09IChzdHJ1Y3QgaG9zdGVu dCAqKTApIHsKLQkgICAgRXJyb3IoIkFkZHJzTWF0Y2goKTogZ2V0aG9zdGJ5bmFtZSglcyk6ICVz IiwgYWRkciwKLQkJICBoc3RyZXJyb3IoaF9lcnJubykpOwotCSAgICByZXR1cm4gMDsKLQl9Ci0J aWYgKDQgIT0gaGUtPmhfbGVuZ3RoIHx8IEFGX0lORVQgIT0gaGUtPmhfYWRkcnR5cGUpIHsKLQkg ICAgRXJyb3IKLQkJKCJBZGRyc01hdGNoKCk6IHdyb25nIGFkZHJlc3Mgc2l6ZSAoNCAhPSAlZCkg b3IgYWRkcmVzcyBmYW1pbHkgKCVkICE9ICVkKSIsCi0JCSBoZS0+aF9sZW5ndGgsIEFGX0lORVQs IGhlLT5oX2FkZHJ0eXBlKTsKLQkgICAgcmV0dXJuIDA7Ci0JfQotCWZvciAoaSA9IDA7IGhlLT5o X2FkZHJfbGlzdFtpXSAhPSAoY2hhciAqKTA7IGkrKykgewotCSAgICBpZiAoCi0jaWYgSEFWRV9N RU1DTVAKLQkJICAgbWVtY21wKGlhZGRyLCBoZS0+aF9hZGRyX2xpc3RbaV0sIGhlLT5oX2xlbmd0 aCkKLSNlbHNlCi0JCSAgIGJjbXAoaWFkZHIsIGhlLT5oX2FkZHJfbGlzdFtpXSwgaGUtPmhfbGVu Z3RoKQotI2VuZGlmCi0JCSAgID09IDApCi0JCXJldHVybiAxOwotCX0KKyMgaWYgSEFWRV9NRU1T RVQKKyAgICBtZW1zZXQoJmhpbnRzLCAwLCBzaXplb2YoaGludHMpKTsKKyMgZWxzZQorICAgIGJ6 ZXJvKCZoaW50cywgc2l6ZW9mKGhpbnRzKSk7CisjIGVuZGlmCisgICAgaGludHMuYWlfZmxhZ3Mg PSBBSV9BRERSQ09ORklHOworICAgIGhpbnRzLmFpX3NvY2t0eXBlID0gU09DS19TVFJFQU07CisK KyAgICBlcnJvciA9IGdldGFkZHJpbmZvKGFkZHIxLCBOVUxMLCAmaGludHMsICZhaTEpOworICAg IGlmIChlcnJvcikgeworICAgICAgICBFcnJvcigiZ2V0YWRkcmluZm8oJXMpOiAlcyIsIGFkZHIx LCBnYWlfc3RyZXJyb3IoZXJyb3IpKTsKKyAgICAgICAgZ290byBkb25lOworICAgIH0KKyAgICBl cnJvciA9IGdldGFkZHJpbmZvKGFkZHIyLCBOVUxMLCAmaGludHMsICZhaTIpOworICAgIGlmIChl cnJvcikgeworICAgICAgICBFcnJvcigiZ2V0YWRkcmluZm8oJXMpOiAlcyIsIGFkZHIyLCBnYWlf c3RyZXJyb3IoZXJyb3IpKTsKKyAgICAgICAgZ290byBkb25lOwogICAgIH0KLSAgICByZXR1cm4g MDsKKyAgICAgICAgCisgICAgZm9yIChhaTE7IGFpMSAhPSBOVUxMOyBhaTEgPSBhaTEtPmFpX25l eHQpIHsKKyAgICAgICAgZm9yIChhaTI7IGFpMiAhPSBOVUxMOyBhaTIgPSBhaTItPmFpX25leHQp IHsKKyAgICAgICAgICAgIGlmIChhaTEtPmFpX2FkZHItPnNhX2ZhbWlseSAhPSBhaTItPmFpX2Fk ZHItPnNhX2ZhbWlseSkKKyAgICAgICAgICAgICAgICBjb250aW51ZTsKKyAgICAgICAgICAgICAg ICAKKyAgICAgICAgICAgIGlmICgKKyMgaWYgSEFWRV9NRU1DTVAKKyAgICAgICAgICAgICAgICAg ICAgbWVtY21wKCZhaTEtPmFpX2FkZHIsICZhaTItPmFpX2FkZHIsCisgICAgICAgICAgICAgICAg ICAgICAgICBzaXplb2Yoc3RydWN0IHNvY2thZGRyX3N0b3JhZ2UpKQorIyBlbHNlCisgICAgICAg ICAgICAgICAgICAgIGJjbXAoJmFpMS0+YWlfYWRkciwgJmFpMi0+YWlfYWRkciwKKyAgICAgICAg ICAgICAgICAgICAgICAgIHNpemVvZihzdHJ1Y3Qgc29ja2FkZHJfc3RvcmFnZSkpCisjIGVuZGlm CisgICAgICAgICAgICAgICAgICAgID09IDApIHsKKyAgICAgICAgICAgICAgICByZXQgPSAxOwor ICAgICAgICAgICAgICAgIGdvdG8gZG9uZTsKKyAgICAgICAgICAgIH0KKyAgICAgICAgfQorICAg IH0KKworZG9uZToKKyAgICBmcmVlYWRkcmluZm8oYWkxKTsKKyAgICBmcmVlYWRkcmluZm8oYWky KTsKKyAgICBNc2coImNvbXBhcmUgJXMgYW5kICVzIHJldHVybnMgJWQiLCBhZGRyMSwgYWRkcjIs IHJldCk7CisgICAgcmV0dXJuIHJldDsKIH0KIAogLyogdGhyZWFkIHRoZXIgbGlzdCBvZiB1bmlx IGNvbnNvbGUgc2VydmVyIG1hY2hpbmVzLCBhbGlhc2VzIGZvcgkoa3NiKQpPbmx5IGluIGNvbnNl cnZlci04LjEuMTguaXB2Ni9jb25zZXJ2ZXI6IC5jb25zZW50LmMuc3dwCmRpZmYgLXVwciBjb25z ZXJ2ZXItOC4xLjE4Lm9yaWcvY29uc2VydmVyL2N1dGlsLmMgY29uc2VydmVyLTguMS4xOC5pcHY2 L2NvbnNlcnZlci9jdXRpbC5jCi0tLSBjb25zZXJ2ZXItOC4xLjE4Lm9yaWcvY29uc2VydmVyL2N1 dGlsLmMJMjAxMC0xMS0wMSAyMzo0Mjo1Ny4wMDAwMDAwMDAgLTA0MDAKKysrIGNvbnNlcnZlci04 LjEuMTguaXB2Ni9jb25zZXJ2ZXIvY3V0aWwuYwkyMDE0LTA0LTAzIDA4OjA1OjQ1Ljg4ODczNTU4 NyAtMDQwMApAQCAtMTIsNiArMTIsNyBAQAogI2luY2x1ZGUgPHZlcnNpb24uaD4KIAogI2luY2x1 ZGUgPG5ldC9pZi5oPgorI2luY2x1ZGUgPGlmYWRkcnMuaD4KICNpZiBIQVZFX1NZU19TT0NLSU9f SAogIyBpbmNsdWRlIDxzeXMvc29ja2lvLmg+CiAjZW5kaWYKQEAgLTI3LDcgKzI4LDYgQEAgcGlk X3QgdGhlcGlkID0gMDsKIGludCBmRGVidWcgPSAwOwogU1RSSU5HICphbGxTdHJpbmdzID0gKFNU UklORyAqKTA7CiBpbnQgc3RyaW5nQ291bnQgPSAwOwkJLyogY291bnQgb2YgYWxsU3RyaW5ncyBs aXN0ICovCi1zdHJ1Y3QgaW5fYWRkciAqbXlBZGRycyA9IChzdHJ1Y3QgaW5fYWRkciAqKTA7CiBj aGFyIG15SG9zdG5hbWVbTUFYSE9TVE5BTUVdOwkvKiBzdGFmZi5jYy5wdXJkdWUuZWR1ICAgICAg ICAgICAgICAgICAgKi8KIGZkX3NldCByaW5pdDsKIGZkX3NldCB3aW5pdDsKQEAgLTIxNzgsMjE2 ICsyMTc4LDYgQEAgUHJ1bmVTcGFjZShzdHJpbmcpCiAJcmV0dXJuIHN0cmluZzsKIH0KIAotLyog ZmlsbHMgdGhlIG15QWRkcnMgYXJyYXkgd2l0aCBob3N0IGludGVyZmFjZSBhZGRyZXNzZXMgKi8K LXZvaWQKLSNpZiBQUk9UT1RZUEVTCi1Qcm9iZUludGVyZmFjZXMoaW5fYWRkcl90IGJpbmRBZGRy KQotI2Vsc2UKLVByb2JlSW50ZXJmYWNlcyhiaW5kQWRkcikKLSAgICBpbl9hZGRyX3QgYmluZEFk ZHI7Ci0jZW5kaWYKLXsKLSNpZmRlZiBTSU9DR0lGQ09ORgotICAgIHN0cnVjdCBpZmNvbmYgaWZj OwotICAgIHN0cnVjdCBpZnJlcSAqaWZyOwotI2lmZGVmIFNJT0NHSUZGTEFHUwotICAgIHN0cnVj dCBpZnJlcSBpZnJjb3B5OwotI2VuZGlmCi0jaWZkZWYgU0lPQ0dJRk5VTQotICAgIGludCBuaWZy OwotI2VuZGlmCi0gICAgaW50IHNvY2s7Ci0gICAgaW50IHIgPSAwLCBtID0gMDsKLSAgICBpbnQg YnVmc2l6ZSA9IDIwNDg7Ci0gICAgaW50IGNvdW50ID0gMDsKLQotICAgIC8qIGlmIHdlIHVzZSAt TSwganVzdCBmaWxsIHRoZSBhcnJheSB3aXRoIHRoYXQgaW50ZXJmYWNlICovCi0gICAgaWYgKGJp bmRBZGRyICE9IElOQUREUl9BTlkpIHsKLQlteUFkZHJzID0gKHN0cnVjdCBpbl9hZGRyICopY2Fs bG9jKDIsIHNpemVvZihzdHJ1Y3QgaW5fYWRkcikpOwotCWlmIChteUFkZHJzID09IChzdHJ1Y3Qg aW5fYWRkciAqKTApCi0JICAgIE91dE9mTWVtKCk7Ci0jaWYgSEFWRV9NRU1DUFkKLQltZW1jcHko JihteUFkZHJzWzBdLnNfYWRkciksICZiaW5kQWRkciwgc2l6ZW9mKGluX2FkZHJfdCkpOwotI2Vs c2UKLQliY29weSgmYmluZEFkZHIsICYobXlBZGRyc1swXS5zX2FkZHIpLCBzaXplb2YoaW5fYWRk cl90KSk7Ci0jZW5kaWYKLQlWZXJib3NlKCJpbnRlcmZhY2UgYWRkcmVzcyAlcyAoLU0gb3B0aW9u KSIsIGluZXRfbnRvYShteUFkZHJzWzBdKSk7Ci0JcmV0dXJuOwotICAgIH0KLQotICAgIGlmICgo c29jayA9IHNvY2tldChBRl9JTkVULCBTT0NLX1NUUkVBTSwgMCkpID09IC0xKSB7Ci0JRXJyb3Io IlByb2JlSW50ZXJmYWNlcygpOiBzb2NrZXQoKTogJXMiLCBzdHJlcnJvcihlcnJubykpOwotCUJ5 ZShFWF9PU0VSUik7Ci0gICAgfQotI2lmZGVmIFNJT0NHSUZOVU0KLSAgICBpZiAoaW9jdGwoc29j aywgU0lPQ0dJRk5VTSwgJm5pZnIpID09IDApCi0JYnVmc2l6ZSA9IG5pZnIgKiBzaXplb2Yoc3Ry dWN0IGlmcmVxKSArIDUxMjsKLSNlbmRpZgotCi0gICAgd2hpbGUgKGJ1ZnNpemUpIHsKLQlpZmMu aWZjX2xlbiA9IGJ1ZnNpemU7Ci0JaWZjLmlmY19yZXEgPSAoc3RydWN0IGlmcmVxICopbWFsbG9j KGlmYy5pZmNfbGVuKTsKLQlpZiAoaWZjLmlmY19yZXEgPT0gKHN0cnVjdCBpZnJlcSAqKTApCi0J ICAgIE91dE9mTWVtKCk7Ci0JaWYgKGlvY3RsKHNvY2ssIFNJT0NHSUZDT05GLCAmaWZjKSAhPSAw ICYmIGVycm5vICE9IEVJTlZBTCkgewotCSAgICBmcmVlKGlmYy5pZmNfcmVxKTsKLQkgICAgY2xv c2Uoc29jayk7Ci0JICAgIEVycm9yKCJQcm9iZUludGVyZmFjZXMoKTogaW9jdGwoU0lPQ0dJRkNP TkYpOiAlcyIsCi0JCSAgc3RyZXJyb3IoZXJybm8pKTsKLQkgICAgQnllKEVYX09TRVJSKTsKLQl9 Ci0JLyogaWYgdGhlIHJldHVybiBzaXplIHBsdXMgYSA1MTIgYnl0ZSAiYnVmZmVyIHpvbmUiIGlz IGxlc3MgdGhhbgotCSAqIHRoZSBidWZmZXIgd2UgcGFzc2VkIGluIChidWZzaXplKSwgd2UncmUg ZG9uZS4gIG90aGVyd2lzZQotCSAqIGFsbG9jYXRlIGEgYmlnZ2VyIGJ1ZmZlciBhbmQgdHJ5IGFn YWluLiAgd2l0aCBhIHRvby1zbWFsbAotCSAqIGJ1ZmZlciwgc29tZSBpbXBsZW1lbnRhdGlvbnMg KGZyZWVic2QpIHdpbGwgZmlsbCB0aGUgYnVmZmVyCi0JICogYmVzdCBpdCBjYW4gKGxlYXZpbmcg YSBnYXAgLSByZXR1cm5pbmcgPD1idWZzaXplKSBhbmQgb3RoZXJzCi0JICogKGxpbnV4KSB3aWxs IHJldHVybiBhIGJ1ZmZlciBsZW5ndGggdGhlIHNhbWUgc2l6ZSBhcyBwYXNzZWQKLQkgKiBpbiAo PT1idWZzaXplKS4gIHNvLCB3ZSdsbCBhc3N1bWUgYSA1MTIgYnl0ZSBnYXAgd291bGQgaGF2ZQot CSAqIGJlZW4gYmlnIGVub3VnaCB0byBwdXQgb25lIG1vcmUgcmVjb3JkIGFuZCBhcyBsb25nIGFz IHdlIGhhdmUKLQkgKiB0aGF0ICJidWZmZXIgem9uZSIsIHdlIHNob3VsZCBoYXZlIGFsbCB0aGUg aW50ZXJmYWNlcy4KLQkgKiBzbywgc29sYXJpcyByZXR1cm5zIEVJTlZBTCBpZiBpdCdzIHRvbyBz bWFsbCwgc28gd2UgY2F0Y2ggdGhhdAotCSAqIGFib3ZlIGFuZCBzaW5jZSBpZl9sZW4gaXMgYnVm c2l6ZSwgaXQnbGwgbG9vcCBhZ2Fpbi4KLQkgKi8KLQlpZiAoaWZjLmlmY19sZW4gKyA1MTIgPCBi dWZzaXplKQotCSAgICBicmVhazsKLQlmcmVlKGlmYy5pZmNfcmVxKTsKLQlidWZzaXplICs9IDIw NDg7Ci0gICAgfQotCi0gICAgLyogdGhpcyBpcyBwcm9iYWJseSB3YXkgb3ZlcmtpbGwsIGJ1dCBi ZXR0ZXIgdG8ga2lsbCBhIGZldyBieXRlcwotICAgICAqIHRoYW4gbG9vcCB0aHJvdWdoIGxvb2tp bmcgZm9yIHZhbGlkIGludGVyZmFjZXMgdGhhdCBhcmUgdXAKLSAgICAgKiB0d2ljZSwgaHVoPwot ICAgICAqLwotICAgIGNvdW50ID0gaWZjLmlmY19sZW4gLyBzaXplb2YoKmlmcik7Ci0gICAgQ09O RERFQlVHKCgxLCAiUHJvYmVJbnRlcmZhY2VzKCk6IGlmY19sZW49PSVkIG1heF9jb3VudD09JWQi LAotCSAgICAgICBpZmMuaWZjX2xlbiwgY291bnQpKTsKLQotICAgIC8qIHNldCB1cCBteUFkZHJz IGFycmF5ICovCi0gICAgaWYgKG15QWRkcnMgIT0gKHN0cnVjdCBpbl9hZGRyICopMCkKLQlmcmVl KG15QWRkcnMpOwotICAgIG15QWRkcnMgPSAoc3RydWN0IGluX2FkZHIgKikwOwotICAgIGlmIChj b3VudCA9PSAwKSB7Ci0JZnJlZShpZmMuaWZjX3JlcSk7Ci0JY2xvc2Uoc29jayk7Ci0JcmV0dXJu OwotICAgIH0KLSAgICBteUFkZHJzID0gKHN0cnVjdCBpbl9hZGRyICopY2FsbG9jKGNvdW50ICsg MSwgc2l6ZW9mKHN0cnVjdCBpbl9hZGRyKSk7Ci0gICAgaWYgKG15QWRkcnMgPT0gKHN0cnVjdCBp bl9hZGRyICopMCkKLQlPdXRPZk1lbSgpOwotCi0gICAgZm9yIChtID0gciA9IDA7IHIgPCBpZmMu aWZjX2xlbjspIHsKLQlzdHJ1Y3Qgc29ja2FkZHIgKnNhOwotCWlmciA9IChzdHJ1Y3QgaWZyZXEg KikmaWZjLmlmY19idWZbcl07Ci0Jc2EgPSAoc3RydWN0IHNvY2thZGRyICopJmlmci0+aWZyX2Fk ZHI7Ci0JLyogZG9uJ3QgdXNlIGxlc3MgdGhhbiBhIGlmcmVxIHNpemVkIGNodW5rICovCi0JaWYg KChpZmMuaWZjX2xlbiAtIHIpIDwgc2l6ZW9mKCppZnIpKQotCSAgICBicmVhazsKLSNpZmRlZiBI QVZFX1NBX0xFTgotCWlmIChzYS0+c2FfbGVuID4gc2l6ZW9mKGlmci0+aWZyX2lmcnUpKQotCSAg ICByICs9IHNpemVvZihpZnItPmlmcl9uYW1lKSArIHNhLT5zYV9sZW47Ci0JZWxzZQotI2VuZGlm Ci0JICAgIHIgKz0gc2l6ZW9mKCppZnIpOwotCi0JaWYgKHNhLT5zYV9mYW1pbHkgPT0gQUZfSU5F VCkgewotCSAgICBzdHJ1Y3Qgc29ja2FkZHJfaW4gKnNpbiA9IChzdHJ1Y3Qgc29ja2FkZHJfaW4g KilzYTsKLQotCSAgICAvKiBtYWtlIHN1cmUgdGhlIGFkZHJlc3MgaXNuJ3QgMC4wLjAuMCwgd2hp Y2ggaXMgaG93IHdlCi0JICAgICAqIHNpZ25hbCB0aGUgZW5kIG9mIG91ciBsaXN0Ci0JICAgICAq LwotCSAgICBpZiAoCi0jaWYgSEFWRV9NRU1DTVAKLQkJICAgbWVtY21wKCYobXlBZGRyc1ttXSks ICYoc2luLT5zaW5fYWRkciksCi0JCQkgIHNpemVvZihzdHJ1Y3QgaW5fYWRkcikpCi0jZWxzZQot CQkgICBiY21wKCYobXlBZGRyc1ttXSksICYoc2luLT5zaW5fYWRkciksCi0JCQlzaXplb2Yoc3Ry dWN0IGluX2FkZHIpKQotI2VuZGlmCi0JCSAgID09IDApCi0JCWNvbnRpbnVlOwotCi0jaWZkZWYg U0lPQ0dJRkZMQUdTCi0JICAgIC8qIG1ha2Ugc3VyZSB0aGUgaW50ZXJmYWNlIGlzIHVwICovCi0J ICAgIGlmcmNvcHkgPSAqaWZyOwotCSAgICBpZiAoKGlvY3RsKHNvY2ssIFNJT0NHSUZGTEFHUywg JmlmcmNvcHkpID09IDApICYmCi0JCSgoaWZyY29weS5pZnJfZmxhZ3MgJiBJRkZfVVApID09IDAp KQotCQljb250aW51ZTsKLSNlbmRpZgotCi0JICAgIENPTkRERUJVRygoMSwgIlByb2JlSW50ZXJm YWNlcygpOiBuYW1lPSVzIGFkZHI9JXMiLAotCQkgICAgICAgaWZyLT5pZnJfbmFtZSwgaW5ldF9u dG9hKHNpbi0+c2luX2FkZHIpKSk7Ci0KLSNpZiBIQVZFX01FTUNQWQotCSAgICBtZW1jcHkoJm15 QWRkcnNbbV0sICYoc2luLT5zaW5fYWRkciksIHNpemVvZihzdHJ1Y3QgaW5fYWRkcikpOwotI2Vs c2UKLQkgICAgYmNvcHkoJihzaW4tPnNpbl9hZGRyKSwgJm15QWRkcnNbbV0sIHNpemVvZihzdHJ1 Y3QgaW5fYWRkcikpOwotI2VuZGlmCi0KLQkgICAgVmVyYm9zZSgiaW50ZXJmYWNlIGFkZHJlc3Mg JXMgKCVzKSIsIGluZXRfbnRvYShteUFkZHJzW21dKSwKLQkJICAgIGlmci0+aWZyX25hbWUpOwot CSAgICBtKys7Ci0JfQotICAgIH0KLSAgICBpZiAobSA9PSAwKSB7Ci0JZnJlZShteUFkZHJzKTsK LQlteUFkZHJzID0gKHN0cnVjdCBpbl9hZGRyICopMDsKLSAgICB9Ci0gICAgY2xvc2Uoc29jayk7 Ci0gICAgZnJlZShpZmMuaWZjX3JlcSk7Ci0jZWxzZSAvKiB1c2UgdGhlIGhvc3RuYW1lIGxpa2Ug dGhlIG9sZCBjb2RlIGRpZCAoYnV0IHVzZSBhbGwgYWRkcmVzc2VzISkgKi8KLSAgICBpbnQgY291 bnQ7Ci0gICAgc3RydWN0IGhvc3RlbnQgKmhlOwotCi0gICAgLyogaWYgd2UgdXNlIC1NLCBqdXN0 IGZpbGwgdGhlIGFycmF5IHdpdGggdGhhdCBpbnRlcmZhY2UgKi8KLSAgICBpZiAoYmluZEFkZHIg IT0gSU5BRERSX0FOWSkgewotCW15QWRkcnMgPSAoc3RydWN0IGluX2FkZHIgKiljYWxsb2MoMiwg c2l6ZW9mKHN0cnVjdCBpbl9hZGRyKSk7Ci0JaWYgKG15QWRkcnMgPT0gKHN0cnVjdCBpbl9hZGRy ICopMCkKLQkgICAgT3V0T2ZNZW0oKTsKLSNpZiBIQVZFX01FTUNQWQotCW1lbWNweSgmKG15QWRk cnNbMF0uc19hZGRyKSwgJmJpbmRBZGRyLCBzaXplb2YoaW5fYWRkcl90KSk7Ci0jZWxzZQotCWJj b3B5KCZiaW5kQWRkciwgJihteUFkZHJzWzBdLnNfYWRkciksIHNpemVvZihpbl9hZGRyX3QpKTsK LSNlbmRpZgotCVZlcmJvc2UoImludGVyZmFjZSBhZGRyZXNzICVzICgtTSBvcHRpb24pIiwgaW5l dF9udG9hKG15QWRkcnNbMF0pKTsKLQlyZXR1cm47Ci0gICAgfQotCi0gICAgVmVyYm9zZSgidXNp bmcgaG9zdG5hbWUgZm9yIGludGVyZmFjZSBhZGRyZXNzZXMiKTsKLSAgICBpZiAoKHN0cnVjdCBo b3N0ZW50ICopMCA9PSAoaGUgPSBnZXRob3N0YnluYW1lKG15SG9zdG5hbWUpKSkgewotCUVycm9y KCJQcm9iZUludGVyZmFjZXMoKTogZ2V0aG9zdGJ5bmFtZSglcyk6ICVzIiwgbXlIb3N0bmFtZSwK LQkgICAgICBoc3RyZXJyb3IoaF9lcnJubykpOwotCXJldHVybjsKLSAgICB9Ci0gICAgaWYgKDQg IT0gaGUtPmhfbGVuZ3RoIHx8IEFGX0lORVQgIT0gaGUtPmhfYWRkcnR5cGUpIHsKLQlFcnJvcgot CSAgICAoIlByb2JlSW50ZXJmYWNlcygpOiBnZXRob3N0YnluYW1lKCVzKTogd3JvbmcgYWRkcmVz cyBzaXplICg0ICE9ICVkKSBvciBhZGRyZXNzIGZhbWlseSAoJWQgIT0gJWQpIiwKLQkgICAgIG15 SG9zdG5hbWUsIGhlLT5oX2xlbmd0aCwgQUZfSU5FVCwgaGUtPmhfYWRkcnR5cGUpOwotCXJldHVy bjsKLSAgICB9Ci0KLSAgICBmb3IgKGNvdW50ID0gMDsgaGUtPmhfYWRkcl9saXN0W2NvdW50XSAh PSAoY2hhciAqKTA7IGNvdW50KyspOwotICAgIGlmIChteUFkZHJzICE9IChzdHJ1Y3QgaW5fYWRk ciAqKTApCi0JZnJlZShteUFkZHJzKTsKLSAgICBteUFkZHJzID0gKHN0cnVjdCBpbl9hZGRyICop MDsKLSAgICBpZiAoY291bnQgPT0gMCkKLQlyZXR1cm47Ci0gICAgbXlBZGRycyA9IChzdHJ1Y3Qg aW5fYWRkciAqKWNhbGxvYyhjb3VudCArIDEsIHNpemVvZihzdHJ1Y3QgaW5fYWRkcikpOwotICAg IGlmIChteUFkZHJzID09IChzdHJ1Y3QgaW5fYWRkciAqKTApCi0JT3V0T2ZNZW0oKTsKLSAgICBm b3IgKGNvdW50LS07IGNvdW50ID49IDA7IGNvdW50LS0pIHsKLSNpZiBIQVZFX01FTUNQWQotCW1l bWNweSgmKG15QWRkcnNbY291bnRdLnNfYWRkciksIGhlLT5oX2FkZHJfbGlzdFtjb3VudF0sCi0J ICAgICAgIGhlLT5oX2xlbmd0aCk7Ci0jZWxzZQotCWJjb3B5KGhlLT5oX2FkZHJfbGlzdFtjb3Vu dF0sICYobXlBZGRyc1tjb3VudF0uc19hZGRyKSwKLQkgICAgICBoZS0+aF9sZW5ndGgpOwotI2Vu ZGlmCi0JVmVyYm9zZSgiaW50ZXJmYWNlIGFkZHJlc3MgJXMgKGhvc3RuYW1lIGFkZHJlc3MpIiwK LQkJaW5ldF9udG9hKG15QWRkcnNbY291bnRdKSk7Ci0gICAgfQotI2VuZGlmCi19Ci0KIGludAog I2lmIFBST1RPVFlQRVMKIElzTWUoY2hhciAqaWQpCkBAIC0yMzk2LDY1ICsyMTg2LDY4IEBAIElz TWUoaWQpCiAgICAgY2hhciAqaWQ7CiAjZW5kaWYKIHsKLSAgICBpbnQgaiwgaTsKLSAgICBzdHJ1 Y3QgaG9zdGVudCAqaGU7Ci0gICAgaW5fYWRkcl90IGFkZHI7Ci0jaWYgSEFWRV9JTkVUX0FUT04K LSAgICBzdHJ1Y3QgaW5fYWRkciBpbmV0YWRkcjsKLSNlbmRpZgotCi0gICAgLyogY2hlY2sgZm9y IGlwIGFkZHJlc3MgbWF0Y2ggKi8KLSNpZiBIQVZFX0lORVRfQVRPTgotICAgIGlmIChpbmV0X2F0 b24oaWQsICZpbmV0YWRkcikgIT0gMCkgewotCWFkZHIgPSBpbmV0YWRkci5zX2FkZHI7Ci0jZWxz ZQotICAgIGFkZHIgPSBpbmV0X2FkZHIoaWQpOwotICAgIGlmIChhZGRyICE9IChpbl9hZGRyX3Qp ICgtMSkpIHsKLSNlbmRpZgotCWZvciAoaSA9IDA7Ci0JICAgICBteUFkZHJzICE9IChzdHJ1Y3Qg aW5fYWRkciAqKTAgJiYKLQkgICAgIG15QWRkcnNbaV0uc19hZGRyICE9IChpbl9hZGRyX3QpIDA7 IGkrKykgewotCSAgICBpZiAoCi0jaWYgSEFWRV9NRU1DTVAKLQkJICAgbWVtY21wKCYobXlBZGRy c1tpXS5zX2FkZHIpLCAmYWRkciwgc2l6ZW9mKGFkZHIpKQotI2Vsc2UKLQkJICAgYmNtcCgmKG15 QWRkcnNbaV0uc19hZGRyKSwgJmFkZHIsIHNpemVvZihhZGRyKSkKLSNlbmRpZgotCQkgICA9PSAw KQotCQlyZXR1cm4gMTsKLQl9Ci0JcmV0dXJuIDA7Ci0gICAgfQorICAgIGludCByZXQgPSAwOwor ICAgIGludCBlcnJvcjsKKyAgICBzdHJ1Y3QgYWRkcmluZm8gaGludHM7CisgICAgc3RydWN0IGFk ZHJpbmZvICpyZXMsICpycDsKKyAgICBzdHJ1Y3QgaWZhZGRycyAqbXlBZGRycywgKmlmYTsKKyAg ICB2b2lkICphLCAqYjsKKyAgICBzaXplX3QgbGVuOwogCi0gICAgLyogY2hlY2sgZm9yIGlwIG1h dGNoIG9mIGhvc3RuYW1lICovCi0gICAgaWYgKChzdHJ1Y3QgaG9zdGVudCAqKTAgPT0gKGhlID0g Z2V0aG9zdGJ5bmFtZShpZCkpKSB7Ci0JRXJyb3IoIklzTWUoKTogZ2V0aG9zdGJ5bmFtZSglcyk6 ICVzIiwgaWQsIGhzdHJlcnJvcihoX2Vycm5vKSk7Ci0JcmV0dXJuIDA7Ci0gICAgfQotICAgIGlm ICg0ICE9IGhlLT5oX2xlbmd0aCB8fCBBRl9JTkVUICE9IGhlLT5oX2FkZHJ0eXBlKSB7Ci0JRXJy b3IKLQkgICAgKCJJc01lKCk6IGdldGhvc3RieW5hbWUoJXMpOiB3cm9uZyBhZGRyZXNzIHNpemUg KDQgIT0gJWQpIG9yIGFkZHJlc3MgZmFtaWx5ICglZCAhPSAlZCkiLAotCSAgICAgaWQsIGhlLT5o X2xlbmd0aCwgQUZfSU5FVCwgaGUtPmhfYWRkcnR5cGUpOwotCXJldHVybiAwOwotICAgIH0KKyAg ICBtZW1zZXQoJmhpbnRzLCAwLCBzaXplb2YoaGludHMpKTsKKyAgICBoaW50cy5haV9mYW1pbHkg PSBQRl9VTlNQRUM7CiAKLSAgICBmb3IgKGogPSAwOyBoZS0+aF9hZGRyX2xpc3Rbal0gIT0gKGNo YXIgKikwOyBqKyspIHsKLQlmb3IgKGkgPSAwOwotCSAgICAgbXlBZGRycyAhPSAoc3RydWN0IGlu X2FkZHIgKikwICYmCi0JICAgICBteUFkZHJzW2ldLnNfYWRkciAhPSAoaW5fYWRkcl90KSAwOyBp KyspIHsKLQkgICAgaWYgKAorICAgIC8qIGdldCBJUCBiYXNlZCBvbiBob3N0bmFtZSAqLworICAg IGVycm9yID0gZ2V0YWRkcmluZm8oaWQgLCBOVUxMLCAmaGludHMsICZyZXMpOworICAgIGlmIChl cnJvcikgeworICAgICAgICBwZXJyb3IoZ2FpX3N0cmVycm9yKGVycm9yKSk7CisgICAgICAgIHJl dHVybiAwOworICAgIH0KKworICAgIC8qIGdldCBsaXN0IG9mIGFsbCBhZGRyZXNzZXMgb24gc3lz dGVtICovCisgICAgZXJyb3IgPSBnZXRpZmFkZHJzKCZteUFkZHJzKTsKKyAgICBpZiAoZXJyb3Ip IHsKKyAgICAgICAgcGVycm9yKCJnZXRpZmFkZHJzIGZhaWxlZCIpOworICAgICAgICByZXR1cm4g MDsKKyAgICB9CisKKyAgICAvKiB0cnkgdG8gZmluZCBhIG1hdGNoICovCisgICAgZm9yIChpZmEg PSBteUFkZHJzOyBpZmEgIT0gTlVMTDsgaWZhID0gaWZhLT5pZmFfbmV4dCkgeworICAgICAgICAv KiBza2lwIGludGVyZmFjZXMgd2l0aG91dCBhZGRyZXNzIG9yIGluIGRvd24gc3RhdGUgKi8KKyAg ICAgICAgaWYgKGlmYS0+aWZhX2FkZHIgPT0gTlVMTCB8fCAhKGlmYS0+aWZhX2ZsYWdzICYgSUZG X1VQKSkKKyAgICAgICAgICAgIGNvbnRpbnVlOworCisgICAgICAgIGZvciAocnAgPSByZXM7IHJw ICE9IE5VTEw7IHJwID0gcnAtPmFpX25leHQpIHsKKyAgICAgICAgICAgIGlmIChpZmEtPmlmYV9h ZGRyLT5zYV9mYW1pbHkgPT0gcnAtPmFpX2FkZHItPnNhX2ZhbWlseSkgeworICAgICAgICAgICAg ICAgIC8qIEkgcmVhbGx5IGRvbid0IGxpa2UgdG8gaGFyZGNvZGUgaXQgYnV0IHdlIGhhdmUgdG8g Ki8KKyAgICAgICAgICAgICAgICBpZiAoaWZhLT5pZmFfYWRkci0+c2FfZmFtaWx5ID09IEFGX0lO RVQpIHsgLyogSVB2NCAqLworICAgICAgICAgICAgICAgICAgICBhID0gJigoKHN0cnVjdCBzb2Nr YWRkcl9pbiAqKWlmYS0+aWZhX2FkZHIpLT5zaW5fYWRkcik7CisgICAgICAgICAgICAgICAgICAg IGIgPSAmKCgoc3RydWN0IHNvY2thZGRyX2luICopcnAtPmFpX2FkZHIpLT5zaW5fYWRkcik7Cisg ICAgICAgICAgICAgICAgICAgIGxlbiA9IHNpemVvZihzdHJ1Y3QgaW5fYWRkcik7CisgICAgICAg ICAgICAgICAgfSBlbHNlIHsgLyogSVB2NiAqLworICAgICAgICAgICAgICAgICAgICBhID0gJigo KHN0cnVjdCBzb2NrYWRkcl9pbjYgKilpZmEtPmlmYV9hZGRyKS0+c2luNl9hZGRyKTsKKyAgICAg ICAgICAgICAgICAgICAgYiA9ICYoKChzdHJ1Y3Qgc29ja2FkZHJfaW42ICopcnAtPmFpX2FkZHIp LT5zaW42X2FkZHIpOworICAgICAgICAgICAgICAgICAgICBsZW4gPSBzaXplb2Yoc3RydWN0IGlu Nl9hZGRyKTsKKyAgICAgICAgICAgICAgICB9CisgICAgCisgICAgICAgICAgICAgICAgaWYgKAog I2lmIEhBVkVfTUVNQ01QCi0JCSAgIG1lbWNtcCgmKG15QWRkcnNbaV0uc19hZGRyKSwgaGUtPmhf YWRkcl9saXN0W2pdLAotCQkJICBoZS0+aF9sZW5ndGgpCisgICAgICAgICAgICAgICAgICAgICAg ICBtZW1jbXAoYSwgYiwgbGVuKQogI2Vsc2UKLQkJICAgYmNtcCgmKG15QWRkcnNbaV0uc19hZGRy KSwgaGUtPmhfYWRkcl9saXN0W2pdLAotCQkJaGUtPmhfbGVuZ3RoKQorICAgICAgICAgICAgICAg ICAgICAgICAgYmNtcChhLCBiLCBsZW4pCiAjZW5kaWYKLQkJICAgPT0gMCkKLQkJcmV0dXJuIDE7 Ci0JfQotICAgIH0KLSAgICByZXR1cm4gMDsKKyAgICAgICAgICAgICAgICAgICAgICAgID09IDAp IHsKKyAgICAgICAgICAgICAgICAgICAgcmV0ID0gMTsKKyAgICAgICAgICAgICAgICAgICAgZ290 byBkb25lOworICAgICAgICAgICAgICAgIH0KKyAgICAgICAgICAgIH0KKyAgICAgICAgfQorICAg IH0KKworZG9uZToKKyAgICBmcmVlaWZhZGRycyhteUFkZHJzKTsKKyAgICBDT05EREVCVUcoKDEs ICJJc01lOiByZXQgJWQgaWQgJXMiLCByZXQsIGlkKSk7CisgICAgcmV0dXJuIHJldDsKIH0KIAog I2lmIEhBVkVfT1BFTlNTTApPbmx5IGluIGNvbnNlcnZlci04LjEuMTguaXB2Ni9jb25zZXJ2ZXI6 IC5jdXRpbC5jLnN3cApkaWZmIC11cHIgY29uc2VydmVyLTguMS4xOC5vcmlnL2NvbnNlcnZlci9j dXRpbC5oIGNvbnNlcnZlci04LjEuMTguaXB2Ni9jb25zZXJ2ZXIvY3V0aWwuaAotLS0gY29uc2Vy dmVyLTguMS4xOC5vcmlnL2NvbnNlcnZlci9jdXRpbC5oCTIwMDktMDktMjYgMDU6MjM6MDQuMDAw MDAwMDAwIC0wNDAwCisrKyBjb25zZXJ2ZXItOC4xLjE4LmlwdjYvY29uc2VydmVyL2N1dGlsLmgJ MjAxNC0wNC0wMSAxMzoxNzo0MC45MDI3OTkzNzEgLTA0MDAKQEAgLTEzNCw3ICsxMzQsNiBAQCBl eHRlcm4gY2hhciAqcHJvZ25hbWU7CiBleHRlcm4gcGlkX3QgdGhlcGlkOwogI2RlZmluZSBNQVhI T1NUTkFNRSAxMDI0CiBleHRlcm4gY2hhciBteUhvc3RuYW1lW107Ci1leHRlcm4gc3RydWN0IGlu X2FkZHIgKm15QWRkcnM7CiBleHRlcm4gZmRfc2V0IHJpbml0OwogZXh0ZXJuIGZkX3NldCB3aW5p dDsKIGV4dGVybiBpbnQgbWF4ZmQ7CkBAIC0yMDIsNyArMjAxLDYgQEAgZXh0ZXJuIGludCBQYXJz ZUlBQ0J1ZiBQQVJBTVMoKENPTlNGSUxFIAogZXh0ZXJuIHZvaWQgKk1lbU1vdmUgUEFSQU1TKCh2 b2lkICosIHZvaWQgKiwgc2l6ZV90KSk7CiBleHRlcm4gY2hhciAqU3RyaW5nQ2hhciBQQVJBTVMo KFNUUklORyAqLCBpbnQsIGNoYXIpKTsKIGV4dGVybiB2b2lkIFBhcnNlRmlsZSBQQVJBTVMoKGNo YXIgKiwgRklMRSAqLCBpbnQpKTsKLWV4dGVybiB2b2lkIFByb2JlSW50ZXJmYWNlcyBQQVJBTVMo KGluX2FkZHJfdCkpOwogZXh0ZXJuIHZvaWQgUHJvY2Vzc1N1YnN0CiBQQVJBTVMoKFNVQlNUICos IGNoYXIgKiosIGNoYXIgKiosIGNoYXIgKiwgY2hhciAqKSk7CiBleHRlcm4gY2hhciAqTXlWZXJz aW9uIFBBUkFNUygodm9pZCkpOwpkaWZmIC11cHIgY29uc2VydmVyLTguMS4xOC5vcmlnL2NvbnNl cnZlci9ncm91cC5jIGNvbnNlcnZlci04LjEuMTguaXB2Ni9jb25zZXJ2ZXIvZ3JvdXAuYwotLS0g Y29uc2VydmVyLTguMS4xOC5vcmlnL2NvbnNlcnZlci9ncm91cC5jCTIwMDktMDktMjYgMDU6NTg6 MDUuMDAwMDAwMDAwIC0wNDAwCisrKyBjb25zZXJ2ZXItOC4xLjE4LmlwdjYvY29uc2VydmVyL2dy b3VwLmMJMjAxNC0wNC0wNCAxNDowNzo1My42NDE0MjUyNTUgLTA0MDAKQEAgLTQ4MTgsNyArNDgx OCw3IEBAIEtpZGRpZShwR0UsIHNmZCkKICNpZiBIQVZFX0RNQUxMT0MgJiYgRE1BTExPQ19NQVJL X0NMSUVOVF9DT05ORUNUSU9OCiAJZG1hbGxvY01hcmtDbGllbnRDb25uZWN0aW9uID0gZG1hbGxv Y19tYXJrKCk7CiAjZW5kaWYKLQlzbyA9IHNpemVvZihzdHJ1Y3Qgc29ja2FkZHJfaW4pOworCXNv ID0gc2l6ZW9mKHN0cnVjdCBzb2NrYWRkcl9zdG9yYWdlKTsKIAlmZCA9IGFjY2VwdChzZmQsIChz dHJ1Y3Qgc29ja2FkZHIgKikmcEdFLT5wQ0xmcmVlLT5jbmN0X3BvcnQsICZzbyk7CiAJaWYgKGZk IDwgMCkgewogCSAgICBFcnJvcigiS2lkZGllKCk6IGFjY2VwdCgpOiAlcyIsIHN0cmVycm9yKGVy cm5vKSk7CkBAIC00OTQ0LDIyICs0OTQ0LDI1IEBAIFNwYXduKHBHRSwgbXNmZCkKICAgICBzdHJ1 Y3Qgc29ja2FkZHJfdW4gbHN0bl9wb3J0OwogICAgIHN0YXRpYyBTVFJJTkcgKnBvcnRQYXRoID0g KFNUUklORyAqKTA7CiAjZWxzZQotICAgIHNvY2tsZW5fdCBzbzsKKyAgICBpbnQgZXJyb3I7Cisg ICAgc3RydWN0IGFkZHJpbmZvICpycCwgaGludHMsICpyZXM7CisgICAgY2hhciBob3N0W05JX01B WEhPU1RdOworICAgIGNoYXIgc2VydltOSV9NQVhTRVJWXTsKICMgaWYgSEFWRV9TRVRTT0NLT1BU CiAgICAgaW50IHRydWUgPSAxOwogIyBlbmRpZgorICAgIHVuc2lnbmVkIHNob3J0IGJpbmRCYXNl UG9ydDsKICAgICB1bnNpZ25lZCBzaG9ydCBwb3J0SW5jID0gMDsKLSAgICBzdHJ1Y3Qgc29ja2Fk ZHJfaW4gbHN0bl9wb3J0OwogI2VuZGlmCiAKICAgICAvKiBnZXQgYSBzb2NrZXQgZm9yIGxpc3Rl bmluZyAqLwotI2lmIEhBVkVfTUVNU0VUCisjaWYgVVNFX1VOSVhfRE9NQUlOX1NPQ0tFVFMKKyMg aWYgSEFWRV9NRU1TRVQKICAgICBtZW1zZXQoKHZvaWQgKikmbHN0bl9wb3J0LCAwLCBzaXplb2Yo bHN0bl9wb3J0KSk7Ci0jZWxzZQorIyBlbHNlCiAgICAgYnplcm8oKGNoYXIgKikmbHN0bl9wb3J0 LCBzaXplb2YobHN0bl9wb3J0KSk7Ci0jZW5kaWYKKyMgZW5kaWYKIAotI2lmIFVTRV9VTklYX0RP TUFJTl9TT0NLRVRTCiAgICAgbHN0bl9wb3J0LnN1bl9mYW1pbHkgPSBBRl9VTklYOwogCiAgICAg aWYgKHBvcnRQYXRoID09IChTVFJJTkcgKikwKQpAQCAtNDk5MCw1MCArNDk5Myw5NCBAQCBTcGF3 bihwR0UsIG1zZmQpCiAgICAgfQogICAgIHBHRS0+cG9ydCA9IHBHRS0+aWQ7CiAjZWxzZQotICAg IGxzdG5fcG9ydC5zaW5fZmFtaWx5ID0gQUZfSU5FVDsKLSAgICBsc3RuX3BvcnQuc2luX2FkZHIu c19hZGRyID0gYmluZEFkZHI7Ci0gICAgbHN0bl9wb3J0LnNpbl9wb3J0ID0gaHRvbnMoYmluZEJh c2VQb3J0KTsKLQotICAgIC8qIGNyZWF0ZSBhIHNvY2tldCB0byBsaXN0ZW4gb24KLSAgICAgKiAo cHJlcGFyZWQgYnkgbWFzdGVyIHNvIGhlIGNhbiBzZWUgdGhlIHBvcnQgbnVtYmVyIG9mIHRoZSBr aWQpCi0gICAgICovCi0gICAgaWYgKChzZmQgPSBzb2NrZXQoQUZfSU5FVCwgU09DS19TVFJFQU0s IDApKSA8IDApIHsKLQlFcnJvcigiU3Bhd24oKTogc29ja2V0KCk6ICVzIiwgc3RyZXJyb3IoZXJy bm8pKTsKLQlCeWUoRVhfT1NFUlIpOwotICAgIH0KKyAgICBmb3IgKHJwID0gYmluZEJhc2VBZGRy OyBycCAhPSBOVUxMOyBycCA9IHJwLT5haV9uZXh0KSB7CisgICAgICAgIGlmICgoc2ZkID0gc29j a2V0KHJwLT5haV9mYW1pbHksIHJwLT5haV9zb2NrdHlwZSwKKyAgICAgICAgICAgICAgICAgICAg ICAgIHJwLT5haV9wcm90b2NvbCkpIDwgMCkgeworICAgICAgICAgICAgRXJyb3IoIlNwYXduKCk6 IHNvY2tldCgpOiAlcyIsIHN0cmVycm9yKGVycm5vKSk7CisgICAgICAgICAgICBjb250aW51ZTsK KyAgICAgICAgfQogIyBpZiBIQVZFX1NFVFNPQ0tPUFQKLSAgICBpZiAoc2V0c29ja29wdAotCShz ZmQsIFNPTF9TT0NLRVQsIFNPX1JFVVNFQUREUiwgKGNoYXIgKikmdHJ1ZSwgc2l6ZW9mKHRydWUp KSA8IDApIHsKLQlFcnJvcigiU3Bhd24oKTogc2V0c29ja29wdCgldSxTT19SRVVTRUFERFIpOiAl cyIsIHNmZCwKLQkgICAgICBzdHJlcnJvcihlcnJubykpOwotCUJ5ZShFWF9PU0VSUik7Ci0gICAg fQorICAgICAgICBpZiAoc2V0c29ja29wdAorICAgICAgICAgICAgKHNmZCwgU09MX1NPQ0tFVCwg U09fUkVVU0VBRERSLCAoY2hhciAqKSZ0cnVlLAorICAgICAgICAgICAgIHNpemVvZih0cnVlKSkg PCAwKSB7CisgICAgICAgICAgICBFcnJvcigiU3Bhd24oKTogc2V0c29ja29wdCgldSxTT19SRVVT RUFERFIpOiAlcyIsIHNmZCwKKyAgICAgICAgICAgICAgICAgICAgc3RyZXJyb3IoZXJybm8pKTsK KyAgICAgICAgICAgIHJldHVybjsKKyAgICAgICAgfQogIyBlbmRpZgorICAgICAgICBpZiAoIVNl dEZsYWdzKHNmZCwgT19OT05CTE9DSywgMCkpCisgICAgICAgICAgICByZXR1cm47CisgICAgCisg ICAgICAgIGVycm9yID0gZ2V0bmFtZWluZm8ocnAtPmFpX2FkZHIsIHJwLT5haV9hZGRybGVuLAor ICAgICAgICAgICAgICAgICAgICBob3N0LCBzaXplb2YoaG9zdCksCisgICAgICAgICAgICAgICAg ICAgIHNlcnYsIHNpemVvZihzZXJ2KSwKKyAgICAgICAgICAgICAgICAgICAgTklfTlVNRVJJQ0hP U1QgfCBOSV9OVU1FUklDU0VSVik7CisgICAgICAgIGlmIChlcnJvcikgeworICAgICAgICAgICAg RXJyb3IoIlNwYXduKCk6IGdldG5hbWVpbmZvIGZhaWxlZDogJXMiLCBnYWlfc3RyZXJyb3IoZXJy b3IpKTsKKyAgICAgICAgICAgIHJldHVybjsKKyAgICAgICAgfQorICAgICAgICBiaW5kQmFzZVBv cnQgPSAodW5zaWduZWQgc2hvcnQpc3RydG9sKHNlcnYsIE5VTEwsIDEwKTsKIAotICAgIGlmICgh U2V0RmxhZ3Moc2ZkLCBPX05PTkJMT0NLLCAwKSkKLQlCeWUoRVhfT1NFUlIpOwotCi0gICAgd2hp bGUgKGJpbmQoc2ZkLCAoc3RydWN0IHNvY2thZGRyICopJmxzdG5fcG9ydCwgc2l6ZW9mKGxzdG5f cG9ydCkpCi0JICAgPCAwKSB7Ci0JaWYgKGJpbmRCYXNlUG9ydCAmJiAoCisgICAgICAgIHdoaWxl IChiaW5kKHNmZCwgcnAtPmFpX2FkZHIsIHJwLT5haV9hZGRybGVuKSA8IDApIHsKKyAgICAgICAg ICAgIGlmIChiaW5kQmFzZVBvcnQgJiYgKAogIyBpZiBkZWZpbmVkKEVBRERSSU5VU0UpCi0JCQkJ KGVycm5vID09IEVBRERSSU5VU0UpIHx8CisgICAgICAgICAgICAgICAgKGVycm5vID09IEVBRERS SU5VU0UpIHx8CiAjIGVuZGlmCi0JCQkJKGVycm5vID09IEVBQ0NFUykpICYmICsrcG9ydEluYykg ewotCSAgICBsc3RuX3BvcnQuc2luX3BvcnQgPSBodG9ucyhiaW5kQmFzZVBvcnQgKyBwb3J0SW5j KTsKLQl9IGVsc2UgewotCSAgICBFcnJvcigiU3Bhd24oKTogYmluZCglaHUpOiAlcyIsIG50b2hz KGxzdG5fcG9ydC5zaW5fcG9ydCksCi0JCSAgc3RyZXJyb3IoZXJybm8pKTsKLQkgICAgQnllKEVY X09TRVJSKTsKLQl9Ci0gICAgfQotICAgIHNvID0gc2l6ZW9mKGxzdG5fcG9ydCk7Ci0KLSAgICBp ZiAoLTEgPT0gZ2V0c29ja25hbWUoc2ZkLCAoc3RydWN0IHNvY2thZGRyICopJmxzdG5fcG9ydCwg JnNvKSkgewotCUVycm9yKCJTcGF3bigpOiBnZXRzb2NrbmFtZSgldSk6ICVzIiwgc2ZkLCBzdHJl cnJvcihlcnJubykpOwotCUJ5ZShFWF9PU0VSUik7Ci0gICAgfQotICAgIHBHRS0+cG9ydCA9IG50 b2hzKGxzdG5fcG9ydC5zaW5fcG9ydCk7CisgICAgICAgICAgICAgICAgKGVycm5vID09IEVBQ0NF UykpICYmICsrcG9ydEluYykgeworICAgICAgICAgICAgICAgIC8qCisgICAgICAgICAgICAgICAg ICogaW5zdGVhZCBvZiBjaGVja2luZyBmb3IgYWlfZmFtaWx5IGFuZCBtb2RpZnlpbmcKKyAgICAg ICAgICAgICAgICAgKiB0aGUgc3RydWN0dXJlIGRpcmVjdGx5IHdlIHdpbGwgZ2VuZXJhdGUgbmV3 IGFkZHJpbmZvCisgICAgICAgICAgICAgICAgICogc3RydWN0dXJlLCBjb3B5IG92ZXIgZmlyc3Qg ZW50cnkgYW5kIHJlbGVhc2UgaXQuCisgICAgICAgICAgICAgICAgICovCisgICAgICAgICAgICAg ICAgbWVtc2V0KCZoaW50cywgMCwgc2l6ZW9mKGhpbnRzKSk7CisgICAgICAgICAgICAgICAgaGlu dHMuYWlfZmFtaWx5ID0gQUZfVU5TUEVDOworICAgICAgICAgICAgICAgIGhpbnRzLmFpX3NvY2t0 eXBlID0gU09DS19TVFJFQU07CisgICAgICAgICAgICAgICAgaGludHMuYWlfZmxhZ3MgPSBBSV9Q QVNTSVZFIHwgQUlfTlVNRVJJQ0hPU1QgfCBBSV9OVU1FUklDU0VSVjsKKyAgICAgICAgICAgICAg ICBzbnByaW50ZihzZXJ2LCBzaXplb2Yoc2VydiksICIlaHUiLCBiaW5kQmFzZVBvcnQgKyBwb3J0 SW5jKTsKKyAgICAgICAgICAgICAgICBlcnJvciA9IGdldGFkZHJpbmZvKGhvc3QsIHNlcnYsICZo aW50cywgJnJlcyk7CisgICAgICAgICAgICAgICAgaWYgKGVycm9yKQorICAgICAgICAgICAgICAg ICAgICBnb3RvIE9VVDsKKworICAgICAgICAgICAgICAgIG1lbWNweShycC0+YWlfYWRkciwgcmVz LT5haV9hZGRyLCBycC0+YWlfYWRkcmxlbik7CisgICAgICAgICAgICAgICAgZnJlZWFkZHJpbmZv KHJlcyk7CisgICAgICAgICAgICAgICAgY29udGludWU7CisgICAgICAgICAgICB9IGVsc2UKKyAg ICAgICAgICAgICAgICBnb3RvIE9VVDsKKyAgICAgICAgfQorICAgICAgICBicmVhazsgLyogaWYg d2UncmUgaGVyZSBiaW5kIHdhcyBzdWNjZXNmdWwgc28gZ2V0IG91dCAqLworCitPVVQ6CisgICAg ICAgIHBvcnRJbmMgPSAwOworICAgICAgICBjbG9zZShzZmQpOworICAgIH0KKworICAgIC8qIGlm IHJwIGlzIG51bGwgd2UgZGlkIG5vdCBiaW5kICovCisgICAgaWYgKHJwID09IE5VTEwpIHsKKyAg ICAgICAgRXJyb3IoIlNwYXduKCk6IGNvdWxkIG5vdCBiaW5kIik7CisgICAgICAgIEJ5ZShFWF9P U0VSUik7CisgICAgfQorCisgICAgaWYgKC0xID09IGdldHNvY2tuYW1lKHNmZCwgcnAtPmFpX2Fk ZHIsICZycC0+YWlfYWRkcmxlbikpIHsKKyAgICAgICAgRXJyb3IoIlNwYXduKCk6IGdldHNvY2tu YW1lKCV1KTogJXMiLCBzZmQsIHN0cmVycm9yKGVycm5vKSk7CisgICAgICAgIEJ5ZShFWF9PU0VS Uik7CisgICAgfQorCisgICAgLyogCisgICAgICogaWYgYmluZEJhc2VQb3J0IGlzIDAgd2UgZGlk IGF1dG8tYXNzaWduIG91ciBwb3J0LiB0byBmaW5kIG91dAorICAgICAqIHdoYXQgd2UgYmluZCB0 byB3ZSBuZWVkIHRvIGNhbGwgZ2V0c29ja25hbWUgKGFib3ZlKSBhbmQgY2FsbAorICAgICAqIGdl dG5hbWVpbmZvIGFnYWluLiBvdGhlcndpc2Ugd2UgaGF2ZSB0aGUgcG9ydCBpbmZvIGluCisgICAg ICogYmluZEJhc2VQb3J0ICsgcG9ydEluYworICAgICAqLworICAgIGlmICghYmluZEJhc2VQb3J0 KSB7CisgICAgICAgIGVycm9yID0gZ2V0bmFtZWluZm8ocnAtPmFpX2FkZHIsIHJwLT5haV9hZGRy bGVuLCBOVUxMLCAwLAorICAgICAgICAgICAgICAgICAgICBzZXJ2LCBzaXplb2Yoc2VydiksIE5J X05VTUVSSUNTRVJWKTsKKyAgICAgICAgaWYgKGVycm9yKSB7CisgICAgICAgICAgICBFcnJvcigi U3Bhd24oKTogZ2V0bmFtZWluZm8gZmFpbGVkOiAlcyIsIGdhaV9zdHJlcnJvcihlcnJvcikpOwor ICAgICAgICAgICAgQnllKEVYX09TRVJSKTsKKyAgICAgICAgfQorICAgICAgICBwR0UtPnBvcnQg PSAodW5zaWduZWQgc2hvcnQpc3RydG9sKHNlcnYsIE5VTEwsIDEwKTsKKyAgICB9IGVsc2UKKyAg ICAgICAgcEdFLT5wb3J0ID0gYmluZEJhc2VQb3J0ICsgcG9ydEluYzsKICNlbmRpZgogCiAgICAg ZmZsdXNoKHN0ZGVycik7Ck9ubHkgaW4gY29uc2VydmVyLTguMS4xOC5pcHY2L2NvbnNlcnZlcjog Lmdyb3VwLmMuc3dwCmRpZmYgLXVwciBjb25zZXJ2ZXItOC4xLjE4Lm9yaWcvY29uc2VydmVyL21h aW4uYyBjb25zZXJ2ZXItOC4xLjE4LmlwdjYvY29uc2VydmVyL21haW4uYwotLS0gY29uc2VydmVy LTguMS4xOC5vcmlnL2NvbnNlcnZlci9tYWluLmMJMjAwOS0wOS0yNiAwNToyMzowNC4wMDAwMDAw MDAgLTA0MDAKKysrIGNvbnNlcnZlci04LjEuMTguaXB2Ni9jb25zZXJ2ZXIvbWFpbi5jCTIwMTQt MDQtMDQgMTE6MzQ6NTYuMzc2Njk0NDA3IC0wNDAwCkBAIC01NCw5ICs1NCw4IEBAIGludCBmQWxs ID0gMCwgZk5vaW5pdCA9IDAsIGZWZXJzaW9uID0gMCwKIAogY2hhciAqcGNDb25maWcgPSBDT05G SUdGSUxFOwogaW50IGNNYXhNZW1iID0gTUFYTUVNQjsKLWluX2FkZHJfdCBiaW5kQWRkciA9IElO QUREUl9BTlk7Ci11bnNpZ25lZCBzaG9ydCBiaW5kUG9ydDsKLXVuc2lnbmVkIHNob3J0IGJpbmRC YXNlUG9ydDsKK3N0cnVjdCBhZGRyaW5mbyAqYmluZEFkZHI7CitzdHJ1Y3QgYWRkcmluZm8gKmJp bmRCYXNlQWRkcjsKIHN0YXRpYyBTVFJJTkcgKnN0YXJ0ZWRNc2cgPSAoU1RSSU5HICopMDsKIENP TkZJRyAqb3B0Q29uZiA9IChDT05GSUcgKikwOwogQ09ORklHICpjb25maWcgPSAoQ09ORklHICop MDsKQEAgLTczLDcgKzcyLDYgQEAgQ09ORklHIGRlZkNvbmZpZyA9CiAjZW5kaWYKIH07CiAKLXN0 cnVjdCBzb2NrYWRkcl9pbiBpbl9wb3J0OwogQ09OU0ZJTEUgKnVuaWZpZWRsb2cgPSAoQ09OU0ZJ TEUgKikwOwogCiAjaWYgSEFWRV9ETUFMTE9DICYmIERNQUxMT0NfTUFSS19NQUlOCkBAIC03NjEs MTQgKzc1OSwxNSBAQCBEZXN0cm95RGF0YVN0cnVjdHVyZXMoKQogCURIX2ZyZWUoZGg0MDk2KTsK ICNlbmRpZgogCi0gICAgaWYgKG15QWRkcnMgIT0gKHN0cnVjdCBpbl9hZGRyICopMCkKLQlmcmVl KG15QWRkcnMpOwotCiAgICAgRGVzdHJveUJyZWFrTGlzdCgpOwogICAgIERlc3Ryb3lTdHJpbmdz KCk7CiAgICAgRGVzdHJveVVzZXJMaXN0KCk7CiAgICAgaWYgKHN1YnN0RGF0YSAhPSAoU1VCU1Qg KikwKQogCWZyZWUoc3Vic3REYXRhKTsKKworICAgIC8qIGNsZWFuIHVwIGFkZHJpbmZvIHN0dWN0 cyAqLworICAgIGZyZWVhZGRyaW5mbyhiaW5kQWRkcik7CisgICAgZnJlZWFkZHJpbmZvKGJpbmRC YXNlQWRkcik7CiB9CiAKIHZvaWQKQEAgLTExNjQsOSArMTE2Myw4IEBAIG1haW4oYXJnYywgYXJn dikKICAgICBpbnQgY3VydWlkID0gMDsKICAgICBHUlBFTlQgKnBHRSA9IChHUlBFTlQgKikwOwog I2lmICFVU0VfVU5JWF9ET01BSU5fU09DS0VUUwotI2lmIEhBVkVfSU5FVF9BVE9OCi0gICAgc3Ry dWN0IGluX2FkZHIgaW5ldGFkZHI7Ci0jZW5kaWYKKyAgICBpbnQgczsKKyAgICBzdHJ1Y3QgYWRk cmluZm8gaGludHM7CiAjZW5kaWYKIAogICAgIGlzTXVsdGlQcm9jID0gMTsJCS8qIG1ha2Ugc3Vy ZSBzdHVmZiBoYXMgdGhlIHBpZCAqLwpAQCAtMTM2NCw0NiArMTM2MiwxMSBAQCBtYWluKGFyZ2Ms IGFyZ3YpCiAgICAgaWYgKGZTeW50YXhPbmx5KQogCU1zZygicGVyZm9ybWluZyBjb25maWd1cmF0 aW9uIGZpbGUgc3ludGF4IGNoZWNrIik7CiAKLSNpZiBVU0VfVU5JWF9ET01BSU5fU09DS0VUUwot ICAgIC8qIERvbid0IGRvIGFueSByZWRpcmVjdHMgaWYgd2UncmUgcHVyZWx5IGxvY2FsCi0gICAg ICogKGJ1dCBpdCBhbGxvd3MgdGhlbSB0byBzZWUgd2hlcmUgcmVtb3RlIGNvbnNvbGVzIGFyZSkK LSAgICAgKi8KLSAgICBvcHRDb25mLT5yZWRpcmVjdCA9IEZMQUdGQUxTRTsKLSAgICBpZiAoaW50 ZXJmYWNlID09IChjaGFyICopMCkKLQlpbnRlcmZhY2UgPSBVRFNESVI7Ci0jZWxzZQotICAgIC8q IHNldCB1cCB0aGUgYWRkcmVzcyB0byBiaW5kIHRvICovCi0gICAgaWYgKGludGVyZmFjZSA9PSAo Y2hhciAqKTAgfHwKLQkoaW50ZXJmYWNlWzBdID09ICcqJyAmJiBpbnRlcmZhY2VbMV0gPT0gJ1ww MDAnKSkKLQliaW5kQWRkciA9IElOQUREUl9BTlk7Ci0gICAgZWxzZSB7Ci0jIGlmIEhBVkVfSU5F VF9BVE9OCi0JaWYgKGluZXRfYXRvbihpbnRlcmZhY2UsICZpbmV0YWRkcikgPT0gMCkgewotCSAg ICBFcnJvcigiaW5ldF9hdG9uKCVzKTogJXMiLCBpbnRlcmZhY2UsICJpbnZhbGlkIElQIGFkZHJl c3MiKTsKLQkgICAgQnllKEVYX09TRVJSKTsKLQl9Ci0JYmluZEFkZHIgPSBpbmV0YWRkci5zX2Fk ZHI7Ci0jIGVsc2UKLQliaW5kQWRkciA9IGluZXRfYWRkcihpbnRlcmZhY2UpOwotCWlmIChiaW5k QWRkciA9PSAoaW5fYWRkcl90KSAoLTEpKSB7Ci0JICAgIEVycm9yKCJpbmV0X2FkZHIoJXMpOiAl cyIsIGludGVyZmFjZSwgImludmFsaWQgSVAgYWRkcmVzcyIpOwotCSAgICBCeWUoRVhfT1NFUlIp OwotCX0KLSMgZW5kaWYKLSAgICB9Ci0gICAgaWYgKGZEZWJ1ZykgewotCXN0cnVjdCBpbl9hZGRy IGJhOwotCWJhLnNfYWRkciA9IGJpbmRBZGRyOwotCUNPTkRERUJVRygoMSwgIm1haW4oKTogYmlu ZCBhZGRyZXNzIHNldCB0byBgJXMnIiwgaW5ldF9udG9hKGJhKSkpOwotICAgIH0KLSNlbmRpZgot CiAgICAgLyogbXVzdCBkbyBhbGwgdGhpcyBzbyBJc01lKCkgd29ya3MgcmlnaHQgKi8KICAgICBp ZiAoZ2V0aG9zdG5hbWUobXlIb3N0bmFtZSwgTUFYSE9TVE5BTUUpICE9IDApIHsKIAlFcnJvcigi Z2V0aG9zdG5hbWUoKTogJXMiLCBzdHJlcnJvcihlcnJubykpOwogCUJ5ZShFWF9PU0VSUik7CiAg ICAgfQotICAgIFByb2JlSW50ZXJmYWNlcyhiaW5kQWRkcik7CiAKICAgICAvKiBpbml0aWFsaXpl IHRoZSB0aW1lcnMgKi8KICAgICBmb3IgKGkgPSAwOyBpIDwgVF9NQVg7IGkrKykKQEAgLTE0MTcs NyArMTM4MCwxNCBAQCBtYWluKGFyZ2MsIGFyZ3YpCiAgICAgUmVhZENmZyhwY0NvbmZpZywgZnBD b25maWcpOwogICAgIGZjbG9zZShmcENvbmZpZyk7CiAKLSNpZiAhVVNFX1VOSVhfRE9NQUlOX1NP Q0tFVFMKKyNpZiBVU0VfVU5JWF9ET01BSU5fU09DS0VUUworICAgIC8qIERvbid0IGRvIGFueSBy ZWRpcmVjdHMgaWYgd2UncmUgcHVyZWx5IGxvY2FsCisgICAgICogKGJ1dCBpdCBhbGxvd3MgdGhl bSB0byBzZWUgd2hlcmUgcmVtb3RlIGNvbnNvbGVzIGFyZSkKKyAgICAgKi8KKyAgICBvcHRDb25m LT5yZWRpcmVjdCA9IEZMQUdGQUxTRTsKKyAgICBpZiAoaW50ZXJmYWNlID09IChjaGFyICopMCkK KwlpbnRlcmZhY2UgPSBVRFNESVI7CisjZWxzZQogICAgIC8qIHNldCB1cCB0aGUgcG9ydCB0byBi aW5kIHRvICovCiAgICAgaWYgKG9wdENvbmYtPnByaW1hcnlwb3J0ICE9IChjaGFyICopMCkKIAlj b25maWctPnByaW1hcnlwb3J0ID0gU3RyRHVwKG9wdENvbmYtPnByaW1hcnlwb3J0KTsKQEAgLTE0 MjgsMjYgKzEzOTgsNiBAQCBtYWluKGFyZ2MsIGFyZ3YpCiAgICAgaWYgKGNvbmZpZy0+cHJpbWFy eXBvcnQgPT0gKGNoYXIgKikwKQogCU91dE9mTWVtKCk7CiAKLSAgICAvKiBMb29rIGZvciBub24t bnVtZXJpYyBjaGFyYWN0ZXJzICovCi0gICAgZm9yIChpID0gMDsgY29uZmlnLT5wcmltYXJ5cG9y dFtpXSAhPSAnXDAwMCc7IGkrKykKLQlpZiAoIWlzZGlnaXQoKGludCljb25maWctPnByaW1hcnlw b3J0W2ldKSkKLQkgICAgYnJlYWs7Ci0KLSAgICBpZiAoY29uZmlnLT5wcmltYXJ5cG9ydFtpXSA9 PSAnXDAwMCcpIHsKLQkvKiBudW1lcmljIG9ubHkgKi8KLQliaW5kUG9ydCA9IGF0b2koY29uZmln LT5wcmltYXJ5cG9ydCk7Ci0gICAgfSBlbHNlIHsKLQkvKiBub24tbnVtZXJpYyBvbmx5ICovCi0J c3RydWN0IHNlcnZlbnQgKnBTRTsKLQlpZiAoKHN0cnVjdCBzZXJ2ZW50ICopMCA9PQotCSAgICAo cFNFID0gZ2V0c2VydmJ5bmFtZShjb25maWctPnByaW1hcnlwb3J0LCAidGNwIikpKSB7Ci0JICAg IEVycm9yKCJnZXRzZXJ2YnluYW1lKCVzKSBmYWlsZWQiLCBjb25maWctPnByaW1hcnlwb3J0KTsK LQkgICAgQnllKEVYX09TRVJSKTsKLQl9IGVsc2UgewotCSAgICBiaW5kUG9ydCA9IG50b2hzKCh1 bnNpZ25lZCBzaG9ydClwU0UtPnNfcG9ydCk7Ci0JfQotICAgIH0KLQogICAgIC8qIHNldCB1cCB0 aGUgc2Vjb25kYXJ5IHBvcnQgdG8gYmluZCB0byAqLwogICAgIGlmIChvcHRDb25mLT5zZWNvbmRh cnlwb3J0ICE9IChjaGFyICopMCkKIAljb25maWctPnNlY29uZGFyeXBvcnQgPSBTdHJEdXAob3B0 Q29uZi0+c2Vjb25kYXJ5cG9ydCk7CkBAIC0xNDU4LDI0ICsxNDA4LDI0IEBAIG1haW4oYXJnYywg YXJndikKICAgICBpZiAoY29uZmlnLT5zZWNvbmRhcnlwb3J0ID09IChjaGFyICopMCkKIAlPdXRP Zk1lbSgpOwogCi0gICAgLyogTG9vayBmb3Igbm9uLW51bWVyaWMgY2hhcmFjdGVycyAqLwotICAg IGZvciAoaSA9IDA7IGNvbmZpZy0+c2Vjb25kYXJ5cG9ydFtpXSAhPSAnXDAwMCc7IGkrKykKLQlp ZiAoIWlzZGlnaXQoKGludCljb25maWctPnNlY29uZGFyeXBvcnRbaV0pKQotCSAgICBicmVhazsK KyAgICAvKiBzZXQgdXAgdGhlIGFkZHJlc3MgdG8gYmluZCB0byAqLworICAgIG1lbXNldCgmaGlu dHMsIDAsIHNpemVvZihoaW50cykpOworICAgIGhpbnRzLmFpX2ZhbWlseSA9IEFGX1VOU1BFQzsK KyAgICBoaW50cy5haV9zb2NrdHlwZSA9IFNPQ0tfU1RSRUFNOworICAgIGhpbnRzLmFpX2ZsYWdz IHw9IEFJX1BBU1NJVkU7CisKKyAgICAvKiBjcmVhdGUgbGlzdCBvciBJUHMgc3VpdGFibGUgZm9y IHByaW1hcnlwb3J0ICovCisgICAgcyA9IGdldGFkZHJpbmZvKGludGVyZmFjZSwgY29uZmlnLT5w cmltYXJ5cG9ydCwgJmhpbnRzLCAmYmluZEFkZHIpOworICAgIGlmIChzKSB7CisJRXJyb3IoImdl dGFkZHJpbmZvKCVzKTogJXMiLCBpbnRlcmZhY2UsIGdhaV9zdHJlcnJvcihzKSk7CisJQnllKEVY X09TRVJSKTsKKyAgICB9CiAKLSAgICBpZiAoY29uZmlnLT5zZWNvbmRhcnlwb3J0W2ldID09ICdc MDAwJykgewotCS8qIG51bWVyaWMgb25seSAqLwotCWJpbmRCYXNlUG9ydCA9IGF0b2koY29uZmln LT5zZWNvbmRhcnlwb3J0KTsKLSAgICB9IGVsc2UgewotCS8qIG5vbi1udW1lcmljIG9ubHkgKi8K LQlzdHJ1Y3Qgc2VydmVudCAqcFNFOwotCWlmICgoc3RydWN0IHNlcnZlbnQgKikwID09Ci0JICAg IChwU0UgPSBnZXRzZXJ2YnluYW1lKGNvbmZpZy0+c2Vjb25kYXJ5cG9ydCwgInRjcCIpKSkgewot CSAgICBFcnJvcigiZ2V0c2VydmJ5bmFtZSglcykgZmFpbGVkIiwgY29uZmlnLT5zZWNvbmRhcnlw b3J0KTsKLQkgICAgQnllKEVYX09TRVJSKTsKLQl9IGVsc2UgewotCSAgICBiaW5kQmFzZVBvcnQg PSBudG9ocygodW5zaWduZWQgc2hvcnQpcFNFLT5zX3BvcnQpOwotCX0KKyAgICAvKiBjcmVhdGUg bGlzdCBvciBJUHMgc3VpdGFibGUgZm9yIHNlY29uZGFyeXBvcnQgKi8KKyAgICBzID0gZ2V0YWRk cmluZm8oaW50ZXJmYWNlLCBjb25maWctPnNlY29uZGFyeXBvcnQsICZoaW50cywgJmJpbmRCYXNl QWRkcik7CisgICAgaWYgKHMpIHsKKwlFcnJvcigiZ2V0YWRkcmluZm8oJXMpOiAlcyIsIGludGVy ZmFjZSwgZ2FpX3N0cmVycm9yKHMpKTsKKwlCeWUoRVhfT1NFUlIpOwogICAgIH0KICNlbmRpZgog CkBAIC0xNjE0LDcgKzE1NjQsNyBAQCBtYWluKGFyZ2MsIGFyZ3YpCiAJLyogaWYgbm8gb25lIGNh biB1c2UgdXMgd2UgbmVlZCB0byBjb21lIHVwIHdpdGggYSBkZWZhdWx0CiAJICovCiAJaWYgKHBB Q0xpc3QgPT0gKEFDQ0VTUyAqKTApCi0JICAgIFNldERlZkFjY2VzcyhteUFkZHJzLCBteUhvc3Ru YW1lKTsKKwkgICAgU2V0RGVmQWNjZXNzKCk7CiAKIAkvKiBzcGF3biBhbGwgdGhlIGNoaWxkcmVu LCBzbyBmaXgga2lkcyBoYXMgYW4gaW5pdGlhbCBwaWQKIAkgKi8KQEAgLTE2NDAsOCArMTU5MCw4 IEBAIG1haW4oYXJnYywgYXJndikKIAkgICAgc2V0cHJvY3RpdGxlKCJtYXN0ZXI6IHBvcnQgMCwg JWQgbG9jYWwsICVkIHJlbW90ZSIsIGxvY2FsLAogCQkJIHJlbW90ZSk7CiAjZWxzZQotCSAgICBz ZXRwcm9jdGl0bGUoIm1hc3RlcjogcG9ydCAlaHUsICVkIGxvY2FsLCAlZCByZW1vdGUiLCBiaW5k UG9ydCwKLQkJCSBsb2NhbCwgcmVtb3RlKTsKKwkgICAgc2V0cHJvY3RpdGxlKCJtYXN0ZXI6IHBv cnQgJWh1LCAlZCBsb2NhbCwgJWQgcmVtb3RlIiwKKwkJICAgIGNvbmZpZy0+cHJpbWFyeXBvcnQs IGxvY2FsLCByZW1vdGUpOwogI2VuZGlmCiAJfQogI2VuZGlmCk9ubHkgaW4gY29uc2VydmVyLTgu MS4xOC5pcHY2L2NvbnNlcnZlcjogLm1haW4uYy5zd3AKZGlmZiAtdXByIGNvbnNlcnZlci04LjEu MTgub3JpZy9jb25zZXJ2ZXIvbWFpbi5oIGNvbnNlcnZlci04LjEuMTguaXB2Ni9jb25zZXJ2ZXIv bWFpbi5oCi0tLSBjb25zZXJ2ZXItOC4xLjE4Lm9yaWcvY29uc2VydmVyL21haW4uaAkyMDA5LTA5 LTI2IDA1OjIzOjA0LjAwMDAwMDAwMCAtMDQwMAorKysgY29uc2VydmVyLTguMS4xOC5pcHY2L2Nv bnNlcnZlci9tYWluLmgJMjAxNC0wNC0wMSAxMzowODoxMi4wNDM3ODA5MzkgLTA0MDAKQEAgLTM5 LDExICszOSwxMSBAQAogZXh0ZXJuIGNoYXIgcmNzaWRbXTsKIGV4dGVybiBpbnQgZkFsbCwgZk5v aW5pdCwgZkludGVyYWN0aXZlLCBmU3RyaXAsIGZEYWVtb24sIGZSZW9wZW4sCiAgICAgZk5vYXV0 b3JldXAsIGZTeW50YXhPbmx5OwotZXh0ZXJuIGluX2FkZHJfdCBiaW5kQWRkcjsKK2V4dGVybiBz dHJ1Y3QgYWRkcmluZm8gKmJpbmRBZGRyOworZXh0ZXJuIHN0cnVjdCBhZGRyaW5mbyAqYmluZEJh c2VBZGRyOwogZXh0ZXJuIHVuc2lnbmVkIHNob3J0IGJpbmRQb3J0LCBiaW5kQmFzZVBvcnQ7CiBl eHRlcm4gY2hhciAqcGNDb25maWc7CiBleHRlcm4gaW50IGNNYXhNZW1iOwotZXh0ZXJuIHN0cnVj dCBzb2NrYWRkcl9pbiBpbl9wb3J0OwogZXh0ZXJuIENPTkZJRyAqb3B0Q29uZjsKIGV4dGVybiBD T05GSUcgKmNvbmZpZzsKIGV4dGVybiBDT05GSUcgZGVmQ29uZmlnOwpkaWZmIC11cHIgY29uc2Vy dmVyLTguMS4xOC5vcmlnL2NvbnNlcnZlci9tYXN0ZXIuYyBjb25zZXJ2ZXItOC4xLjE4LmlwdjYv Y29uc2VydmVyL21hc3Rlci5jCi0tLSBjb25zZXJ2ZXItOC4xLjE4Lm9yaWcvY29uc2VydmVyL21h c3Rlci5jCTIwMDktMDktMjYgMDU6MjM6MDQuMDAwMDAwMDAwIC0wNDAwCisrKyBjb25zZXJ2ZXIt OC4xLjE4LmlwdjYvY29uc2VydmVyL21hc3Rlci5jCTIwMTQtMDQtMDMgMDk6MzY6MTYuMTc3Mzg3 Njk3IC0wNDAwCkBAIC01ODgsNyArNTg4LDcgQEAgRG9Ob3JtYWxSZWFkKHBDTFNlcnZpbmcpCiAJ CSAgICBGaWxlUHJpbnQocENMU2VydmluZy0+ZmQsIEZMQUdUUlVFLCAiQDAiKTsKIAkJICAgIGlT ZXAgPSAwOwogI2Vsc2UKLQkJICAgIHN0cnVjdCBzb2NrYWRkcl9pbiBsY2w7CisJCSAgICBzdHJ1 Y3Qgc29ja2FkZHJfc3RvcmFnZSBsY2w7CiAJCSAgICBzb2NrbGVuX3Qgc28gPSBzaXplb2YobGNs KTsKIAkJICAgIGlmICgtMSA9PQogCQkJZ2V0c29ja25hbWUoRmlsZUZETnVtKHBDTFNlcnZpbmct PmZkKSwKQEAgLTYwMCw4ICs2MDAsMTggQEAgRG9Ob3JtYWxSZWFkKHBDTFNlcnZpbmcpCiAJCQkg ICAgICBGaWxlRkROdW0ocENMU2VydmluZy0+ZmQpLCBzdHJlcnJvcihlcnJubykpOwogCQkJaVNl cCA9IC0xOwogCQkgICAgfSBlbHNlIHsKLQkJCUZpbGVQcmludChwQ0xTZXJ2aW5nLT5mZCwgRkxB R1RSVUUsICJAJXMiLAotCQkJCSAgaW5ldF9udG9hKGxjbC5zaW5fYWRkcikpOworCQkJY2hhciBh ZGRyW0lORVQ2X0FERFJTVFJMRU5dOworICAgICAgICAgICAgICAgICAgICAgICAgaW50IGVycm9y OworICAgICAgICAgICAgICAgICAgICAgICAgZXJyb3IgPSBnZXRuYW1laW5mbygoc3RydWN0IHNv Y2thZGRyICopJmxjbCwgc28sIGFkZHIsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgc2l6ZW9mKGFkZHIpLCBOVUxMLCAwLCBOSV9OVU1FUklDSE9TVCk7CisgICAgICAg ICAgICAgICAgICAgICAgICBpZiAoZXJyb3IpIHsKKwkJCSAgICAgICAgRmlsZVdyaXRlKHBDTFNl cnZpbmctPmZkLCBGTEFHRkFMU0UsCisJCQkJICAgICAgICAiZ2V0bmFtZWluZm8gZmFpbGVkLCB0 cnkgYWdhaW4gbGF0ZXJcclxuIiwKKwkJCQkgICAgICAgIC0xKTsKKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgRXJyb3IoIk1hc3RlcigpOiBnYXRlbmFtZWluZm86ICVzIiwgZ2FpX3N0 cmVycm9yKGVycm9yKSk7CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlTZXAgPSAt MTsKKyAgICAgICAgICAgICAgICAgICAgICAgIH0KKwkJCUZpbGVQcmludChwQ0xTZXJ2aW5nLT5m ZCwgRkxBR1RSVUUsICJAJXMiLCBhZGRyKTsKIAkJCWlTZXAgPSAwOwogCQkgICAgfQogI2VuZGlm CkBAIC03MzQsMTEgKzc0NCw5IEBAIE1hc3RlcigpCiAjaWYgVVNFX1VOSVhfRE9NQUlOX1NPQ0tF VFMKICAgICBzdHJ1Y3Qgc29ja2FkZHJfdW4gbWFzdGVyX3BvcnQ7CiAgICAgc3RhdGljIFNUUklO RyAqcG9ydFBhdGggPSAoU1RSSU5HICopMDsKLSNlbHNlCi0gICAgc3RydWN0IHNvY2thZGRyX2lu IG1hc3Rlcl9wb3J0OwotIyBpZiBIQVZFX1NFVFNPQ0tPUFQKKyNlbmRpZgorI2lmIEhBVkVfU0VU U09DS09QVAogICAgIGludCB0cnVlID0gMTsKLSMgZW5kaWYKICNlbmRpZgogICAgIEZJTEUgKmZw OwogICAgIENPTlNDTElFTlQgKnBDTFNlcnZpbmcgPSAoQ09OU0NMSUVOVCAqKTA7CkBAIC03Nzgs MTMgKzc4NiwxMiBAQCBNYXN0ZXIoKQogCiAgICAgLyogc2V0IHVwIHBvcnQgZm9yIG1hc3RlciB0 byBsaXN0ZW4gb24KICAgICAgKi8KLSNpZiBIQVZFX01FTVNFVAorI2lmIFVTRV9VTklYX0RPTUFJ Tl9TT0NLRVRTCisjIGlmIEhBVkVfTUVNU0VUCiAgICAgbWVtc2V0KCh2b2lkICopJm1hc3Rlcl9w b3J0LCAwLCBzaXplb2YobWFzdGVyX3BvcnQpKTsKLSNlbHNlCisjIGVsc2UKICAgICBiemVybygo Y2hhciAqKSZtYXN0ZXJfcG9ydCwgc2l6ZW9mKG1hc3Rlcl9wb3J0KSk7Ci0jZW5kaWYKLQotI2lm IFVTRV9VTklYX0RPTUFJTl9TT0NLRVRTCisjIGVuZGlmCiAgICAgbWFzdGVyX3BvcnQuc3VuX2Zh bWlseSA9IEFGX1VOSVg7CiAKICAgICBpZiAocG9ydFBhdGggPT0gKFNUUklORyAqKTApCkBAIC04 MTgsMzkgKzgyNSwzOSBAQCBNYXN0ZXIoKQogCXJldHVybjsKICAgICB9CiAjZWxzZQotICAgIG1h c3Rlcl9wb3J0LnNpbl9mYW1pbHkgPSBBRl9JTkVUOwotICAgIG1hc3Rlcl9wb3J0LnNpbl9hZGRy LnNfYWRkciA9IGJpbmRBZGRyOwotICAgIG1hc3Rlcl9wb3J0LnNpbl9wb3J0ID0gaHRvbnMoYmlu ZFBvcnQpOwotCi0gICAgaWYgKChtc2ZkID0gc29ja2V0KEFGX0lORVQsIFNPQ0tfU1RSRUFNLCAw KSkgPCAwKSB7Ci0JRXJyb3IoIk1hc3RlcigpOiBzb2NrZXQoQUZfSU5FVCxTT0NLX1NUUkVBTSk6 ICVzIiwKLQkgICAgICBzdHJlcnJvcihlcnJubykpOwotCXJldHVybjsKLSAgICB9CisgICAgc3Ry dWN0IGFkZHJpbmZvICpycDsKKyAgICBmb3IgKHJwID0gYmluZEFkZHI7IHJwICE9IE5VTEw7IHJw ID0gcnAtPmFpX25leHQpIHsKKyAgICAgICAgaWYgKChtc2ZkID0gc29ja2V0KHJwLT5haV9mYW1p bHksIHJwLT5haV9zb2NrdHlwZSwKKyAgICAgICAgICAgICAgICAgICAgICAgIHJwLT5haV9wcm90 b2NvbCkpIDwgMCkgeworICAgICAgICAgICAgRXJyb3IoIk1hc3RlcigpOiBzb2NrZXQoKTogJXMi LAorICAgICAgICAgICAgICAgICAgICBzdHJlcnJvcihlcnJubykpOworICAgICAgICAgICAgY29u dGludWU7CisgICAgICAgIH0KICMgaWYgSEFWRV9TRVRTT0NLT1BUCi0gICAgaWYgKHNldHNvY2tv cHQKLQkobXNmZCwgU09MX1NPQ0tFVCwgU09fUkVVU0VBRERSLCAoY2hhciAqKSZ0cnVlLAotCSBz aXplb2YodHJ1ZSkpIDwgMCkgewotCUVycm9yKCJNYXN0ZXIoKTogc2V0c29ja29wdCgldSxTT19S RVVTRUFERFIpOiAlcyIsIG1zZmQsCi0JICAgICAgc3RyZXJyb3IoZXJybm8pKTsKLQlyZXR1cm47 Ci0gICAgfQorICAgICAgICBpZiAoc2V0c29ja29wdAorICAgICAgICAgICAgKG1zZmQsIFNPTF9T T0NLRVQsIFNPX1JFVVNFQUREUiwgKGNoYXIgKikmdHJ1ZSwKKyAgICAgICAgICAgICBzaXplb2Yo dHJ1ZSkpIDwgMCkgeworICAgICAgICAgICAgRXJyb3IoIk1hc3RlcigpOiBzZXRzb2Nrb3B0KCV1 LFNPX1JFVVNFQUREUik6ICVzIiwgbXNmZCwKKyAgICAgICAgICAgICAgICAgICAgc3RyZXJyb3Io ZXJybm8pKTsKKyAgICAgICAgICAgIHJldHVybjsKKyAgICAgICAgfQogIyBlbmRpZgorICAgICAg ICBpZiAoIVNldEZsYWdzKG1zZmQsIE9fTk9OQkxPQ0ssIDApKQorICAgICAgICAgICAgcmV0dXJu OworICAgIAorICAgICAgICBpZiAoYmluZChtc2ZkLCBycC0+YWlfYWRkciwgcnAtPmFpX2FkZHJs ZW4pID09IDApCisgICAgICAgICAgICBicmVhazsKIAotICAgIGlmICghU2V0RmxhZ3MobXNmZCwg T19OT05CTE9DSywgMCkpCi0JcmV0dXJuOwotCi0gICAgaWYgKGJpbmQobXNmZCwgKHN0cnVjdCBz b2NrYWRkciAqKSZtYXN0ZXJfcG9ydCwgc2l6ZW9mKG1hc3Rlcl9wb3J0KSkgPAotCTApIHsKLQlF cnJvcigiTWFzdGVyKCk6IGJpbmQoJWh1KTogJXMiLCBudG9ocyhtYXN0ZXJfcG9ydC5zaW5fcG9y dCksCi0JICAgICAgc3RyZXJyb3IoZXJybm8pKTsKLQlyZXR1cm47CisgICAgICAgIGNsb3NlKG1z ZmQpOwogICAgIH0KKwogICAgIGlmIChsaXN0ZW4obXNmZCwgU09NQVhDT05OKSA8IDApIHsKLQlF cnJvcigiTWFzdGVyKCk6IGxpc3RlbiglaHUpOiAlcyIsIG50b2hzKG1hc3Rlcl9wb3J0LnNpbl9w b3J0KSwKLQkgICAgICBzdHJlcnJvcihlcnJubykpOwotCXJldHVybjsKKyAgICAgICAgRXJyb3Io Ik1hc3RlcigpOiBsaXN0ZW4oKTogJXMiLCBzdHJlcnJvcihlcnJubykpOworICAgICAgICByZXR1 cm47CiAgICAgfQorCisgICAgLyogc2F2ZSBhZGRybGVuIGZvciBhY2NlcHQgKi8KKwlzbyA9IHJw LT5haV9hZGRybGVuOwogI2VuZGlmCiAKICAgICBmcCA9IGZvcGVuKFBJREZJTEUsICJ3Iik7CkBA IC05ODMsNyArOTkwLDYgQEAgTWFzdGVyKCkKIAlkbWFsbG9jTWFya0NsaWVudENvbm5lY3Rpb24g PSBkbWFsbG9jX21hcmsoKTsKICNlbmRpZgogCi0Jc28gPSBzaXplb2Yoc3RydWN0IHNvY2thZGRy X2luKTsKIAlmb3IgKGNmZCA9IDA7IGNmZCA9PSAwOykgewogCSAgICBjZmQgPQogCQlhY2NlcHQo bXNmZCwgKHN0cnVjdCBzb2NrYWRkciAqKSZwQ0xtZnJlZS0+Y25jdF9wb3J0LCAmc28pOwpPbmx5 IGluIGNvbnNlcnZlci04LjEuMTguaXB2Ni9jb25zZXJ2ZXI6IC5tYXN0ZXIuYy5zd3AKZGlmZiAt dXByIGNvbnNlcnZlci04LjEuMTgub3JpZy9jb25zZXJ2ZXIvcmVhZGNmZy5jIGNvbnNlcnZlci04 LjEuMTguaXB2Ni9jb25zZXJ2ZXIvcmVhZGNmZy5jCi0tLSBjb25zZXJ2ZXItOC4xLjE4Lm9yaWcv Y29uc2VydmVyL3JlYWRjZmcuYwkyMDA5LTA5LTI2IDA1OjIwOjQ3LjAwMDAwMDAwMCAtMDQwMAor KysgY29uc2VydmVyLTguMS4xOC5pcHY2L2NvbnNlcnZlci9yZWFkY2ZnLmMJMjAxNC0wNC0wMiAx Mjo0NDoyOS4yMzgzODY4ODMgLTA0MDAKQEAgLTUxOTYsNyArNTE5Niw3IEBAIFJlUmVhZENmZyhm ZCwgbXNmZCkKICAgICAvKiBpZiBubyBvbmUgY2FuIHVzZSB1cyB3ZSBuZWVkIHRvIGNvbWUgdXAg d2l0aCBhIGRlZmF1bHQKICAgICAgKi8KICAgICBpZiAocEFDTGlzdCA9PSAoQUNDRVNTICopMCkK LQlTZXREZWZBY2Nlc3MobXlBZGRycywgbXlIb3N0bmFtZSk7CisJU2V0RGVmQWNjZXNzKCk7CiAK ICAgICBpZiAoaXNNYXN0ZXIpIHsKIAlHUlBFTlQgKnBHRTsKT25seSBpbiBjb25zZXJ2ZXItOC4x LjE4LmlwdjYvY29uc2VydmVyOiAucmVhZGNmZy5jLnN3cApkaWZmIC11cHIgY29uc2VydmVyLTgu MS4xOC5vcmlnL2NvbnNvbGUvY29uc29sZS5jIGNvbnNlcnZlci04LjEuMTguaXB2Ni9jb25zb2xl L2NvbnNvbGUuYwotLS0gY29uc2VydmVyLTguMS4xOC5vcmlnL2NvbnNvbGUvY29uc29sZS5jCTIw MDktMTAtMTkgMDI6NDQ6MDYuMDAwMDAwMDAwIC0wNDAwCisrKyBjb25zZXJ2ZXItOC4xLjE4Lmlw djYvY29uc29sZS9jb25zb2xlLmMJMjAxNC0wNC0wMyAxNTozMzoyOC41MDU2NjEzOTIgLTA0MDAK QEAgLTQ0LDYgKzQ0LDggQEAKICNpbmNsdWRlIDxnc3NhcGkvZ3NzYXBpLmg+CiAjZW5kaWYKIAor I2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4KKyNpbmNsdWRlIDxuZXRkYi5oPgogCiBpbnQgZlJlcGxh eSA9IDAsIGZWZXJzaW9uID0gMDsKIGludCBzaG93RXhlY0RhdGEgPSAxOwpAQCAtNTQ1LDIwICs1 NDcsMjIgQEAgR2V0UG9ydChwY1RvSG9zdCwgc1BvcnQpCiAgICAgc3RydWN0IHNvY2thZGRyX3Vu IHBvcnQ7CiAgICAgc3RhdGljIFNUUklORyAqcG9ydFBhdGggPSAoU1RSSU5HICopMDsKICNlbHNl Ci0gICAgc3RydWN0IGhvc3RlbnQgKmhwID0gKHN0cnVjdCBob3N0ZW50ICopMDsKLSAgICBzdHJ1 Y3Qgc29ja2FkZHJfaW4gcG9ydDsKKyAgICBpbnQgZXJyb3I7CisgICAgY2hhciBob3N0W05JX01B WEhPU1RdOworICAgIGNoYXIgc2VydltOSV9NQVhTRVJWXTsKKyAgICBzdHJ1Y3QgYWRkcmluZm8g KmFpLCAqcnAsIGhpbnRzOwogI2VuZGlmCiAKLSNpZiBIQVZFX01FTVNFVAorI2lmIFVTRV9VTklY X0RPTUFJTl9TT0NLRVRTCisjIGlmIEhBVkVfTUVNU0VUCiAgICAgbWVtc2V0KCh2b2lkICopKCZw b3J0KSwgJ1wwMDAnLCBzaXplb2YocG9ydCkpOwotI2Vsc2UKKyMgZWxzZQogICAgIGJ6ZXJvKChj aGFyICopKCZwb3J0KSwgc2l6ZW9mKHBvcnQpKTsKLSNlbmRpZgorIyBlbmRpZgogCi0jaWYgVVNF X1VOSVhfRE9NQUlOX1NPQ0tFVFMKICAgICBpZiAocG9ydFBhdGggPT0gKFNUUklORyAqKTApCiAJ cG9ydFBhdGggPSBBbGxvY1N0cmluZygpOwotICAgIEJ1aWxkU3RyaW5nUHJpbnQocG9ydFBhdGgs ICIlcy8laHUiLCBjb25maWctPm1hc3Rlciwgc1BvcnQpOworICAgIEJ1aWxkU3RyaW5nUHJpbnQo cG9ydFBhdGgsICIlcy8laHUiLCBjb25maWctPm1hc3RlciwgaHRvbnMoc1BvcnQpKTsKICAgICBw b3J0LnN1bl9mYW1pbHkgPSBBRl9VTklYOwogICAgIGlmIChwb3J0UGF0aC0+dXNlZCA+IHNpemVv Zihwb3J0LnN1bl9wYXRoKSkgewogCUVycm9yKCJHZXRQb3J0OiBwYXRoIHRvIHNvY2tldCB0b28g bG9uZzogJXMiLCBwb3J0UGF0aC0+c3RyaW5nKTsKQEAgLTU4MSw1NCArNTg1LDQ5IEBAIEdldFBv cnQocGNUb0hvc3QsIHNQb3J0KQogCXJldHVybiAoQ09OU0ZJTEUgKikwOwogICAgIH0KICNlbHNl Ci0jIGlmIEhBVkVfSU5FVF9BVE9OCi0gICAgaWYgKGluZXRfYXRvbihwY1RvSG9zdCwgJihwb3J0 LnNpbl9hZGRyKSkgPT0gMCkKKyMgaWYgSEFWRV9NRU1TRVQKKyAgICBtZW1zZXQoJmhpbnRzLCAw LCBzaXplb2YoaGludHMpKTsKICMgZWxzZQotICAgIHBvcnQuc2luX2FkZHIuc19hZGRyID0gaW5l dF9hZGRyKHBjVG9Ib3N0KTsKLSAgICBpZiAoKGluX2FkZHJfdCkgKC0xKSA9PSBwb3J0LnNpbl9h ZGRyLnNfYWRkcikKKyAgICBiemVybygmaGludHMsIHNpemVvZihoaW50cykpOwogIyBlbmRpZgot ICAgIHsKLQlpZiAoKHN0cnVjdCBob3N0ZW50ICopMCAhPSAoaHAgPSBnZXRob3N0YnluYW1lKHBj VG9Ib3N0KSkpIHsKLSMgaWYgSEFWRV9NRU1DUFkKLQkgICAgbWVtY3B5KChjaGFyICopJnBvcnQu c2luX2FkZHIuc19hZGRyLCAoY2hhciAqKWhwLT5oX2FkZHIsCi0JCSAgIGhwLT5oX2xlbmd0aCk7 Ci0jIGVsc2UKLQkgICAgYmNvcHkoKGNoYXIgKilocC0+aF9hZGRyLCAoY2hhciAqKSZwb3J0LnNp bl9hZGRyLnNfYWRkciwKLQkJICBocC0+aF9sZW5ndGgpOwotIyBlbmRpZgotCX0gZWxzZSB7Ci0J ICAgIEVycm9yKCJnZXRob3N0YnluYW1lKCVzKTogJXMiLCBwY1RvSG9zdCwgaHN0cmVycm9yKGhf ZXJybm8pKTsKLQkgICAgcmV0dXJuIChDT05TRklMRSAqKTA7Ci0JfQotICAgIH0KLSAgICBwb3J0 LnNpbl9wb3J0ID0gc1BvcnQ7Ci0gICAgcG9ydC5zaW5fZmFtaWx5ID0gQUZfSU5FVDsKIAotICAg IGlmIChmRGVidWcpIHsKLQlpZiAoKHN0cnVjdCBob3N0ZW50ICopMCAhPSBocCAmJiAoY2hhciAq KTAgIT0gaHAtPmhfbmFtZSkgewotCSAgICBDT05EREVCVUcoKDEsICJHZXRQb3J0OiBob3N0bmFt ZT0lcyAoJXMpLCBpcD0lcywgcG9ydD0laHUiLAotCQkgICAgICAgaHAtPmhfbmFtZSwgcGNUb0hv c3QsIGluZXRfbnRvYShwb3J0LnNpbl9hZGRyKSwKLQkJICAgICAgIG50b2hzKHNQb3J0KSkpOwot CX0gZWxzZSB7Ci0JICAgIENPTkRERUJVRygoMSwKLQkJICAgICAgICJHZXRQb3J0OiBob3N0bmFt ZT08dW5yZXNvbHZlZD4gKCVzKSwgaXA9JXMsIHBvcnQ9JWh1IiwKLQkJICAgICAgIHBjVG9Ib3N0 LCBpbmV0X250b2EocG9ydC5zaW5fYWRkciksIG50b2hzKHNQb3J0KSkpOwotCX0KLSAgICB9Ci0K LSAgICAvKiBzZXQgdXAgdGhlIHNvY2tldCB0byB0YWxrIHRvIHRoZSBzZXJ2ZXIgZm9yIGFsbCBj b25zb2xlcwotICAgICAqIChpdCB3aWxsIHRlbGwgdXMgd2hvIHRvIHRhbGsgdG8gdG8gZ2V0IGEg cmVhbCBjb25uZWN0aW9uKQotICAgICAqLwotICAgIGlmICgocyA9IHNvY2tldChBRl9JTkVULCBT T0NLX1NUUkVBTSwgMCkpIDwgMCkgewotCUVycm9yKCJzb2NrZXQoQUZfSU5FVCxTT0NLX1NUUkVB TSk6ICVzIiwgc3RyZXJyb3IoZXJybm8pKTsKLQlyZXR1cm4gKENPTlNGSUxFICopMDsKLSAgICB9 Ci0KLSAgICBpZiAoY29ubmVjdChzLCAoc3RydWN0IHNvY2thZGRyICopKCZwb3J0KSwgc2l6ZW9m KHBvcnQpKSA8IDApIHsKLQlFcnJvcigiY29ubmVjdCgpOiAlaHVAJXM6ICVzIiwgbnRvaHMocG9y dC5zaW5fcG9ydCksIHBjVG9Ib3N0LAotCSAgICAgIHN0cmVycm9yKGVycm5vKSk7Ci0JcmV0dXJu IChDT05TRklMRSAqKTA7Ci0gICAgfQorICAgIGhpbnRzLmFpX2ZsYWdzID0gQUlfQUREUkNPTkZJ RzsKKyAgICBoaW50cy5haV9zb2NrdHlwZSA9IFNPQ0tfU1RSRUFNOworICAgIHNucHJpbnRmKHNl cnYsIHNpemVvZihzZXJ2KSwgIiVodSIsIHNQb3J0KTsKKworICAgIGVycm9yID0gZ2V0YWRkcmlu Zm8ocGNUb0hvc3QsIHNlcnYsICZoaW50cywgJmFpKTsKKyAgICBpZiAoZXJyb3IpIHsKKyAgICAg ICAgRXJyb3IoImdldGFkZHJpbmZvKCVzKTogJXMiLCBwY1RvSG9zdCwgZ2FpX3N0cmVycm9yKGVy cm9yKSk7CisgICAgICAgIHJldHVybiAoQ09OU0ZJTEUgKikwOworICAgIH0KKworICAgIHJwID0g YWk7CisgICAgd2hpbGUocnApIHsKKyAgICAgICAgZXJyb3IgPSBnZXRuYW1laW5mbyhycC0+YWlf YWRkciwgcnAtPmFpX2FkZHJsZW4sCisgICAgICAgICAgICAgICAgICAgIGhvc3QsIHNpemVvZiho b3N0KSwKKyAgICAgICAgICAgICAgICAgICAgc2Vydiwgc2l6ZW9mKHNlcnYpLAorICAgICAgICAg ICAgICAgICAgICBOSV9OVU1FUklDSE9TVCB8IE5JX05VTUVSSUNTRVJWKTsKKyAgICAgICAgaWYg KGVycm9yKSB7CisgICAgICAgICAgICBjb250aW51ZTsKKyAgICAgICAgfQorICAgICAgICBDT05E REVCVUcoKDEsICJHZXRQb3J0OiBob3N0bmFtZT0lcywgaXA9JXMsIHBvcnQ9JXMiLAorICAgICAg ICAgICAgICAgICAgICBwY1RvSG9zdCwgaG9zdCwgc2VydikpOworCisgICAgICAgIC8qIHNldCB1 cCB0aGUgc29ja2V0IHRvIHRhbGsgdG8gdGhlIHNlcnZlciBmb3IgYWxsIGNvbnNvbGVzCisgICAg ICAgICAqIChpdCB3aWxsIHRlbGwgdXMgd2hvIHRvIHRhbGsgdG8gdG8gZ2V0IGEgcmVhbCBjb25u ZWN0aW9uKQorICAgICAgICAgKi8KKyAgICAgICAgcyA9IHNvY2tldChycC0+YWlfZmFtaWx5LCBy cC0+YWlfc29ja3R5cGUsIHJwLT5haV9wcm90b2NvbCk7CisgICAgICAgIGlmIChzICE9IC0xKSB7 CisgICAgICAgICAgICBpZiAoY29ubmVjdChzLCBycC0+YWlfYWRkciwgcnAtPmFpX2FkZHJsZW4p ID09IDApIAorICAgICAgICAgICAgICAgIGdvdG8gc3VjY2VzczsKKyAgICAgICAgICAgIGNsb3Nl KHMpOworICAgICAgICB9CisgICAgICAgIHJwID0gcnAtPmFpX25leHQ7CisgICAgfQorICAgIEVy cm9yKCJVbmFibGUgdG8gY29ubmVjdCB0byAlczolcyIsIGhvc3QsIHNlcnYpOyAKKyAgICByZXR1 cm4gKENPTlNGSUxFICopMDsKK3N1Y2Nlc3M6CisgICAgZnJlZWFkZHJpbmZvKGFpKTsKICNlbmRp ZgogCiAgICAgcmV0dXJuIEZpbGVPcGVuRkQocywgc2ltcGxlU29ja2V0KTsKQEAgLTcwNiw4ICs3 MDUsNiBAQCBEZXN0cm95RGF0YVN0cnVjdHVyZXMoKQogICAgIERlc3Ryb3lDb25maWcob3B0Q29u Zik7CiAgICAgRGVzdHJveUNvbmZpZyhjb25maWcpOwogICAgIERlc3Ryb3lUZXJtaW5hbChwVGVy bSk7Ci0gICAgaWYgKG15QWRkcnMgIT0gKHN0cnVjdCBpbl9hZGRyICopMCkKLQlmcmVlKG15QWRk cnMpOwogICAgIERlc3Ryb3lTdHJpbmdzKCk7CiAgICAgaWYgKHN1YnN0RGF0YSAhPSAoU1VCU1Qg KikwKQogCWZyZWUoc3Vic3REYXRhKTsKQEAgLTE2NDUsNyArMTY0Miw3IEBAIERvQ21kcyhtYXN0 ZXIsIHBwb3J0cywgY21kaSkKICNpZiBVU0VfVU5JWF9ET01BSU5fU09DS0VUUwogCSAgICBwb3J0 ID0gMDsKICNlbHNlCi0JICAgIHBvcnQgPSBodG9ucyhiaW5kUG9ydCk7CisJICAgIHBvcnQgPSBi aW5kUG9ydDsKICNlbmRpZgogCX0gZWxzZSBpZiAoIWlzZGlnaXQoKGludCkocG9ydHNbMF0pKSkg ewogCSAgICBFcnJvcigiaW52YWxpZCBwb3J0IHNwZWMgZm9yICVzOiBgJXMnIiwgc2VydmVyTmFt ZSwgcG9ydHMpOwpAQCAtMTY1NCw3ICsxNjUxLDcgQEAgRG9DbWRzKG1hc3RlciwgcHBvcnRzLCBj bWRpKQogI2lmIFVTRV9VTklYX0RPTUFJTl9TT0NLRVRTCiAJICAgIHBvcnQgPSAoc2hvcnQpYXRv aShwb3J0cyk7CiAjZWxzZQotCSAgICBwb3J0ID0gaHRvbnMoKHNob3J0KWF0b2kocG9ydHMpKTsK KwkgICAgcG9ydCA9IChzaG9ydClhdG9pKHBvcnRzKTsKICNlbmRpZgogCX0KIApAQCAtMjIxNiw4 ICsyMjEzLDYgQEAgbWFpbihhcmdjLCBhcmd2KQogCUJ5ZShFWF9PSyk7CiAgICAgfQogCi0gICAg UHJvYmVJbnRlcmZhY2VzKElOQUREUl9BTlkpOwotCiAgICAgaWYgKHJlYWRTeXN0ZW1Db25mKQog CVJlYWRDb25mKENMSUVOVENPTkZJR0ZJTEUsIEZMQUdGQUxTRSk7CiAKT25seSBpbiBjb25zZXJ2 ZXItOC4xLjE4LmlwdjYvY29uc29sZTogLmNvbnNvbGUuYy5zd3AK --001a1136b00624d8c604f63bcc77-- From glance@acc.umu.se Wed Apr 9 08:52:59 2014 Received: from mail.acc.umu.se (mail.acc.umu.se [130.239.18.156]) by underdog.stansell.org (8.14.7/8.14.7) with ESMTP id s398qtcc025015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Apr 2014 08:52:59 GMT Received: from localhost (localhost [127.0.0.1]) by amavisd-new (Postfix) with ESMTP id 8757FDBC; Wed, 9 Apr 2014 10:52:53 +0200 (MEST) X-Virus-Scanned: amavisd-new at acc.umu.se Received: by mail.acc.umu.se (Postfix, from userid 24471) id A1C85DBA; Wed, 9 Apr 2014 10:52:49 +0200 (MEST) Date: Wed, 9 Apr 2014 10:52:48 +0200 From: Anton Lundin To: Bryan Stansell Subject: Re: conserver-8.1.20 is available Message-ID: <20140409085248.GR1989@kennedy.acc.umu.se> References: <20140404164517.GA16362@underdog.stansell.org> <53521EEB-6182-48B9-91AD-01FD7C370DCC@conserver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <53521EEB-6182-48B9-91AD-01FD7C370DCC@conserver.com> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Score: -2.55 () BAYES_00,RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 Cc: users@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.16 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 08:53:00 -0000 I dumped two old patches i found laying around on my github account a while back, so i might post them here to. First a dead simple memleak and cleanup: https://github.com/glance-/conserver/commit/4f41ebb149488edbedf069c5de4a926640adc3dc.patch And then a SO_PEERCRED auth patch: https://github.com/glance-/conserver/commit/14bf8a1f16829335f31b3f78a318b2e2726b794d.patch It might need a config flag if it should be enabled or not, but its generally a quite nice feature. //Anton On 04 April, 2014 - Bryan Stansell wrote: > There isn't a repository available. Not yet, at least. I was thinking about going from the old-school CVS repository I have locally to git and then shoving it into github as a public instance. There's a bit of cleanup work I need to do to make that happen, however. > > You can pull previous versions from the website (need to know the name) or hit it via ftp (to ftp.conserver.com) and get the old releases (naming is pretty straightforward). > > Patches can just be sent to me directly, or more often, posted to this list so it's archived and others get a chance to work with it before I get around to putting it in an official release. > > IPv6 is certainly a missing piece, and something I was going to look into (at some point). I'm sure I'm not the only one that would like to see the patch! > > Thanks! > > Bryan > > On Apr 4, 2014, at 10:24 AM, Milos Vyletel wrote: > > > Bryan, > > > > I was wondering if there is a public source code repository with conserver where > > we can see changes made between versions. I've looked at website but could > > not find any. > > > > Btw. is there any recommended process for patch submission? The reason I ask > > is that I have rather big patch adding IPv6 support to conserver almost ready. I'm > > still polishing code and testing it but it should be ready soon. > > > > Thanks, > > Milos > > > > > > On Fri, Apr 4, 2014 at 12:45 PM, Bryan Stansell wrote: > > I've finally integrated and expanded a patch that was submitted over > > 3 years ago (yikes!) - direct IPMI serial over LAN support. Hopefully > > this will work just as well as forking off an ipmi command but also > > allow less resource usage. > > > > I'm curious to hear about any success or horror stories - share if you > > can. Thanks! > > > > version 8.1.20 (Apr 4, 2014): > > - IPMI serial over LAN support via FreeIPMI - based on patch by Anton > > D. Kachalov > > - minor cleanup of code, removal of gcc warnings and such that should > > have no fuctional change > > > > Bryan Stansell > > _______________________________________________ > > users mailing list > > users@conserver.com > > https://www.conserver.com/mailman/listinfo/users > > > > _______________________________________________ > users mailing list > users@conserver.com > https://www.conserver.com/mailman/listinfo/users -- Anton Lundin +46702-161604 From bryan@conserver.com Fri Apr 11 18:18:20 2014 Received: from [192.168.0.107] (c-98-207-6-47.hsd1.ca.comcast.net [98.207.6.47]) (authenticated bits=0) by underdog.stansell.org (8.14.7/8.14.7) with ESMTP id s3BIIJZB028346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Apr 2014 18:18:20 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: conserver-8.1.20 freeipmi seems lack a send-break functionality From: Bryan Stansell In-Reply-To: Date: Fri, 11 Apr 2014 11:18:20 -0700 Message-Id: References: To: "Alexander Y. Fomichev" X-Mailer: Apple Mail (2.1874) X-Spam-Score: 0.412 () BAYES_00,HELO_MISC_IP,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by underdog.stansell.org id s3BIIJZB028346 Cc: users@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.16 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 18:18:21 -0000 Ooops! Yep, sending of a break was totally overlooked. Thanks for the patch. I'll probably be releasing 8.1.21 "relatively soon" as there are quite a few contributions that have come in over the last week or so (this, a UDS enhancement, missing closedir(), and IPv6 code). If anyone has anything else in the works, let me know and we can try and time things. Bryan On Apr 11, 2014, at 12:57 AM, Alexander Y. Fomichev wrote: > New shiny 8.1.20 freeipmi implementation looks really great, tnx! > At least i don't see this bunch of forked ipmitools any more :) > But suddenly i found myself not capable to send sysrq with ipmi consoles. > Though it seems could be fixed easily. A 5-min patch in attachement > just calls ipmiconsole_ctx_generate_break instead of tcsendbreak > (serial break) if we have IPMI and console is of IPMI type. It works > at least for supermicro bmcs. > > -- > Best regards. > Alexander Y. Fomichev > From bryan@stansell.org Mon Apr 21 04:58:48 2014 Received: from underdog.stansell.org (localhost [127.0.0.1]) by underdog.stansell.org (8.14.7/8.14.7) with ESMTP id s3L4wlfE019772; Mon, 21 Apr 2014 04:58:47 GMT Received: (from bryan@localhost) by underdog.stansell.org (8.14.7/8.14.7/Submit) id s3L4wlkS019771; Mon, 21 Apr 2014 04:58:47 GMT Date: Mon, 21 Apr 2014 04:58:47 +0000 From: Bryan Stansell To: announce@conserver.com, users@conserver.com Subject: conserver-8.2.0 is available Message-ID: <20140421045841.GA19609@underdog.stansell.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.16 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 04:58:48 -0000 I've integrated a few more submissions and bug fixes, and decided that it's time up the numbering to 8.2.0. Mainly it signifies the addition of IPv6-aware code and the assumption of an ANSI C compiler (shows you how old this code is). As always, feedback, code, etc is greatly appreciated (preferably via the users mailing list so everyone can see, but direct mail is fine too). version 8.2.0 (Apr 20, 2014): - added --with-trust-uds-cred which uses getsockopt() to fetch and trust the client uid, bypassing password lookups - patch by Anton Lundin - missing closedir() causing memory leak - patch by Anton Lundin - sending a break signal over IPMI was broken - based on patch by Alexander Y. Fomichev - IPv6 support (marked as experimental at this point because it's untested (except by the author), there's a lack of documentation, and I'm hoping for non-getifaddrs() system support) - patch by Milos Vyletel - no more K&R compiler support Bryan Stansell From bstout@squareup.com Mon Apr 21 17:29:54 2014 Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by underdog.stansell.org (8.14.7/8.14.7) with ESMTP id s3LHTqrU015252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Apr 2014 17:29:54 GMT Received: by mail-pa0-f51.google.com with SMTP id kq14so3924208pab.24 for ; Mon, 21 Apr 2014 10:29:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=squareup.com; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=sno5NSyoSn+x968spZBncNnWDN/qO4q7iETAhpo9TjY=; b=TPC2gK2qnD5CmsZ3Gw+FwanOzdLy0v7Jnx0aDjUU6r9eHoWbBGELrBZnR+vLKOVzk9 Sp7WGlCBaHXtk2L1G4cPda6Fz0Jdr4ohiUcc5S4rx8SasLNsKDpOi4F8X1b01uRvX4we SJmGX54I+EFGslJuETW0+4tdqmxJtYYGh2wYc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=sno5NSyoSn+x968spZBncNnWDN/qO4q7iETAhpo9TjY=; b=Me+u9+QnhmA7HnwOO5mGnvV4IXabam4Zxha04XieRl5R/brYIhXIUffDSIIlo1ZnEM 2heorM65kotrDMKjt9xXxK98Uj0lzec/BnWM5V9VJOnWC3fQr/FIFgMpdxH0PQJY35gC UOydUQApDRwZ5Y6L7O2bl3NtQTjgURO/nitr3BLyP1sNEsYM13dz5XB9K+tz2WL8Pjs8 aGq8dIcyZh+Ea2wM4mlLD8Hsy9AGddHULCi3D/4uXH5pljDmYRHa4c92shIuyWc5H6eb 3OG0dwU6T36CqQM2LJKlyXfy3MNiFsiRVdHz1/Td8cEMc/gQ2+Kuu9E/sD0M7Ocb7i1w 2bdw== X-Gm-Message-State: ALoCoQk75NWNkuitAQjdMEkhTtvUpiFs6U6D5CC86Rc2N/oyGNFTeGREl+xHASxEWSzUtR0nMoK1 MIME-Version: 1.0 X-Received: by 10.66.136.71 with SMTP id py7mr39746061pab.2.1398101392495; Mon, 21 Apr 2014 10:29:52 -0700 (PDT) Received: by 10.70.30.228 with HTTP; Mon, 21 Apr 2014 10:29:52 -0700 (PDT) Date: Mon, 21 Apr 2014 10:29:52 -0700 Message-ID: Subject: Conserver and ssh From: Brandon Stout To: users@conserver.com Content-Type: multipart/alternative; boundary=001a11332dfcdc21f504f790d80e X-Spam-Score: -1.489 () BAYES_00,HTML_MESSAGE,T_DKIM_INVALID X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.16 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 17:29:54 -0000 --001a11332dfcdc21f504f790d80e Content-Type: text/plain; charset=UTF-8 hello, I am trying to use conserver to connect to serial ports over ssh and it is hanging. When I go direct it works fine (i am using Opengear IMX4248): [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002 Password: cs02 login: cs02 login: from console it just hangs: [bstout@akebia etc]$ console dr01.arista [Enter `^Ec?' for help] this is the only thing that shows up in the log file [Mon Apr 21 10:19:25 2014] conserver (29839): [dr01.arista] login bstout@localhost [-- bstout@localhost attached -- Mon Apr 21 10:19:25 2014] this is the conserver.cf file default full { rw *; } default opengear { type host; portbase 3000; portinc 1; } default * { logfile /var/log/conserver; timestamp 1hab; include full; master localhost; } default console01 { include opengear; host console01; } console dr01.arista { include console01; port 1; } console dr02.arista { include console01; port 2; } when I change the portbase to be telnet (6000) it works fine so I know conserver is at least running correctly in the back. Has anyone gotten this to work using ssh? thanks -- brandon --001a11332dfcdc21f504f790d80e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
hello, I am trying to use conserver to connect to ser= ial ports over ssh and it is hanging. When I go direct it works fine (i am = using Opengear IMX4248):

[bstout@lab etc]$ ssh root@172.24.19.40 -p 3002
Password:=C2=A0
cs02 login:=C2=A0
cs02 login:=C2= =A0


from console it just hangs:
[bstout@akebia etc]$ console dr01.arista
[Enter `^Ec?'= for help]


this is the only thing that shows up in = the log file

[Mon Apr 21 10:19:25 2014] conserver = (29839): [dr01.arista] login bstout@localhost
[-- bstout@localhos= t attached -- Mon Apr 21 10:19:25 2014]



this is the conserver.cf file

default f= ull { rw *; }
d= efault opengear =C2=A0{ type host; portbase 3000; portinc 1; }=C2=A0
default * {
logfile /var/log/conserver;
timestamp 1hab;
include full;
master localhost;
}
default console01 { include opengear; host console01; = }
console dr01.arista { include console01; port 1; }
co= nsole dr02.arista { include console01; port 2; }

when I change the portbase to be telnet (6000) it works= fine so I know conserver is at least running correctly in the back.=C2=A0<= /div>

Has anyone gotten this to work using ssh?

thanks

--

brandon
--001a11332dfcdc21f504f790d80e-- From nstraz@redhat.com Mon Apr 21 17:39:21 2014 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by underdog.stansell.org (8.14.7/8.14.7) with ESMTP id s3LHdJvo016044 for ; Mon, 21 Apr 2014 17:39:21 GMT Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3LHdJC8007700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 21 Apr 2014 13:39:19 -0400 Received: from tin.rawstew (ovpn-113-159.phx2.redhat.com [10.3.113.159]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id s3LHdHm7005465 for ; Mon, 21 Apr 2014 13:39:18 -0400 Received: by tin.rawstew (sSMTP sendmail emulation); Mon, 21 Apr 2014 13:39:17 -0400 From: "Nathan Straz" Date: Mon, 21 Apr 2014 13:39:17 -0400 To: users@conserver.com Subject: Re: Conserver and ssh Message-ID: <20140421173917.GB9600@redhat.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Spam-Score: -2.551 () BAYES_00,RP_MATCHES_RCVD X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.16 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 17:39:21 -0000 On Apr 21 10:29, Brandon Stout wrote: > hello, I am trying to use conserver to connect to serial ports over ssh and > it is hanging. When I go direct it works fine (i am using Opengear IMX4248): > > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002 ... > default full { rw *; } > default opengear { type host; portbase 3000; portinc 1; } > default * { > logfile /var/log/conserver; > timestamp 1hab; > include full; > master localhost; > } > default console01 { include opengear; host console01; } > console dr01.arista { include console01; port 1; } > console dr02.arista { include console01; port 2; } ... > Has anyone gotten this to work using ssh? I think you need to use the exec host type and setup the right execsubst to get ssh to use the right port number. The "host" type is just a raw TCP socket connection. Nate From bstout@squareup.com Mon Apr 21 18:26:50 2014 Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by underdog.stansell.org (8.14.7/8.14.7) with ESMTP id s3LIQl6v020805 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Apr 2014 18:26:49 GMT Received: by mail-pa0-f41.google.com with SMTP id fa1so4028804pad.28 for ; Mon, 21 Apr 2014 11:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=squareup.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VIK2xflPuwxNMQuz77eJtyN3Djqx+q23cJdga3XO7B8=; b=bwDvYkbYEoHFKNHlj5ZqLGIwdjIwhFiGn+1clK9j6pevu6AE0NBD30435Ys6Pg4yxD g5g6bRUqITlYB0QBhHoL1+/PMGU2pOzl6gtRCtPEXoRM5F6I0jpUAkNSK9hrOICjc7+y 9ZyWbznng3nlXylIPnxGKEBunrw/Wdq1DWpRM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VIK2xflPuwxNMQuz77eJtyN3Djqx+q23cJdga3XO7B8=; b=BGI9oegCzv9ODydgxeVPAKsvgGM3BwPib7I/QBwQ/K+ieTwQYc7Bu1KKa/XhlPv0H4 OYn9DM/RjpytPXEW9kCaqwTXhHWDnDpv2PFO+rHzvWLI/FywzZC7E1vUEB8oQXhL1ieA GpxtPerSRqKM5LOPzhYwPEBU77rhI7PtBnDozwEv5dVgwonVZjQp30b3bPu6TQbActUk 1uSIgFWVBpn505QkVvgs6rbygAsc/sR9DO71Z6IFZHVUm0gfI3Q8imIB4SG2TIlfCM8v ZDxnCHJDluIqNjCKo2lVQmUA5TCX/27W6qqG577NvgYHAyyqFl9tyI6mdO/6aCBQOqrr 1c8g== X-Gm-Message-State: ALoCoQlg36XBOY2rPr3CCy8zoAPqLa8eNARMH0TXIxnmFKcsRGOs+dxXv3VQOVjXW8e9MA1Flczc MIME-Version: 1.0 X-Received: by 10.68.171.4 with SMTP id aq4mr4470433pbc.150.1398104806101; Mon, 21 Apr 2014 11:26:46 -0700 (PDT) Received: by 10.70.30.228 with HTTP; Mon, 21 Apr 2014 11:26:46 -0700 (PDT) In-Reply-To: <20140421173917.GB9600@redhat.com> References: <20140421173917.GB9600@redhat.com> Date: Mon, 21 Apr 2014 11:26:46 -0700 Message-ID: Subject: Re: Conserver and ssh From: Brandon Stout To: Nathan Straz Content-Type: multipart/alternative; boundary=047d7bacbb4853a3c204f791a404 X-Spam-Score: -1.489 () BAYES_00,HTML_MESSAGE,T_DKIM_INVALID X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 Cc: users@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.16 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 18:26:50 -0000 --047d7bacbb4853a3c204f791a404 Content-Type: text/plain; charset=UTF-8 thanks Nathan, I actually was trying that right after I sent this email and added this default opengear-ssh { type exec; portbase 2000; portinc 1; exec /usr/bin/ssh -p P -l tsuser H; execsubst H=hs,P=Pd; } still not working though with just about nothing useful in the logs. Doesn't hang but it still doesn't work. Just empty space and no output. On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz wrote: > On Apr 21 10:29, Brandon Stout wrote: > > hello, I am trying to use conserver to connect to serial ports over ssh > and > > it is hanging. When I go direct it works fine (i am using Opengear > IMX4248): > > > > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002 > ... > > default full { rw *; } > > default opengear { type host; portbase 3000; portinc 1; } > > default * { > > logfile /var/log/conserver; > > timestamp 1hab; > > include full; > > master localhost; > > } > > default console01 { include opengear; host console01; } > > console dr01.arista { include console01; port 1; } > > console dr02.arista { include console01; port 2; } > ... > > Has anyone gotten this to work using ssh? > > I think you need to use the exec host type and setup the right execsubst > to get ssh to use the right port number. The "host" type is just a raw > TCP socket connection. > > Nate > _______________________________________________ > users mailing list > users@conserver.com > https://www.conserver.com/mailman/listinfo/users > -- brandon --047d7bacbb4853a3c204f791a404 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
thanks Nathan, I actually was trying that right after I se= nt this email and added this

default opengear-ssh {= type exec; portbase 2000; portinc 1;
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0exec /usr/bin/ssh -p P -l tsuser = H;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e= xecsubst H=3Dhs,P=3DPd; }

still not working = though with just about nothing useful in the logs. Doesn't hang but it = still doesn't work. Just empty space and no output.=C2=A0


On Mon,= Apr 21, 2014 at 10:39 AM, Nathan Straz <nstraz@redhat.com> = wrote:
On Apr 21 10:29, Brandon Sto= ut wrote:
> hello, I am trying to use conserver to connect to serial ports over ss= h and
> it is hanging. When I go direct it works fine (i am using Opengear IMX= 4248):
>
> [bstout@lab etc]$ ssh root@172.24= .19.40 -p 3002
...
> default full { rw *; }
> default opengear =C2=A0{ type host; portbase 3000; portinc 1; }
> default * {
> logfile /var/log/conserver;
> timestamp 1hab;
> include full;
> master localhost;
> }
> default console01 { include opengear; host console01; }
> console dr01.arista { include console01; port 1; }
> console dr02.arista { include console01; port 2; }
...
> Has anyone gotten this to work using ssh?

I think you need to use the exec host type and setup the right execsu= bst
to get ssh to use the right port number. =C2=A0The "host" type is= just a raw
TCP socket connection.

Nate
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users



--

bra= ndon
--047d7bacbb4853a3c204f791a404-- From consoleteam@gmail.com Mon Apr 21 18:31:21 2014 Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by underdog.stansell.org (8.14.7/8.14.7) with ESMTP id s3LIVJSO021266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Apr 2014 18:31:21 GMT Received: by mail-ie0-f181.google.com with SMTP id tp5so4027535ieb.26 for ; Mon, 21 Apr 2014 11:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pu7C6/Nr6PmZpxu17CHGuOB4gbamp6Z53QvEBTZQXDI=; b=woAE0t7T/lzZiMJ0xnaAQBmwceGrBL6N/PRQVpl9xsG9uVzbNduymAYpZtSggigPNF mOjTT3d2J3pfXIfO8VWdZewYS0tz/CgsSTXp3Q6VQWsckqhRTy9WcxM3WV9rgE/HuFxJ yvGTRg7zc+9u1sX87rgHk4znNghYQhX93g+MzW8Ym/nFaoYjynYiKskJ2ruKARpWuexr MEPAeC+4UwSldkqabrBhF0ChZm9QC9E07/duDANx6leWy4kFgXfdmQeCt2Yd3w9HKnc2 l1+l+bSzMwuuH1CSrOh5zAjaYdI4rT4hWDc6jgHV4JA88UXhnVrKPCxw856uOWG0v9Rn WfxA== MIME-Version: 1.0 X-Received: by 10.43.145.137 with SMTP id ju9mr32334914icc.36.1398105078691; Mon, 21 Apr 2014 11:31:18 -0700 (PDT) Received: by 10.43.56.74 with HTTP; Mon, 21 Apr 2014 11:31:18 -0700 (PDT) In-Reply-To: References: <20140421173917.GB9600@redhat.com> Date: Mon, 21 Apr 2014 11:31:18 -0700 Message-ID: Subject: Re: Conserver and ssh From: Zonker To: Brandon Stout Content-Type: multipart/alternative; boundary=001a11c2e2b893005704f791b4fb X-Spam-Score: -1.488 () BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,T_DKIM_INVALID X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 Cc: "users@conserver.com" X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.16 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 18:31:21 -0000 --001a11c2e2b893005704f791b4fb Content-Type: text/plain; charset=UTF-8 OK... but base 2000 is telnet (with authentication) versus the ssh that you had tried... is your IM set up to listen on telnet (versus the unauthenticated telnet on base 6000)? What do you see in the logs on the IM" Failed connections, I'd guess... -Z- On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout wrote: > thanks Nathan, I actually was trying that right after I sent this email > and added this > > default opengear-ssh { type exec; portbase 2000; portinc 1; > exec /usr/bin/ssh -p P -l tsuser H; > execsubst H=hs,P=Pd; } > > still not working though with just about nothing useful in the logs. > Doesn't hang but it still doesn't work. Just empty space and no output. > > > On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz wrote: > >> On Apr 21 10:29, Brandon Stout wrote: >> > hello, I am trying to use conserver to connect to serial ports over ssh >> and >> > it is hanging. When I go direct it works fine (i am using Opengear >> IMX4248): >> > >> > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002 >> ... >> > default full { rw *; } >> > default opengear { type host; portbase 3000; portinc 1; } >> > default * { >> > logfile /var/log/conserver; >> > timestamp 1hab; >> > include full; >> > master localhost; >> > } >> > default console01 { include opengear; host console01; } >> > console dr01.arista { include console01; port 1; } >> > console dr02.arista { include console01; port 2; } >> ... >> > Has anyone gotten this to work using ssh? >> >> I think you need to use the exec host type and setup the right execsubst >> to get ssh to use the right port number. The "host" type is just a raw >> TCP socket connection. >> >> Nate >> _______________________________________________ >> users mailing list >> users@conserver.com >> https://www.conserver.com/mailman/listinfo/users >> > > > > -- > > brandon > > _______________________________________________ > users mailing list > users@conserver.com > https://www.conserver.com/mailman/listinfo/users > > -- Sent from my new iPhone 6 Watch (prototype), see my reviews here! www.conserver.com/consoles/ -- consoleteam.blogspot.com - - - - - - - - www.ncry.org www.d4tm.org www.hackerdojo.com --001a11c2e2b893005704f791b4fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK... but base 2000 is telnet (with authentica= tion) versus the ssh that you had tried... is your IM set up to listen on t= elnet (versus the unauthenticated telnet on base 6000)?

What do you see in the logs on the IM" Failed co= nnections, I'd guess...

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 -Z-




On Mon, Apr 21, 2014 at 11:26 AM, Brand= on Stout <bstout@squareup.com> wrote:
thanks Nathan, I actually w= as trying that right after I sent this email and added this

<= div>
default opengear-ssh { type exec; portbase 2000; portinc 1;
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0exec /= usr/bin/ssh -p P -l tsuser H;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e= xecsubst H=3Dhs,P=3DPd; }

still not working = though with just about nothing useful in the logs. Doesn't hang but it = still doesn't work. Just empty space and no output.=C2=A0


On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz <nstraz@= redhat.com> wrote:
On Apr 21 10:29, Brandon Stout wrote: > hello, I am trying to use conserver to connect to serial ports over ss= h and
> it is hanging. When I go direct it works fine (i am using Opengear IMX= 4248):
>
> [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002
...
> default full { rw *; }
> default opengear =C2=A0{ type host; portbase 3000; portinc 1; }
> default * {
> logfile /var/log/conserver;
> timestamp 1hab;
> include full;
> master localhost;
> }
> default console01 { include opengear; host console01; }
> console dr01.arista { include console01; port 1; }
> console dr02.arista { include console01; port 2; }
...
> Has anyone gotten this to work using ssh?

I think you need to use the exec host type and setup the right execsu= bst
to get ssh to use the right port number. =C2=A0The "host" type is= just a raw
TCP socket connection.

Nate
_______________________________________________
users mailing list
users@conserver.co= m
https://www.conserver.com/mailman/listinfo/users



--

brandon

_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users




--
Se= nt from my new iPhone 6 Watch (prototype), see my reviews here!
www.conserver.com= /consoles/ -- consoleteam.blogspot.com
- - - - - - - -
www.n= cry.org
www.d4tm.o= rg
www.hacke= rdojo.com
--001a11c2e2b893005704f791b4fb-- From bstout@squareup.com Mon Apr 21 18:32:25 2014 Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) by underdog.stansell.org (8.14.7/8.14.7) with ESMTP id s3LIWN65021401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Apr 2014 18:32:25 GMT Received: by mail-pd0-f180.google.com with SMTP id v10so3973817pde.11 for ; Mon, 21 Apr 2014 11:32:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=squareup.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NnTUFpEMMtnCNVlH4DfsMNKgn32ObGVd2Y15B+uFMEk=; b=EyTiD9RDzd1mAzA3yJ8PgXbX4ubeYJpATAKVHeZa32YgEyyrJxjNtxdCrtpCb2qmeU iAepaSCJm4LNqX262jSCVDdp/0uGML5RGGVvxzcq+7f1v/REmPWjHcKMdAcMCWL+tAU0 fNmdVsZbrh4IhDCnwHy3d5XlpztfpUB4ctH4I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NnTUFpEMMtnCNVlH4DfsMNKgn32ObGVd2Y15B+uFMEk=; b=HYDzWd1X/dc/7JUZb50H7D49G+0fW2gjskmW5IPMMiW79vhuwZcrTNpKfQ3YMj6PPq 6c7lxDAsvHMnsGg/fCw4TLtbzaRI4RA8rQ4i/EXTM1vJc+E6P07sG2M+xpYsJfa/+fCl D/RDup89CWekUlKNAYn67lDNtG5QhT5O2DjPe+TLKOCKZ/UBn7dqHt6dgOwjVtZ75O2c Vxo5ebPwFCHBLKZ0SFUp14VyXmAju6g03dNYzNXtvwO0PpLTSCVk1fhEWZJ4VVMVxH0D nODauzDL9XbfK5fKW/ByvEOYrgZXNCi1lioLQzbZ65c43NaSKcW4su1ebNE2KM2fEGTT ypcQ== X-Gm-Message-State: ALoCoQns+4TIZyWbc0WPed3HF19bdydrlR37n8BCKjrT6uxRdsdRNsVpM2+vS99WrnQUNpWFYYk3 MIME-Version: 1.0 X-Received: by 10.68.170.66 with SMTP id ak2mr39766207pbc.5.1398105143394; Mon, 21 Apr 2014 11:32:23 -0700 (PDT) Received: by 10.70.30.228 with HTTP; Mon, 21 Apr 2014 11:32:23 -0700 (PDT) In-Reply-To: References: <20140421173917.GB9600@redhat.com> Date: Mon, 21 Apr 2014 11:32:23 -0700 Message-ID: Subject: Re: Conserver and ssh From: Brandon Stout To: Nathan Straz Content-Type: multipart/alternative; boundary=047d7b86d55c6e521904f791b804 X-Spam-Score: -1.489 () BAYES_00,HTML_MESSAGE,T_DKIM_INVALID X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 Cc: users@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.16 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 18:32:26 -0000 --047d7b86d55c6e521904f791b804 Content-Type: text/plain; charset=UTF-8 So I actually figured out the problem so now it connects, I get the password prompt and when I enter it correctly it works. The problem is that when I disconnect and reconnect, it no longer asks me for a password and just puts me through to the console. is there some sort of disconnect I need to do manually to get it to reset and ask for a password? Seems like it just stays connected once the pw is entered, regardless of someone exiting. On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout wrote: > thanks Nathan, I actually was trying that right after I sent this email > and added this > > default opengear-ssh { type exec; portbase 2000; portinc 1; > exec /usr/bin/ssh -p P -l tsuser H; > execsubst H=hs,P=Pd; } > > still not working though with just about nothing useful in the logs. > Doesn't hang but it still doesn't work. Just empty space and no output. > > > On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz wrote: > >> On Apr 21 10:29, Brandon Stout wrote: >> > hello, I am trying to use conserver to connect to serial ports over ssh >> and >> > it is hanging. When I go direct it works fine (i am using Opengear >> IMX4248): >> > >> > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002 >> ... >> > default full { rw *; } >> > default opengear { type host; portbase 3000; portinc 1; } >> > default * { >> > logfile /var/log/conserver; >> > timestamp 1hab; >> > include full; >> > master localhost; >> > } >> > default console01 { include opengear; host console01; } >> > console dr01.arista { include console01; port 1; } >> > console dr02.arista { include console01; port 2; } >> ... >> > Has anyone gotten this to work using ssh? >> >> I think you need to use the exec host type and setup the right execsubst >> to get ssh to use the right port number. The "host" type is just a raw >> TCP socket connection. >> >> Nate >> _______________________________________________ >> users mailing list >> users@conserver.com >> https://www.conserver.com/mailman/listinfo/users >> > > > > -- > > brandon > -- brandon --047d7b86d55c6e521904f791b804 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So I actually figured out the problem so now it connects, = I get the password prompt and when I enter it correctly it works. The probl= em is that when I disconnect and reconnect, it no longer asks me for a pass= word and just puts me through to the console. is there some sort of disconn= ect I need to do manually to get it to reset and ask for a password? Seems = like it just stays connected once the pw is entered, regardless of someone = exiting.


On Mon, Apr 2= 1, 2014 at 11:26 AM, Brandon Stout <bstout@squareup.com> w= rote:
thanks Nathan, I actually w= as trying that right after I sent this email and added this

<= div>
default opengear-ssh { type exec; portbase 2000; portinc 1;
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0exec /= usr/bin/ssh -p P -l tsuser H;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e= xecsubst H=3Dhs,P=3DPd; }

still not working = though with just about nothing useful in the logs. Doesn't hang but it = still doesn't work. Just empty space and no output.=C2=A0


On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz <nstraz@= redhat.com> wrote:
On Apr 21 10:29, Brandon Stout wrote: > hello, I am trying to use conserver to connect to serial ports over ss= h and
> it is hanging. When I go direct it works fine (i am using Opengear IMX= 4248):
>
> [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002
...
> default full { rw *; }
> default opengear =C2=A0{ type host; portbase 3000; portinc 1; }
> default * {
> logfile /var/log/conserver;
> timestamp 1hab;
> include full;
> master localhost;
> }
> default console01 { include opengear; host console01; }
> console dr01.arista { include console01; port 1; }
> console dr02.arista { include console01; port 2; }
...
> Has anyone gotten this to work using ssh?

I think you need to use the exec host type and setup the right execsu= bst
to get ssh to use the right port number. =C2=A0The "host" type is= just a raw
TCP socket connection.

Nate
_______________________________________________
users mailing list
users@conserver.co= m
https://www.conserver.com/mailman/listinfo/users



--

brandon



--

bra= ndon
--047d7b86d55c6e521904f791b804-- From bstout@squareup.com Mon Apr 21 18:38:38 2014 Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by underdog.stansell.org (8.14.7/8.14.7) with ESMTP id s3LIcasS022106 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Apr 2014 18:38:38 GMT Received: by mail-pa0-f48.google.com with SMTP id hz1so3998674pad.21 for ; Mon, 21 Apr 2014 11:38:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=squareup.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7wvNV8MNsN3Ap2LU9DgSLG2Gwyi+d4O7LvhrMjMD3jw=; b=O4f93bXk9G9sic+W2mqZzkG3dQVDOavnbOJ1KD6gC+rf7jrf1w6KdNrpVv96gFfnBy L6eYMw5oS4nVH70DNt+JJQKxrkkzPDCiGZo2PF2Ho2rNAa+L62jgkosbllJX7zp85ErJ HQLyRHiEU59V2J7kls1tNru44o7qV504MG32U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7wvNV8MNsN3Ap2LU9DgSLG2Gwyi+d4O7LvhrMjMD3jw=; b=Mlqv/yLNhbzzRpHrmPjULwZKclMYb5PXuSJ+rK5Hb0pL/HA0OOkSrTpBJQWCcUljbQ JAGwM3QEOzoB5NT+4qMqY9J4rwEc1l5EkXYxqxy08I89QVzDQuY1nsrRFXyKd6RwFdNg w/kTrmHkCYGLdo17uGARKsgMt+ujHpE0lswOz+aAfuEDsINH9ad99tF2fDMBO83eGKsD vXmLDVWYWf6dl4mwmWvTw+553GhqFRMqI4/3WW/nYa4+6SpzVFOQbYuHds9iNc4hsJdm 3162D1nihwrUlpO/2l09mGldddEVbiiHwhTWayJQNuYswzEMAlmmNtacrA0kRPaKG1ks qRKw== X-Gm-Message-State: ALoCoQlDxjX6cjgUn5QQStqO6LO4ddFi5mxNnDFrK9PjMsClRxrzIVYQmnBvF/L1rNoagVF/Bfpd MIME-Version: 1.0 X-Received: by 10.68.143.231 with SMTP id sh7mr39877551pbb.7.1398105516113; Mon, 21 Apr 2014 11:38:36 -0700 (PDT) Received: by 10.70.30.228 with HTTP; Mon, 21 Apr 2014 11:38:36 -0700 (PDT) In-Reply-To: References: <20140421173917.GB9600@redhat.com> Date: Mon, 21 Apr 2014 11:38:36 -0700 Message-ID: Subject: Re: Conserver and ssh From: Brandon Stout To: Nathan Straz Content-Type: multipart/alternative; boundary=047d7b2e43d6a58e5204f791cedd X-Spam-Score: -1.489 () BAYES_00,HTML_MESSAGE,T_DKIM_INVALID X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 Cc: users@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.16 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 18:38:38 -0000 --047d7b2e43d6a58e5204f791cedd Content-Type: text/plain; charset=UTF-8 Also, how does the conserver.passwd work? When does it use that rather than the authentication on the Opengear itself? To test, I have the same user on the Opengear as well as in the conserver.passwd with different passwords to see where it gets its passwords from. So far it just looks like it is using the password from the Opengear. I configured conserver with all the defaults so I am assuming conserver.passwd just needs to exist within the same directory as conserver.cf. Did I configure something incorrectly or does there need to be a line in the conserver.cf file to point to where conserver.passwd exists? On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout wrote: > So I actually figured out the problem so now it connects, I get the > password prompt and when I enter it correctly it works. The problem is that > when I disconnect and reconnect, it no longer asks me for a password and > just puts me through to the console. is there some sort of disconnect I > need to do manually to get it to reset and ask for a password? Seems like > it just stays connected once the pw is entered, regardless of someone > exiting. > > > On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout wrote: > >> thanks Nathan, I actually was trying that right after I sent this email >> and added this >> >> default opengear-ssh { type exec; portbase 2000; portinc 1; >> exec /usr/bin/ssh -p P -l tsuser H; >> execsubst H=hs,P=Pd; } >> >> still not working though with just about nothing useful in the logs. >> Doesn't hang but it still doesn't work. Just empty space and no output. >> >> >> On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz wrote: >> >>> On Apr 21 10:29, Brandon Stout wrote: >>> > hello, I am trying to use conserver to connect to serial ports over >>> ssh and >>> > it is hanging. When I go direct it works fine (i am using Opengear >>> IMX4248): >>> > >>> > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002 >>> ... >>> > default full { rw *; } >>> > default opengear { type host; portbase 3000; portinc 1; } >>> > default * { >>> > logfile /var/log/conserver; >>> > timestamp 1hab; >>> > include full; >>> > master localhost; >>> > } >>> > default console01 { include opengear; host console01; } >>> > console dr01.arista { include console01; port 1; } >>> > console dr02.arista { include console01; port 2; } >>> ... >>> > Has anyone gotten this to work using ssh? >>> >>> I think you need to use the exec host type and setup the right execsubst >>> to get ssh to use the right port number. The "host" type is just a raw >>> TCP socket connection. >>> >>> Nate >>> _______________________________________________ >>> users mailing list >>> users@conserver.com >>> https://www.conserver.com/mailman/listinfo/users >>> >> >> >> >> -- >> >> brandon >> > > > > -- > > brandon > -- brandon --047d7b2e43d6a58e5204f791cedd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Also, how does the conserver.passwd work? When does it use= that rather than the authentication on the Opengear itself? To test, I hav= e the same user on the Opengear as well as in the conserver.passwd with dif= ferent passwords to see where it gets its passwords from. So far it just lo= oks like it is using the password from the Opengear. I configured conserver= with all the defaults so I am assuming conserver.passwd just needs to exis= t within the same directory as conserver.cf= . Did I configure something incorrectly or does there need to be a line= in the conserver.cf file to point to w= here conserver.passwd exists?


On Mon, Apr 2= 1, 2014 at 11:32 AM, Brandon Stout <bstout@squareup.com> w= rote:
So I actually figured out t= he problem so now it connects, I get the password prompt and when I enter i= t correctly it works. The problem is that when I disconnect and reconnect, = it no longer asks me for a password and just puts me through to the console= . is there some sort of disconnect I need to do manually to get it to reset= and ask for a password? Seems like it just stays connected once the pw is = entered, regardless of someone exiting.


On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout <bstout@squareup.com<= /a>> wrote:
thanks Nathan, I actually was trying that right after I sent this email a= nd added this

default opengear-ssh { type exec; portbase 2000; portinc 1;
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0exec /= usr/bin/ssh -p P -l tsuser H;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e= xecsubst H=3Dhs,P=3DPd; }

still not working = though with just about nothing useful in the logs. Doesn't hang but it = still doesn't work. Just empty space and no output.=C2=A0


On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz <nstraz@redhat.com&g= t; wrote:
On Apr 21 10:29, Brandon Stout wrote: > hello, I am trying to use conserver to connect to serial ports over ss= h and
> it is hanging. When I go direct it works fine (i am using Opengear IMX= 4248):
>
> [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002
...
> default full { rw *; }
> default opengear =C2=A0{ type host; portbase 3000; portinc 1; }
> default * {
> logfile /var/log/conserver;
> timestamp 1hab;
> include full;
> master localhost;
> }
> default console01 { include opengear; host console01; }
> console dr01.arista { include console01; port 1; }
> console dr02.arista { include console01; port 2; }
...
> Has anyone gotten this to work using ssh?

I think you need to use the exec host type and setup the right execsu= bst
to get ssh to use the right port number. =C2=A0The "host" type is= just a raw
TCP socket connection.

Nate
_______________________________________________
users mailing list
users@conserver.co= m
https://www.conserver.com/mailman/listinfo/users



<= font color=3D"#888888">--

brandon



--

brandon



--

bra= ndon
--047d7b2e43d6a58e5204f791cedd-- From cross+conserver@distal.com Mon Apr 21 19:15:16 2014 Received: from hydra.pix.net (hydra.pix.net [71.178.232.4]) by underdog.stansell.org (8.14.7/8.14.7) with ESMTP id s3LJFA4X026454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Apr 2014 19:15:15 GMT Received: from mail.distal.com (mail.distal.com [IPv6:2001:470:e24c:200::ae25]) (authenticated bits=0) by hydra.pix.net (8.14.5/8.14.5) with ESMTP id s3LJF12N094531; Mon, 21 Apr 2014 15:15:09 -0400 (EDT) (envelope-from cross+conserver@distal.com) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98 at mail.pix.net Received: from zalamar.mm-corp.net ([65.207.51.176]) (authenticated bits=0) by mail.distal.com (8.14.8/8.14.8) with ESMTP id s3LJDdWC060469 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 Apr 2014 15:13:40 -0400 (EDT) (envelope-from cross+conserver@distal.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Conserver and ssh From: Chris Ross In-Reply-To: Date: Mon, 21 Apr 2014 15:13:16 -0400 Message-Id: <60CDA197-F0A1-4291-916B-E6E45713D15C@distal.com> References: <20140421173917.GB9600@redhat.com> To: Brandon Stout X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.distal.com [206.138.151.250]); Mon, 21 Apr 2014 15:13:40 -0400 (EDT) X-Spam-Score: -1.5 () BAYES_00 X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by underdog.stansell.org id s3LJFA4X026454 Cc: users@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.16 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 19:15:16 -0000 “Your milage may vary”, but for myself, I’m consoling UNIX servers, so I want their console output to be logged even when noone is connected. To accomplish this, I have a script that will log into the session for me upon initialization of the console, and then stay attached. As you’ve determined, conserver leaves the TCP connection active, so you don’t need to authenticate against the ssh connection again after the initial connection. I suspect you’re not getting it to use the local/conserver password at all, or else when you first start up, you’d have to enter both, in the correct sequence. One to connect to the established ssh command, then another to ssh to authenticate the network connection. So, I guess you need to decide whether you want to have the connection drop and reestablish, which is what you seemed to be asking for, or rather want just to get the conserver password prompting working, which I’m not doing, so can’t help with directly. Thoughts and information that I hope is helpful. - Chris On Apr 21, 2014, at 14:38, Brandon Stout wrote: > Also, how does the conserver.passwd work? When does it use that rather than the authentication on the Opengear itself? To test, I have the same user on the Opengear as well as in the conserver.passwd with different passwords to see where it gets its passwords from. So far it just looks like it is using the password from the Opengear. I configured conserver with all the defaults so I am assuming conserver.passwd just needs to exist within the same directory as conserver.cf. Did I configure something incorrectly or does there need to be a line in the conserver.cf file to point to where conserver.passwd exists? > > > On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout wrote: > So I actually figured out the problem so now it connects, I get the password prompt and when I enter it correctly it works. The problem is that when I disconnect and reconnect, it no longer asks me for a password and just puts me through to the console. is there some sort of disconnect I need to do manually to get it to reset and ask for a password? Seems like it just stays connected once the pw is entered, regardless of someone exiting. > > > On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout wrote: > thanks Nathan, I actually was trying that right after I sent this email and added this > > default opengear-ssh { type exec; portbase 2000; portinc 1; > exec /usr/bin/ssh -p P -l tsuser H; > execsubst H=hs,P=Pd; } > > still not working though with just about nothing useful in the logs. Doesn't hang but it still doesn't work. Just empty space and no output. > > > On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz wrote: > On Apr 21 10:29, Brandon Stout wrote: > > hello, I am trying to use conserver to connect to serial ports over ssh and > > it is hanging. When I go direct it works fine (i am using Opengear IMX4248): > > > > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002 > ... > > default full { rw *; } > > default opengear { type host; portbase 3000; portinc 1; } > > default * { > > logfile /var/log/conserver; > > timestamp 1hab; > > include full; > > master localhost; > > } > > default console01 { include opengear; host console01; } > > console dr01.arista { include console01; port 1; } > > console dr02.arista { include console01; port 2; } > ... > > Has anyone gotten this to work using ssh? > > I think you need to use the exec host type and setup the right execsubst > to get ssh to use the right port number. The "host" type is just a raw > TCP socket connection. > > Nate > _______________________________________________ > users mailing list > users@conserver.com > https://www.conserver.com/mailman/listinfo/users > > > > -- > > brandon > > > > -- > > brandon > > > > -- > > brandon > _______________________________________________ > users mailing list > users@conserver.com > https://www.conserver.com/mailman/listinfo/users From mmamaenko@yahoo.com Mon Apr 21 19:18:12 2014 Received: from nm10-vm5.bullet.mail.ne1.yahoo.com (nm10-vm5.bullet.mail.ne1.yahoo.com [98.138.91.232]) by underdog.stansell.org (8.14.7/8.14.7) with ESMTP id s3LJIA7Q026723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Apr 2014 19:18:12 GMT Received: from [98.138.101.130] by nm10.bullet.mail.ne1.yahoo.com with NNFMP; 21 Apr 2014 19:18:09 -0000 Received: from [98.138.88.236] by tm18.bullet.mail.ne1.yahoo.com with NNFMP; 21 Apr 2014 19:18:09 -0000 Received: from [127.0.0.1] by omp1036.mail.ne1.yahoo.com with NNFMP; 21 Apr 2014 19:18:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 743217.79043.bm@omp1036.mail.ne1.yahoo.com Received: (qmail 90889 invoked by uid 60001); 21 Apr 2014 19:18:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398107889; bh=OQ/ZdvMSo9bkZxzEkE7LHSnnvTB85LsapsSaNTsz+lA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=tMyilR07FzUKcMMJlgaBpoqNIu2nOzRyM8mtPN4EnY3sM+w97Frm0Q72gMoShJGpvYvor1dj19kvn8ReuUMwk4aNyFpNaucSLJ7u7OJNf+VCFxo0NBl3Tfv9T7U87EoPwpLhh1I7FjP1HNyT/EmqQa2kBtaZhnie/KbFguUqbaQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=HWlDKYanASR8T1+RgyFYnT0bEmWzJKjjGlLsfVgP2JZKoNsdqerxZCXtpzbYOk4CFlfdxW/Y2r2H2PIeli+K6chsUQ/j6wy6h4IwnLuZGz4GfJQzeFH9tQVFGyfgFXb3SIehclYAILI1Cqvw0X6XYijYVS0OHxCItoScF2Ngqkg=; X-YMail-OSG: iuDtdvgVM1kpWEesNbO7qqTKN95031KWIYcdbGPFfPycZnv FJJIHmlIo2eop6ZBdx8tYEv.uEAsClbK8CkXL8WKJa3cFNQDtuycDf03iuNN ggYrcz6GBQWU1vVjKHLMtMcuBZUBh94g.aqE9UyLqUFXBjzv750UZ3DFJ8p6 OeC2EknOlDjaVAZOIrBYR7Yyyc8ROp7a0LOgrm0I22nR_DHksVYqDwEk4_2d eqxpIHINsQKKcwnt48tHXjxg_Ke64.2GYpocYI3C5knLvbQLYNdSpMTSNaQO mxMurE3sj4Kit.zRz1JNvGXGsXi4mAvu6yS5kNdRiQVEm0l.97x1FuIpAypB 1S7a8vZMCXheTIb2Z1i8zh10xpJxoolZ_sMkVU53I83XFaNak8lyhkCib8Mh zDtk2Z9vYlP.iftpxJYVRXMAt1oYBdRTrrRRfVb_Ni03J7ZuMGXF3wx5zs9a zv9kfx9Z8ufheYw5iwklNkWhwup5xZ6mcM5kd3Cx0et8hNJIEWyd6Cjs6pbg _ifDBsTByfkFVop3r555L9t65oOddRrYs5GMJhyOaIuvcxfAtuJo- Received: from [15.203.233.79] by web121003.mail.ne1.yahoo.com via HTTP; Mon, 21 Apr 2014 12:18:09 PDT X-Rocket-MIMEInfo: 002.001, SSB1c2UgdGhpcyBjb25maWcgaW4gb3JkZXIgdG8gYWNjZXNzIHNlcmlhbCBjYWJsZSBhdHRhY2hlZCB0byBzZXJpYWwydXNiIGFkYXB0ZXIgb24gbXkgY29uc2VydmVyIHNlcnZlcjoKZGVmYXVsdCAqIHsKwqDCoMKgwqDCoMKgwqAgIyBUaGUgJyYnIGNoYXJhY3RlciBpcyBzdWJzdGl0dXRlZCB3aXRoIHRoZSBjb25zb2xlIG5hbWUKwqDCoMKgwqDCoMKgwqAgbG9nZmlsZSAvdmFyL2NvbnNvbGVzLyY7CsKgwqDCoMKgwqDCoMKgIHJ3IHN5c2FkbWluO8KgICMgdXNlIHRoZSBncm91cCBkZWZpbmVkIGFib3ZlCgEwAQEBAQ-- X-Mailer: YahooMailWebService/0.8.185.657 Message-ID: <1398107889.4971.YahooMailNeo@web121003.mail.ne1.yahoo.com> Date: Mon, 21 Apr 2014 12:18:09 -0700 (PDT) From: mikhail mamaenko Subject: Unable to see console output To: "users@conserver.com" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-2027350018-225328108-1398107889=:4971" X-Spam-Score: -2.539 () BAYES_00, FREEMAIL_FROM, HTML_MESSAGE, RP_MATCHES_RCVD, T_DKIM_INVALID X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.16 Precedence: list Reply-To: mikhail mamaenko List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 19:18:12 -0000 ---2027350018-225328108-1398107889=:4971 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I use this config in order to access serial cable attached to serial2usb ad= apter on my conserver server:=0Adefault * {=0A=A0=A0=A0=A0=A0=A0=A0 # The '= &' character is substituted with the console name=0A=A0=A0=A0=A0=A0=A0=A0 l= ogfile /var/consoles/&;=0A=A0=A0=A0=A0=A0=A0=A0 rw sysadmin;=A0 # use the g= roup defined above=0A=A0=A0=A0=A0=A0=A0=A0 master localhost;=0A}=0A=0Adefau= lt usb2serial {=0A=A0=A0=A0=A0=A0=A0=A0 type device;=0A=A0=A0=A0=A0=A0=A0= =A0 device /dev/ttyUSB.;=0A=A0=A0=A0=A0=A0=A0=A0 devicesubst .=3DPd;=0A=A0= =A0=A0=A0=A0=A0=A0 portbase -1;=0A=A0=A0=A0=A0=A0=A0=A0 portinc 1;=0A=A0=A0= =A0=A0=A0=A0=A0 host none;=0A=A0=A0=A0=A0=A0=A0=A0 baud 9600;=0A=A0=A0=A0= =A0=A0=A0=A0 parity none;=0A}=0A=0Aconsole usb0 { include usb2serial; port = 1; }=0A=0AWhen connecting remotely to conserver and run call usb0 I can see= only characters I am typing not console responses. All console output is g= oing directly to log file.=0AWhat I am doing wrong? I want to ave interacti= ve communication with my device connected through serial cable=0A=0AThank y= ou,=0AMike ---2027350018-225328108-1398107889=:4971 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I use this config in order to acces= s serial cable attached to serial2usb adapter on my conserver server:
=
default * {
  = ;      # The '&' character is substituted with= the console name
     &n= bsp;  logfile /var/consoles/&;
 &nbs= p;      rw sysadmin;  # use the group defined= above
        = master localhost;
}

default usb2serial {
 &n= bsp;      type device;
        device /dev/ttyUSB.;=
        device= subst .=3DPd;
      =   portbase -1;
     =    portinc 1;
    &n= bsp;   host none;
   &nbs= p;    baud 9600;
   =      parity none;
}

console usb0 { include usb2seria= l; port 1; }
When connecting remotely to conserver and run call u= sb0 I can see only characters I am typing not console responses. All console output is going directly to log file.
What I am doing w= rong? I want to ave interactive communication with my device connected thro= ugh serial cable

Thank you,=
Mike

---2027350018-225328108-1398107889=:4971-- From bstout@squareup.com Mon Apr 21 19:25:33 2014 Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by underdog.stansell.org (8.14.7/8.14.7) with ESMTP id s3LJPVnE027507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Apr 2014 19:25:33 GMT Received: by mail-pa0-f47.google.com with SMTP id lj1so4048675pab.34 for ; Mon, 21 Apr 2014 12:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=squareup.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QRwRb+Z8iFEKF1Zwd/05xFtNJ6Fb0P2P+9/X4sEsreg=; b=ao9DIS3klhvqORUp/f4kVk6hOCnRv9xhvLA79LCbegKHZxMGXaBCcZ/wpq0OXXi/nn NUtFRMNm3/xFTU9BzJKb14ZkmjEqyjlnGpgBwJgvGjmVMitawbuotYw+ogKTz7NeZ7+P qf4MszWW1FjHew2/j+qg2ajdoS95c5K7jWDmw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QRwRb+Z8iFEKF1Zwd/05xFtNJ6Fb0P2P+9/X4sEsreg=; b=Vq13uY/So9QSD2cz38UUI3gyJplTG52X3VUFMqCerYoFD3B/8md3k03tafZq5tx3M3 Dp9r3+HYH8IDc6hvedDFqHKMzsFia3g53Kwhd10zPqgqQ1EnFUmPSyWIiU4DpZpxVJ// H/u3lOR4PL56TZeH2rIOMXUbcz7ijmGfcC1NGAXQzLKJsJhE+usz7TymClOWbT73tdHD NM3CVjTj3AFUl0l1/XmN+bhChtwaracHWcBfuex8YsMrgVqPO9LUE/jAjqBIEyQa0/nJ +8/b5oIeMvIo+EtkdUTh8uMfsj9PeQNmE5/9D9hA7T9y0FsZeYzXGkeVm4km9lXMvYSv fzOQ== X-Gm-Message-State: ALoCoQnBj6CJa1AE3NMe/aBpI0YVBXwyG4P5LLBswpAJzZb6oe/IWTKM/ZCJGa/IKbeY9Zj/xmUh MIME-Version: 1.0 X-Received: by 10.66.149.37 with SMTP id tx5mr39666756pab.81.1398108330931; Mon, 21 Apr 2014 12:25:30 -0700 (PDT) Received: by 10.70.30.228 with HTTP; Mon, 21 Apr 2014 12:25:30 -0700 (PDT) In-Reply-To: <60CDA197-F0A1-4291-916B-E6E45713D15C@distal.com> References: <20140421173917.GB9600@redhat.com> <60CDA197-F0A1-4291-916B-E6E45713D15C@distal.com> Date: Mon, 21 Apr 2014 12:25:30 -0700 Message-ID: Subject: Re: Conserver and ssh From: Brandon Stout To: Chris Ross Content-Type: multipart/alternative; boundary=047d7b6dcdcc6c43d504f792762a X-Spam-Score: -1.489 () BAYES_00,HTML_MESSAGE,T_DKIM_INVALID X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 Cc: users@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.16 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 19:25:33 -0000 --047d7b6dcdcc6c43d504f792762a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the reply Chris. You are correct, it is not using the local/conserver password but just the console server (opengear) password. I actually don't really care which password to use, as long as it asks for a password anytime someone wants to connect to a console port. It works correctly if you just ssh to the console via port 30xx. But when using conserver, it just asks once and that is it. Looking at the logs, it looks like it conserver tries to login to every port preemptively and keep it open as opposed to just opening a session when someone asks for it. Is there a way to change this behavior? On Mon, Apr 21, 2014 at 12:13 PM, Chris Ross wr= ote: > > =E2=80=9CYour milage may vary=E2=80=9D, but for myself, I=E2=80=99m con= soling UNIX servers, so I > want their console output to be logged even when noone is connected. To > accomplish this, I have a script that will log into the session for me up= on > initialization of the console, and then stay attached. As you=E2=80=99ve > determined, conserver leaves the TCP connection active, so you don=E2=80= =99t need > to authenticate against the ssh connection again after the initial > connection. > > I suspect you=E2=80=99re not getting it to use the local/conserver pass= word at > all, or else when you first start up, you=E2=80=99d have to enter both, i= n the > correct sequence. One to connect to the established ssh command, then > another to ssh to authenticate the network connection. > > So, I guess you need to decide whether you want to have the connection > drop and reestablish, which is what you seemed to be asking for, or rathe= r > want just to get the conserver password prompting working, which I=E2=80= =99m not > doing, so can=E2=80=99t help with directly. > > Thoughts and information that I hope is helpful. > > - Chris > > On Apr 21, 2014, at 14:38, Brandon Stout wrote: > > > Also, how does the conserver.passwd work? When does it use that rather > than the authentication on the Opengear itself? To test, I have the same > user on the Opengear as well as in the conserver.passwd with different > passwords to see where it gets its passwords from. So far it just looks > like it is using the password from the Opengear. I configured conserver > with all the defaults so I am assuming conserver.passwd just needs to exi= st > within the same directory as conserver.cf. Did I configure something > incorrectly or does there need to be a line in the conserver.cf file to > point to where conserver.passwd exists? > > > > > > On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout > wrote: > > So I actually figured out the problem so now it connects, I get the > password prompt and when I enter it correctly it works. The problem is th= at > when I disconnect and reconnect, it no longer asks me for a password and > just puts me through to the console. is there some sort of disconnect I > need to do manually to get it to reset and ask for a password? Seems like > it just stays connected once the pw is entered, regardless of someone > exiting. > > > > > > On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout > wrote: > > thanks Nathan, I actually was trying that right after I sent this email > and added this > > > > default opengear-ssh { type exec; portbase 2000; portinc 1; > > exec /usr/bin/ssh -p P -l tsuser H; > > execsubst H=3Dhs,P=3DPd; } > > > > still not working though with just about nothing useful in the logs. > Doesn't hang but it still doesn't work. Just empty space and no output. > > > > > > On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz > wrote: > > On Apr 21 10:29, Brandon Stout wrote: > > > hello, I am trying to use conserver to connect to serial ports over > ssh and > > > it is hanging. When I go direct it works fine (i am using Opengear > IMX4248): > > > > > > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002 > > ... > > > default full { rw *; } > > > default opengear { type host; portbase 3000; portinc 1; } > > > default * { > > > logfile /var/log/conserver; > > > timestamp 1hab; > > > include full; > > > master localhost; > > > } > > > default console01 { include opengear; host console01; } > > > console dr01.arista { include console01; port 1; } > > > console dr02.arista { include console01; port 2; } > > ... > > > Has anyone gotten this to work using ssh? > > > > I think you need to use the exec host type and setup the right execsubs= t > > to get ssh to use the right port number. The "host" type is just a raw > > TCP socket connection. > > > > Nate > > _______________________________________________ > > users mailing list > > users@conserver.com > > https://www.conserver.com/mailman/listinfo/users > > > > > > > > -- > > > > brandon > > > > > > > > -- > > > > brandon > > > > > > > > -- > > > > brandon > > _______________________________________________ > > users mailing list > > users@conserver.com > > https://www.conserver.com/mailman/listinfo/users > > --=20 brandon --047d7b6dcdcc6c43d504f792762a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the reply Chris. You are correct, it is not usi= ng the local/conserver password but just the console server (opengear) pass= word. I actually don't really care which password to use, as long as it= asks for a password anytime someone wants to connect to a console port. It= works correctly if you just ssh to the console via port 30xx. But when usi= ng conserver, it just asks once and that is it. Looking at the logs, it loo= ks like it conserver tries to login to every port preemptively and keep it = open as opposed to just opening a session when someone asks for it. Is ther= e a way to change this behavior?


On Mon, Apr 2= 1, 2014 at 12:13 PM, Chris Ross <cross+conserver@distal.com&g= t; wrote:

=C2=A0 =E2=80=9CYour milage may vary=E2=80=9D, but for myself, I=E2=80=99m = consoling UNIX servers, so I want their console output to be logged even wh= en noone is connected. =C2=A0To accomplish this, I have a script that will = log into the session for me upon initialization of the console, and then st= ay attached. =C2=A0As you=E2=80=99ve determined, conserver leaves the TCP c= onnection active, so you don=E2=80=99t need to authenticate against the ssh= connection again after the initial connection.

=C2=A0 I suspect you=E2=80=99re not getting it to use the local/conserver p= assword at all, or else when you first start up, you=E2=80=99d have to ente= r both, in the correct sequence. =C2=A0One to connect to the established ss= h command, then another to ssh to authenticate the network connection.

=C2=A0 So, I guess you need to decide whether you want to have the connecti= on drop and reestablish, which is what you seemed to be asking for, or rath= er want just to get the conserver password prompting working, which I=E2=80= =99m not doing, so can=E2=80=99t help with directly.

=C2=A0 Thoughts and information that I hope is helpful.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Chris

On Apr 21, 2014, at 14:38, Brandon Stout <bstout@squareup.com> wrote:

> Also, how does the conserver.passwd work? When does it use that rather= than the authentication on the Opengear itself? To test, I have the same u= ser on the Opengear as well as in the conserver.passwd with different passw= ords to see where it gets its passwords from. So far it just looks like it = is using the password from the Opengear. I configured conserver with all th= e defaults so I am assuming conserver.passwd just needs to exist within the= same directory as conser= ver.cf. Did I configure something incorrectly or does there need to be = a line in the conserver.c= f file to point to where conserver.passwd exists?
>
>
> On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout <bstout@squareup.com> wrote:
> So I actually figured out the problem so now it connects, I get the pa= ssword prompt and when I enter it correctly it works. The problem is that w= hen I disconnect and reconnect, it no longer asks me for a password and jus= t puts me through to the console. is there some sort of disconnect I need t= o do manually to get it to reset and ask for a password? Seems like it just= stays connected once the pw is entered, regardless of someone exiting.
>
>
> On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout <bstout@squareup.com> wrote:
> thanks Nathan, I actually was trying that right after I sent this emai= l and added this
>
> default opengear-ssh { type exec; portbase 2000; portinc 1;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e= xec /usr/bin/ssh -p P -l tsuser H;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e= xecsubst H=3Dhs,P=3DPd; }
>
> still not working though with just about nothing useful in the logs. D= oesn't hang but it still doesn't work. Just empty space and no outp= ut.
>
>
> On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz <nstraz@redhat.com> wrote:
> On Apr 21 10:29, Brandon Stout wrote:
> > hello, I am trying to use conserver to connect to serial ports ov= er ssh and
> > it is hanging. When I go direct it works fine (i am using Opengea= r IMX4248):
> >
> > [bstout@lab etc]$ ssh root@1= 72.24.19.40 -p 3002
> ...
> > default full { rw *; }
> > default opengear =C2=A0{ type host; portbase 3000; portinc 1; } > > default * {
> > logfile /var/log/conserver;
> > timestamp 1hab;
> > include full;
> > master localhost;
> > }
> > default console01 { include opengear; host console01; }
> > console dr01.arista { include console01; port 1; }
> > console dr02.arista { include console01; port 2; }
> ...
> > Has anyone gotten this to work using ssh?
>
> I think you need to use the exec host type and setup the right execsub= st
> to get ssh to use the right port number. =C2=A0The "host" ty= pe is just a raw
> TCP socket connection.
>
> Nate
> _______________________________________________
> users mailing list
> users@conserver.com
> https://www.conserver.com/mailman/listinfo/users
>
>
>
> --
>
> brandon
>
>
>
> --
>
> brandon
>
>
>
> --
>
> brandon
> _______________________________________________
> users mailing list
> users@conserver.com
> https://www.conserver.com/mailman/listinfo/users




--
=
brandon
--047d7b6dcdcc6c43d504f792762a-- From cross+conserver@distal.com Mon Apr 21 19:30:38 2014 Received: from hydra.pix.net (hydra.pix.net [71.178.232.4]) by underdog.stansell.org (8.14.7/8.14.7) with ESMTP id s3LJUZOD028097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Apr 2014 19:30:37 GMT Received: from mail.distal.com (mail.distal.com [IPv6:2001:470:e24c:200::ae25]) (authenticated bits=0) by hydra.pix.net (8.14.5/8.14.5) with ESMTP id s3LJUQQx094638; Mon, 21 Apr 2014 15:30:33 -0400 (EDT) (envelope-from cross+conserver@distal.com) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98 at mail.pix.net Received: from zalamar.mm-corp.net ([65.207.51.176]) (authenticated bits=0) by mail.distal.com (8.14.8/8.14.8) with ESMTP id s3LJT4jK060524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 Apr 2014 15:29:05 -0400 (EDT) (envelope-from cross+conserver@distal.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Conserver and ssh From: Chris Ross In-Reply-To: Date: Mon, 21 Apr 2014 15:28:41 -0400 Message-Id: <4FDE14E4-0FF4-40E3-8D9E-AF5593CAA271@distal.com> References: <20140421173917.GB9600@redhat.com> <60CDA197-F0A1-4291-916B-E6E45713D15C@distal.com> To: Brandon Stout X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.distal.com [206.138.151.250]); Mon, 21 Apr 2014 15:29:05 -0400 (EDT) X-Spam-Score: -1.5 () BAYES_00 X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by underdog.stansell.org id s3LJUZOD028097 Cc: users@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.16 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 19:30:38 -0000 I don’t know, I’m afraid. You’re correct that that’s what it does. It’s designed and used as a console logging apparatus, as much as a console access mechanism. As I mentioned, that’s something I require of such a system myself. It’s where all of my console logs live. If you only want it to establish a connect in an on-demand basis, I would be surprised if there _wasn’t_ a way to do that, but I don’t know what it is myself. Sorry I can’t help directly. - Chris On Apr 21, 2014, at 15:25, Brandon Stout wrote: > Thanks for the reply Chris. You are correct, it is not using the local/conserver password but just the console server (opengear) password. I actually don't really care which password to use, as long as it asks for a password anytime someone wants to connect to a console port. It works correctly if you just ssh to the console via port 30xx. But when using conserver, it just asks once and that is it. Looking at the logs, it looks like it conserver tries to login to every port preemptively and keep it open as opposed to just opening a session when someone asks for it. Is there a way to change this behavior? > > > On Mon, Apr 21, 2014 at 12:13 PM, Chris Ross wrote: > > “Your milage may vary”, but for myself, I’m consoling UNIX servers, so I want their console output to be logged even when noone is connected. To accomplish this, I have a script that will log into the session for me upon initialization of the console, and then stay attached. As you’ve determined, conserver leaves the TCP connection active, so you don’t need to authenticate against the ssh connection again after the initial connection. > > I suspect you’re not getting it to use the local/conserver password at all, or else when you first start up, you’d have to enter both, in the correct sequence. One to connect to the established ssh command, then another to ssh to authenticate the network connection. > > So, I guess you need to decide whether you want to have the connection drop and reestablish, which is what you seemed to be asking for, or rather want just to get the conserver password prompting working, which I’m not doing, so can’t help with directly. > > Thoughts and information that I hope is helpful. > > - Chris > > On Apr 21, 2014, at 14:38, Brandon Stout wrote: > > > Also, how does the conserver.passwd work? When does it use that rather than the authentication on the Opengear itself? To test, I have the same user on the Opengear as well as in the conserver.passwd with different passwords to see where it gets its passwords from. So far it just looks like it is using the password from the Opengear. I configured conserver with all the defaults so I am assuming conserver.passwd just needs to exist within the same directory as conserver.cf. Did I configure something incorrectly or does there need to be a line in the conserver.cf file to point to where conserver.passwd exists? > > > > > > On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout wrote: > > So I actually figured out the problem so now it connects, I get the password prompt and when I enter it correctly it works. The problem is that when I disconnect and reconnect, it no longer asks me for a password and just puts me through to the console. is there some sort of disconnect I need to do manually to get it to reset and ask for a password? Seems like it just stays connected once the pw is entered, regardless of someone exiting. > > > > > > On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout wrote: > > thanks Nathan, I actually was trying that right after I sent this email and added this > > > > default opengear-ssh { type exec; portbase 2000; portinc 1; > > exec /usr/bin/ssh -p P -l tsuser H; > > execsubst H=hs,P=Pd; } > > > > still not working though with just about nothing useful in the logs. Doesn't hang but it still doesn't work. Just empty space and no output. > > > > > > On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz wrote: > > On Apr 21 10:29, Brandon Stout wrote: > > > hello, I am trying to use conserver to connect to serial ports over ssh and > > > it is hanging. When I go direct it works fine (i am using Opengear IMX4248): > > > > > > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002 > > ... > > > default full { rw *; } > > > default opengear { type host; portbase 3000; portinc 1; } > > > default * { > > > logfile /var/log/conserver; > > > timestamp 1hab; > > > include full; > > > master localhost; > > > } > > > default console01 { include opengear; host console01; } > > > console dr01.arista { include console01; port 1; } > > > console dr02.arista { include console01; port 2; } > > ... > > > Has anyone gotten this to work using ssh? > > > > I think you need to use the exec host type and setup the right execsubst > > to get ssh to use the right port number. The "host" type is just a raw > > TCP socket connection. > > > > Nate > > _______________________________________________ > > users mailing list > > users@conserver.com > > https://www.conserver.com/mailman/listinfo/users > > > > > > > > -- > > > > brandon > > > > > > > > -- > > > > brandon > > > > > > > > -- > > > > brandon > > _______________________________________________ > > users mailing list > > users@conserver.com > > https://www.conserver.com/mailman/listinfo/users > > > > > -- > > brandon From bstout@squareup.com Mon Apr 21 19:32:51 2014 Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by underdog.stansell.org (8.14.7/8.14.7) with ESMTP id s3LJWmw4028296 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Apr 2014 19:32:50 GMT Received: by mail-pb0-f49.google.com with SMTP id jt11so4037296pbb.36 for ; Mon, 21 Apr 2014 12:32:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=squareup.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1ZenNnfygjw9vbVW7W1UvTU+NisSU476DOpS8ziVLHE=; b=FXCx1mgA/PoDPoSpDU/LJgko1G0cEUSLuVIJXw1n6D2owJbXSzk8N+wChfbld3ERfF yGgcdvQdI2VJCXlDKQodtDXNJ9dT7PlyVmqzOvpa27cGrfmEz2hE8OgteqooZPdCf9kW dBAg59QcgxbK+VrG4cVhM/WvRAmwdP50kqLnY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1ZenNnfygjw9vbVW7W1UvTU+NisSU476DOpS8ziVLHE=; b=mi625qyZT6jCP68QwCRO6h6xG+3xRe1qJhtdSP9+OGwS7utkFOqSYFWJPncSspa5aB 0g3raZ3aCG1lsv0PfdeGYPKc7fFyxzy+EI3N+76/C5b8JngBD8kiVacbAcIsWmI4N01K SuwaO+tWNbNbN23j6xXD5ca5cJbdcxkf3iKBJ8NruzMNnsLdJ2t6qUM3xbzgopiDdZ/x HWKxxQMGGl9RBnQAy9x4DNqgNB4Z/leLI/dDR9XT7iTsT7c9y7RIeXXjLQoEa1uXG+dt zi7k5EZ4i88zsZlERgmIpCzWvfMpdgoNz71oDCvUiS7BlTPglwi900N/jO3F/u+2YT2y 713g== X-Gm-Message-State: ALoCoQn5lXC5wCg9zvCgO/jI9nBvvla1kefrzx/HC36dWDL5t1bntJ/nlx3AaZ/WPBxNGJmMH0xv MIME-Version: 1.0 X-Received: by 10.68.196.202 with SMTP id io10mr4758351pbc.149.1398108768360; Mon, 21 Apr 2014 12:32:48 -0700 (PDT) Received: by 10.70.30.228 with HTTP; Mon, 21 Apr 2014 12:32:48 -0700 (PDT) In-Reply-To: <4FDE14E4-0FF4-40E3-8D9E-AF5593CAA271@distal.com> References: <20140421173917.GB9600@redhat.com> <60CDA197-F0A1-4291-916B-E6E45713D15C@distal.com> <4FDE14E4-0FF4-40E3-8D9E-AF5593CAA271@distal.com> Date: Mon, 21 Apr 2014 12:32:48 -0700 Message-ID: Subject: Re: Conserver and ssh From: Brandon Stout To: Chris Ross Content-Type: multipart/alternative; boundary=e89a8fb208a67ee99104f7929020 X-Spam-Score: -1.489 () BAYES_00,HTML_MESSAGE,T_DKIM_INVALID X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 Cc: users@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.16 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 19:32:51 -0000 --e89a8fb208a67ee99104f7929020 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable No problem, thanks for your knowledge though Chris. On Mon, Apr 21, 2014 at 12:28 PM, Chris Ross wr= ote: > > I don=E2=80=99t know, I=E2=80=99m afraid. You=E2=80=99re correct that = that=E2=80=99s what it does. > It=E2=80=99s designed and used as a console logging apparatus, as much a= s a > console access mechanism. As I mentioned, that=E2=80=99s something I req= uire of > such a system myself. It=E2=80=99s where all of my console logs live. I= f you only > want it to establish a connect in an on-demand basis, I would be surprise= d > if there _wasn=E2=80=99t_ a way to do that, but I don=E2=80=99t know what= it is myself. > > Sorry I can=E2=80=99t help directly. > > - Chris > > On Apr 21, 2014, at 15:25, Brandon Stout wrote: > > > Thanks for the reply Chris. You are correct, it is not using the > local/conserver password but just the console server (opengear) password.= I > actually don't really care which password to use, as long as it asks for = a > password anytime someone wants to connect to a console port. It works > correctly if you just ssh to the console via port 30xx. But when using > conserver, it just asks once and that is it. Looking at the logs, it look= s > like it conserver tries to login to every port preemptively and keep it > open as opposed to just opening a session when someone asks for it. Is > there a way to change this behavior? > > > > > > On Mon, Apr 21, 2014 at 12:13 PM, Chris Ross > wrote: > > > > =E2=80=9CYour milage may vary=E2=80=9D, but for myself, I=E2=80=99m c= onsoling UNIX servers, so > I want their console output to be logged even when noone is connected. T= o > accomplish this, I have a script that will log into the session for me up= on > initialization of the console, and then stay attached. As you=E2=80=99ve > determined, conserver leaves the TCP connection active, so you don=E2=80= =99t need > to authenticate against the ssh connection again after the initial > connection. > > > > I suspect you=E2=80=99re not getting it to use the local/conserver pa= ssword at > all, or else when you first start up, you=E2=80=99d have to enter both, i= n the > correct sequence. One to connect to the established ssh command, then > another to ssh to authenticate the network connection. > > > > So, I guess you need to decide whether you want to have the connectio= n > drop and reestablish, which is what you seemed to be asking for, or rathe= r > want just to get the conserver password prompting working, which I=E2=80= =99m not > doing, so can=E2=80=99t help with directly. > > > > Thoughts and information that I hope is helpful. > > > > - Chris > > > > On Apr 21, 2014, at 14:38, Brandon Stout wrote: > > > > > Also, how does the conserver.passwd work? When does it use that rathe= r > than the authentication on the Opengear itself? To test, I have the same > user on the Opengear as well as in the conserver.passwd with different > passwords to see where it gets its passwords from. So far it just looks > like it is using the password from the Opengear. I configured conserver > with all the defaults so I am assuming conserver.passwd just needs to exi= st > within the same directory as conserver.cf. Did I configure something > incorrectly or does there need to be a line in the conserver.cf file to > point to where conserver.passwd exists? > > > > > > > > > On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout > wrote: > > > So I actually figured out the problem so now it connects, I get the > password prompt and when I enter it correctly it works. The problem is th= at > when I disconnect and reconnect, it no longer asks me for a password and > just puts me through to the console. is there some sort of disconnect I > need to do manually to get it to reset and ask for a password? Seems like > it just stays connected once the pw is entered, regardless of someone > exiting. > > > > > > > > > On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout > wrote: > > > thanks Nathan, I actually was trying that right after I sent this > email and added this > > > > > > default opengear-ssh { type exec; portbase 2000; portinc 1; > > > exec /usr/bin/ssh -p P -l tsuser H; > > > execsubst H=3Dhs,P=3DPd; } > > > > > > still not working though with just about nothing useful in the logs. > Doesn't hang but it still doesn't work. Just empty space and no output. > > > > > > > > > On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz > wrote: > > > On Apr 21 10:29, Brandon Stout wrote: > > > > hello, I am trying to use conserver to connect to serial ports over > ssh and > > > > it is hanging. When I go direct it works fine (i am using Opengear > IMX4248): > > > > > > > > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002 > > > ... > > > > default full { rw *; } > > > > default opengear { type host; portbase 3000; portinc 1; } > > > > default * { > > > > logfile /var/log/conserver; > > > > timestamp 1hab; > > > > include full; > > > > master localhost; > > > > } > > > > default console01 { include opengear; host console01; } > > > > console dr01.arista { include console01; port 1; } > > > > console dr02.arista { include console01; port 2; } > > > ... > > > > Has anyone gotten this to work using ssh? > > > > > > I think you need to use the exec host type and setup the right > execsubst > > > to get ssh to use the right port number. The "host" type is just a r= aw > > > TCP socket connection. > > > > > > Nate > > > _______________________________________________ > > > users mailing list > > > users@conserver.com > > > https://www.conserver.com/mailman/listinfo/users > > > > > > > > > > > > -- > > > > > > brandon > > > > > > > > > > > > -- > > > > > > brandon > > > > > > > > > > > > -- > > > > > > brandon > > > _______________________________________________ > > > users mailing list > > > users@conserver.com > > > https://www.conserver.com/mailman/listinfo/users > > > > > > > > > > -- > > > > brandon > > --=20 brandon --e89a8fb208a67ee99104f7929020 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No problem, thanks for your knowledge though Chris.=C2=A0<= /div>


On Mon, = Apr 21, 2014 at 12:28 PM, Chris Ross <cross+conserver@distal.com<= /a>> wrote:

=C2=A0 I don=E2=80=99t know, I=E2=80=99m afraid. =C2=A0You=E2=80=99re corre= ct that that=E2=80=99s what it does. =C2=A0It=E2=80=99s designed and used a= s a console logging apparatus, as much as a console access mechanism. =C2= =A0As I mentioned, that=E2=80=99s something I require of such a system myse= lf. =C2=A0It=E2=80=99s where all of my console logs live. =C2=A0If you only= want it to establish a connect in an on-demand basis, I would be surprised= if there _wasn=E2=80=99t_ a way to do that, but I don=E2=80=99t know what = it is myself.

=C2=A0 Sorry I can=E2=80=99t help directly.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0- =C2=A0Chris

On Apr 21, 2014, at 15:25, Brandon Stout <bstout@squareup.com> wrote:

> Thanks for the reply Chris. You are correct, it is not using the local= /conserver password but just the console server (opengear) password. I actu= ally don't really care which password to use, as long as it asks for a = password anytime someone wants to connect to a console port. It works corre= ctly if you just ssh to the console via port 30xx. But when using conserver= , it just asks once and that is it. Looking at the logs, it looks like it c= onserver tries to login to every port preemptively and keep it open as oppo= sed to just opening a session when someone asks for it. Is there a way to c= hange this behavior?
>
>
> On Mon, Apr 21, 2014 at 12:13 PM, Chris Ross <cross+conserver@distal.com> wrote:
>
> =C2=A0 =E2=80=9CYour milage may vary=E2=80=9D, but for myself, I=E2=80= =99m consoling UNIX servers, so I want their console output to be logged ev= en when noone is connected. =C2=A0To accomplish this, I have a script that = will log into the session for me upon initialization of the console, and th= en stay attached. =C2=A0As you=E2=80=99ve determined, conserver leaves the = TCP connection active, so you don=E2=80=99t need to authenticate against th= e ssh connection again after the initial connection.
>
> =C2=A0 I suspect you=E2=80=99re not getting it to use the local/conser= ver password at all, or else when you first start up, you=E2=80=99d have to= enter both, in the correct sequence. =C2=A0One to connect to the establish= ed ssh command, then another to ssh to authenticate the network connection.=
>
> =C2=A0 So, I guess you need to decide whether you want to have the con= nection drop and reestablish, which is what you seemed to be asking for, or= rather want just to get the conserver password prompting working, which I= =E2=80=99m not doing, so can=E2=80=99t help with directly.
>
> =C2=A0 Thoughts and information that I hope is helpful.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Chris
>
> On Apr 21, 2014, at 14:38, Brandon Stout <bstout@squareup.com> wrote:
>
> > Also, how does the conserver.passwd work? When does it use that r= ather than the authentication on the Opengear itself? To test, I have the s= ame user on the Opengear as well as in the conserver.passwd with different = passwords to see where it gets its passwords from. So far it just looks lik= e it is using the password from the Opengear. I configured conserver with a= ll the defaults so I am assuming conserver.passwd just needs to exist withi= n the same directory as c= onserver.cf. Did I configure something incorrectly or does there need t= o be a line in the conser= ver.cf file to point to where conserver.passwd exists?
> >
> >
> > On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout <bstout@squareup.com> wrote:
> > So I actually figured out the problem so now it connects, I get t= he password prompt and when I enter it correctly it works. The problem is t= hat when I disconnect and reconnect, it no longer asks me for a password an= d just puts me through to the console. is there some sort of disconnect I n= eed to do manually to get it to reset and ask for a password? Seems like it= just stays connected once the pw is entered, regardless of someone exiting= .
> >
> >
> > On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout <bstout@squareup.com> wrote:
> > thanks Nathan, I actually was trying that right after I sent this= email and added this
> >
> > default opengear-ssh { type exec; portbase 2000; portinc 1;
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0exec /usr/bin/ssh -p P -l tsuser H;
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0execsubst H=3Dhs,P=3DPd; }
> >
> > still not working though with just about nothing useful in the lo= gs. Doesn't hang but it still doesn't work. Just empty space and no= output.
> >
> >
> > On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz <nstraz@redhat.com> wrote:
> > On Apr 21 10:29, Brandon Stout wrote:
> > > hello, I am trying to use conserver to connect to serial por= ts over ssh and
> > > it is hanging. When I go direct it works fine (i am using Op= engear IMX4248):
> > >
> > > [bstout@lab etc]$ ssh r= oot@172.24.19.40 -p 3002
> > ...
> > > default full { rw *; }
> > > default opengear =C2=A0{ type host; portbase 3000; portinc 1= ; }
> > > default * {
> > > logfile /var/log/conserver;
> > > timestamp 1hab;
> > > include full;
> > > master localhost;
> > > }
> > > default console01 { include opengear; host console01; }
> > > console dr01.arista { include console01; port 1; }
> > > console dr02.arista { include console01; port 2; }
> > ...
> > > Has anyone gotten this to work using ssh?
> >
> > I think you need to use the exec host type and setup the right ex= ecsubst
> > to get ssh to use the right port number. =C2=A0The "host&quo= t; type is just a raw
> > TCP socket connection.
> >
> > Nate
> > _______________________________________________
> > users mailing list
> > users@conserver.com > > https://www.conserver.com/mailman/listinfo/users
> >
> >
> >
> > --
> >
> > brandon
> >
> >
> >
> > --
> >
> > brandon
> >
> >
> >
> > --
> >
> > brandon
> > _______________________________________________
> > users mailing list
> > users@conserver.com > > https://www.conserver.com/mailman/listinfo/users
>
>
>
>
> --
>
> brandon




--
=
brandon
--e89a8fb208a67ee99104f7929020-- From nstraz@redhat.com Mon Apr 21 19:42:17 2014 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by underdog.stansell.org (8.14.7/8.14.7) with ESMTP id s3LJgFms029311 for ; Mon, 21 Apr 2014 19:42:17 GMT Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3LJgEHq019799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 21 Apr 2014 15:42:14 -0400 Received: from tin.rawstew (ovpn-113-159.phx2.redhat.com [10.3.113.159]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id s3LJgCqa001007; Mon, 21 Apr 2014 15:42:12 -0400 Received: by tin.rawstew (sSMTP sendmail emulation); Mon, 21 Apr 2014 15:42:12 -0400 From: "Nathan Straz" Date: Mon, 21 Apr 2014 15:42:12 -0400 To: Brandon Stout Subject: Re: Conserver and ssh Message-ID: <20140421194212.GD9600@redhat.com> References: <20140421173917.GB9600@redhat.com> <60CDA197-F0A1-4291-916B-E6E45713D15C@distal.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Spam-Score: -2.551 () BAYES_00,RP_MATCHES_RCVD Cc: users@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.16 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 19:42:17 -0000 On Apr 21 12:25, Brandon Stout wrote: > Thanks for the reply Chris. You are correct, it is not using the > local/conserver password but just the console server (opengear) password. I > actually don't really care which password to use, as long as it asks for a > password anytime someone wants to connect to a console port. You want to use "options ondemand." Nate From consoleteam@gmail.com Mon Apr 21 20:35:08 2014 Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) by underdog.stansell.org (8.14.7/8.14.7) with ESMTP id s3LKZ5lu006087 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Apr 2014 20:35:07 GMT Received: by mail-ig0-f175.google.com with SMTP id h3so2204587igd.8 for ; Mon, 21 Apr 2014 13:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E71xy3U4kDtjHJIQkf7KARIfJJzLx3bv0kgfMXeDKP8=; b=NInvfp8lohy5dDJyGRsuV9/d/g0p69ivlJ6eD8gUIys0ccFVsM0pKrcx2NnXRiW3ym fDKndjSCXe3FlAXGViGkqz0wj6NKIknGSBZFKPU410f0fVIoHvda374Fa/MrII3pgU5w zr8/2MYNpa+dOOnhfNz0D4lYU/DahNeRJqvA9jSsYFsXcsRiJ+eVs6yTK1qkr/35ZL7e zEruXnaAjvu+bcxFqOffXZyjJF1XbvL2WSuIg35ritJDmcyu285NI3d52r6SnMno3d+T zP7bi/vshnVk3xqwRSZPM1JJTUQeVzKNsgnmtzWdD+BJC9ztEbdhFlDZ9CW7g97nyYMd t8bA== MIME-Version: 1.0 X-Received: by 10.43.140.144 with SMTP id ja16mr33502411icc.46.1398112504851; Mon, 21 Apr 2014 13:35:04 -0700 (PDT) Received: by 10.43.56.74 with HTTP; Mon, 21 Apr 2014 13:35:04 -0700 (PDT) In-Reply-To: References: <20140421173917.GB9600@redhat.com> <60CDA197-F0A1-4291-916B-E6E45713D15C@distal.com> Date: Mon, 21 Apr 2014 13:35:04 -0700 Message-ID: Subject: Re: Conserver and ssh From: Zonker To: Brandon Stout Content-Type: multipart/alternative; boundary=001a11c1e8c0352ffa04f7936f92 X-Spam-Score: -1.488 () BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,T_DKIM_INVALID X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 Cc: "users@conserver.com" X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.16 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 20:35:08 -0000 --001a11c1e8c0352ffa04f7936f92 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Chris Ross is correct... The model of conserver connecting (and then trying to maintain connection) is built around the model that a sysadmin wants to capture any messages that a console may cough up (memory error at 0x23484325, root volume at 98%, core dumped, etc.), so that when a system fails to respond on the network, and you try to use the console only to find it unresponsive... THEN is when we are glad that we can tail the log file for that device, and see what was happening! :-) Once we see the problem, we can then grep the logs for similar machines, and see if we see any of the early signs of pending failure on similar devices in our collection. :-) Using ssh is a way to encrypt the data between the console server and the conserver host. But, as you scale up (think many dozens of console servers, and thousands of ports), consider that SSH on each of those connections is a lot more overhead. Many shops use a dedicated management subnet and use the telnet option instead. The conserver.passwd is a good option when you want to give someone console access, but not give them shell access on your NIS network. By giving them an account local to your conserver host, and using the local password file, they can access consoles, and no more. In one case, where I needed to give contractors access to *some* consoles, I installed conserver where the contractors had access (rather than letting them have access to my primary logs), and had this conserver.passwd; cat /usr/local/etc/conserver.passwd # Users can either have a pre-defined account name here, # or they can refer to an existing shell account... # for Shell accounts, "*passwd*" means to use their shell passwd # Or, you can enforce a pre-assigned password, by adding a crypted string # (this bypasses the shell passwd, forcing them to use the console passwd) # perl -e 'print crypt("password","Ah")."\n";' # The "Ah" picks the first two characters of the password, and is the "salt" # used for the crypt... root: temp_FE:ceOfgr9fefOqNw # Contractor users must come to their consoles from a CLUSTER_HOST v-prtent:*passwd* v-boulder:*passwd* *any*:*passwd* Also, "temp_FE" was an account when they needed someone more random to come in and work on the devices, and we could change that password at will. Best regards, -Z- On Mon, Apr 21, 2014 at 12:25 PM, Brandon Stout wrote= : > Thanks for the reply Chris. You are correct, it is not using the > local/conserver password but just the console server (opengear) password.= I > actually don't really care which password to use, as long as it asks for = a > password anytime someone wants to connect to a console port. It works > correctly if you just ssh to the console via port 30xx. But when using > conserver, it just asks once and that is it. Looking at the logs, it look= s > like it conserver tries to login to every port preemptively and keep it > open as opposed to just opening a session when someone asks for it. Is > there a way to change this behavior? > > > On Mon, Apr 21, 2014 at 12:13 PM, Chris Ross = wrote: > >> >> =E2=80=9CYour milage may vary=E2=80=9D, but for myself, I=E2=80=99m co= nsoling UNIX servers, so >> I want their console output to be logged even when noone is connected. = To >> accomplish this, I have a script that will log into the session for me u= pon >> initialization of the console, and then stay attached. As you=E2=80=99v= e >> determined, conserver leaves the TCP connection active, so you don=E2=80= =99t need >> to authenticate against the ssh connection again after the initial >> connection. >> >> I suspect you=E2=80=99re not getting it to use the local/conserver pas= sword at >> all, or else when you first start up, you=E2=80=99d have to enter both, = in the >> correct sequence. One to connect to the established ssh command, then >> another to ssh to authenticate the network connection. >> >> So, I guess you need to decide whether you want to have the connection >> drop and reestablish, which is what you seemed to be asking for, or rath= er >> want just to get the conserver password prompting working, which I=E2=80= =99m not >> doing, so can=E2=80=99t help with directly. >> >> Thoughts and information that I hope is helpful. >> >> - Chris >> >> On Apr 21, 2014, at 14:38, Brandon Stout wrote: >> >> > Also, how does the conserver.passwd work? When does it use that rather >> than the authentication on the Opengear itself? To test, I have the same >> user on the Opengear as well as in the conserver.passwd with different >> passwords to see where it gets its passwords from. So far it just looks >> like it is using the password from the Opengear. I configured conserver >> with all the defaults so I am assuming conserver.passwd just needs to ex= ist >> within the same directory as conserver.cf. Did I configure something >> incorrectly or does there need to be a line in the conserver.cf file to >> point to where conserver.passwd exists? >> > >> > >> > On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout >> wrote: >> > So I actually figured out the problem so now it connects, I get the >> password prompt and when I enter it correctly it works. The problem is t= hat >> when I disconnect and reconnect, it no longer asks me for a password and >> just puts me through to the console. is there some sort of disconnect I >> need to do manually to get it to reset and ask for a password? Seems lik= e >> it just stays connected once the pw is entered, regardless of someone >> exiting. >> > >> > >> > On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout >> wrote: >> > thanks Nathan, I actually was trying that right after I sent this emai= l >> and added this >> > >> > default opengear-ssh { type exec; portbase 2000; portinc 1; >> > exec /usr/bin/ssh -p P -l tsuser H; >> > execsubst H=3Dhs,P=3DPd; } >> > >> > still not working though with just about nothing useful in the logs. >> Doesn't hang but it still doesn't work. Just empty space and no output. >> > >> > >> > On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz >> wrote: >> > On Apr 21 10:29, Brandon Stout wrote: >> > > hello, I am trying to use conserver to connect to serial ports over >> ssh and >> > > it is hanging. When I go direct it works fine (i am using Opengear >> IMX4248): >> > > >> > > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002 >> > ... >> > > default full { rw *; } >> > > default opengear { type host; portbase 3000; portinc 1; } >> > > default * { >> > > logfile /var/log/conserver; >> > > timestamp 1hab; >> > > include full; >> > > master localhost; >> > > } >> > > default console01 { include opengear; host console01; } >> > > console dr01.arista { include console01; port 1; } >> > > console dr02.arista { include console01; port 2; } >> > ... >> > > Has anyone gotten this to work using ssh? >> > >> > I think you need to use the exec host type and setup the right execsub= st >> > to get ssh to use the right port number. The "host" type is just a ra= w >> > TCP socket connection. >> > >> > Nate >> > _______________________________________________ >> > users mailing list >> > users@conserver.com >> > https://www.conserver.com/mailman/listinfo/users >> > >> > >> > >> > -- >> > >> > brandon >> > >> > >> > >> > -- >> > >> > brandon >> > >> > >> > >> > -- >> > >> > brandon >> > _______________________________________________ >> > users mailing list >> > users@conserver.com >> > https://www.conserver.com/mailman/listinfo/users >> >> > > > -- > > brandon > > _______________________________________________ > users mailing list > users@conserver.com > https://www.conserver.com/mailman/listinfo/users > > --=20 Sent from my new iPhone 6 Watch (prototype), see my reviews here! www.conserver.com/consoles/ -- consoleteam.blogspot.com - - - - - - - - www.ncry.org www.d4tm.org www.hackerdojo.com --001a11c1e8c0352ffa04f7936f92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0 Chris Ross is correct... The model of c= onserver connecting (and then trying to maintain connection) is built aroun= d the model that a sysadmin wants to capture any messages that a console ma= y cough up (memory error at 0x23484325, root volume at 98%, core dumped, et= c.), so that when a system fails to respond on the network, and you try to = use the console only to find it unresponsive... THEN is when we are glad th= at we can tail the log file for that device, and see what was happening!=C2= =A0 :-)

=C2=A0 Once we see the problem, we can then grep the = logs for similar machines, and see if we see any of the early signs of pend= ing failure on similar devices in our collection. :-)


=C2=A0 Using ssh is a way to encrypt the data bet= ween the console server and the conserver host. But, as you scale up (think= many dozens of console servers, and thousands of ports), consider that SSH= on each of those connections is a lot more overhead.=C2=A0 Many shops use = a dedicated management subnet and use the telnet option instead.

=C2=A0 The conserver.passwd is a good option when you= want to give someone console access, but not give them shell access on you= r NIS network. By giving them an account local to your conserver host, and = using the local password file, they can access consoles, and no more.

=C2=A0 In one case, where I needed to give contractor= s access to *some* consoles, I installed conserver where the contractors ha= d access (rather than letting them have access to my primary logs), and had= this conserver.passwd;

=C2=A0cat /usr/local/etc/conserver.passwd
# Users can either have a = pre-defined account name here,
# or they can refer to an existing shell = account...
#=C2=A0 for Shell accounts, "*passwd*" means to use= their shell passwd
# Or, you can enforce a pre-assigned password, by adding a crypted string#=C2=A0 (this bypasses the shell passwd, forcing them to use the console = passwd)
# perl -e 'print crypt("password","Ah").= "\n";'
#=C2=A0 The "Ah" picks the first two characters of the password, = and is the "salt"
#=C2=A0 used for the crypt...
root:
te= mp_FE:ceOfgr9fefOqNw
# Contractor users must come to their consoles from= a CLUSTER_HOST
v-prtent:*passwd*
v-boulder:*passwd*
*any*:*passwd*

Also, "temp_FE" was an account when they needed someone m= ore random to come in and work on the devices, and we could change that pas= sword at will.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Best regards,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 -Z-



On Mon, Apr 21, 2014 at 12:25 PM, Brandon Stout <bstout@squareup.com<= /a>> wrote:
Thanks for the reply Chris.= You are correct, it is not using the local/conserver password but just the= console server (opengear) password. I actually don't really care which= password to use, as long as it asks for a password anytime someone wants t= o connect to a console port. It works correctly if you just ssh to the cons= ole via port 30xx. But when using conserver, it just asks once and that is = it. Looking at the logs, it looks like it conserver tries to login to every= port preemptively and keep it open as opposed to just opening a session wh= en someone asks for it. Is there a way to change this behavior?


On Mon, Apr 21, 2014 at 12:13 PM, Chris Ross &l= t;cross+con= server@distal.com> wrote:

=C2=A0 =E2=80=9CYour milage may vary=E2=80=9D, but for myself, I=E2=80=99m = consoling UNIX servers, so I want their console output to be logged even wh= en noone is connected. =C2=A0To accomplish this, I have a script that will = log into the session for me upon initialization of the console, and then st= ay attached. =C2=A0As you=E2=80=99ve determined, conserver leaves the TCP c= onnection active, so you don=E2=80=99t need to authenticate against the ssh= connection again after the initial connection.

=C2=A0 I suspect you=E2=80=99re not getting it to use the local/conserver p= assword at all, or else when you first start up, you=E2=80=99d have to ente= r both, in the correct sequence. =C2=A0One to connect to the established ss= h command, then another to ssh to authenticate the network connection.

=C2=A0 So, I guess you need to decide whether you want to have the connecti= on drop and reestablish, which is what you seemed to be asking for, or rath= er want just to get the conserver password prompting working, which I=E2=80= =99m not doing, so can=E2=80=99t help with directly.

=C2=A0 Thoughts and information that I hope is helpful.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Chris

On Apr 21, 2014, at 14:38, Brandon Stout <bstout@squareup.com> wrote:

> Also, how does the conserver.passwd work? When does it use that rather= than the authentication on the Opengear itself? To test, I have the same u= ser on the Opengear as well as in the conserver.passwd with different passw= ords to see where it gets its passwords from. So far it just looks like it = is using the password from the Opengear. I configured conserver with all th= e defaults so I am assuming conserver.passwd just needs to exist within the= same directory as conser= ver.cf. Did I configure something incorrectly or does there need to be = a line in the conserver.c= f file to point to where conserver.passwd exists?
>
>
> On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout <bstout@squareup.com> wrote: > So I actually figured out the problem so now it connects, I get the pa= ssword prompt and when I enter it correctly it works. The problem is that w= hen I disconnect and reconnect, it no longer asks me for a password and jus= t puts me through to the console. is there some sort of disconnect I need t= o do manually to get it to reset and ask for a password? Seems like it just= stays connected once the pw is entered, regardless of someone exiting.
>
>
> On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout <bstout@squareup.com> wrote: > thanks Nathan, I actually was trying that right after I sent this emai= l and added this
>
> default opengear-ssh { type exec; portbase 2000; portinc 1;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e= xec /usr/bin/ssh -p P -l tsuser H;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e= xecsubst H=3Dhs,P=3DPd; }
>
> still not working though with just about nothing useful in the logs. D= oesn't hang but it still doesn't work. Just empty space and no outp= ut.
>
>
> On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz <nstraz@redhat.com> wrote:
> On Apr 21 10:29, Brandon Stout wrote:
> > hello, I am trying to use conserver to connect to serial ports ov= er ssh and
> > it is hanging. When I go direct it works fine (i am using Opengea= r IMX4248):
> >
> > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002
> ...
> > default full { rw *; }
> > default opengear =C2=A0{ type host; portbase 3000; portinc 1; } > > default * {
> > logfile /var/log/conserver;
> > timestamp 1hab;
> > include full;
> > master localhost;
> > }
> > default console01 { include opengear; host console01; }
> > console dr01.arista { include console01; port 1; }
> > console dr02.arista { include console01; port 2; }
> ...
> > Has anyone gotten this to work using ssh?
>
> I think you need to use the exec host type and setup the right execsub= st
> to get ssh to use the right port number. =C2=A0The "host" ty= pe is just a raw
> TCP socket connection.
>
> Nate
> _______________________________________________
> users mailing list
> users@conserv= er.com
> https://www.conserver.com/mailman/listinfo/users
>
>
>
> --
>
> brandon
>
>
>
> --
>
> brandon
>
>
>
> --
>
> brandon
> _______________________________________________
> users mailing list
> users@conserv= er.com
> https://www.conserver.com/mailman/listinfo/users




<= /div>--

brandon=

_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users




--
Se= nt from my new iPhone 6 Watch (prototype), see my reviews here!
www.conserver.com= /consoles/ -- consoleteam.blogspot.com
- - - - - - - -
www.n= cry.org
www.d4tm.o= rg
www.hacke= rdojo.com
--001a11c1e8c0352ffa04f7936f92-- From bstout@squareup.com Mon Apr 21 20:53:34 2014 Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by underdog.stansell.org (8.14.7/8.14.7) with ESMTP id s3LKrWea008116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Apr 2014 20:53:34 GMT Received: by mail-pa0-f54.google.com with SMTP id lf10so4129628pab.13 for ; Mon, 21 Apr 2014 13:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=squareup.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9ZwBB8rQAhjffk0pXoyj3hh0XUtngEfYufDf5qpXrH4=; b=dbYymcDfNRhLD6DAIWm4QR1eVwp2WRFoZQMNWR+LoDKu5F7t8VOi/diuIKn5Arh7V/ wnuf6H4fFKRSt4vjCZYekjyoUwx8BJ1OARV0uIhrCqOCHAXxk78nB0MVcxxlKeqiveDP nDleD7QfhJaULK5fbkTSNQlH/grtNwB6i7Jvw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9ZwBB8rQAhjffk0pXoyj3hh0XUtngEfYufDf5qpXrH4=; b=Dv3j9dqjzIhYAANYcE/P9qBY8cxVTsk+DC3QgFf+kDcQXI6KXzXG90uw3f8BhWOezP to5Nly34PLjxxXptsolFTDHqgKcXgmStjff/d0WBjqEizvCht2wOlxn05QRm0M6q+x62 Br5ebg+lUmuMna+nT5u1ilwiXIvKcRP52Gs476sR5Jxzhz1GtQOg0/OqX6H/DPnYZ3jD vigOE0gD20F1iztjfqv7sWw6gswn8qC4zfdWjkJFQ/SJxVj2yc4VqwBYnkf+SVvvRX3D NwDiWyAfT34BFmoI2gb++yIEspz9upOn6c5nATJB81iCEU5pcIFmSsJewiJcwsSbES1z 5zLQ== X-Gm-Message-State: ALoCoQnM6bLgsun4y4EeRv7Ulgd6N/mazyzMjjLesUCS3GWXoH33Mhp13ELdPpnHXJsWh4R+2Q83 MIME-Version: 1.0 X-Received: by 10.68.143.231 with SMTP id sh7mr40473322pbb.7.1398113612179; Mon, 21 Apr 2014 13:53:32 -0700 (PDT) Received: by 10.70.30.228 with HTTP; Mon, 21 Apr 2014 13:53:32 -0700 (PDT) In-Reply-To: <20140421194212.GD9600@redhat.com> References: <20140421173917.GB9600@redhat.com> <60CDA197-F0A1-4291-916B-E6E45713D15C@distal.com> <20140421194212.GD9600@redhat.com> Date: Mon, 21 Apr 2014 13:53:32 -0700 Message-ID: Subject: Re: Conserver and ssh From: Brandon Stout To: Nathan Straz Content-Type: multipart/alternative; boundary=047d7b2e43d635b98204f793b163 X-Spam-Score: -1.489 () BAYES_00,HTML_MESSAGE,T_DKIM_INVALID X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 Cc: users@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.16 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 20:53:35 -0000 --047d7b2e43d635b98204f793b163 Content-Type: text/plain; charset=UTF-8 Nathan, that worked. Thanks a bunch. On Mon, Apr 21, 2014 at 12:42 PM, Nathan Straz wrote: > On Apr 21 12:25, Brandon Stout wrote: > > Thanks for the reply Chris. You are correct, it is not using the > > local/conserver password but just the console server (opengear) > password. I > > actually don't really care which password to use, as long as it asks for > a > > password anytime someone wants to connect to a console port. > > You want to use "options ondemand." > > Nate > -- brandon --047d7b2e43d635b98204f793b163 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nathan, that worked. Thanks a bunch.=C2=A0


On Mon, Apr 21, 2014 at= 12:42 PM, Nathan Straz <nstraz@redhat.com> wrote:
On Apr 21 12:25, Brandon Sto= ut wrote:
> Thanks for the reply Chris. You are correct, it is not using the
> local/conserver password but just the console server (opengear) passwo= rd. I
> actually don't really care which password to use, as long as it as= ks for a
> password anytime someone wants to connect to a console port.

You want to use "options ondemand."

Nate



--

bra= ndon
--047d7b2e43d635b98204f793b163-- From bstout@squareup.com Mon Apr 21 21:13:42 2014 Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by underdog.stansell.org (8.14.7/8.14.7) with ESMTP id s3LLDdDN011228 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Apr 2014 21:13:41 GMT Received: by mail-pb0-f51.google.com with SMTP id uo5so4126532pbc.38 for ; Mon, 21 Apr 2014 14:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=squareup.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GtSwkous+UR8/NkkSNJP8OeSndqNM4JI0Cw2CGs2akw=; b=L/odQDmCg9VjVIrwlSSDR9fz+S1w2QxEnHTtoXou/fqk4D8/ue+nXGfWdsdyUIWi16 bhAab0eAkU8KEdCWEzQ7XdxROGJXH6oLrFm53Vo4kpx8a82nlaSSvy/e/lyLybbr2Fzi I9dHdF62HJR3jlGaQ9QcQithgggKiEhesbEe4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GtSwkous+UR8/NkkSNJP8OeSndqNM4JI0Cw2CGs2akw=; b=G7GcQvdqzgfY/pkz7AZN8GpDxyAwBjsGLEmoDn4Y6y6+GZKcpjHh1FPi9c48iv2Cpo PylmygK9vo+Zl/jt9hWjdX0OrirgBOPdvJqf1lm2tvKvAZIh3Uhq0PJliFwlBkSFKrRC bkvsjtkIBpRYF5g1pkscO5o+xnLJwy/nd3broOnrYhZequbujaHYymy4YGJn46SlpiSX GJRErEX8P/hHGDTR1pJpN+F516kQGw4EbnpSuh5V53+7dLfjDeiG06ZaNEi+K34xmkJd m49rzXYD2Pp+9jx0KLuyL7D97ompuFWrJ2T76JoLb/tMc8TgVltPV4adP0EOtFzVfIgQ RCSw== X-Gm-Message-State: ALoCoQna4u+hK967J6R0/7dgfCELzQYaeBZ9b5hogHCe1tqSjJ175w3qPuEJAs7kd48B6GQlEKx8 MIME-Version: 1.0 X-Received: by 10.68.105.36 with SMTP id gj4mr40571410pbb.64.1398114819016; Mon, 21 Apr 2014 14:13:39 -0700 (PDT) Received: by 10.70.30.228 with HTTP; Mon, 21 Apr 2014 14:13:38 -0700 (PDT) In-Reply-To: References: <20140421173917.GB9600@redhat.com> <60CDA197-F0A1-4291-916B-E6E45713D15C@distal.com> Date: Mon, 21 Apr 2014 14:13:38 -0700 Message-ID: Subject: Re: Conserver and ssh From: Brandon Stout To: Zonker Content-Type: multipart/alternative; boundary=047d7b66f01d24a33a04f793f9ef X-Spam-Score: -1.489 () BAYES_00,HTML_MESSAGE,T_DKIM_INVALID X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 Cc: "users@conserver.com" X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.16 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 21:13:44 -0000 --047d7b66f01d24a33a04f793f9ef Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hey Z, This all makes sense, thanks for the info. From an conserver.passwd perspective, is the location and usage of the file need to be called out in the conserver.cf file or should it automatically use it for authentication? Right now I have it working being authenticated by the Opengear but want to test to see if I can get it working using this file. Is there something I needed to do to get conserver to use the file? thanks Brandon On Mon, Apr 21, 2014 at 1:35 PM, Zonker wrote: > Chris Ross is correct... The model of conserver connecting (and then > trying to maintain connection) is built around the model that a sysadmin > wants to capture any messages that a console may cough up (memory error a= t > 0x23484325, root volume at 98%, core dumped, etc.), so that when a system > fails to respond on the network, and you try to use the console only to > find it unresponsive... THEN is when we are glad that we can tail the log > file for that device, and see what was happening! :-) > > Once we see the problem, we can then grep the logs for similar machines= , > and see if we see any of the early signs of pending failure on similar > devices in our collection. :-) > > > Using ssh is a way to encrypt the data between the console server and > the conserver host. But, as you scale up (think many dozens of console > servers, and thousands of ports), consider that SSH on each of those > connections is a lot more overhead. Many shops use a dedicated managemen= t > subnet and use the telnet option instead. > > The conserver.passwd is a good option when you want to give someone > console access, but not give them shell access on your NIS network. By > giving them an account local to your conserver host, and using the local > password file, they can access consoles, and no more. > > In one case, where I needed to give contractors access to *some* > consoles, I installed conserver where the contractors had access (rather > than letting them have access to my primary logs), and had this > conserver.passwd; > > cat /usr/local/etc/conserver.passwd > # Users can either have a pre-defined account name here, > # or they can refer to an existing shell account... > # for Shell accounts, "*passwd*" means to use their shell passwd > # Or, you can enforce a pre-assigned password, by adding a crypted string > # (this bypasses the shell passwd, forcing them to use the console passw= d) > # perl -e 'print crypt("password","Ah")."\n";' > # The "Ah" picks the first two characters of the password, and is the > "salt" > # used for the crypt... > root: > temp_FE:ceOfgr9fefOqNw > # Contractor users must come to their consoles from a CLUSTER_HOST > v-prtent:*passwd* > v-boulder:*passwd* > *any*:*passwd* > > Also, "temp_FE" was an account when they needed someone more random to > come in and work on the devices, and we could change that password at wil= l. > > Best regards, > > -Z- > > > > On Mon, Apr 21, 2014 at 12:25 PM, Brandon Stout wrot= e: > >> Thanks for the reply Chris. You are correct, it is not using the >> local/conserver password but just the console server (opengear) password= . I >> actually don't really care which password to use, as long as it asks for= a >> password anytime someone wants to connect to a console port. It works >> correctly if you just ssh to the console via port 30xx. But when using >> conserver, it just asks once and that is it. Looking at the logs, it loo= ks >> like it conserver tries to login to every port preemptively and keep it >> open as opposed to just opening a session when someone asks for it. Is >> there a way to change this behavior? >> >> >> On Mon, Apr 21, 2014 at 12:13 PM, Chris Ross wrote: >> >>> >>> =E2=80=9CYour milage may vary=E2=80=9D, but for myself, I=E2=80=99m c= onsoling UNIX servers, so >>> I want their console output to be logged even when noone is connected. = To >>> accomplish this, I have a script that will log into the session for me = upon >>> initialization of the console, and then stay attached. As you=E2=80=99= ve >>> determined, conserver leaves the TCP connection active, so you don=E2= =80=99t need >>> to authenticate against the ssh connection again after the initial >>> connection. >>> >>> I suspect you=E2=80=99re not getting it to use the local/conserver pa= ssword at >>> all, or else when you first start up, you=E2=80=99d have to enter both,= in the >>> correct sequence. One to connect to the established ssh command, then >>> another to ssh to authenticate the network connection. >>> >>> So, I guess you need to decide whether you want to have the connectio= n >>> drop and reestablish, which is what you seemed to be asking for, or rat= her >>> want just to get the conserver password prompting working, which I=E2= =80=99m not >>> doing, so can=E2=80=99t help with directly. >>> >>> Thoughts and information that I hope is helpful. >>> >>> - Chris >>> >>> On Apr 21, 2014, at 14:38, Brandon Stout wrote: >>> >>> > Also, how does the conserver.passwd work? When does it use that rathe= r >>> than the authentication on the Opengear itself? To test, I have the sam= e >>> user on the Opengear as well as in the conserver.passwd with different >>> passwords to see where it gets its passwords from. So far it just looks >>> like it is using the password from the Opengear. I configured conserver >>> with all the defaults so I am assuming conserver.passwd just needs to e= xist >>> within the same directory as conserver.cf. Did I configure something >>> incorrectly or does there need to be a line in the conserver.cf file to >>> point to where conserver.passwd exists? >>> > >>> > >>> > On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout >>> wrote: >>> > So I actually figured out the problem so now it connects, I get the >>> password prompt and when I enter it correctly it works. The problem is = that >>> when I disconnect and reconnect, it no longer asks me for a password an= d >>> just puts me through to the console. is there some sort of disconnect I >>> need to do manually to get it to reset and ask for a password? Seems li= ke >>> it just stays connected once the pw is entered, regardless of someone >>> exiting. >>> > >>> > >>> > On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout >>> wrote: >>> > thanks Nathan, I actually was trying that right after I sent this >>> email and added this >>> > >>> > default opengear-ssh { type exec; portbase 2000; portinc 1; >>> > exec /usr/bin/ssh -p P -l tsuser H; >>> > execsubst H=3Dhs,P=3DPd; } >>> > >>> > still not working though with just about nothing useful in the logs. >>> Doesn't hang but it still doesn't work. Just empty space and no output. >>> > >>> > >>> > On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz >>> wrote: >>> > On Apr 21 10:29, Brandon Stout wrote: >>> > > hello, I am trying to use conserver to connect to serial ports over >>> ssh and >>> > > it is hanging. When I go direct it works fine (i am using Opengear >>> IMX4248): >>> > > >>> > > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002 >>> > ... >>> > > default full { rw *; } >>> > > default opengear { type host; portbase 3000; portinc 1; } >>> > > default * { >>> > > logfile /var/log/conserver; >>> > > timestamp 1hab; >>> > > include full; >>> > > master localhost; >>> > > } >>> > > default console01 { include opengear; host console01; } >>> > > console dr01.arista { include console01; port 1; } >>> > > console dr02.arista { include console01; port 2; } >>> > ... >>> > > Has anyone gotten this to work using ssh? >>> > >>> > I think you need to use the exec host type and setup the right >>> execsubst >>> > to get ssh to use the right port number. The "host" type is just a r= aw >>> > TCP socket connection. >>> > >>> > Nate >>> > _______________________________________________ >>> > users mailing list >>> > users@conserver.com >>> > https://www.conserver.com/mailman/listinfo/users >>> > >>> > >>> > >>> > -- >>> > >>> > brandon >>> > >>> > >>> > >>> > -- >>> > >>> > brandon >>> > >>> > >>> > >>> > -- >>> > >>> > brandon >>> > _______________________________________________ >>> > users mailing list >>> > users@conserver.com >>> > https://www.conserver.com/mailman/listinfo/users >>> >>> >> >> >> -- >> >> brandon >> >> _______________________________________________ >> users mailing list >> users@conserver.com >> https://www.conserver.com/mailman/listinfo/users >> >> > > > -- > Sent from my new iPhone 6 Watch (prototype), see my reviews here! > www.conserver.com/consoles/ -- consoleteam.blogspot.com > - - - - - - - - > www.ncry.org > www.d4tm.org > www.hackerdojo.com > --=20 brandon --047d7b66f01d24a33a04f793f9ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Z,

This all makes sense, thanks for= the info. From an conserver.passwd perspective, is the location and usage = of the file need to be called out in the co= nserver.cf file or should it automatically use it for authentication? R= ight now I have it working being authenticated by the Opengear but want to = test to see if I can get it working using this file. Is there something I n= eeded to do to get conserver to use the file?

thanks
Brandon


On Mon, Apr 21, 2014 at 1:35 PM,= Zonker <consoleteam@gmail.com> wrote:
=C2=A0 Chris Ro= ss is correct... The model of conserver connecting (and then trying to main= tain connection) is built around the model that a sysadmin wants to capture= any messages that a console may cough up (memory error at 0x23484325, root= volume at 98%, core dumped, etc.), so that when a system fails to respond = on the network, and you try to use the console only to find it unresponsive= ... THEN is when we are glad that we can tail the log file for that device,= and see what was happening!=C2=A0 :-)

=C2=A0 Once we see the problem, we can then grep the = logs for similar machines, and see if we see any of the early signs of pend= ing failure on similar devices in our collection. :-)


=C2=A0 Using ssh is a way to encrypt the data bet= ween the console server and the conserver host. But, as you scale up (think= many dozens of console servers, and thousands of ports), consider that SSH= on each of those connections is a lot more overhead.=C2=A0 Many shops use = a dedicated management subnet and use the telnet option instead.

=C2=A0 The conserver.passwd is a good option when you= want to give someone console access, but not give them shell access on you= r NIS network. By giving them an account local to your conserver host, and = using the local password file, they can access consoles, and no more.

=C2=A0 In one case, where I needed to give contractor= s access to *some* consoles, I installed conserver where the contractors ha= d access (rather than letting them have access to my primary logs), and had= this conserver.passwd;

=C2=A0cat /usr/local/etc/conserver.passwd
# Users can either have a = pre-defined account name here,
# or they can refer to an existing shell = account...
#=C2=A0 for Shell accounts, "*passwd*" means to use= their shell passwd
# Or, you can enforce a pre-assigned password, by adding a crypted string#=C2=A0 (this bypasses the shell passwd, forcing them to use the console = passwd)
# perl -e 'print crypt("password","Ah").= "\n";'
#=C2=A0 The "Ah" picks the first two characters of the password, = and is the "salt"
#=C2=A0 used for the crypt...
root:
te= mp_FE:ceOfgr9fefOqNw
# Contractor users must come to their consoles from= a CLUSTER_HOST
v-prtent:*passwd*
v-boulder:*passwd*
*any*:*passwd*

Also, "temp_FE" was an account when they needed someone m= ore random to come in and work on the devices, and we could change that pas= sword at will.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Best regards,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 -Z-



<= div class=3D"gmail_quote">On Mon, Apr 21, 2014 at 12:25 PM, Brandon Stout <= span dir=3D"ltr"><bstout@squareup.com> wrote:
Thanks for the reply Chris.= You are correct, it is not using the local/conserver password but just the= console server (opengear) password. I actually don't really care which= password to use, as long as it asks for a password anytime someone wants t= o connect to a console port. It works correctly if you just ssh to the cons= ole via port 30xx. But when using conserver, it just asks once and that is = it. Looking at the logs, it looks like it conserver tries to login to every= port preemptively and keep it open as opposed to just opening a session wh= en someone asks for it. Is there a way to change this behavior?


On = Mon, Apr 21, 2014 at 12:13 PM, Chris Ross <cross+conserver@distal= .com> wrote:

=C2=A0 =E2=80=9CYour milage may vary=E2=80=9D, but for myself, I=E2=80=99m = consoling UNIX servers, so I want their console output to be logged even wh= en noone is connected. =C2=A0To accomplish this, I have a script that will = log into the session for me upon initialization of the console, and then st= ay attached. =C2=A0As you=E2=80=99ve determined, conserver leaves the TCP c= onnection active, so you don=E2=80=99t need to authenticate against the ssh= connection again after the initial connection.

=C2=A0 I suspect you=E2=80=99re not getting it to use the local/conserver p= assword at all, or else when you first start up, you=E2=80=99d have to ente= r both, in the correct sequence. =C2=A0One to connect to the established ss= h command, then another to ssh to authenticate the network connection.

=C2=A0 So, I guess you need to decide whether you want to have the connecti= on drop and reestablish, which is what you seemed to be asking for, or rath= er want just to get the conserver password prompting working, which I=E2=80= =99m not doing, so can=E2=80=99t help with directly.

=C2=A0 Thoughts and information that I hope is helpful.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Chris

On Apr 21, 2014, at 14:38, Brandon Stout <bstout@squareup.com> wrote:

> Also, how does the conserver.passwd work? When does it use that rather= than the authentication on the Opengear itself? To test, I have the same u= ser on the Opengear as well as in the conserver.passwd with different passw= ords to see where it gets its passwords from. So far it just looks like it = is using the password from the Opengear. I configured conserver with all th= e defaults so I am assuming conserver.passwd just needs to exist within the= same directory as conser= ver.cf. Did I configure something incorrectly or does there need to be = a line in the conserver.c= f file to point to where conserver.passwd exists?
>
>
> On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout <bstout@squareup.com> wrote: > So I actually figured out the problem so now it connects, I get the pa= ssword prompt and when I enter it correctly it works. The problem is that w= hen I disconnect and reconnect, it no longer asks me for a password and jus= t puts me through to the console. is there some sort of disconnect I need t= o do manually to get it to reset and ask for a password? Seems like it just= stays connected once the pw is entered, regardless of someone exiting.
>
>
> On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout <bstout@squareup.com> wrote: > thanks Nathan, I actually was trying that right after I sent this emai= l and added this
>
> default opengear-ssh { type exec; portbase 2000; portinc 1;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e= xec /usr/bin/ssh -p P -l tsuser H;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e= xecsubst H=3Dhs,P=3DPd; }
>
> still not working though with just about nothing useful in the logs. D= oesn't hang but it still doesn't work. Just empty space and no outp= ut.
>
>
> On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz <nstraz@redhat.com> wrote:
> On Apr 21 10:29, Brandon Stout wrote:
> > hello, I am trying to use conserver to connect to serial ports ov= er ssh and
> > it is hanging. When I go direct it works fine (i am using Opengea= r IMX4248):
> >
> > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002
> ...
> > default full { rw *; }
> > default opengear =C2=A0{ type host; portbase 3000; portinc 1; } > > default * {
> > logfile /var/log/conserver;
> > timestamp 1hab;
> > include full;
> > master localhost;
> > }
> > default console01 { include opengear; host console01; }
> > console dr01.arista { include console01; port 1; }
> > console dr02.arista { include console01; port 2; }
> ...
> > Has anyone gotten this to work using ssh?
>
> I think you need to use the exec host type and setup the right execsub= st
> to get ssh to use the right port number. =C2=A0The "host" ty= pe is just a raw
> TCP socket connection.
>
> Nate
> _______________________________________________
> users mailing list
> users@conserv= er.com
> https://www.conserver.com/mailman/listinfo/users
>
>
>
> --
>
> brandon
>
>
>
> --
>
> brandon
>
>
>
> --
>
> brandon
> _______________________________________________
> users mailing list
> users@conserv= er.com
> https://www.conserver.com/mailman/listinfo/users




<= /div>--

brandon

_______________________________________________
users mailing list
users@conserver.co= m
https://www.conserver.com/mailman/listinfo/users




--
Sent from my new iPhone 6 Watch (prototype), see = my reviews here!
www.conserver.com/consoles/ -- consoleteam.blogspot.com
- - - - - - - -
www.n= cry.org
www.d4tm.o= rg
www.hacke= rdojo.com



--

bra= ndon
--047d7b66f01d24a33a04f793f9ef-- From consoleteam@gmail.com Mon Apr 21 22:37:40 2014 Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by underdog.stansell.org (8.14.7/8.14.7) with ESMTP id s3LMbajw015032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Apr 2014 22:37:38 GMT Received: by mail-ie0-f172.google.com with SMTP id as1so4519639iec.31 for ; Mon, 21 Apr 2014 15:37:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=403tkAofv28gv6dQ8iK9bGQ6RRtBP7Z1+aE9fsqILMU=; b=VI+4fdXRLC+oIOE+mMts69ffGk7AwwF2kX5lUmM1E/XG9TqVZM5+4CHOLkNz2vi6Xc jw2wlxPhvQ6YgA4vE0YdJzRARLeXJNjohf5PyqHcEKnLJyhH+wN0YblEti3Gr7zdKPt9 U1tTpPouZfeZlPA2rdEpssazlMtGGw/suHP/c7o3lszAUD/uIT8luW3578WPBXNmGwXl DFor1YnL56mi4nkdniWEZhDKFdTgjudVVAmT71OfKdljcf59xPSSxJ1ziCE9VHDTbFHo 0m+cwMWXzDSl2W9akXzogIiEwaD3NPBuY3sfDnA0flZ7/LgNBUhrNp5ABARW5Bs6qbWn u/Pg== MIME-Version: 1.0 X-Received: by 10.50.109.230 with SMTP id hv6mr25574743igb.9.1398119856242; Mon, 21 Apr 2014 15:37:36 -0700 (PDT) Received: by 10.43.56.74 with HTTP; Mon, 21 Apr 2014 15:37:36 -0700 (PDT) In-Reply-To: References: <20140421173917.GB9600@redhat.com> <60CDA197-F0A1-4291-916B-E6E45713D15C@distal.com> Date: Mon, 21 Apr 2014 15:37:36 -0700 Message-ID: Subject: Re: Conserver and ssh From: Zonker To: Brandon Stout Content-Type: multipart/alternative; boundary=089e013a1d8e628fee04f79525e7 X-Spam-Score: -1.488 () BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,T_DKIM_INVALID X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 Cc: "users@conserver.com" X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.16 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 22:37:40 -0000 --089e013a1d8e628fee04f79525e7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Try thinking of authentication in the following model... 1) A secure connection from the Conserver host to the console server(s). (Management net, maybe static routes instead of defaults, SSH if needed) - Conserver opens a conenction for every configured port, and starts logging. 2) User access to the console sessions. - Maybe the SSH to the conserver, or they have a console client on their host - Users "connect" to a given console session... conserver "tees" them in. ( User types, data goes to the console... device sends data back, conserver logs it and forwards the data to the user.) In this model, only Conserver would need to know how to log into the console server. (I make sure my console servers only allow one connection per serial port in the reverse-TCP mode. This way, if anyone else know how to access that port and has the credentials, they would be unable to connect of Conserver got their first. Also in this model, users would authenticate on Conserver... either by SSH to the Conserver host, or with their own conserver client. In the latter case, the client users need to validate with conserver when they make the connection, and this would be checked in the conserver.passwd file= . It's been a great model for many types of administration. But, if it's not for you, perhaps you can share what make your scenario different/difficult? Best regards, -Z- http://www.conserver.com/consoles/ You may find a couple of my older LISA tutorials useful, and you can find them at http://www.conserver.com/consoles/Training/published.html On Mon, Apr 21, 2014 at 2:13 PM, Brandon Stout wrote: > Hey Z, > > This all makes sense, thanks for the info. From an conserver.passwd > perspective, is the location and usage of the file need to be called out = in > the conserver.cf file or should it automatically use it for > authentication? Right now I have it working being authenticated by the > Opengear but want to test to see if I can get it working using this file. > Is there something I needed to do to get conserver to use the file? > > thanks > Brandon > > > On Mon, Apr 21, 2014 at 1:35 PM, Zonker wrote: > >> Chris Ross is correct... The model of conserver connecting (and then >> trying to maintain connection) is built around the model that a sysadmin >> wants to capture any messages that a console may cough up (memory error = at >> 0x23484325, root volume at 98%, core dumped, etc.), so that when a syste= m >> fails to respond on the network, and you try to use the console only to >> find it unresponsive... THEN is when we are glad that we can tail the lo= g >> file for that device, and see what was happening! :-) >> >> Once we see the problem, we can then grep the logs for similar >> machines, and see if we see any of the early signs of pending failure on >> similar devices in our collection. :-) >> >> >> Using ssh is a way to encrypt the data between the console server and >> the conserver host. But, as you scale up (think many dozens of console >> servers, and thousands of ports), consider that SSH on each of those >> connections is a lot more overhead. Many shops use a dedicated manageme= nt >> subnet and use the telnet option instead. >> >> The conserver.passwd is a good option when you want to give someone >> console access, but not give them shell access on your NIS network. By >> giving them an account local to your conserver host, and using the local >> password file, they can access consoles, and no more. >> >> In one case, where I needed to give contractors access to *some* >> consoles, I installed conserver where the contractors had access (rather >> than letting them have access to my primary logs), and had this >> conserver.passwd; >> >> cat /usr/local/etc/conserver.passwd >> # Users can either have a pre-defined account name here, >> # or they can refer to an existing shell account... >> # for Shell accounts, "*passwd*" means to use their shell passwd >> # Or, you can enforce a pre-assigned password, by adding a crypted strin= g >> # (this bypasses the shell passwd, forcing them to use the console >> passwd) >> # perl -e 'print crypt("password","Ah")."\n";' >> # The "Ah" picks the first two characters of the password, and is the >> "salt" >> # used for the crypt... >> root: >> temp_FE:ceOfgr9fefOqNw >> # Contractor users must come to their consoles from a CLUSTER_HOST >> v-prtent:*passwd* >> v-boulder:*passwd* >> *any*:*passwd* >> >> Also, "temp_FE" was an account when they needed someone more random to >> come in and work on the devices, and we could change that password at wi= ll. >> >> Best regards, >> >> -Z- >> >> >> >> On Mon, Apr 21, 2014 at 12:25 PM, Brandon Stout wro= te: >> >>> Thanks for the reply Chris. You are correct, it is not using the >>> local/conserver password but just the console server (opengear) passwor= d. I >>> actually don't really care which password to use, as long as it asks fo= r a >>> password anytime someone wants to connect to a console port. It works >>> correctly if you just ssh to the console via port 30xx. But when using >>> conserver, it just asks once and that is it. Looking at the logs, it lo= oks >>> like it conserver tries to login to every port preemptively and keep it >>> open as opposed to just opening a session when someone asks for it. Is >>> there a way to change this behavior? >>> >>> >>> On Mon, Apr 21, 2014 at 12:13 PM, Chris Ross >> > wrote: >>> >>>> >>>> =E2=80=9CYour milage may vary=E2=80=9D, but for myself, I=E2=80=99m = consoling UNIX servers, >>>> so I want their console output to be logged even when noone is connect= ed. >>>> To accomplish this, I have a script that will log into the session fo= r me >>>> upon initialization of the console, and then stay attached. As you=E2= =80=99ve >>>> determined, conserver leaves the TCP connection active, so you don=E2= =80=99t need >>>> to authenticate against the ssh connection again after the initial >>>> connection. >>>> >>>> I suspect you=E2=80=99re not getting it to use the local/conserver p= assword >>>> at all, or else when you first start up, you=E2=80=99d have to enter b= oth, in the >>>> correct sequence. One to connect to the established ssh command, then >>>> another to ssh to authenticate the network connection. >>>> >>>> So, I guess you need to decide whether you want to have the >>>> connection drop and reestablish, which is what you seemed to be asking= for, >>>> or rather want just to get the conserver password prompting working, w= hich >>>> I=E2=80=99m not doing, so can=E2=80=99t help with directly. >>>> >>>> Thoughts and information that I hope is helpful. >>>> >>>> - Chris >>>> >>>> On Apr 21, 2014, at 14:38, Brandon Stout wrote: >>>> >>>> > Also, how does the conserver.passwd work? When does it use that >>>> rather than the authentication on the Opengear itself? To test, I have= the >>>> same user on the Opengear as well as in the conserver.passwd with diff= erent >>>> passwords to see where it gets its passwords from. So far it just look= s >>>> like it is using the password from the Opengear. I configured conserve= r >>>> with all the defaults so I am assuming conserver.passwd just needs to = exist >>>> within the same directory as conserver.cf. Did I configure something >>>> incorrectly or does there need to be a line in the conserver.cf file >>>> to point to where conserver.passwd exists? >>>> > >>>> > >>>> > On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout >>>> wrote: >>>> > So I actually figured out the problem so now it connects, I get the >>>> password prompt and when I enter it correctly it works. The problem is= that >>>> when I disconnect and reconnect, it no longer asks me for a password a= nd >>>> just puts me through to the console. is there some sort of disconnect = I >>>> need to do manually to get it to reset and ask for a password? Seems l= ike >>>> it just stays connected once the pw is entered, regardless of someone >>>> exiting. >>>> > >>>> > >>>> > On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout >>>> wrote: >>>> > thanks Nathan, I actually was trying that right after I sent this >>>> email and added this >>>> > >>>> > default opengear-ssh { type exec; portbase 2000; portinc 1; >>>> > exec /usr/bin/ssh -p P -l tsuser H; >>>> > execsubst H=3Dhs,P=3DPd; } >>>> > >>>> > still not working though with just about nothing useful in the logs. >>>> Doesn't hang but it still doesn't work. Just empty space and no output= . >>>> > >>>> > >>>> > On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz >>>> wrote: >>>> > On Apr 21 10:29, Brandon Stout wrote: >>>> > > hello, I am trying to use conserver to connect to serial ports ove= r >>>> ssh and >>>> > > it is hanging. When I go direct it works fine (i am using Opengear >>>> IMX4248): >>>> > > >>>> > > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002 >>>> > ... >>>> > > default full { rw *; } >>>> > > default opengear { type host; portbase 3000; portinc 1; } >>>> > > default * { >>>> > > logfile /var/log/conserver; >>>> > > timestamp 1hab; >>>> > > include full; >>>> > > master localhost; >>>> > > } >>>> > > default console01 { include opengear; host console01; } >>>> > > console dr01.arista { include console01; port 1; } >>>> > > console dr02.arista { include console01; port 2; } >>>> > ... >>>> > > Has anyone gotten this to work using ssh? >>>> > >>>> > I think you need to use the exec host type and setup the right >>>> execsubst >>>> > to get ssh to use the right port number. The "host" type is just a >>>> raw >>>> > TCP socket connection. >>>> > >>>> > Nate >>>> > _______________________________________________ >>>> > users mailing list >>>> > users@conserver.com >>>> > https://www.conserver.com/mailman/listinfo/users >>>> > >>>> > >>>> > >>>> > -- >>>> > >>>> > brandon >>>> > >>>> > >>>> > >>>> > -- >>>> > >>>> > brandon >>>> > >>>> > >>>> > >>>> > -- >>>> > >>>> > brandon >>>> > _______________________________________________ >>>> > users mailing list >>>> > users@conserver.com >>>> > https://www.conserver.com/mailman/listinfo/users >>>> >>>> >>> >>> >>> -- >>> >>> brandon >>> >>> _______________________________________________ >>> users mailing list >>> users@conserver.com >>> https://www.conserver.com/mailman/listinfo/users >>> >>> >> >> >> -- >> Sent from my new iPhone 6 Watch (prototype), see my reviews here! >> www.conserver.com/consoles/ -- consoleteam.blogspot.com >> - - - - - - - - >> www.ncry.org >> www.d4tm.org >> www.hackerdojo.com >> > > > > -- > > brandon > --=20 Sent from my new iPhone 6 Watch (prototype), see my reviews here! www.conserver.com/consoles/ -- consoleteam.blogspot.com - - - - - - - - www.ncry.org www.d4tm.org www.hackerdojo.com --089e013a1d8e628fee04f79525e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Try thinking of authentication in the followin= g model...

=C2=A0 1)=C2=A0 A secure connection from the Conserver host to the console = server(s).
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 (Management net, maybe static routes instead of defaults, SSH if nee= ded)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Conserver op= ens a conenction for every configured port, and starts logging.
=C2=A0 2)=C2=A0 User access to the console sessions.
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -=C2=A0 Maybe the SSH to the con= server, or they have a console client on their host
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Users "= connect" to a given console session... conserver "tees" them= in.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ( User types, data goes to the c= onsole... device sends data back, conserver logs it and forwards the data t= o the user.)

=C2=A0 In this model, only Conserver would need to know how to log into the= console server.=C2=A0 (I make sure my console servers only allow one conne= ction per serial port in the reverse-TCP mode. This way, if anyone else kno= w how to access that port and has the credentials, they would be unable to = connect of Conserver got their first.

=C2=A0 Also in this model, users would authenticate o= n Conserver... either by SSH to the Conserver host, or with their own conse= rver client. In the latter case, the client users need to validate with con= server when they make the connection, and this would be checked in the cons= erver.passwd file.

=C2=A0 It's been a great model for many types of = administration. But, if it's not for you, perhaps you can share what ma= ke your scenario different/difficult?

=C2=A0=C2=A0=C2=A0=C2=A0 Best regards,

=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 -Z-=C2=A0=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 http://= www.conserver.com/consoles/

=C2=A0 You may fin= d a couple of my older LISA tutorials useful, and you can find them at
http:= //www.conserver.com/consoles/Training/published.html



On Mon, Apr= 21, 2014 at 2:13 PM, Brandon Stout <bstout@squareup.com> = wrote:
Hey Z,

T= his all makes sense, thanks for the info. From an conserver.passwd perspect= ive, is the location and usage of the file need to be called out in the conserver.cf file or sho= uld it automatically use it for authentication? Right now I have it working= being authenticated by the Opengear but want to test to see if I can get i= t working using this file. Is there something I needed to do to get conserv= er to use the file?

thanks
Brandon


On Mon, A= pr 21, 2014 at 1:35 PM, Zonker <consoleteam@gmail.com> w= rote:
=C2=A0 Chris Ro= ss is correct... The model of conserver connecting (and then trying to main= tain connection) is built around the model that a sysadmin wants to capture= any messages that a console may cough up (memory error at 0x23484325, root= volume at 98%, core dumped, etc.), so that when a system fails to respond = on the network, and you try to use the console only to find it unresponsive= ... THEN is when we are glad that we can tail the log file for that device,= and see what was happening!=C2=A0 :-)

=C2=A0 Once we see the problem, we can then grep the = logs for similar machines, and see if we see any of the early signs of pend= ing failure on similar devices in our collection. :-)


=C2=A0 Using ssh is a way to encrypt the data bet= ween the console server and the conserver host. But, as you scale up (think= many dozens of console servers, and thousands of ports), consider that SSH= on each of those connections is a lot more overhead.=C2=A0 Many shops use = a dedicated management subnet and use the telnet option instead.

=C2=A0 The conserver.passwd is a good option when you= want to give someone console access, but not give them shell access on you= r NIS network. By giving them an account local to your conserver host, and = using the local password file, they can access consoles, and no more.

=C2=A0 In one case, where I needed to give contractor= s access to *some* consoles, I installed conserver where the contractors ha= d access (rather than letting them have access to my primary logs), and had= this conserver.passwd;

=C2=A0cat /usr/local/etc/conserver.passwd
# Users can either have a = pre-defined account name here,
# or they can refer to an existing shell = account...
#=C2=A0 for Shell accounts, "*passwd*" means to use= their shell passwd
# Or, you can enforce a pre-assigned password, by adding a crypted string#=C2=A0 (this bypasses the shell passwd, forcing them to use the console = passwd)
# perl -e 'print crypt("password","Ah").= "\n";'
#=C2=A0 The "Ah" picks the first two characters of the password, = and is the "salt"
#=C2=A0 used for the crypt...
root:
te= mp_FE:ceOfgr9fefOqNw
# Contractor users must come to their consoles from= a CLUSTER_HOST
v-prtent:*passwd*
v-boulder:*passwd*
*any*:*passwd*

Also, "temp_FE" was an account when they needed someone m= ore random to come in and work on the devices, and we could change that pas= sword at will.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Best regards,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 -Z-



On Mon, Apr 21, 2014 at 12:25 PM, Brandon Stout <bstout@squ= areup.com> wrote:
Thanks for the reply Chris.= You are correct, it is not using the local/conserver password but just the= console server (opengear) password. I actually don't really care which= password to use, as long as it asks for a password anytime someone wants t= o connect to a console port. It works correctly if you just ssh to the cons= ole via port 30xx. But when using conserver, it just asks once and that is = it. Looking at the logs, it looks like it conserver tries to login to every= port preemptively and keep it open as opposed to just opening a session wh= en someone asks for it. Is there a way to change this behavior?


On = Mon, Apr 21, 2014 at 12:13 PM, Chris Ross <cross+conserver@distal= .com> wrote:

=C2=A0 =E2=80=9CYour milage may vary=E2=80=9D, but for myself, I=E2=80=99m = consoling UNIX servers, so I want their console output to be logged even wh= en noone is connected. =C2=A0To accomplish this, I have a script that will = log into the session for me upon initialization of the console, and then st= ay attached. =C2=A0As you=E2=80=99ve determined, conserver leaves the TCP c= onnection active, so you don=E2=80=99t need to authenticate against the ssh= connection again after the initial connection.

=C2=A0 I suspect you=E2=80=99re not getting it to use the local/conserver p= assword at all, or else when you first start up, you=E2=80=99d have to ente= r both, in the correct sequence. =C2=A0One to connect to the established ss= h command, then another to ssh to authenticate the network connection.

=C2=A0 So, I guess you need to decide whether you want to have the connecti= on drop and reestablish, which is what you seemed to be asking for, or rath= er want just to get the conserver password prompting working, which I=E2=80= =99m not doing, so can=E2=80=99t help with directly.

=C2=A0 Thoughts and information that I hope is helpful.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Chris

On Apr 21, 2014, at 14:38, Brandon Stout <bstout@squareup.com> wrote:

> Also, how does the conserver.passwd work? When does it use that rather= than the authentication on the Opengear itself? To test, I have the same u= ser on the Opengear as well as in the conserver.passwd with different passw= ords to see where it gets its passwords from. So far it just looks like it = is using the password from the Opengear. I configured conserver with all th= e defaults so I am assuming conserver.passwd just needs to exist within the= same directory as conser= ver.cf. Did I configure something incorrectly or does there need to be = a line in the conserver.c= f file to point to where conserver.passwd exists?
>
>
> On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout <bstout@squareup.com> wrote: > So I actually figured out the problem so now it connects, I get the pa= ssword prompt and when I enter it correctly it works. The problem is that w= hen I disconnect and reconnect, it no longer asks me for a password and jus= t puts me through to the console. is there some sort of disconnect I need t= o do manually to get it to reset and ask for a password? Seems like it just= stays connected once the pw is entered, regardless of someone exiting.
>
>
> On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout <bstout@squareup.com> wrote: > thanks Nathan, I actually was trying that right after I sent this emai= l and added this
>
> default opengear-ssh { type exec; portbase 2000; portinc 1;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e= xec /usr/bin/ssh -p P -l tsuser H;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e= xecsubst H=3Dhs,P=3DPd; }
>
> still not working though with just about nothing useful in the logs. D= oesn't hang but it still doesn't work. Just empty space and no outp= ut.
>
>
> On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz <nstraz@redhat.com> wrote:
> On Apr 21 10:29, Brandon Stout wrote:
> > hello, I am trying to use conserver to connect to serial ports ov= er ssh and
> > it is hanging. When I go direct it works fine (i am using Opengea= r IMX4248):
> >
> > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002
> ...
> > default full { rw *; }
> > default opengear =C2=A0{ type host; portbase 3000; portinc 1; } > > default * {
> > logfile /var/log/conserver;
> > timestamp 1hab;
> > include full;
> > master localhost;
> > }
> > default console01 { include opengear; host console01; }
> > console dr01.arista { include console01; port 1; }
> > console dr02.arista { include console01; port 2; }
> ...
> > Has anyone gotten this to work using ssh?
>
> I think you need to use the exec host type and setup the right execsub= st
> to get ssh to use the right port number. =C2=A0The "host" ty= pe is just a raw
> TCP socket connection.
>
> Nate
> _______________________________________________
> users mailing list
> users@conserv= er.com
> https://www.conserver.com/mailman/listinfo/users
>
>
>
> --
>
> brandon
>
>
>
> --
>
> brandon
>
>
>
> --
>
> brandon
> _______________________________________________
> users mailing list
> users@conserv= er.com
> https://www.conserver.com/mailman/listinfo/users




<= /div>--

brandon

_______________________________________________
users mailing list
users@conserver.co= m
https://www.conserver.com/mailman/listinfo/users




--
Sent from my new iPhone 6 Watch (prototype), see my reviews = here!
w= ww.conserver.com/consoles/ -- consoleteam.blogspot.com
- - - - - - - -
www.n= cry.org
www.d4tm.o= rg
www.hacke= rdojo.com



--

brandon


--
Sent f= rom my new iPhone 6 Watch (prototype), see my reviews here!
www.conserver.com/cons= oles/ -- = consoleteam.blogspot.com
- - - - - - - -
www.n= cry.org
www.d4tm.o= rg
www.hacke= rdojo.com
--089e013a1d8e628fee04f79525e7-- From bstout@squareup.com Mon Apr 21 22:57:29 2014 Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) by underdog.stansell.org (8.14.7/8.14.7) with ESMTP id s3LMvQIN022836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Apr 2014 22:57:28 GMT Received: by mail-pd0-f174.google.com with SMTP id y13so4162391pdi.33 for ; Mon, 21 Apr 2014 15:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=squareup.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tMiLA/lpKtKe4YS7hQhlE/wIhghBvTaccugocdPTnhY=; b=YY3a8GOsUdUHSzRe27QtqNFA1jYF4vNriHyJ0gSGB8eFYaEFi/qUEof+G1nNQUUg0U 0O/SuwzFUW6lGy9baUmWsnXmv2xjfqQ4sAAWFbRSRzUpzGXndoh5UF5Nm0SmmBqmRrsX 5vE/geAs/ALDNAOhRph2sjpraDP0ZmtALcXzk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tMiLA/lpKtKe4YS7hQhlE/wIhghBvTaccugocdPTnhY=; b=cJ4lvmlxtt6hi2XxeML980U4BlOrOfj2nf27J3oAZrJtJI72/VPDItc6y/jb7bBNZF 8cRHwt8/NUSQCaGk2mTxVIdmy0woI2PD3u5iO9692KnU8XTFMgdg1yN+WuZLwOrwWVP0 C9EniL0/Z5gE0V3o46ePC0HC8xBag3IzxoqQeytalKTOwURMXI37FICeUR4sAWJaANcf nVRUhPEyuFvyBK4hEBGZ6IHYF6gJLCzB7Ce0JlfnnecQlW85eqYF1Vknu2oRDoVHTcnL 000Z4CFmLtqM0CD6id6y4OmpCLLy+5e3EX3zTMIMbLlaS/ENdKuWW1GGp+gxGkWgZytN BM9g== X-Gm-Message-State: ALoCoQmBaEBmNadjJDVHh6MunQk99Ajwv14O/k761kC8ruK4XGk8jtVOqveZKUTKSw0wXgK7nNcg MIME-Version: 1.0 X-Received: by 10.68.184.66 with SMTP id es2mr40721253pbc.19.1398121044763; Mon, 21 Apr 2014 15:57:24 -0700 (PDT) Received: by 10.70.30.228 with HTTP; Mon, 21 Apr 2014 15:57:24 -0700 (PDT) In-Reply-To: References: <20140421173917.GB9600@redhat.com> <60CDA197-F0A1-4291-916B-E6E45713D15C@distal.com> Date: Mon, 21 Apr 2014 15:57:24 -0700 Message-ID: Subject: Re: Conserver and ssh From: Brandon Stout To: Zonker Content-Type: multipart/alternative; boundary=047d7bd76d4439f4f704f7956c86 X-Spam-Score: -1.489 () BAYES_00,HTML_MESSAGE,T_DKIM_INVALID X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 Cc: "users@conserver.com" X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.16 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 22:57:29 -0000 --047d7bd76d4439f4f704f7956c86 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hey Z, This is starting to make a lot more sense. Thanks for the email. It sounds like I may not be able to use it exactly how I wanted to but I can get by with local user/pw on the console server if this is the case. I am using the conserver as both conserver host and conserver client, by which a user will logon to this host to gain console access only to console servers configured locally (nothing distributed). The server is also used for other functions so other users have access to the box who I don't want to have access to the consoles. I was trying to control access via conserver.passwd but it sounds like that is only used for conserver clients outside of the conserver. It seems as though I will just need to create individual accounts on the console server itself and control access there. thanks Brandon On Mon, Apr 21, 2014 at 3:37 PM, Zonker wrote: > Try thinking of authentication in the following model... > > 1) A secure connection from the Conserver host to the console server(s= ). > (Management net, maybe static routes instead of defaults, SSH if > needed) > - Conserver opens a conenction for every configured port, and > starts logging. > 2) User access to the console sessions. > - Maybe the SSH to the conserver, or they have a console client > on their host > - Users "connect" to a given console session... conserver "tees" > them in. > ( User types, data goes to the console... device sends data back, > conserver logs it and forwards the data to the user.) > > In this model, only Conserver would need to know how to log into the > console server. (I make sure my console servers only allow one connectio= n > per serial port in the reverse-TCP mode. This way, if anyone else know ho= w > to access that port and has the credentials, they would be unable to > connect of Conserver got their first. > > Also in this model, users would authenticate on Conserver... either by > SSH to the Conserver host, or with their own conserver client. In the > latter case, the client users need to validate with conserver when they > make the connection, and this would be checked in the conserver.passwd fi= le. > > It's been a great model for many types of administration. But, if it's > not for you, perhaps you can share what make your scenario > different/difficult? > > Best regards, > > -Z- http://www.conserver.com/consoles/ > > You may find a couple of my older LISA tutorials useful, and you can > find them at > http://www.conserver.com/consoles/Training/published.html > > > > On Mon, Apr 21, 2014 at 2:13 PM, Brandon Stout wrote= : > >> Hey Z, >> >> This all makes sense, thanks for the info. From an conserver.passwd >> perspective, is the location and usage of the file need to be called out= in >> the conserver.cf file or should it automatically use it for >> authentication? Right now I have it working being authenticated by the >> Opengear but want to test to see if I can get it working using this file= . >> Is there something I needed to do to get conserver to use the file? >> >> thanks >> Brandon >> >> >> On Mon, Apr 21, 2014 at 1:35 PM, Zonker wrote: >> >>> Chris Ross is correct... The model of conserver connecting (and then >>> trying to maintain connection) is built around the model that a sysadmi= n >>> wants to capture any messages that a console may cough up (memory error= at >>> 0x23484325, root volume at 98%, core dumped, etc.), so that when a syst= em >>> fails to respond on the network, and you try to use the console only to >>> find it unresponsive... THEN is when we are glad that we can tail the l= og >>> file for that device, and see what was happening! :-) >>> >>> Once we see the problem, we can then grep the logs for similar >>> machines, and see if we see any of the early signs of pending failure o= n >>> similar devices in our collection. :-) >>> >>> >>> Using ssh is a way to encrypt the data between the console server and >>> the conserver host. But, as you scale up (think many dozens of console >>> servers, and thousands of ports), consider that SSH on each of those >>> connections is a lot more overhead. Many shops use a dedicated managem= ent >>> subnet and use the telnet option instead. >>> >>> The conserver.passwd is a good option when you want to give someone >>> console access, but not give them shell access on your NIS network. By >>> giving them an account local to your conserver host, and using the loca= l >>> password file, they can access consoles, and no more. >>> >>> In one case, where I needed to give contractors access to *some* >>> consoles, I installed conserver where the contractors had access (rathe= r >>> than letting them have access to my primary logs), and had this >>> conserver.passwd; >>> >>> cat /usr/local/etc/conserver.passwd >>> # Users can either have a pre-defined account name here, >>> # or they can refer to an existing shell account... >>> # for Shell accounts, "*passwd*" means to use their shell passwd >>> # Or, you can enforce a pre-assigned password, by adding a crypted stri= ng >>> # (this bypasses the shell passwd, forcing them to use the console >>> passwd) >>> # perl -e 'print crypt("password","Ah")."\n";' >>> # The "Ah" picks the first two characters of the password, and is the >>> "salt" >>> # used for the crypt... >>> root: >>> temp_FE:ceOfgr9fefOqNw >>> # Contractor users must come to their consoles from a CLUSTER_HOST >>> v-prtent:*passwd* >>> v-boulder:*passwd* >>> *any*:*passwd* >>> >>> Also, "temp_FE" was an account when they needed someone more random to >>> come in and work on the devices, and we could change that password at w= ill. >>> >>> Best regards, >>> >>> -Z- >>> >>> >>> >>> On Mon, Apr 21, 2014 at 12:25 PM, Brandon Stout wr= ote: >>> >>>> Thanks for the reply Chris. You are correct, it is not using the >>>> local/conserver password but just the console server (opengear) passwo= rd. I >>>> actually don't really care which password to use, as long as it asks f= or a >>>> password anytime someone wants to connect to a console port. It works >>>> correctly if you just ssh to the console via port 30xx. But when using >>>> conserver, it just asks once and that is it. Looking at the logs, it l= ooks >>>> like it conserver tries to login to every port preemptively and keep i= t >>>> open as opposed to just opening a session when someone asks for it. Is >>>> there a way to change this behavior? >>>> >>>> >>>> On Mon, Apr 21, 2014 at 12:13 PM, Chris Ross < >>>> cross+conserver@distal.com> wrote: >>>> >>>>> >>>>> =E2=80=9CYour milage may vary=E2=80=9D, but for myself, I=E2=80=99m= consoling UNIX servers, >>>>> so I want their console output to be logged even when noone is connec= ted. >>>>> To accomplish this, I have a script that will log into the session f= or me >>>>> upon initialization of the console, and then stay attached. As you= =E2=80=99ve >>>>> determined, conserver leaves the TCP connection active, so you don=E2= =80=99t need >>>>> to authenticate against the ssh connection again after the initial >>>>> connection. >>>>> >>>>> I suspect you=E2=80=99re not getting it to use the local/conserver = password >>>>> at all, or else when you first start up, you=E2=80=99d have to enter = both, in the >>>>> correct sequence. One to connect to the established ssh command, the= n >>>>> another to ssh to authenticate the network connection. >>>>> >>>>> So, I guess you need to decide whether you want to have the >>>>> connection drop and reestablish, which is what you seemed to be askin= g for, >>>>> or rather want just to get the conserver password prompting working, = which >>>>> I=E2=80=99m not doing, so can=E2=80=99t help with directly. >>>>> >>>>> Thoughts and information that I hope is helpful. >>>>> >>>>> - Chris >>>>> >>>>> On Apr 21, 2014, at 14:38, Brandon Stout wrote: >>>>> >>>>> > Also, how does the conserver.passwd work? When does it use that >>>>> rather than the authentication on the Opengear itself? To test, I hav= e the >>>>> same user on the Opengear as well as in the conserver.passwd with dif= ferent >>>>> passwords to see where it gets its passwords from. So far it just loo= ks >>>>> like it is using the password from the Opengear. I configured conserv= er >>>>> with all the defaults so I am assuming conserver.passwd just needs to= exist >>>>> within the same directory as conserver.cf. Did I configure something >>>>> incorrectly or does there need to be a line in the conserver.cf file >>>>> to point to where conserver.passwd exists? >>>>> > >>>>> > >>>>> > On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout >>>>> wrote: >>>>> > So I actually figured out the problem so now it connects, I get the >>>>> password prompt and when I enter it correctly it works. The problem i= s that >>>>> when I disconnect and reconnect, it no longer asks me for a password = and >>>>> just puts me through to the console. is there some sort of disconnect= I >>>>> need to do manually to get it to reset and ask for a password? Seems = like >>>>> it just stays connected once the pw is entered, regardless of someone >>>>> exiting. >>>>> > >>>>> > >>>>> > On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout >>>>> wrote: >>>>> > thanks Nathan, I actually was trying that right after I sent this >>>>> email and added this >>>>> > >>>>> > default opengear-ssh { type exec; portbase 2000; portinc 1; >>>>> > exec /usr/bin/ssh -p P -l tsuser H; >>>>> > execsubst H=3Dhs,P=3DPd; } >>>>> > >>>>> > still not working though with just about nothing useful in the logs= . >>>>> Doesn't hang but it still doesn't work. Just empty space and no outpu= t. >>>>> > >>>>> > >>>>> > On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz >>>>> wrote: >>>>> > On Apr 21 10:29, Brandon Stout wrote: >>>>> > > hello, I am trying to use conserver to connect to serial ports >>>>> over ssh and >>>>> > > it is hanging. When I go direct it works fine (i am using Opengea= r >>>>> IMX4248): >>>>> > > >>>>> > > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002 >>>>> > ... >>>>> > > default full { rw *; } >>>>> > > default opengear { type host; portbase 3000; portinc 1; } >>>>> > > default * { >>>>> > > logfile /var/log/conserver; >>>>> > > timestamp 1hab; >>>>> > > include full; >>>>> > > master localhost; >>>>> > > } >>>>> > > default console01 { include opengear; host console01; } >>>>> > > console dr01.arista { include console01; port 1; } >>>>> > > console dr02.arista { include console01; port 2; } >>>>> > ... >>>>> > > Has anyone gotten this to work using ssh? >>>>> > >>>>> > I think you need to use the exec host type and setup the right >>>>> execsubst >>>>> > to get ssh to use the right port number. The "host" type is just a >>>>> raw >>>>> > TCP socket connection. >>>>> > >>>>> > Nate >>>>> > _______________________________________________ >>>>> > users mailing list >>>>> > users@conserver.com >>>>> > https://www.conserver.com/mailman/listinfo/users >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > >>>>> > brandon >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > >>>>> > brandon >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > >>>>> > brandon >>>>> > _______________________________________________ >>>>> > users mailing list >>>>> > users@conserver.com >>>>> > https://www.conserver.com/mailman/listinfo/users >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> brandon >>>> >>>> _______________________________________________ >>>> users mailing list >>>> users@conserver.com >>>> https://www.conserver.com/mailman/listinfo/users >>>> >>>> >>> >>> >>> -- >>> Sent from my new iPhone 6 Watch (prototype), see my reviews here! >>> www.conserver.com/consoles/ -- consoleteam.blogspot.com >>> - - - - - - - - >>> www.ncry.org >>> www.d4tm.org >>> www.hackerdojo.com >>> >> >> >> >> -- >> >> brandon >> > > > > -- > Sent from my new iPhone 6 Watch (prototype), see my reviews here! > www.conserver.com/consoles/ -- consoleteam.blogspot.com > - - - - - - - - > www.ncry.org > www.d4tm.org > www.hackerdojo.com > --=20 brandon --047d7bd76d4439f4f704f7956c86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Z,

This is starting to make a lot m= ore sense. Thanks for the email. It sounds like I may not be able to use it= exactly how I wanted to but I can get by with local user/pw on the console= server if this is the case. I am using the conserver as both conserver hos= t and conserver client, by which a user will logon to this host to gain con= sole access only to console servers configured locally (nothing distributed= ). The server is also used for other functions so other users have access t= o the box who I don't want to have access to the consoles. I was trying= to control access via conserver.passwd but it sounds like that is only use= d for conserver clients outside of the conserver. It seems as though I will= just need to create individual accounts on the console server itself and c= ontrol access there.=C2=A0

thanks
Brandon


On Mon, Apr 21, 2014 at 3:37 PM,= Zonker <consoleteam@gmail.com> wrote:
Try thinking of= authentication in the following model...

=C2=A0 1)=C2=A0 A secure connection from the Conserver host to the console = server(s).
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 (Management net, maybe static routes instead of defaults, SSH if nee= ded)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Conserver op= ens a conenction for every configured port, and starts logging.
=C2=A0 2)=C2=A0 User access to the console sessions.
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -=C2=A0 Maybe the SSH to the con= server, or they have a console client on their host
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Users "= connect" to a given console session... conserver "tees" them= in.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ( User types, data goes to the c= onsole... device sends data back, conserver logs it and forwards the data t= o the user.)

=C2=A0 In this model, only Conserver would need to know how to log into the= console server.=C2=A0 (I make sure my console servers only allow one conne= ction per serial port in the reverse-TCP mode. This way, if anyone else kno= w how to access that port and has the credentials, they would be unable to = connect of Conserver got their first.

=C2=A0 Also in this model, users would authenticate o= n Conserver... either by SSH to the Conserver host, or with their own conse= rver client. In the latter case, the client users need to validate with con= server when they make the connection, and this would be checked in the cons= erver.passwd file.

=C2=A0 It's been a great model for many types of = administration. But, if it's not for you, perhaps you can share what ma= ke your scenario different/difficult?

=C2=A0=C2=A0=C2=A0=C2=A0 Best regards,

=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 -Z-=C2=A0=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 http://www.conserver.com/consoles/

=C2=A0 You may find a couple of my older LISA tutorials useful, and you can= find them at
http://www.conserver.com/consoles/Training/published.html =



On Mon, Apr 21, 2014 at 2:13 PM, Brandon= Stout <bstout@squareup.com> wrote:
Hey Z,

T= his all makes sense, thanks for the info. From an conserver.passwd perspect= ive, is the location and usage of the file need to be called out in the conserver.cf file or sho= uld it automatically use it for authentication? Right now I have it working= being authenticated by the Opengear but want to test to see if I can get i= t working using this file. Is there something I needed to do to get conserv= er to use the file?

thanks
Brandon


On Mon, Apr 21, 2014 a= t 1:35 PM, Zonker <consoleteam@gmail.com> wrote:
=C2=A0 Chris Ro= ss is correct... The model of conserver connecting (and then trying to main= tain connection) is built around the model that a sysadmin wants to capture= any messages that a console may cough up (memory error at 0x23484325, root= volume at 98%, core dumped, etc.), so that when a system fails to respond = on the network, and you try to use the console only to find it unresponsive= ... THEN is when we are glad that we can tail the log file for that device,= and see what was happening!=C2=A0 :-)

=C2=A0 Once we see the problem, we can then grep the = logs for similar machines, and see if we see any of the early signs of pend= ing failure on similar devices in our collection. :-)


=C2=A0 Using ssh is a way to encrypt the data bet= ween the console server and the conserver host. But, as you scale up (think= many dozens of console servers, and thousands of ports), consider that SSH= on each of those connections is a lot more overhead.=C2=A0 Many shops use = a dedicated management subnet and use the telnet option instead.

=C2=A0 The conserver.passwd is a good option when you= want to give someone console access, but not give them shell access on you= r NIS network. By giving them an account local to your conserver host, and = using the local password file, they can access consoles, and no more.

=C2=A0 In one case, where I needed to give contractor= s access to *some* consoles, I installed conserver where the contractors ha= d access (rather than letting them have access to my primary logs), and had= this conserver.passwd;

=C2=A0cat /usr/local/etc/conserver.passwd
# Users can either have a = pre-defined account name here,
# or they can refer to an existing shell = account...
#=C2=A0 for Shell accounts, "*passwd*" means to use= their shell passwd
# Or, you can enforce a pre-assigned password, by adding a crypted string#=C2=A0 (this bypasses the shell passwd, forcing them to use the console = passwd)
# perl -e 'print crypt("password","Ah").= "\n";'
#=C2=A0 The "Ah" picks the first two characters of the password, = and is the "salt"
#=C2=A0 used for the crypt...
root:
te= mp_FE:ceOfgr9fefOqNw
# Contractor users must come to their consoles from= a CLUSTER_HOST
v-prtent:*passwd*
v-boulder:*passwd*
*any*:*passwd*

Also, "temp_FE" was an account when they needed someone m= ore random to come in and work on the devices, and we could change that pas= sword at will.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Best regards,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 -Z-



On Mon, Apr 21, 2014 at 12:25 PM, Brandon Stout <bstout@squ= areup.com> wrote:
Thanks for the reply Chris.= You are correct, it is not using the local/conserver password but just the= console server (opengear) password. I actually don't really care which= password to use, as long as it asks for a password anytime someone wants t= o connect to a console port. It works correctly if you just ssh to the cons= ole via port 30xx. But when using conserver, it just asks once and that is = it. Looking at the logs, it looks like it conserver tries to login to every= port preemptively and keep it open as opposed to just opening a session wh= en someone asks for it. Is there a way to change this behavior?


On = Mon, Apr 21, 2014 at 12:13 PM, Chris Ross <cross+conserver@distal= .com> wrote:

=C2=A0 =E2=80=9CYour milage may vary=E2=80=9D, but for myself, I=E2=80=99m = consoling UNIX servers, so I want their console output to be logged even wh= en noone is connected. =C2=A0To accomplish this, I have a script that will = log into the session for me upon initialization of the console, and then st= ay attached. =C2=A0As you=E2=80=99ve determined, conserver leaves the TCP c= onnection active, so you don=E2=80=99t need to authenticate against the ssh= connection again after the initial connection.

=C2=A0 I suspect you=E2=80=99re not getting it to use the local/conserver p= assword at all, or else when you first start up, you=E2=80=99d have to ente= r both, in the correct sequence. =C2=A0One to connect to the established ss= h command, then another to ssh to authenticate the network connection.

=C2=A0 So, I guess you need to decide whether you want to have the connecti= on drop and reestablish, which is what you seemed to be asking for, or rath= er want just to get the conserver password prompting working, which I=E2=80= =99m not doing, so can=E2=80=99t help with directly.

=C2=A0 Thoughts and information that I hope is helpful.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Chris

On Apr 21, 2014, at 14:38, Brandon Stout <bstout@squareup.com> wrote:

> Also, how does the conserver.passwd work? When does it use that rather= than the authentication on the Opengear itself? To test, I have the same u= ser on the Opengear as well as in the conserver.passwd with different passw= ords to see where it gets its passwords from. So far it just looks like it = is using the password from the Opengear. I configured conserver with all th= e defaults so I am assuming conserver.passwd just needs to exist within the= same directory as conser= ver.cf. Did I configure something incorrectly or does there need to be = a line in the conserver.c= f file to point to where conserver.passwd exists?
>
>
> On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout <bstout@squareup.com> wrote: > So I actually figured out the problem so now it connects, I get the pa= ssword prompt and when I enter it correctly it works. The problem is that w= hen I disconnect and reconnect, it no longer asks me for a password and jus= t puts me through to the console. is there some sort of disconnect I need t= o do manually to get it to reset and ask for a password? Seems like it just= stays connected once the pw is entered, regardless of someone exiting.
>
>
> On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout <bstout@squareup.com> wrote: > thanks Nathan, I actually was trying that right after I sent this emai= l and added this
>
> default opengear-ssh { type exec; portbase 2000; portinc 1;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e= xec /usr/bin/ssh -p P -l tsuser H;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e= xecsubst H=3Dhs,P=3DPd; }
>
> still not working though with just about nothing useful in the logs. D= oesn't hang but it still doesn't work. Just empty space and no outp= ut.
>
>
> On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz <nstraz@redhat.com> wrote:
> On Apr 21 10:29, Brandon Stout wrote:
> > hello, I am trying to use conserver to connect to serial ports ov= er ssh and
> > it is hanging. When I go direct it works fine (i am using Opengea= r IMX4248):
> >
> > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002
> ...
> > default full { rw *; }
> > default opengear =C2=A0{ type host; portbase 3000; portinc 1; } > > default * {
> > logfile /var/log/conserver;
> > timestamp 1hab;
> > include full;
> > master localhost;
> > }
> > default console01 { include opengear; host console01; }
> > console dr01.arista { include console01; port 1; }
> > console dr02.arista { include console01; port 2; }
> ...
> > Has anyone gotten this to work using ssh?
>
> I think you need to use the exec host type and setup the right execsub= st
> to get ssh to use the right port number. =C2=A0The "host" ty= pe is just a raw
> TCP socket connection.
>
> Nate
> _______________________________________________
> users mailing list
> users@conserv= er.com
> https://www.conserver.com/mailman/listinfo/users
>
>
>
> --
>
> brandon
>
>
>
> --
>
> brandon
>
>
>
> --
>
> brandon
> _______________________________________________
> users mailing list
> users@conserv= er.com
> https://www.conserver.com/mailman/listinfo/users




<= /div>--

brandon

_______________________________________________
users mailing list
users@conserver.co= m
https://www.conserver.com/mailman/listinfo/users




--
Sent from my new iPhone 6 Watch (prototype), see my reviews = here!
w= ww.conserver.com/consoles/ -- consoleteam.blogspot.com
- - - - - - - -
www.n= cry.org
www.d4tm.o= rg
www.hacke= rdojo.com



<= font color=3D"#888888">--

brandon



--
Sent f= rom my new iPhone 6 Watch (prototype), see my reviews here!
www.conserver.com/cons= oles/ -- = consoleteam.blogspot.com
- - - - - - - -
www.n= cry.org
www.d4tm.o= rg
www.hacke= rdojo.com



--
=
brandon
--047d7bd76d4439f4f704f7956c86-- From consoleteam@gmail.com Mon Apr 21 23:15:06 2014 Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) by underdog.stansell.org (8.14.7/8.14.7) with ESMTP id s3LNF2nB029361 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Apr 2014 23:15:04 GMT Received: by mail-ig0-f171.google.com with SMTP id c1so2330254igq.10 for ; Mon, 21 Apr 2014 16:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O2aXIZfJa/jhMYZROs21YOeeQT1Si9sOKaj9rTjNd88=; b=MgLLdiq1KdYlUNIZyuiAmOOetvDccd4xGXkucr91XVH4bfuNT8xHw1xK9GmW+u1tZK DzSt4XRbe4ZgWdqJC4oqDNOCVGKoN/Izdh/pkbqNhX9u0KY+RWLcszrAgyEZvCPT0LzZ 5rLb/LYgLwZ+Gx823yxaRXp5Bsm6o0DO5OYic3BOkwef0ByZBE+N2+jlDJtgVKmbe8z6 Vrr4666HmqwFKbovfhYcyXA3722OqJeqENrOPLlizTd0MFvWdGI5k0yiWqII9WeFvmKp sWhkVJ0GpW0ku8pipSWV0cJAVm1QYG0nKVkPYzMj70b1Odx6AbjvGpFYfnNpusbQqmnm yLXQ== MIME-Version: 1.0 X-Received: by 10.50.109.230 with SMTP id hv6mr25738200igb.9.1398122101814; Mon, 21 Apr 2014 16:15:01 -0700 (PDT) Received: by 10.43.56.74 with HTTP; Mon, 21 Apr 2014 16:15:01 -0700 (PDT) In-Reply-To: References: <20140421173917.GB9600@redhat.com> <60CDA197-F0A1-4291-916B-E6E45713D15C@distal.com> Date: Mon, 21 Apr 2014 16:15:01 -0700 Message-ID: Subject: Re: Conserver and ssh From: Zonker To: Brandon Stout Content-Type: multipart/alternative; boundary=089e013a1d8e3b404404f795abfc X-Spam-Score: -1.488 () BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,T_DKIM_INVALID X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 Cc: "users@conserver.com" X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.16 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 23:15:06 -0000 --089e013a1d8e3b404404f795abfc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There is a lot of good features that come from using the model I describe, especially if you may need to scale-up the deployment later. If you can afford the time, try to get through the two LISA presentations from 2002. (It's free... :-) If they don't entice you, going directly to the console server may be good enough for your needs. Best regards, -Z- On Mon, Apr 21, 2014 at 3:57 PM, Brandon Stout wrote: > Hey Z, > > This is starting to make a lot more sense. Thanks for the email. It sound= s > like I may not be able to use it exactly how I wanted to but I can get by > with local user/pw on the console server if this is the case. I am using > the conserver as both conserver host and conserver client, by which a use= r > will logon to this host to gain console access only to console servers > configured locally (nothing distributed). The server is also used for oth= er > functions so other users have access to the box who I don't want to have > access to the consoles. I was trying to control access via conserver.pass= wd > but it sounds like that is only used for conserver clients outside of the > conserver. It seems as though I will just need to create individual > accounts on the console server itself and control access there. > > thanks > Brandon > > > On Mon, Apr 21, 2014 at 3:37 PM, Zonker wrote: > >> Try thinking of authentication in the following model... >> >> 1) A secure connection from the Conserver host to the console >> server(s). >> (Management net, maybe static routes instead of defaults, SSH i= f >> needed) >> - Conserver opens a conenction for every configured port, and >> starts logging. >> 2) User access to the console sessions. >> - Maybe the SSH to the conserver, or they have a console client >> on their host >> - Users "connect" to a given console session... conserver "tees" >> them in. >> ( User types, data goes to the console... device sends data back= , >> conserver logs it and forwards the data to the user.) >> >> In this model, only Conserver would need to know how to log into the >> console server. (I make sure my console servers only allow one connecti= on >> per serial port in the reverse-TCP mode. This way, if anyone else know h= ow >> to access that port and has the credentials, they would be unable to >> connect of Conserver got their first. >> >> Also in this model, users would authenticate on Conserver... either by >> SSH to the Conserver host, or with their own conserver client. In the >> latter case, the client users need to validate with conserver when they >> make the connection, and this would be checked in the conserver.passwd f= ile. >> >> It's been a great model for many types of administration. But, if it's >> not for you, perhaps you can share what make your scenario >> different/difficult? >> >> Best regards, >> >> -Z- http://www.conserver.com/consoles/ >> >> You may find a couple of my older LISA tutorials useful, and you can >> find them at >> http://www.conserver.com/consoles/Training/published.html >> >> >> >> On Mon, Apr 21, 2014 at 2:13 PM, Brandon Stout wrot= e: >> >>> Hey Z, >>> >>> This all makes sense, thanks for the info. From an conserver.passwd >>> perspective, is the location and usage of the file need to be called ou= t in >>> the conserver.cf file or should it automatically use it for >>> authentication? Right now I have it working being authenticated by the >>> Opengear but want to test to see if I can get it working using this fil= e. >>> Is there something I needed to do to get conserver to use the file? >>> >>> thanks >>> Brandon >>> >>> >>> On Mon, Apr 21, 2014 at 1:35 PM, Zonker wrote: >>> >>>> Chris Ross is correct... The model of conserver connecting (and then >>>> trying to maintain connection) is built around the model that a sysadm= in >>>> wants to capture any messages that a console may cough up (memory erro= r at >>>> 0x23484325, root volume at 98%, core dumped, etc.), so that when a sys= tem >>>> fails to respond on the network, and you try to use the console only t= o >>>> find it unresponsive... THEN is when we are glad that we can tail the = log >>>> file for that device, and see what was happening! :-) >>>> >>>> Once we see the problem, we can then grep the logs for similar >>>> machines, and see if we see any of the early signs of pending failure = on >>>> similar devices in our collection. :-) >>>> >>>> >>>> Using ssh is a way to encrypt the data between the console server an= d >>>> the conserver host. But, as you scale up (think many dozens of console >>>> servers, and thousands of ports), consider that SSH on each of those >>>> connections is a lot more overhead. Many shops use a dedicated manage= ment >>>> subnet and use the telnet option instead. >>>> >>>> The conserver.passwd is a good option when you want to give someone >>>> console access, but not give them shell access on your NIS network. By >>>> giving them an account local to your conserver host, and using the loc= al >>>> password file, they can access consoles, and no more. >>>> >>>> In one case, where I needed to give contractors access to *some* >>>> consoles, I installed conserver where the contractors had access (rath= er >>>> than letting them have access to my primary logs), and had this >>>> conserver.passwd; >>>> >>>> cat /usr/local/etc/conserver.passwd >>>> # Users can either have a pre-defined account name here, >>>> # or they can refer to an existing shell account... >>>> # for Shell accounts, "*passwd*" means to use their shell passwd >>>> # Or, you can enforce a pre-assigned password, by adding a crypted >>>> string >>>> # (this bypasses the shell passwd, forcing them to use the console >>>> passwd) >>>> # perl -e 'print crypt("password","Ah")."\n";' >>>> # The "Ah" picks the first two characters of the password, and is the >>>> "salt" >>>> # used for the crypt... >>>> root: >>>> temp_FE:ceOfgr9fefOqNw >>>> # Contractor users must come to their consoles from a CLUSTER_HOST >>>> v-prtent:*passwd* >>>> v-boulder:*passwd* >>>> *any*:*passwd* >>>> >>>> Also, "temp_FE" was an account when they needed someone more random to >>>> come in and work on the devices, and we could change that password at = will. >>>> >>>> Best regards, >>>> >>>> -Z- >>>> >>>> >>>> >>>> On Mon, Apr 21, 2014 at 12:25 PM, Brandon Stout w= rote: >>>> >>>>> Thanks for the reply Chris. You are correct, it is not using the >>>>> local/conserver password but just the console server (opengear) passw= ord. I >>>>> actually don't really care which password to use, as long as it asks = for a >>>>> password anytime someone wants to connect to a console port. It works >>>>> correctly if you just ssh to the console via port 30xx. But when usin= g >>>>> conserver, it just asks once and that is it. Looking at the logs, it = looks >>>>> like it conserver tries to login to every port preemptively and keep = it >>>>> open as opposed to just opening a session when someone asks for it. I= s >>>>> there a way to change this behavior? >>>>> >>>>> >>>>> On Mon, Apr 21, 2014 at 12:13 PM, Chris Ross < >>>>> cross+conserver@distal.com> wrote: >>>>> >>>>>> >>>>>> =E2=80=9CYour milage may vary=E2=80=9D, but for myself, I=E2=80=99= m consoling UNIX servers, >>>>>> so I want their console output to be logged even when noone is conne= cted. >>>>>> To accomplish this, I have a script that will log into the session = for me >>>>>> upon initialization of the console, and then stay attached. As you= =E2=80=99ve >>>>>> determined, conserver leaves the TCP connection active, so you don= =E2=80=99t need >>>>>> to authenticate against the ssh connection again after the initial >>>>>> connection. >>>>>> >>>>>> I suspect you=E2=80=99re not getting it to use the local/conserver= password >>>>>> at all, or else when you first start up, you=E2=80=99d have to enter= both, in the >>>>>> correct sequence. One to connect to the established ssh command, th= en >>>>>> another to ssh to authenticate the network connection. >>>>>> >>>>>> So, I guess you need to decide whether you want to have the >>>>>> connection drop and reestablish, which is what you seemed to be aski= ng for, >>>>>> or rather want just to get the conserver password prompting working,= which >>>>>> I=E2=80=99m not doing, so can=E2=80=99t help with directly. >>>>>> >>>>>> Thoughts and information that I hope is helpful. >>>>>> >>>>>> - Chris >>>>>> >>>>>> On Apr 21, 2014, at 14:38, Brandon Stout wrote= : >>>>>> >>>>>> > Also, how does the conserver.passwd work? When does it use that >>>>>> rather than the authentication on the Opengear itself? To test, I ha= ve the >>>>>> same user on the Opengear as well as in the conserver.passwd with di= fferent >>>>>> passwords to see where it gets its passwords from. So far it just lo= oks >>>>>> like it is using the password from the Opengear. I configured conser= ver >>>>>> with all the defaults so I am assuming conserver.passwd just needs t= o exist >>>>>> within the same directory as conserver.cf. Did I configure something >>>>>> incorrectly or does there need to be a line in the conserver.cf file >>>>>> to point to where conserver.passwd exists? >>>>>> > >>>>>> > >>>>>> > On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout < >>>>>> bstout@squareup.com> wrote: >>>>>> > So I actually figured out the problem so now it connects, I get th= e >>>>>> password prompt and when I enter it correctly it works. The problem = is that >>>>>> when I disconnect and reconnect, it no longer asks me for a password= and >>>>>> just puts me through to the console. is there some sort of disconnec= t I >>>>>> need to do manually to get it to reset and ask for a password? Seems= like >>>>>> it just stays connected once the pw is entered, regardless of someon= e >>>>>> exiting. >>>>>> > >>>>>> > >>>>>> > On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout < >>>>>> bstout@squareup.com> wrote: >>>>>> > thanks Nathan, I actually was trying that right after I sent this >>>>>> email and added this >>>>>> > >>>>>> > default opengear-ssh { type exec; portbase 2000; portinc 1; >>>>>> > exec /usr/bin/ssh -p P -l tsuser H; >>>>>> > execsubst H=3Dhs,P=3DPd; } >>>>>> > >>>>>> > still not working though with just about nothing useful in the >>>>>> logs. Doesn't hang but it still doesn't work. Just empty space and n= o >>>>>> output. >>>>>> > >>>>>> > >>>>>> > On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz >>>>>> wrote: >>>>>> > On Apr 21 10:29, Brandon Stout wrote: >>>>>> > > hello, I am trying to use conserver to connect to serial ports >>>>>> over ssh and >>>>>> > > it is hanging. When I go direct it works fine (i am using >>>>>> Opengear IMX4248): >>>>>> > > >>>>>> > > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002 >>>>>> > ... >>>>>> > > default full { rw *; } >>>>>> > > default opengear { type host; portbase 3000; portinc 1; } >>>>>> > > default * { >>>>>> > > logfile /var/log/conserver; >>>>>> > > timestamp 1hab; >>>>>> > > include full; >>>>>> > > master localhost; >>>>>> > > } >>>>>> > > default console01 { include opengear; host console01; } >>>>>> > > console dr01.arista { include console01; port 1; } >>>>>> > > console dr02.arista { include console01; port 2; } >>>>>> > ... >>>>>> > > Has anyone gotten this to work using ssh? >>>>>> > >>>>>> > I think you need to use the exec host type and setup the right >>>>>> execsubst >>>>>> > to get ssh to use the right port number. The "host" type is just = a >>>>>> raw >>>>>> > TCP socket connection. >>>>>> > >>>>>> > Nate >>>>>> > _______________________________________________ >>>>>> > users mailing list >>>>>> > users@conserver.com >>>>>> > https://www.conserver.com/mailman/listinfo/users >>>>>> > >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > >>>>>> > brandon >>>>>> > >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > >>>>>> > brandon >>>>>> > >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > >>>>>> > brandon >>>>>> > _______________________________________________ >>>>>> > users mailing list >>>>>> > users@conserver.com >>>>>> > https://www.conserver.com/mailman/listinfo/users >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> brandon >>>>> >>>>> _______________________________________________ >>>>> users mailing list >>>>> users@conserver.com >>>>> https://www.conserver.com/mailman/listinfo/users >>>>> >>>>> >>>> >>>> >>>> -- >>>> Sent from my new iPhone 6 Watch (prototype), see my reviews here! >>>> www.conserver.com/consoles/ -- consoleteam.blogspot.com >>>> - - - - - - - - >>>> www.ncry.org >>>> www.d4tm.org >>>> www.hackerdojo.com >>>> >>> >>> >>> >>> -- >>> >>> brandon >>> >> >> >> >> -- >> Sent from my new iPhone 6 Watch (prototype), see my reviews here! >> www.conserver.com/consoles/ -- consoleteam.blogspot.com >> - - - - - - - - >> www.ncry.org >> www.d4tm.org >> www.hackerdojo.com >> > > > > -- > > brandon > --=20 Sent from my new iPhone 6 Watch (prototype), see my reviews here! www.conserver.com/consoles/ -- consoleteam.blogspot.com - - - - - - - - www.ncry.org www.d4tm.org www.hackerdojo.com --089e013a1d8e3b404404f795abfc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0 There is a lot of good features that co= me from using the model I describe, especially if you may need to scale-up = the deployment later.

=C2=A0 If you can afford the time, try to get through= the two LISA presentations from 2002.=C2=A0 (It's free... :-)=C2=A0 If= they don't entice you, going directly to the console server may be goo= d enough for your needs.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Best regards,

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -Z-



On Mon, Apr 21, 2014 at 3:57 PM, Brandon Stout <bstout@squareup.com> wrote:
Hey Z,

T= his is starting to make a lot more sense. Thanks for the email. It sounds l= ike I may not be able to use it exactly how I wanted to but I can get by wi= th local user/pw on the console server if this is the case. I am using the = conserver as both conserver host and conserver client, by which a user will= logon to this host to gain console access only to console servers configur= ed locally (nothing distributed). The server is also used for other functio= ns so other users have access to the box who I don't want to have acces= s to the consoles. I was trying to control access via conserver.passwd but = it sounds like that is only used for conserver clients outside of the conse= rver. It seems as though I will just need to create individual accounts on = the console server itself and control access there.=C2=A0

thanks
Brandon


On Mon, A= pr 21, 2014 at 3:37 PM, Zonker <consoleteam@gmail.com> w= rote:
Try thinking of= authentication in the following model...

=C2=A0 1)=C2=A0 A secure connection from the Conserver host to the console = server(s).
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 (Management net, maybe static routes instead of defaults, SSH if nee= ded)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Conserver op= ens a conenction for every configured port, and starts logging.
=C2=A0 2)=C2=A0 User access to the console sessions.
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -=C2=A0 Maybe the SSH to the con= server, or they have a console client on their host
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Users "= connect" to a given console session... conserver "tees" them= in.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ( User types, data goes to the c= onsole... device sends data back, conserver logs it and forwards the data t= o the user.)

=C2=A0 In this model, only Conserver would need to know how to log into the= console server.=C2=A0 (I make sure my console servers only allow one conne= ction per serial port in the reverse-TCP mode. This way, if anyone else kno= w how to access that port and has the credentials, they would be unable to = connect of Conserver got their first.

=C2=A0 Also in this model, users would authenticate o= n Conserver... either by SSH to the Conserver host, or with their own conse= rver client. In the latter case, the client users need to validate with con= server when they make the connection, and this would be checked in the cons= erver.passwd file.

=C2=A0 It's been a great model for many types of = administration. But, if it's not for you, perhaps you can share what ma= ke your scenario different/difficult?

=C2=A0=C2=A0=C2=A0=C2=A0 Best regards,

=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 -Z-=C2=A0=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 http://www.conserver.com/consoles/

=C2=A0 You may find a couple of my older LISA tutorials useful, and you can= find them at
http://www.conserver.com/consoles/Training/published.html =



On Mon, Apr 21, 2014 at 2:13 PM, Brandon= Stout <bstout@squareup.com> wrote:
Hey Z,

T= his all makes sense, thanks for the info. From an conserver.passwd perspect= ive, is the location and usage of the file need to be called out in the conserver.cf file or sho= uld it automatically use it for authentication? Right now I have it working= being authenticated by the Opengear but want to test to see if I can get i= t working using this file. Is there something I needed to do to get conserv= er to use the file?

thanks
Brandon


On Mon, Apr 21, 2014 a= t 1:35 PM, Zonker <consoleteam@gmail.com> wrote:
=C2=A0 Chris Ro= ss is correct... The model of conserver connecting (and then trying to main= tain connection) is built around the model that a sysadmin wants to capture= any messages that a console may cough up (memory error at 0x23484325, root= volume at 98%, core dumped, etc.), so that when a system fails to respond = on the network, and you try to use the console only to find it unresponsive= ... THEN is when we are glad that we can tail the log file for that device,= and see what was happening!=C2=A0 :-)

=C2=A0 Once we see the problem, we can then grep the = logs for similar machines, and see if we see any of the early signs of pend= ing failure on similar devices in our collection. :-)


=C2=A0 Using ssh is a way to encrypt the data bet= ween the console server and the conserver host. But, as you scale up (think= many dozens of console servers, and thousands of ports), consider that SSH= on each of those connections is a lot more overhead.=C2=A0 Many shops use = a dedicated management subnet and use the telnet option instead.

=C2=A0 The conserver.passwd is a good option when you= want to give someone console access, but not give them shell access on you= r NIS network. By giving them an account local to your conserver host, and = using the local password file, they can access consoles, and no more.

=C2=A0 In one case, where I needed to give contractor= s access to *some* consoles, I installed conserver where the contractors ha= d access (rather than letting them have access to my primary logs), and had= this conserver.passwd;

=C2=A0cat /usr/local/etc/conserver.passwd
# Users can either have a = pre-defined account name here,
# or they can refer to an existing shell = account...
#=C2=A0 for Shell accounts, "*passwd*" means to use= their shell passwd
# Or, you can enforce a pre-assigned password, by adding a crypted string#=C2=A0 (this bypasses the shell passwd, forcing them to use the console = passwd)
# perl -e 'print crypt("password","Ah").= "\n";'
#=C2=A0 The "Ah" picks the first two characters of the password, = and is the "salt"
#=C2=A0 used for the crypt...
root:
te= mp_FE:ceOfgr9fefOqNw
# Contractor users must come to their consoles from= a CLUSTER_HOST
v-prtent:*passwd*
v-boulder:*passwd*
*any*:*passwd*

Also, "temp_FE" was an account when they needed someone m= ore random to come in and work on the devices, and we could change that pas= sword at will.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Best regards,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 -Z-



On Mon, Apr 21, 2014 at 12:25 PM, Brandon Stout <bstout@squ= areup.com> wrote:
Thanks for the reply Chris.= You are correct, it is not using the local/conserver password but just the= console server (opengear) password. I actually don't really care which= password to use, as long as it asks for a password anytime someone wants t= o connect to a console port. It works correctly if you just ssh to the cons= ole via port 30xx. But when using conserver, it just asks once and that is = it. Looking at the logs, it looks like it conserver tries to login to every= port preemptively and keep it open as opposed to just opening a session wh= en someone asks for it. Is there a way to change this behavior?


On = Mon, Apr 21, 2014 at 12:13 PM, Chris Ross <cross+conserver@distal= .com> wrote:

=C2=A0 =E2=80=9CYour milage may vary=E2=80=9D, but for myself, I=E2=80=99m = consoling UNIX servers, so I want their console output to be logged even wh= en noone is connected. =C2=A0To accomplish this, I have a script that will = log into the session for me upon initialization of the console, and then st= ay attached. =C2=A0As you=E2=80=99ve determined, conserver leaves the TCP c= onnection active, so you don=E2=80=99t need to authenticate against the ssh= connection again after the initial connection.

=C2=A0 I suspect you=E2=80=99re not getting it to use the local/conserver p= assword at all, or else when you first start up, you=E2=80=99d have to ente= r both, in the correct sequence. =C2=A0One to connect to the established ss= h command, then another to ssh to authenticate the network connection.

=C2=A0 So, I guess you need to decide whether you want to have the connecti= on drop and reestablish, which is what you seemed to be asking for, or rath= er want just to get the conserver password prompting working, which I=E2=80= =99m not doing, so can=E2=80=99t help with directly.

=C2=A0 Thoughts and information that I hope is helpful.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Chris

On Apr 21, 2014, at 14:38, Brandon Stout <bstout@squareup.com> wrote:

> Also, how does the conserver.passwd work? When does it use that rather= than the authentication on the Opengear itself? To test, I have the same u= ser on the Opengear as well as in the conserver.passwd with different passw= ords to see where it gets its passwords from. So far it just looks like it = is using the password from the Opengear. I configured conserver with all th= e defaults so I am assuming conserver.passwd just needs to exist within the= same directory as conser= ver.cf. Did I configure something incorrectly or does there need to be = a line in the conserver.c= f file to point to where conserver.passwd exists?
>
>
> On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout <bstout@squareup.com> wrote: > So I actually figured out the problem so now it connects, I get the pa= ssword prompt and when I enter it correctly it works. The problem is that w= hen I disconnect and reconnect, it no longer asks me for a password and jus= t puts me through to the console. is there some sort of disconnect I need t= o do manually to get it to reset and ask for a password? Seems like it just= stays connected once the pw is entered, regardless of someone exiting.
>
>
> On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout <bstout@squareup.com> wrote: > thanks Nathan, I actually was trying that right after I sent this emai= l and added this
>
> default opengear-ssh { type exec; portbase 2000; portinc 1;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e= xec /usr/bin/ssh -p P -l tsuser H;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e= xecsubst H=3Dhs,P=3DPd; }
>
> still not working though with just about nothing useful in the logs. D= oesn't hang but it still doesn't work. Just empty space and no outp= ut.
>
>
> On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz <nstraz@redhat.com> wrote:
> On Apr 21 10:29, Brandon Stout wrote:
> > hello, I am trying to use conserver to connect to serial ports ov= er ssh and
> > it is hanging. When I go direct it works fine (i am using Opengea= r IMX4248):
> >
> > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002
> ...
> > default full { rw *; }
> > default opengear =C2=A0{ type host; portbase 3000; portinc 1; } > > default * {
> > logfile /var/log/conserver;
> > timestamp 1hab;
> > include full;
> > master localhost;
> > }
> > default console01 { include opengear; host console01; }
> > console dr01.arista { include console01; port 1; }
> > console dr02.arista { include console01; port 2; }
> ...
> > Has anyone gotten this to work using ssh?
>
> I think you need to use the exec host type and setup the right execsub= st
> to get ssh to use the right port number. =C2=A0The "host" ty= pe is just a raw
> TCP socket connection.
>
> Nate
> _______________________________________________
> users mailing list
> users@conserv= er.com
> https://www.conserver.com/mailman/listinfo/users
>
>
>
> --
>
> brandon
>
>
>
> --
>
> brandon
>
>
>
> --
>
> brandon
> _______________________________________________
> users mailing list
> users@conserv= er.com
> https://www.conserver.com/mailman/listinfo/users




<= /div>--

brandon

_______________________________________________
users mailing list
users@conserver.co= m
https://www.conserver.com/mailman/listinfo/users




--
Sent from my new iPhone 6 Watch (prototype), see my reviews = here!
w= ww.conserver.com/consoles/ -- consoleteam.blogspot.com
- - - - - - - -
www.n= cry.org
www.d4tm.o= rg
www.hacke= rdojo.com



<= font color=3D"#888888">--

brandon



--
Sent f= rom my new iPhone 6 Watch (prototype), see my reviews here!
www.conserver.com/cons= oles/ -- = consoleteam.blogspot.com
- - - - - - - -
www.n= cry.org
www.d4tm.o= rg
www.hacke= rdojo.com



<= /div>--

brandon=



--
Sent f= rom my new iPhone 6 Watch (prototype), see my reviews here!
www.conserver.com/cons= oles/ -- = consoleteam.blogspot.com
- - - - - - - -
www.n= cry.org
www.d4tm.o= rg
www.hacke= rdojo.com
--089e013a1d8e3b404404f795abfc-- From bryan@conserver.com Tue Apr 22 01:12:56 2014 Received: from [10.53.162.12] (mobile-198-228-221-121.mycingular.net [198.228.221.121]) (authenticated bits=0) by underdog.stansell.org (8.14.7/8.14.7) with ESMTP id s3M1Csr1010262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 22 Apr 2014 01:12:55 GMT Subject: Conserver and ssh References: From: Bryan Stansell Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (11D167) Message-Id: <9FC2ADC9-B4C9-48AA-B366-AEBADF673BA6@conserver.com> Date: Mon, 21 Apr 2014 18:12:54 -0700 To: users@conserver.com Mime-Version: 1.0 (1.0) X-Spam-Score: 0.413 () BAYES_00,HELO_MISC_IP,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by underdog.stansell.org id s3M1Csr1010262 X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.16 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 01:12:56 -0000 It sounds like you want a subset of your unix host users to be able to access various consoles. It also sounds like you may not have authentication at the conserver layer (for users) enabled yet. Conserver has many options to enable pretty much any (sane) scenario. The client->conserver communication can be "trusted" (so, restricted via ip only), "allowed" (requires username/password lookup), and "rejected" (again, by ip). You can also list which users have r/w access to which consoles, which have r/o and, which have none. You can group users, include/exclude per console, etc. If you want to use user/pass auth, you need to make sure you have "allowed" vs "trusted" in the access section of the config. Once you get password prompts, you can either define new passwords in the conserver.passwd file or have it use the system passwords. Users can be granted access to consoles via the "rw" and "ro" console options. There are a set of sample config files in the source distribution which talk about various topologies as well as options. Looking at those may help, as well as the specific keywords I called out above, and the sample files (not sure if repos include them - doubt it). If you describe your ideal situation, I can also help form a config template that should do what you want. Personally, I like having conserver attach to all consoles so you have an audit log at all times and control access via the "allowed" keyword and setting up access lists per console with "rw". If you grant folks access via the network (console client on other hosts), they don't even need real accounts on your conserver host - just create them in conserver.password. Not that it fits your use case, but just wanted to call it out. Oh, and if you really want to know who is who, you can use SSL between the client and sever, requiring the user to have been given a signed cert - takes more setup, but possible. Anyway, I hope this helps. Bottom line, whatever you'd like to see as far as authentication and access control is probably possible. Don't settle for something you don't really want - I (or someone on the list) can help steer you down the right path. Hopefully I already did, but if not, let me know (by example?) what you'd like to see and I can help. Bryan > On Apr 21, 2014, at 3:57 PM, Brandon Stout wrote: > > Hey Z, > > This is starting to make a lot more sense. Thanks for the email. It sounds like I may not be able to use it exactly how I wanted to but I can get by with local user/pw on the console server if this is the case. I am using the conserver as both conserver host and conserver client, by which a user will logon to this host to gain console access only to console servers configured locally (nothing distributed). The server is also used for other functions so other users have access to the box who I don't want to have access to the consoles. I was trying to control access via conserver.passwd but it sounds like that is only used for conserver clients outside of the conserver. It seems as though I will just need to create individual accounts on the console server itself and control access there. > > thanks > Brandon > From bryan@conserver.com Tue Apr 22 01:32:33 2014 Received: from [10.53.162.12] (mobile-198-228-221-121.mycingular.net [198.228.221.121]) (authenticated bits=0) by underdog.stansell.org (8.14.7/8.14.7) with ESMTP id s3M1WVFx016761 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 22 Apr 2014 01:32:32 GMT Subject: Re: Unable to see console output References: <1398107889.4971.YahooMailNeo@web121003.mail.ne1.yahoo.com> From: Bryan Stansell Content-Type: multipart/alternative; boundary=Apple-Mail-F82DF8B4-5695-4FD6-86C4-4752B17614C4 X-Mailer: iPhone Mail (11D167) In-Reply-To: <1398107889.4971.YahooMailNeo@web121003.mail.ne1.yahoo.com> Message-Id: <0A72602E-0699-46BC-9D0F-0AEDB58CFCCF@conserver.com> Date: Mon, 21 Apr 2014 18:32:30 -0700 To: "users@conserver.com" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) X-Spam-Score: 0.415 () BAYES_00, HELO_MISC_IP, HTML_MESSAGE, MIME_QP_LONG_LINE, RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.16 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 01:32:33 -0000 --Apple-Mail-F82DF8B4-5695-4FD6-86C4-4752B17614C4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Are you using the "console" client? By saying "call usb0", it sounds like yo= u're using telnet and tying to talk the conserver protocol directly. If so, y= eah, you haven't done all that's required. I suggest looking for the client a= nd using that - *waaaaaay* easier for normal cases. Only if you need some cu= stom interaction (programmatically - an even then...) should you be avoiding= the client.=20 If you are using the client, I'll need more details.=20 Bryan > On Apr 21, 2014, at 12:18 PM, mikhail mamaenko wrote= : >=20 > I use this config in order to access serial cable attached to serial2usb a= dapter on my conserver server: > default * { > # The '&' character is substituted with the console name > logfile /var/consoles/&; > rw sysadmin; # use the group defined above > master localhost; > } >=20 > default usb2serial { > type device; > device /dev/ttyUSB.; > devicesubst .=3DPd; > portbase -1; > portinc 1; > host none; > baud 9600; > parity none; > } >=20 > console usb0 { include usb2serial; port 1; } > When connecting remotely to conserver and run call usb0 I can see only cha= racters I am typing not console responses. All console output is going direc= tly to log file. > What I am doing wrong? I want to ave interactive communication with my dev= ice connected through serial cable >=20 > Thank you, > Mike >=20 > _______________________________________________ > users mailing list > users@conserver.com > https://www.conserver.com/mailman/listinfo/users --Apple-Mail-F82DF8B4-5695-4FD6-86C4-4752B17614C4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Are you using the "console" client? By= saying "call usb0", it sounds like you're using telnet and tying to talk th= e conserver protocol directly. If so, yeah, you haven't done all that's requ= ired. I suggest looking for the client and using that - *waaaaaay* easier fo= r normal cases. Only if you need some custom interaction (programmatically -= an even then...) should you be avoiding the client. 

If you are using the client, I'll need more details. 

Bryan

On Apr 21, 2014, at 12:18 PM, mikhail ma= maenko <mmamaenko@yahoo.com>= ; wrote:

I use this config in order to access serial cable attached to serial2usb a= dapter on my conserver server:
default * {        # The '&a= mp;' character is substituted with the console name
        logfile /var/consoles/&;
        rw sysadmin;=   # use the group defined above
  &n= bsp;     master localhost;
}
default usb2serial {
        type device;        device /d= ev/ttyUSB.;
      &nb= sp; devicesubst .=3DPd;
    &nb= sp;   portbase -1;
   &nbs= p;    portinc 1;
   &= nbsp;    host none;
  &nbs= p;     baud 9600;
  &= nbsp;     parity none;
}

console usb0 { include usb2seri= al; port 1; }
When connecting remotely to conserver and run call usb0 I= can see only characters I am typing not console responses. All console output is going directly to log file.
What I am doing wrong= ? I want to ave interactive communication with my device connected through s= erial cable

Thank you,
Mike

_______= ________________________________________
users mailing list<= /span>
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
= --Apple-Mail-F82DF8B4-5695-4FD6-86C4-4752B17614C4-- From bstout@squareup.com Tue Apr 22 20:57:32 2014 Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by underdog.stansell.org (8.14.7/8.14.7) with ESMTP id s3MKvTwP017359 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 22 Apr 2014 20:57:31 GMT Received: by mail-pb0-f45.google.com with SMTP id uo5so21879pbc.4 for ; Tue, 22 Apr 2014 13:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=squareup.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sQP1u2DYHoHcvUXFljpjJTQb8a+OMd13ywusDkap0dg=; b=RdVgykg8BZ7NDQVA+CJTrLqQp569QUN4GA0U649aHeZKfhfC9PjRa3jJqiEmYYA0ch F0uqSqXjUutei/XLF3NjJx2L+tCfcJXnCTWKBYggG/mHMYMnGLrYyuAqmXrnLv/jl8MF +IiM5/gpT58cUKqD7z4+nxtgOk8Ae3DahxhDQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sQP1u2DYHoHcvUXFljpjJTQb8a+OMd13ywusDkap0dg=; b=lWQ81V6XKVDX5ULRx/0fUDpgtKrTps1MSGtB3vILCG91RumpxB1zJnqigN5qmOPA7I 3wUEab4sYS9Xb1yb9sFVB/1GHVLojefc+Uns7E8kZ1xtKfOMkqTHFDnVD7QjyZZIxE+z W7uDgWrWRqytXNELs0X6iL2branbmcCYBHxOfAlmZ5cMJImfoLoEXo3v1E1PywPIflY4 PZLHuxJBh19YIb3UW+AfBp+qOkPIXaF3w5aH9fc1p7j59qPGSp1d7Ljx0HELVV4tsTC4 5B270ppYjWbE4XmlBm13Wod0zclGJMaVcBXtEm1wlWplvP0NucNIeJsPu/bRI+N09C4G iFzw== X-Gm-Message-State: ALoCoQmmFeGMeXZH1yToowiPMJGavNGaOq9X1upKnf22Hu1XC4aSxAccR+5TRQ7kQ6jrZgmVijRk MIME-Version: 1.0 X-Received: by 10.68.190.200 with SMTP id gs8mr12327960pbc.130.1398200248580; Tue, 22 Apr 2014 13:57:28 -0700 (PDT) Received: by 10.70.30.228 with HTTP; Tue, 22 Apr 2014 13:57:28 -0700 (PDT) In-Reply-To: <9FC2ADC9-B4C9-48AA-B366-AEBADF673BA6@conserver.com> References: <9FC2ADC9-B4C9-48AA-B366-AEBADF673BA6@conserver.com> Date: Tue, 22 Apr 2014 13:57:28 -0700 Message-ID: Subject: Re: Conserver and ssh From: Brandon Stout To: Bryan Stansell Content-Type: multipart/alternative; boundary=e89a8ff1c36824411504f7a7ddec X-Spam-Score: -1.489 () BAYES_00,HTML_MESSAGE,T_DKIM_INVALID X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 Cc: "users@conserver.com" X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.16 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 20:57:32 -0000 --e89a8ff1c36824411504f7a7ddec Content-Type: text/plain; charset=UTF-8 Thanks Bryan, I am definitely working on taking advantage of the distributed option but taking baby steps for now to get all conserver hosts up and running and configured first. I attempted to do distributed at first but one of my hosts is behind a fw doing pat and it looks like conserver starts on TCP/782 but then moves to a higher TCP port afterwords and this broke. So once I remedy this I will be attempting it again to see if i can get it working. The ideal goal would be to be able to have the client running on laptops so you wouldn't even need to jump onto a bastion host. I will definitely be hitting up this list next week when I start so thanks for the initial information to help me get started. Something I will probably want to get info on his how to secure the communication. I am assuming this is all done in clear text right now but I could be wrong. thanks Brandon On Mon, Apr 21, 2014 at 6:12 PM, Bryan Stansell wrote: > It sounds like you want a subset of your unix host users to be able to > access various consoles. It also sounds like you may not have > authentication at the conserver layer (for users) enabled yet. > > Conserver has many options to enable pretty much any (sane) scenario. The > client->conserver communication can be "trusted" (so, restricted via ip > only), "allowed" (requires username/password lookup), and "rejected" > (again, by ip). You can also list which users have r/w access to which > consoles, which have r/o and, which have none. You can group users, > include/exclude per console, etc. > > If you want to use user/pass auth, you need to make sure you have > "allowed" vs "trusted" in the access section of the config. Once you get > password prompts, you can either define new passwords in the > conserver.passwd file or have it use the system passwords. Users can be > granted access to consoles via the "rw" and "ro" console options. > > There are a set of sample config files in the source distribution which > talk about various topologies as well as options. Looking at those may > help, as well as the specific keywords I called out above, and the sample > files (not sure if repos include them - doubt it). > > If you describe your ideal situation, I can also help form a config > template that should do what you want. Personally, I like having conserver > attach to all consoles so you have an audit log at all times and control > access via the "allowed" keyword and setting up access lists per console > with "rw". If you grant folks access via the network (console client on > other hosts), they don't even need real accounts on your conserver host - > just create them in conserver.password. Not that it fits your use case, > but just wanted to call it out. Oh, and if you really want to know who is > who, you can use SSL between the client and sever, requiring the user to > have been given a signed cert - takes more setup, but possible. > > Anyway, I hope this helps. Bottom line, whatever you'd like to see as far > as authentication and access control is probably possible. Don't settle for > something you don't really want - I (or someone on the list) can help steer > you down the right path. Hopefully I already did, but if not, let me know > (by example?) what you'd like to see and I can help. > > Bryan > > > On Apr 21, 2014, at 3:57 PM, Brandon Stout wrote: > > > > Hey Z, > > > > This is starting to make a lot more sense. Thanks for the email. It > sounds like I may not be able to use it exactly how I wanted to but I can > get by with local user/pw on the console server if this is the case. I am > using the conserver as both conserver host and conserver client, by which a > user will logon to this host to gain console access only to console servers > configured locally (nothing distributed). The server is also used for other > functions so other users have access to the box who I don't want to have > access to the consoles. I was trying to control access via conserver.passwd > but it sounds like that is only used for conserver clients outside of the > conserver. It seems as though I will just need to create individual > accounts on the console server itself and control access there. > > > > thanks > > Brandon > > > > _______________________________________________ > users mailing list > users@conserver.com > https://www.conserver.com/mailman/listinfo/users > -- brandon --e89a8ff1c36824411504f7a7ddec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Bryan, I am definitely working on taking advantage = of the distributed option but taking baby steps for now to get all conserve= r hosts up and running and configured first. I attempted to do distributed = at first but one of my hosts is behind a fw doing pat and it looks like con= server starts on TCP/782 but then moves to a higher TCP port afterwords and= this broke. So once I remedy this I will be attempting it again to see if = i can get it working. The ideal goal would be to be able to have the client= running on laptops so you wouldn't even need to jump onto a bastion ho= st. I will definitely be hitting up this list next week when I start so tha= nks for the initial information to help me get started. Something I will pr= obably want to get info on his how to secure the communication. I am assumi= ng this is all done in clear text right now but I could be wrong.

thanks
Brandon


On Mon, Apr 21, 2014 at 6:12 PM, Brya= n Stansell <bryan@conserver.com> wrote:
It sounds like you want a subset of your uni= x host users to be able to access various consoles. It also sounds like you= may not have authentication at the conserver layer (for users) enabled yet= .

Conserver has many options to enable pretty much any (sane) scenario. =C2= =A0The client->conserver communication can be "trusted" (so, r= estricted via ip only), "allowed" (requires username/password loo= kup), and "rejected" (again, by ip). You can also list which user= s have r/w access to which consoles, which have r/o and, which have none. Y= ou can group users, include/exclude per console, etc.

If you want to use user/pass auth, you need to make sure you have "all= owed" vs "trusted" in the access section of the config. Once= you get password prompts, you can either define new passwords in the conse= rver.passwd file or have it use the system passwords. =C2=A0Users can be gr= anted access to consoles via the "rw" and "ro" console = options.

There are a set of sample config files in the source distribution which tal= k about various topologies as well as options. Looking at those may help, a= s well as the specific keywords I called out above, and the sample files (n= ot sure if repos include them - doubt it).

If you describe your ideal situation, I can also help form a config templat= e that should do what you want. =C2=A0Personally, I like having conserver a= ttach to all consoles so you have an audit log at all times and control acc= ess via the "allowed" keyword and setting up access lists per con= sole with "rw". =C2=A0If you grant folks access via the network (= console client on other hosts), they don't even need real accounts on y= our conserver host - just create them in conserver.password. =C2=A0Not that= it fits your use case, but just wanted to call it out. Oh, and if you real= ly want to know who is who, you can use SSL between the client and sever, r= equiring the user to have been given a signed cert - takes more setup, but = possible.

Anyway, I hope this helps. Bottom line, whatever you'd like to see as f= ar as authentication and access control is probably possible. Don't set= tle for something you don't really want - I (or someone on the list) ca= n help steer you down the right path. Hopefully I already did, but if not, = let me know (by example?) what you'd like to see and I can help.

Bryan

> On Apr 21, 2014, at 3:57 PM, Brandon Stout <bstout@squareup.com> wrote:
>
> Hey Z,
>
> This is starting to make a lot more sense. Thanks for the email. It so= unds like I may not be able to use it exactly how I wanted to but I can get= by with local user/pw on the console server if this is the case. I am usin= g the conserver as both conserver host and conserver client, by which a use= r will logon to this host to gain console access only to console servers co= nfigured locally (nothing distributed). The server is also used for other f= unctions so other users have access to the box who I don't want to have= access to the consoles. I was trying to control access via conserver.passw= d but it sounds like that is only used for conserver clients outside of the= conserver. It seems as though I will just need to create individual accoun= ts on the console server itself and control access there.
>
> thanks
> Brandon
>

_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users



--

bra= ndon
--e89a8ff1c36824411504f7a7ddec--