From mikemol at gmail.com  Fri Sep  5 10:57:11 2014
From: mikemol at gmail.com (Michael Mol)
Date: Fri, 5 Sep 2014 10:57:11 -0400
Subject: [GRLUG] Friday After Five
Message-ID: <CA+czFiDHhZvj+P=NLWT7a5CuPEaSoBh1UAp3F_uUD+ekEqydkQ@mail.gmail.com>

We here at Virtual Interconnect are hosting the Grand Rapids Linux
User's Group for weekly socials. Kyle and myself serve as anchors; at
least one of us will be here during the event.

Time: 5PM-7PM Fridays, every week

Location: 315 Richard Terrace, Grand Rapids MI 49506 (Not
handicapped-accessible, sorry.) Google Street View:
http://goo.gl/maps/CDOzO

Commute: Parking is on the south side of the building, and The #6 bus
route runs right in front of us, the #5 and #19 come close. Nearest
stops: http://bit.ly/QyS7RY

Food: Popcorn and water are free. Anything else is BYOB (No alcohol),
although something else may be arranged for in the future.

Entry: The door is always locked, unless it's propped open. Ring the
doorbell if it's shut.

Loitering: When Kyle and I have to go, we have to go. There are
restaurants, cafes and bookstores all around, though.

-- 
:wq

From chouse at gmail.com  Sun Sep  7 19:51:38 2014
From: chouse at gmail.com (Christopher House)
Date: Sun, 7 Sep 2014 19:51:38 -0400
Subject: [GRLUG] IPv6 network nightmare
Message-ID: <CAB6bZF-4V868_AV44cqAYnTUKGwLSs5UKx4DTt8azOEoh6-J1w@mail.gmail.com>

Not an IPv6 person at all but thought those on the list might find this
interesting:
http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/

"I have come to the conclusion that so much in IPv6 design and
implementation has been botched by protocol designers and vendors (both
ours and others) that it is simply unsafe to run IPv6 on a production
network except in very limited geographical circumstances and with very
tight central administration of hosts."

"The fundamental design problem with IPv6 is related to how it functions
over shared layer-2 networks like Ethernet"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20140907/60879f5d/attachment-0001.html>

From mikemol at gmail.com  Sun Sep  7 23:05:18 2014
From: mikemol at gmail.com (Michael Mol)
Date: Sun, 07 Sep 2014 23:05:18 -0400
Subject: [GRLUG] IPv6 network nightmare
In-Reply-To: <CAB6bZF-4V868_AV44cqAYnTUKGwLSs5UKx4DTt8azOEoh6-J1w@mail.gmail.com>
References: <CAB6bZF-4V868_AV44cqAYnTUKGwLSs5UKx4DTt8azOEoh6-J1w@mail.gmail.com>
Message-ID: <a3a72198-fa61-45d0-9b96-a76e64e524d6@email.android.com>

http://www.reddit.com/r/ipv6/comments/2fnmlj/the_network_nightmare_that_ate_my_week/?sort=confidence

For perspectives of those familiar with IPv6.

Now, while I think privacy addressing is a pain and three halves, I'm primarily with the top comment: Don't use such large layer 2 domains. Switch less, route more. (This improves the behavior of v4 ndtworks, too...)


On September 7, 2014 7:51:38 PM EDT, Christopher House <chouse at gmail.com> wrote:
>Not an IPv6 person at all but thought those on the list might find this
>interesting:
>http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/
>
>"I have come to the conclusion that so much in IPv6 design and
>implementation has been botched by protocol designers and vendors (both
>ours and others) that it is simply unsafe to run IPv6 on a production
>network except in very limited geographical circumstances and with very
>tight central administration of hosts."
>
>"The fundamental design problem with IPv6 is related to how it
>functions
>over shared layer-2 networks like Ethernet"
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>grlug mailing list
>grlug at grlug.org
>http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20140907/c1361aef/attachment.html>

From awilliam at whitemice.org  Mon Sep  8 10:13:27 2014
From: awilliam at whitemice.org (Adam Tauno Williams)
Date: Mon, 08 Sep 2014 10:13:27 -0400
Subject: [GRLUG] IPv6 network nightmare
In-Reply-To: <CAB6bZF-4V868_AV44cqAYnTUKGwLSs5UKx4DTt8azOEoh6-J1w@mail.gmail.com>
References: <CAB6bZF-4V868_AV44cqAYnTUKGwLSs5UKx4DTt8azOEoh6-J1w@mail.gmail.com>
Message-ID: <1410185607.4310.4.camel@whitemice.org>

On Sun, 2014-09-07 at 19:51 -0400, Christopher House wrote: 
> Not an IPv6 person at all but thought those on the list might find
> this
> interesting: http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/
> "I have come to the conclusion that so much in IPv6 design and
> implementation has been botched by protocol designers and vendors
> (both ours and others) that it is simply unsafe to run IPv6 on a
> production network except in very limited geographical circumstances
> and with very tight central administration of hosts."

Bull.

Most of his issues relate completely to a bad vendor / crappy firmware.
Nothing here indicates anything was "botched" by "designers".  People
keep saying this - but IPv6 is much *SIMPLER* than IPv4, there is much
less to botch.

I will agree that the replacement of ARP with discovery changes a lot of
things - way more than people realize [I suspect at this point most
people don't even think about it as they are so accustomed to the
idiosyncrasies of ARP].

But I think the nut of his argument is here: "since IPv6 is still not
implemented on very large layer-2 networks like a campus network or
*****our***** building,"

This sounds much more like an issue with Juniper than IPv6.

When we get to the statement: '''IPv6 ?privacy? addresses are an
incredible botch added to IPv6''' then I entirely agree.  This "privacy"
setup is **INSANE**.  But can be turned off.  ALWAYS turn it off.

  Windows:
   netsh interface ipv6 set privacy state=disabled store=persistent
   netsh interface ipv6 set privacy state=disabled store=active

  Linux:
     /proc/sys/net/ipv6/conf/eth0/use_tempaddr
     0 = disabled
     1 = enabled but prefer a real address
     >1 = enabled and use this stupid feature
    
'''We will probably move towards not supporting IPv6 ?stateless?
autoconfiguration at all, and rely on DHCPv6 to assign stable, traceable
addresses to all IPv6 clients'''

Yes. That has been the recommended practice for a long time.
Statelessness is magick, and the trouble with all magick thusly applies:
tamogenesis.


-- 
Adam Tauno Williams <mailto:awilliam at whitemice.org> GPG D95ED383
Systems Administrator, Python Developer, LPI / NCLA


From mfarver at mindbent.org  Mon Sep  8 10:41:38 2014
From: mfarver at mindbent.org (Mark Farver)
Date: Mon, 8 Sep 2014 10:41:38 -0400
Subject: [GRLUG] IPv6 network nightmare
In-Reply-To: <1410185607.4310.4.camel@whitemice.org>
References: <CAB6bZF-4V868_AV44cqAYnTUKGwLSs5UKx4DTt8azOEoh6-J1w@mail.gmail.com>
 <1410185607.4310.4.camel@whitemice.org>
Message-ID: <CACNU6M4RKC3_1=h-qWar7YTovnXzA-XK5dyKQ8kV2XzeuSCt=w@mail.gmail.com>

On Sep 8, 2014 10:17 AM, "Adam Tauno Williams" <awilliam at whitemice.org>
wrote:

> I will agree that the replacement of ARP with discovery changes a lot of
> things - way more than people realize [I suspect at this point most
> people don't even think about it as they are so accustomed to the
> idiosyncrasies of ARP].

His argument that ARP is well supported in hardware but multicast isn't is
probably fair.  Networking hardware has lagged in this area for years.

The network community has had an inappropriate dislike of multicast since
it was first specified and many network admins and vendors avoid it to this
day. One senior network admin told me that multicast was "Internet wide
broadcast packets" and therefore would never be allowed on his network.

Campus scale IPV6 installs are fairly common in academia and I've never
heard of one going sideways like this

And while it is convenient and sometimes unavoidable, extending all of your
L2 domains to the core is asking for trouble even without IPV6.  (Nothing
more fun than watching a network loop take down the entire core switch.).
The risk of network loops goes down substantially if you don't have a
complicated spanning tree and if your north south links are L3.  Don't
think of spanning tree as a magnificent oak.  It is more like Kudzu...

He doesn't go into details on the hardware but from his description i think
they are using a layer 2 switch with rudimentary L3 abilities (probably a
Ex8200)... This is acceptable for small networks but not a campus size one
no matter what the sales guy says.  Alas core routing hardware (juniper MX
series is my fav) is fantastically expensive.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20140908/96bc940f/attachment.html>

From awilliam at whitemice.org  Mon Sep  8 12:07:46 2014
From: awilliam at whitemice.org (Adam Tauno Williams)
Date: Mon, 08 Sep 2014 12:07:46 -0400
Subject: [GRLUG] IPv6 network nightmare
In-Reply-To: <CACNU6M4RKC3_1=h-qWar7YTovnXzA-XK5dyKQ8kV2XzeuSCt=w@mail.gmail.com>
References: <CAB6bZF-4V868_AV44cqAYnTUKGwLSs5UKx4DTt8azOEoh6-J1w@mail.gmail.com>
 <1410185607.4310.4.camel@whitemice.org>
 <CACNU6M4RKC3_1=h-qWar7YTovnXzA-XK5dyKQ8kV2XzeuSCt=w@mail.gmail.com>
Message-ID: <1410192466.4310.6.camel@whitemice.org>

On Mon, 2014-09-08 at 10:41 -0400, Mark Farver wrote:
> On Sep 8, 2014 10:17 AM, "Adam Tauno Williams"
> <awilliam at whitemice.org> wrote:
> His argument that ARP is well supported in hardware but multicast
> isn't is probably fair.  Networking hardware has lagged in this area
> for years.
> The network community has had an inappropriate dislike of multicast
> since it was first specified and many network admins and vendors avoid
> it to this day. 

Yep.  To be fair multicast wasn't even a glimmer in the designers eye
when IPv4 was brought forth into the world; it was tacked on, and many
of the tools make it feel that way. This is an area IPv6 cleans up
considerably.  And since an IPv6 stack implementation has ground-up
inclusion we will hopefully see much more consistently and universality
of support.

> Campus scale IPV6 installs are fairly common in academia and I've
> never heard of one going sideways like this 

Ditto

> And while it is convenient and sometimes unavoidable, extending all of
> your L2 domains to the core is asking for trouble even without IPV6. 

Yep.

> (Nothing more fun than watching a network loop take down the entire
> core switch.).  The risk of network loops goes down substantially if
> you don't have a complicated spanning tree and if your north south
> links are L3.  Don't think of spanning tree as a magnificent oak.  It
> is more like Kudzu...

Preach it brother!  Use spanning-tree and the like when really
necessary, otherwise route [call it Layer 3 Switching if your boss likes
those buzzwords more].

> He doesn't go into details on the hardware but from his description i
> think they are using a layer 2 switch with rudimentary L3 abilities
> (probably a Ex8200)... This is acceptable for small networks but not a
> campus size one no matter what the sales guy says.  Alas core routing
> hardware (juniper MX series is my fav) is fantastically expensive.

But very good routing performance, suitable for most sites, can be had
with pretty reasonably priced hardware.

-- 
Adam Tauno Williams <mailto:awilliam at whitemice.org> GPG D95ED383
Systems Administrator, Python Developer, LPI / NCLA


From mfarver at mindbent.org  Mon Sep  8 12:29:42 2014
From: mfarver at mindbent.org (Mark Farver)
Date: Mon, 8 Sep 2014 12:29:42 -0400
Subject: [GRLUG] IPv6 network nightmare
In-Reply-To: <1410192466.4310.6.camel@whitemice.org>
References: <CAB6bZF-4V868_AV44cqAYnTUKGwLSs5UKx4DTt8azOEoh6-J1w@mail.gmail.com>
 <1410185607.4310.4.camel@whitemice.org>
 <CACNU6M4RKC3_1=h-qWar7YTovnXzA-XK5dyKQ8kV2XzeuSCt=w@mail.gmail.com>
 <1410192466.4310.6.camel@whitemice.org>
Message-ID: <CACNU6M5VaWxi5XLLmKSF4BF4bmvRpbEMXst9TzLBOmXQeqCpFQ@mail.gmail.com>

On Sep 8, 2014 12:12 PM, "Adam Tauno Williams" <awilliam at whitemice.org>
wrote:

> But very good routing performance, suitable for most sites, can be had
> with pretty reasonably priced hardware.

If you are an all Juniper shop you'll find they have a bit of a hole in
their product line.  They sell awesome ISP and carrier grade routers for
the high end...but they don't have a middle of the road routing
product...instead they have compromise all in one products that can do
routing, firewall or other stuff depending on software load but don't do
anything particularly well and tend to do too much in software instead of
hardware.

I think Software Defined Networking would solve a lot of problems in the
mid tier market but I haven't found anyone interested in trying it.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20140908/49320021/attachment.html>

From lvl at omnitec.net  Mon Sep  8 18:50:47 2014
From: lvl at omnitec.net (L. V. Lammert)
Date: Mon, 8 Sep 2014 17:50:47 -0500 (CDT)
Subject: [GRLUG] Cisco <ctl>break
Message-ID: <Pine.BSO.4.53.1409081749120.7984@Mail.omnitec.net>

Need to tweak a 1725 router, .. but <ctl><break> seems to not work from
the keyboard using Minicom.

Before I down the router again, can someone confirm that <ctl>AZF does
work with Cisco to get to ROMMON?

	Thanks!

	Lee

From grlug at darkhaven.net  Tue Sep  9 15:34:19 2014
From: grlug at darkhaven.net (Dan Taylor)
Date: Tue, 09 Sep 2014 15:34:19 -0400
Subject: [GRLUG] Cisco <ctl>break
In-Reply-To: <Pine.BSO.4.53.1409081749120.7984@Mail.omnitec.net>
References: <Pine.BSO.4.53.1409081749120.7984@Mail.omnitec.net>
Message-ID: <540F563B.3070406@darkhaven.net>

Depends what the config register is set to.

http://www.cisco.com/c/en/us/support/docs/routers/10000-series-routers/50421-config-register-use.html

On 09/08/2014 06:50 PM, L. V. Lammert wrote:
> Need to tweak a 1725 router, .. but <ctl><break> seems to not work from
> the keyboard using Minicom.
>
> Before I down the router again, can someone confirm that <ctl>AZF does
> work with Cisco to get to ROMMON?
>
> 	Thanks!
>
> 	Lee
> _______________________________________________
> grlug mailing list
> grlug at grlug.org
> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>


From flanderb at gmail.com  Tue Sep  9 15:52:25 2014
From: flanderb at gmail.com (Benjamin Flanders)
Date: Tue, 9 Sep 2014 15:52:25 -0400
Subject: [GRLUG] Ubiquiti issues
Message-ID: <CAJdZESptdrH6axca=RgOs68X7s61F3PmoNbSYhcSTf=ZrqjqKA@mail.gmail.com>

Thank you all for your help.  I've moved the controller off the windows
server and onto a linux (virtual)box.  This did seem to help.  I can now
get up to 20ish clients.  It still varies from 17-23 valid ip's.  I am
going to move the dhcp server to the same box today.  I have a feeling that
this will help, but not truly fix the issue.  I believe that there is
something randomly blocking access to this windows server.

Question:
What would cause a client to be randomly unable to access or ping a certain
server on the network, while other clients have no issue pinging said
server, nor does that client have an issue pinging other servers.  It isn't
just this laptop, I've witnessed this directly one other time a few weeks
ago.

Background:
Today I had a sales manager come to me saying that his internet was going
up and down all morning, but he has had a strong connection the whole
time(from the little icon in the system tray).  It was currently down so
went over there and found that I couldn't ping the dns server, but I could
ping other servers on the network.  I tested with his phone and I could get
to google(I think this verified the dns server was working and accessible
to his phone)

Mmm, I thought, I have wireshark at my desk on the other side of the
office(as if I knew how to use it).  So I grabbed his laptop and went to my
office.  Alas, when I got to my desk the laptop was not having any issues
with pinging the dns server anymore.  I don't know if it was crossing into
another AP (reconnecting to network), or just that it randomly started
working.

Once I get the DHCP server on the linux box I'll truely see if my issue
stops being getting an IP lease and starts to becoming a DNS issue.

Share and Enjoy
Ben

On Sat, Aug 30, 2014 at 11:05 AM, Godwin <geektoyz at gmail.com> wrote:

> I'd setup a dhcp server on a separate Linux vm for testing.  I too have
> the Controller on a Windows server, but dhcp is on a Linux server.
> Three APs managed (one local, two over VPN link) with multiple ssid's
> including a local guest (vlan) one with voucher needed.  It's a beautiful
> thing.  :)  You can 'tail - f' the dhcp log and see if the requests are
> forwarded by the APs.
>
> G-
>  On Aug 28, 2014 1:41 PM, "Adam Tauno Williams" <awilliam at whitemice.org>
> wrote:
>
>> On Thu, 2014-08-28 at 13:04 -0400, Benjamin Flanders wrote:
>> > So my questions:
>> > Does DHCP need a certain % of open addresses in the pool?
>>
>> Not "normal" DHCP, but I have only ever [and hope to only ever] use
>> ISC's DHCP server - what is packaged with every LINUX distribution ever.
>>
>> > Could it perhaps be an issue of having the Ubiquiti Controller on the
>> > same server as the DHCP server?
>>
>> No clue.
>>
>> >   - I could start up a linux server on VMWare and put the controller
>> > on that.  I'm doing this right now(I just thought of this)
>>
>> Good plan.
>>
>> > I understand that this is the Linux Group and this could possibly be a
>> > windows DHCP issue so is there a local windows group I could go to if
>> > you all think windows is the issue.
>>
>> Can you wireshark the attempt to acquire a lease?
>>
>> > Could the Cisco switches be filtering or interfering somehow?
>>
>> They could be, but not likely, unless you have setup some filtering,
>> etc..
>> --
>> Adam Tauno Williams <mailto:awilliam at whitemice.org> GPG D95ED383
>> Systems Administrator, Python Developer, LPI / NCLA
>>
>> _______________________________________________
>> grlug mailing list
>> grlug at grlug.org
>> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>>
>
> _______________________________________________
> grlug mailing list
> grlug at grlug.org
> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20140909/b96e2537/attachment-0001.html>

From lvl at omnitec.net  Tue Sep  9 15:59:28 2014
From: lvl at omnitec.net (L. V. Lammert)
Date: Tue, 9 Sep 2014 14:59:28 -0500 (CDT)
Subject: [GRLUG] Cisco <ctl>break
In-Reply-To: <540F563B.3070406@darkhaven.net>
References: <Pine.BSO.4.53.1409081749120.7984@Mail.omnitec.net>
 <540F563B.3070406@darkhaven.net>
Message-ID: <Pine.BSO.4.53.1409091459170.7984@Mail.omnitec.net>

On Tue, 9 Sep 2014, Dan Taylor wrote:

> Depends what the config register is set to.
>
> http://www.cisco.com/c/en/us/support/docs/routers/10000-series-routers/50421-config-register-use.html
>
Thanks for the reference!

	Lee

From awilliam at whitemice.org  Tue Sep  9 16:05:51 2014
From: awilliam at whitemice.org (Adam Tauno Williams)
Date: Tue, 09 Sep 2014 16:05:51 -0400
Subject: [GRLUG] Cisco <ctl>break
In-Reply-To: <Pine.BSO.4.53.1409081749120.7984@Mail.omnitec.net>
References: <Pine.BSO.4.53.1409081749120.7984@Mail.omnitec.net>
Message-ID: <1410293151.8477.0.camel@whitemice.org>

On Mon, 2014-09-08 at 17:50 -0500, L. V. Lammert wrote: 
> Need to tweak a 1725 router, .. but <ctl><break> seems to not work from
> the keyboard using Minicom.
> Before I down the router again, can someone confirm that <ctl>AZF does
> work with Cisco to get to ROMMON?

Ctrl-A,F works in Minicom to break into ROMON.  I use minicom regularly
to do this.

-- 
Adam Tauno Williams <mailto:awilliam at whitemice.org> GPG D95ED383
Systems Administrator, Python Developer, LPI / NCLA


From awilliam at whitemice.org  Tue Sep  9 16:17:56 2014
From: awilliam at whitemice.org (Adam Tauno Williams)
Date: Tue, 09 Sep 2014 16:17:56 -0400
Subject: [GRLUG] Ubiquiti issues
In-Reply-To: <CAJdZESptdrH6axca=RgOs68X7s61F3PmoNbSYhcSTf=ZrqjqKA@mail.gmail.com>
References: <CAJdZESptdrH6axca=RgOs68X7s61F3PmoNbSYhcSTf=ZrqjqKA@mail.gmail.com>
Message-ID: <1410293876.8477.2.camel@whitemice.org>

On Tue, 2014-09-09 at 15:52 -0400, Benjamin Flanders wrote: 
> Question:
> What would cause a client to be randomly unable to access or ping a
> certain server on the network, while other clients have no issue
> pinging said server, nor does that client have an issue pinging other
> servers.  It isn't just this laptop, I've witnessed this directly one
> other time a few weeks ago.

A bad switch, wigging out spanning-tree configuration, a bad switch,
overlapping MAC#s on the network, a bad switch, or a switch whose table
has overflowed [hard to believe these days]. 
> Background:
> Today I had a sales manager come to me saying that his internet was
> going up and down all morning, but he has had a strong connection the
> whole time(from the little icon in the system tray).  It was currently
> down so went over there and found that I couldn't ping the dns server,

Do you use managed switches?  Do you see errors of any kind?  Do they
report issues to a trap collector [an NMS?]?  If you have modern managed
switches they are likely trying very hard to tell you what the problem
is. 
> Mmm, I thought, I have wireshark at my desk on the other side of the
> office(as if I knew how to use it).  So I grabbed his laptop and went
> to my office.  Alas, when I got to my desk the laptop was not having
> any issues with pinging the dns server anymore.  I don't know if it
> was crossing into another AP (reconnecting to network), or just that
> it randomly started working.

Do you see errors?  Whatever the Windows equivalent of "netstat -i" is.

> Once I get the DHCP server on the linux box I'll truely see if my
> issue stops being getting an IP lease and starts to becoming a DNS
> issue.

I'd wager it is neither. 
-- 
Adam Tauno Williams <mailto:awilliam at whitemice.org> GPG D95ED383
Systems Administrator, Python Developer, LPI / NCLA


From lvl at omnitec.net  Tue Sep  9 17:32:58 2014
From: lvl at omnitec.net (L. V. Lammert)
Date: Tue, 9 Sep 2014 16:32:58 -0500 (CDT)
Subject: [GRLUG] Cisco <ctl>break
In-Reply-To: <1410293151.8477.0.camel@whitemice.org>
References: <Pine.BSO.4.53.1409081749120.7984@Mail.omnitec.net>
 <1410293151.8477.0.camel@whitemice.org>
Message-ID: <Pine.BSO.4.53.1409091632450.7984@Mail.omnitec.net>

On Tue, 9 Sep 2014, Adam Tauno Williams wrote:

> Ctrl-A,F works in Minicom to break into ROMON.  I use minicom regularly
> to do this.
>
Confirmed, ..

	Thanks!

	Lee

From kyle at virtualinterconnect.com  Fri Sep 12 08:04:43 2014
From: kyle at virtualinterconnect.com (Kyle Maas)
Date: Fri, 12 Sep 2014 08:04:43 -0400
Subject: [GRLUG] Friday after Five
Message-ID: <5412E15B.8070706@virtualinterconnect.com>

We here at Virtual Interconnect are hosting the Grand Rapids Linux
User's Group for weekly socials. Mike and myself serve as anchors; at
least one of us will be here during the event.

Time: 5PM-7PM Fridays, every week

Location: 315 Richard Terrace, Grand Rapids MI 49506 (Not
handicapped-accessible, sorry.) Google Street View:
http://goo.gl/maps/CDOzO

Commute: Parking is on the south side of the building, and The #6 bus
route runs right in front of us, the #5 and #19 come close. Nearest
stops: http://bit.ly/QyS7RY

Food: Popcorn and water are free. Anything else is BYOB (No alcohol),
although something else may be arranged for in the future.

Entry: The door is always locked, unless it's propped open. Ring the
doorbell if it's shut.

Loitering: When Mike and I have to go, we have to go. There are
restaurants, cafes and bookstores all around, though.

From ebever at researchintegration.org  Sat Sep 13 19:46:43 2014
From: ebever at researchintegration.org (Eric Beversluis)
Date: Sat, 13 Sep 2014 19:46:43 -0400
Subject: [GRLUG] Wonky old computer
Message-ID: <5414D763.5080403@researchintegration.org>

I was checking out an old computer this morning--a dual boot setup with 
an early Fedora and Win98 on it--I hadn't run it for 6 or so years. 
Initially it booted up nicely to Windows (I aborted the Fedora boot when 
my flat-screen monitor didn't like the resolution it was getting from 
Fedora). But at some point it froze up and I had to power it down.

Now it won't boot at all. It gets to the point of saying it's found a 
boot at IDE 0 but then hangs. "Searching for boot record from IDE-0. .OK"

With Knoppix I can access the old Fedora files but even Knoppix doesn't 
see the Windows partition--it only sees /dev/sda1 and /dev/sda2, the 
Fedora and swap partitions.

Any ideas? Did the Windows partition just somehow self-destruct?

Thanks.

From awilliam at whitemice.org  Mon Sep 15 06:30:42 2014
From: awilliam at whitemice.org (Adam Tauno Williams)
Date: Mon, 15 Sep 2014 06:30:42 -0400
Subject: [GRLUG] Wonky old computer
In-Reply-To: <5414D763.5080403@researchintegration.org>
References: <5414D763.5080403@researchintegration.org>
Message-ID: <1410777042.2028.3.camel@whitemice.org>

On Sat, 2014-09-13 at 19:46 -0400, Eric Beversluis wrote: 
> I was checking out an old computer this morning--a dual boot setup with 
> an early Fedora and Win98 on it--I hadn't run it for 6 or so years. 
> Initially it booted up nicely to Windows (I aborted the Fedora boot when 
> my flat-screen monitor didn't like the resolution it was getting from 
> Fedora). But at some point it froze up and I had to power it down.
> Now it won't boot at all. It gets to the point of saying it's found a 
> boot at IDE 0 but then hangs. "Searching for boot record from IDE-0. .OK"
> With Knoppix I can access the old Fedora files but even Knoppix doesn't 
> see the Windows partition--it only sees /dev/sda1 and /dev/sda2, the 
> Fedora and swap partitions.
> Any ideas? Did the Windows partition just somehow self-destruct?

Does the system physically have two drives?  If it has only one then
wither SDA1 or SDA2 is the Windows partition.  What does the output of
"/sbin/fdisk -l" look like?

You have a failed/failing drive most likely - no surprise for a drive
that sat idle for six years. 

-- 
Adam Tauno Williams <mailto:awilliam at whitemice.org> GPG D95ED383
Systems Administrator, Python Developer, LPI / NCLA


From andross at gmail.com  Mon Sep 15 14:19:49 2014
From: andross at gmail.com (andross at gmail.com)
Date: Mon, 15 Sep 2014 14:19:49 -0400
Subject: [GRLUG] Wonky old computer
In-Reply-To: <1410777042.2028.3.camel@whitemice.org>
References: <5414D763.5080403@researchintegration.org>
 <1410777042.2028.3.camel@whitemice.org>
Message-ID: <CAGY=PXqzpL_9AcLPKjDKHg-9SO5JqJKDna7yXScHhk8nEN78GA@mail.gmail.com>

Yeah, failing hard drive, probably mucked up the partition tables. You
might be able to use testdisk to rebuild the partition table and get at the
data.

On Mon, Sep 15, 2014 at 6:30 AM, Adam Tauno Williams <awilliam at whitemice.org
> wrote:

> On Sat, 2014-09-13 at 19:46 -0400, Eric Beversluis wrote:
> > I was checking out an old computer this morning--a dual boot setup with
> > an early Fedora and Win98 on it--I hadn't run it for 6 or so years.
> > Initially it booted up nicely to Windows (I aborted the Fedora boot when
> > my flat-screen monitor didn't like the resolution it was getting from
> > Fedora). But at some point it froze up and I had to power it down.
> > Now it won't boot at all. It gets to the point of saying it's found a
> > boot at IDE 0 but then hangs. "Searching for boot record from IDE-0. .OK"
> > With Knoppix I can access the old Fedora files but even Knoppix doesn't
> > see the Windows partition--it only sees /dev/sda1 and /dev/sda2, the
> > Fedora and swap partitions.
> > Any ideas? Did the Windows partition just somehow self-destruct?
>
> Does the system physically have two drives?  If it has only one then
> wither SDA1 or SDA2 is the Windows partition.  What does the output of
> "/sbin/fdisk -l" look like?
>
> You have a failed/failing drive most likely - no surprise for a drive
> that sat idle for six years.
>
> --
> Adam Tauno Williams <mailto:awilliam at whitemice.org> GPG D95ED383
> Systems Administrator, Python Developer, LPI / NCLA
>
> _______________________________________________
> grlug mailing list
> grlug at grlug.org
> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20140915/7910e6a1/attachment.html>

From ebever at researchintegration.org  Mon Sep 15 15:13:02 2014
From: ebever at researchintegration.org (Eric Beversluis)
Date: Mon, 15 Sep 2014 15:13:02 -0400
Subject: [GRLUG] Wonky old computer
In-Reply-To: <CAGY=PXqzpL_9AcLPKjDKHg-9SO5JqJKDna7yXScHhk8nEN78GA@mail.gmail.com>
References: <5414D763.5080403@researchintegration.org>
 <1410777042.2028.3.camel@whitemice.org>
 <CAGY=PXqzpL_9AcLPKjDKHg-9SO5JqJKDna7yXScHhk8nEN78GA@mail.gmail.com>
Message-ID: <54173A3E.5060900@researchintegration.org>

Turns out there are two HDDs, per Adam's guess. Which makes it easier to 
understand why the Fedora system is available but not the Windows 
system--I'm guessing it's unlikely that one partition would go bad but 
not another on the same HDD barring some process having corrupted one of 
the partitions.

I've removed the wonky HDD and will experiment some with it via an 
IDE-USB connection. I don't think there's actually that much data on it 
that I'd need. The eTower will go to recycle along with some other 
oldie's that should have gone out long ago.

Thanks.

EB
On 09/15/2014 02:19 PM, andross at gmail.com wrote:
> Yeah, failing hard drive, probably mucked up the partition tables. You 
> might be able to use testdisk to rebuild the partition table and get 
> at the data.
>
> On Mon, Sep 15, 2014 at 6:30 AM, Adam Tauno Williams 
> <awilliam at whitemice.org <mailto:awilliam at whitemice.org>> wrote:
>
>     On Sat, 2014-09-13 at 19:46 -0400, Eric Beversluis wrote:
>     > I was checking out an old computer this morning--a dual boot
>     setup with
>     > an early Fedora and Win98 on it--I hadn't run it for 6 or so years.
>     > Initially it booted up nicely to Windows (I aborted the Fedora
>     boot when
>     > my flat-screen monitor didn't like the resolution it was getting
>     from
>     > Fedora). But at some point it froze up and I had to power it down.
>     > Now it won't boot at all. It gets to the point of saying it's
>     found a
>     > boot at IDE 0 but then hangs. "Searching for boot record from
>     IDE-0. .OK"
>     > With Knoppix I can access the old Fedora files but even Knoppix
>     doesn't
>     > see the Windows partition--it only sees /dev/sda1 and /dev/sda2, the
>     > Fedora and swap partitions.
>     > Any ideas? Did the Windows partition just somehow self-destruct?
>
>     Does the system physically have two drives?  If it has only one then
>     wither SDA1 or SDA2 is the Windows partition.  What does the output of
>     "/sbin/fdisk -l" look like?
>
>     You have a failed/failing drive most likely - no surprise for a drive
>     that sat idle for six years.
>
>     --
>     Adam Tauno Williams <mailto:awilliam at whitemice.org
>     <mailto:awilliam at whitemice.org>> GPG D95ED383
>     Systems Administrator, Python Developer, LPI / NCLA
>
>     _______________________________________________
>     grlug mailing list
>     grlug at grlug.org <mailto:grlug at grlug.org>
>     http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>
>
>
>
> _______________________________________________
> grlug mailing list
> grlug at grlug.org
> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20140915/f169b64e/attachment.html>

From kyle at virtualinterconnect.com  Wed Sep 17 10:43:46 2014
From: kyle at virtualinterconnect.com (Kyle Maas)
Date: Wed, 17 Sep 2014 10:43:46 -0400
Subject: [GRLUG] Friday after Five
Message-ID: <54199E22.9090907@virtualinterconnect.com>

We here at Virtual Interconnect are hosting the Grand Rapids Linux
User's Group for weekly socials. Mike and myself serve as anchors; at
least one of us will be here during the event.

Time: 5PM-7PM Fridays, every week

Location: 315 Richard Terrace, Grand Rapids MI 49506 (Not
handicapped-accessible, sorry.) Google Street View:
http://goo.gl/maps/CDOzO

Commute: Parking is on the south side of the building, and The #6 bus
route runs right in front of us, the #5 and #19 come close. Nearest
stops: http://bit.ly/QyS7RY

Food: Popcorn and water are free. Anything else is BYOB (No alcohol),
although something else may be arranged for in the future.

Entry: The door is always locked, unless it's propped open. Ring the
doorbell if it's shut.

Loitering: When Mike and I have to go, we have to go. There are
restaurants, cafes and bookstores all around, though.

From christophersayer at gmail.com  Wed Sep 17 17:13:40 2014
From: christophersayer at gmail.com (Christopher Sayer)
Date: Wed, 17 Sep 2014 17:13:40 -0400
Subject: [GRLUG] Me
Message-ID: <CAMNuTyRT839aR8SFiQTuH7aUCnEJ=kv8iLi5xx6Zo1FqjqTKPA@mail.gmail.com>

Totally.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20140917/631326a6/attachment.html>

From geektoyz at gmail.com  Wed Sep 17 22:20:08 2014
From: geektoyz at gmail.com (Godwin)
Date: Wed, 17 Sep 2014 22:20:08 -0400
Subject: [GRLUG] Me
In-Reply-To: <CAMNuTyRT839aR8SFiQTuH7aUCnEJ=kv8iLi5xx6Zo1FqjqTKPA@mail.gmail.com>
References: <CAMNuTyRT839aR8SFiQTuH7aUCnEJ=kv8iLi5xx6Zo1FqjqTKPA@mail.gmail.com>
Message-ID: <CAO0okVycwvQE_zFZrGgCzY=HnZDVOr3EudkmM+eSx-KB3Gn_Gg@mail.gmail.com>

Welcome to the LUG Chris.
On Sep 17, 2014 5:13 PM, "Christopher Sayer" <christophersayer at gmail.com>
wrote:

> Totally.
>
> _______________________________________________
> grlug mailing list
> grlug at grlug.org
> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20140917/0bc12f22/attachment.html>

From kyle at virtualinterconnect.com  Thu Sep 18 14:50:08 2014
From: kyle at virtualinterconnect.com (Kyle Maas)
Date: Thu, 18 Sep 2014 14:50:08 -0400
Subject: [GRLUG] Me
In-Reply-To: <CAO0okVycwvQE_zFZrGgCzY=HnZDVOr3EudkmM+eSx-KB3Gn_Gg@mail.gmail.com>
References: <CAMNuTyRT839aR8SFiQTuH7aUCnEJ=kv8iLi5xx6Zo1FqjqTKPA@mail.gmail.com>
 <CAO0okVycwvQE_zFZrGgCzY=HnZDVOr3EudkmM+eSx-KB3Gn_Gg@mail.gmail.com>
Message-ID: <541B2960.7080800@virtualinterconnect.com>

For anyone new who hasn't heard, aside from the mailing list we also
have the website:

http://grlug.org/

The IRC chat channel:

#grlug on FreeNode

And the weekly informal meetings on Fridays from 5:00pm-7:00pm (see
other e-mail for location and other details).

Warm Regards,
Kyle Maas



On 09/17/2014 10:20 PM, Godwin wrote:
>
> Welcome to the LUG Chris.
>
> On Sep 17, 2014 5:13 PM, "Christopher Sayer"
> <christophersayer at gmail.com <mailto:christophersayer at gmail.com>> wrote:
>
>     Totally. 
>
>     _______________________________________________
>     grlug mailing list
>     grlug at grlug.org <mailto:grlug at grlug.org>
>     http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>
>
>
> _______________________________________________
> grlug mailing list
> grlug at grlug.org
> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20140918/ea3475b8/attachment.html>

From lvl at omnitec.net  Thu Sep 18 18:08:24 2014
From: lvl at omnitec.net (L. V. Lammert)
Date: Thu, 18 Sep 2014 17:08:24 -0500 (CDT)
Subject: [GRLUG] WiFi Weirdness
Message-ID: <Pine.BSO.4.53.1409181700010.7984@Mail.omnitec.net>

At a conference with a bunch of folks, .. WiFI is a big issue - even
sitting in front of the AP with nobody around, my machine cannot connect,
while a Mac has no problem!

It's hard to tell anything from the logs, am I missing something?

	TIA!

	Lee

====================================



2014-09-18T16:42:07.933189-05:00 Envy kernel: [24224.515753] cfg80211: Calling CRDA to update world regulatory domain
2014-09-18T16:42:07.941803-05:00 Envy kernel: [24224.527834] cfg80211: World regulatory domain updated:
2014-09-18T16:42:07.941821-05:00 Envy kernel: [24224.527839] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
2014-09-18T16:42:07.941823-05:00 Envy kernel: [24224.527842] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
2014-09-18T16:42:07.941825-05:00 Envy kernel: [24224.527844] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
2014-09-18T16:42:07.941826-05:00 Envy kernel: [24224.527846] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
2014-09-18T16:42:07.941827-05:00 Envy kernel: [24224.527847] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
2014-09-18T16:42:07.941828-05:00 Envy kernel: [24224.527849] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
2014-09-18T16:42:11.734977-05:00 Envy kernel: [24228.317676] wlo1: Athenticate with d8:c7:c8:39:5d:22
2014-09-18T16:42:11.753843-05:00 Envy kernel: [24228.336203] wlo1: send auth to d8:c7:c8:39:5d:22 (try 1/3)
2014-09-18T16:42:11.759819-05:00 Envy kernel: [24228.342342] wlo1: authenticated
2014-09-18T16:42:11.759882-05:00 Envy kernel: [24228.343133] wlo1: associate with d8:c7:c8:39:5d:22 (try 1/3)
2014-09-18T16:42:11.764807-05:00 Envy kernel: [24228.347718] wlo1: RX AssocResp from d8:c7:c8:39:5d:22 (capab=0x421 status=0 aid=2)
2014-09-18T16:42:11.764824-05:00 Envy kernel: [24228.347993] wlo1: associated
2014-09-18T16:42:11.779710-05:00 Envy avahi-daemon[658]: Withdrawing address record for fe80::2ae3:47ff:fea1:8ea1 on wlo1.
2014-09-18T16:42:11.780522-05:00 Envy avahi-daemon[658]: Leaving mDNSmulticast group on interface wlo1.IPv6 with address fe80::2ae3:47ff:fea1:8ea1.
2014-09-18T16:42:11.781179-05:00 Envy avahi-daemon[658]: Interface wlo1.IPv6 no longer relevant for mDNS.
2014-09-18T16:42:11.783847-05:00 Envy dhclient[20312]: Internet Systems Consortium DHCP Client 4.2.5-P1
2014-09-18T16:42:11.784696-05:00 Envy dhclient[20312]: Copyright 2004-2013 Internet Systems Consortium.
2014-09-18T16:42:11.785459-05:00 Envy dhclient[20312]: All rights reserved.
2014-09-18T16:42:11.785977-05:00 Envy dhclient[20312]: For info, please visit https://www.isc.org/software/dhcp/
2014-09-18T16:42:11.786209-05:00 Envy dhclient[20312]:
2014-09-18T16:42:11.801051-05:00 Envy dhclient[20312]: Listening on LPF/wlo1/28:e3:47:a1:8e:a1
2014-09-18T16:42:11.801547-05:00 Envy dhclient[20312]: Sending on   LPF/wlo1/28:e3:47:a1:8e:a1
2014-09-18T16:42:11.801948-05:00 Envy dhclient[20312]: Sending on   Socket/fallback
2014-09-18T16:42:11.802516-05:00 Envy dhclient[20312]: DHCPDISCOVER on wlo1 to 255.255.255.255 port 67 interval 4
2014-09-18T16:42:13.690299-05:00 Envy avahi-daemon[658]: Joining mDNS multicast group on interface wlo1.IPv6 with address fe80::2ae3:47ff:fea1:8ea1.
2014-09-18T16:42:13.691124-05:00 Envy avahi-daemon[658]: New relevant interface wlo1.IPv6 for mDNS.
2014-09-18T16:42:13.691770-05:00 Envy avahi-daemon[658]: Registering new address record for fe80::2ae3:47ff:fea1:8ea1 on wlo1.*.
2014-09-18T16:42:15.673832-05:00 Envy dhclient[20312]: DHCPDISCOVER on wlo1 to 255.255.255.255 port 67 interval 4
2014-09-18T16:42:19.959190-05:00 Envy dhclient[20312]: DHCPDISCOVER on wlo1 to 255.255.255.255 port 67 interval 9
2014-09-18T16:42:28.617309-05:00 Envy dhclient[20312]: DHCPDISCOVER on wlo1 to 255.255.255.255 port 67 interval 8
2014-09-18T16:42:36.130831-05:00 Envy dhclient[20312]: DHCPDISCOVER on wlo1 to 255.255.255.255 port 67 interval 14
2014-09-18T16:42:50.194039-05:00 Envy dhclient[20312]: DHCPDISCOVER on wlo1 to 255.255.255.255 port 67 interval 9
2014-09-18T16:42:56.921486-05:00 Envy kernel: [24273.462396] wlo1: deauthenticating from d8:c7:c8:39:5d:22 by local choice (reason=3)
2014-09-18T16:42:56.934429-05:00 Envy kernel: [24273.473721] cfg80211: Calling CRDA to update world regulatory domain
2014-09-18T16:42:56.942852-05:00 Envy kernel: [24273.483861] cfg80211: World regulatory domain updated:
2014-09-18T16:42:56.942864-05:00 Envy kernel: [24273.483868] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
2014-09-18T16:42:56.942866-05:00 Envy kernel: [24273.483872] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
2014-09-18T16:42:56.942868-05:00 Envy kernel: [24273.483875] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
2014-09-18T16:42:56.942869-05:00 Envy kernel: [24273.483877] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
2014-09-18T16:42:56.942870-05:00 Envy kernel: [24273.483879] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
2014-09-18T16:42:56.942872-05:00 Envy kernel: [24273.483882] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)


From mfarver at mindbent.org  Thu Sep 18 19:17:08 2014
From: mfarver at mindbent.org (Mark Farver)
Date: Thu, 18 Sep 2014 19:17:08 -0400
Subject: [GRLUG] WiFi Weirdness
In-Reply-To: <Pine.BSO.4.53.1409181700010.7984@Mail.omnitec.net>
References: <Pine.BSO.4.53.1409181700010.7984@Mail.omnitec.net>
Message-ID: <CACNU6M42g-pHGxUE0Dv5hXJbGPzDzscQTOXUciumQzRmyYusog@mail.gmail.com>

It appears you are failing to get a DHCP address from the server.  It is
either out of addresses or overloaded.  It will be random what clients will
be able to connect.

Mark
On Sep 18, 2014 6:08 PM, "L. V. Lammert" <lvl at omnitec.net> wrote:

> At a conference with a bunch of folks, .. WiFI is a big issue - even
> sitting in front of the AP with nobody around, my machine cannot connect,
> while a Mac has no problem!
>
> It's hard to tell anything from the logs, am I missing something?
>
>         TIA!
>
>         Lee
>
> ====================================
>
>
>
> 2014-09-18T16:42:07.933189-05:00 Envy kernel: [24224.515753] cfg80211:
> Calling CRDA to update world regulatory domain
> 2014-09-18T16:42:07.941803-05:00 Envy kernel: [24224.527834] cfg80211:
> World regulatory domain updated:
> 2014-09-18T16:42:07.941821-05:00 Envy kernel: [24224.527839] cfg80211:
> (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> 2014-09-18T16:42:07.941823-05:00 Envy kernel: [24224.527842] cfg80211:
> (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> 2014-09-18T16:42:07.941825-05:00 Envy kernel: [24224.527844] cfg80211:
> (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> 2014-09-18T16:42:07.941826-05:00 Envy kernel: [24224.527846] cfg80211:
> (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> 2014-09-18T16:42:07.941827-05:00 Envy kernel: [24224.527847] cfg80211:
> (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> 2014-09-18T16:42:07.941828-05:00 Envy kernel: [24224.527849] cfg80211:
> (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> 2014-09-18T16:42:11.734977-05:00 Envy kernel: [24228.317676] wlo1:
> Athenticate with d8:c7:c8:39:5d:22
> 2014-09-18T16:42:11.753843-05:00 Envy kernel: [24228.336203] wlo1: send
> auth to d8:c7:c8:39:5d:22 (try 1/3)
> 2014-09-18T16:42:11.759819-05:00 Envy kernel: [24228.342342] wlo1:
> authenticated
> 2014-09-18T16:42:11.759882-05:00 Envy kernel: [24228.343133] wlo1:
> associate with d8:c7:c8:39:5d:22 (try 1/3)
> 2014-09-18T16:42:11.764807-05:00 Envy kernel: [24228.347718] wlo1: RX
> AssocResp from d8:c7:c8:39:5d:22 (capab=0x421 status=0 aid=2)
> 2014-09-18T16:42:11.764824-05:00 Envy kernel: [24228.347993] wlo1:
> associated
> 2014-09-18T16:42:11.779710-05:00 Envy avahi-daemon[658]: Withdrawing
> address record for fe80::2ae3:47ff:fea1:8ea1 on wlo1.
> 2014-09-18T16:42:11.780522-05:00 Envy avahi-daemon[658]: Leaving
> mDNSmulticast group on interface wlo1.IPv6 with address
> fe80::2ae3:47ff:fea1:8ea1.
> 2014-09-18T16:42:11.781179-05:00 Envy avahi-daemon[658]: Interface
> wlo1.IPv6 no longer relevant for mDNS.
> 2014-09-18T16:42:11.783847-05:00 Envy dhclient[20312]: Internet Systems
> Consortium DHCP Client 4.2.5-P1
> 2014-09-18T16:42:11.784696-05:00 Envy dhclient[20312]: Copyright 2004-2013
> Internet Systems Consortium.
> 2014-09-18T16:42:11.785459-05:00 Envy dhclient[20312]: All rights reserved.
> 2014-09-18T16:42:11.785977-05:00 Envy dhclient[20312]: For info, please
> visit https://www.isc.org/software/dhcp/
> 2014-09-18T16:42:11.786209-05:00 Envy dhclient[20312]:
> 2014-09-18T16:42:11.801051-05:00 Envy dhclient[20312]: Listening on
> LPF/wlo1/28:e3:47:a1:8e:a1
> 2014-09-18T16:42:11.801547-05:00 Envy dhclient[20312]: Sending on
>  LPF/wlo1/28:e3:47:a1:8e:a1
> 2014-09-18T16:42:11.801948-05:00 Envy dhclient[20312]: Sending on
>  Socket/fallback
> 2014-09-18T16:42:11.802516-05:00 Envy dhclient[20312]: DHCPDISCOVER on
> wlo1 to 255.255.255.255 port 67 interval 4
> 2014-09-18T16:42:13.690299-05:00 Envy avahi-daemon[658]: Joining mDNS
> multicast group on interface wlo1.IPv6 with address
> fe80::2ae3:47ff:fea1:8ea1.
> 2014-09-18T16:42:13.691124-05:00 Envy avahi-daemon[658]: New relevant
> interface wlo1.IPv6 for mDNS.
> 2014-09-18T16:42:13.691770-05:00 Envy avahi-daemon[658]: Registering new
> address record for fe80::2ae3:47ff:fea1:8ea1 on wlo1.*.
> 2014-09-18T16:42:15.673832-05:00 Envy dhclient[20312]: DHCPDISCOVER on
> wlo1 to 255.255.255.255 port 67 interval 4
> 2014-09-18T16:42:19.959190-05:00 Envy dhclient[20312]: DHCPDISCOVER on
> wlo1 to 255.255.255.255 port 67 interval 9
> 2014-09-18T16:42:28.617309-05:00 Envy dhclient[20312]: DHCPDISCOVER on
> wlo1 to 255.255.255.255 port 67 interval 8
> 2014-09-18T16:42:36.130831-05:00 Envy dhclient[20312]: DHCPDISCOVER on
> wlo1 to 255.255.255.255 port 67 interval 14
> 2014-09-18T16:42:50.194039-05:00 Envy dhclient[20312]: DHCPDISCOVER on
> wlo1 to 255.255.255.255 port 67 interval 9
> 2014-09-18T16:42:56.921486-05:00 Envy kernel: [24273.462396] wlo1:
> deauthenticating from d8:c7:c8:39:5d:22 by local choice (reason=3)
> 2014-09-18T16:42:56.934429-05:00 Envy kernel: [24273.473721] cfg80211:
> Calling CRDA to update world regulatory domain
> 2014-09-18T16:42:56.942852-05:00 Envy kernel: [24273.483861] cfg80211:
> World regulatory domain updated:
> 2014-09-18T16:42:56.942864-05:00 Envy kernel: [24273.483868] cfg80211:
> (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> 2014-09-18T16:42:56.942866-05:00 Envy kernel: [24273.483872] cfg80211:
> (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> 2014-09-18T16:42:56.942868-05:00 Envy kernel: [24273.483875] cfg80211:
> (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> 2014-09-18T16:42:56.942869-05:00 Envy kernel: [24273.483877] cfg80211:
> (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> 2014-09-18T16:42:56.942870-05:00 Envy kernel: [24273.483879] cfg80211:
> (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> 2014-09-18T16:42:56.942872-05:00 Envy kernel: [24273.483882] cfg80211:
> (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>
> _______________________________________________
> grlug mailing list
> grlug at grlug.org
> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20140918/7310f616/attachment.html>

From lvl at omnitec.net  Thu Sep 18 20:06:23 2014
From: lvl at omnitec.net (L. V. Lammert)
Date: Thu, 18 Sep 2014 19:06:23 -0500 (CDT)
Subject: [GRLUG] WiFi Weirdness
In-Reply-To: <CACNU6M42g-pHGxUE0Dv5hXJbGPzDzscQTOXUciumQzRmyYusog@mail.gmail.com>
References: <Pine.BSO.4.53.1409181700010.7984@Mail.omnitec.net>
 <CACNU6M42g-pHGxUE0Dv5hXJbGPzDzscQTOXUciumQzRmyYusog@mail.gmail.com>
Message-ID: <Pine.BSO.4.53.1409181903100.7984@Mail.omnitec.net>

On Thu, 18 Sep 2014, Mark Farver wrote:

> It appears you are failing to get a DHCP address from the server.  It is
> either out of addresses or overloaded.  It will be random what clients will
> be able to connect.
>
That was my original thought, .. thanks!

	Lee

From awilliam at whitemice.org  Fri Sep 19 06:36:52 2014
From: awilliam at whitemice.org (Adam Tauno Williams)
Date: Fri, 19 Sep 2014 06:36:52 -0400
Subject: [GRLUG] WiFi Weirdness
In-Reply-To: <Pine.BSO.4.53.1409181700010.7984@Mail.omnitec.net>
References: <Pine.BSO.4.53.1409181700010.7984@Mail.omnitec.net>
Message-ID: <1411123012.2865.1.camel@whitemice.org>

On Thu, 2014-09-18 at 17:08 -0500, L. V. Lammert wrote: 
> At a conference with a bunch of folks, .. WiFI is a big issue - even
> sitting in front of the AP with nobody around, my machine cannot connect,
> while a Mac has no problem!
> It's hard to tell anything from the logs, am I missing something?
> 2014-09-18T16:42:56.921486-05:00 Envy kernel: [24273.462396] wlo1: deauthenticating from d8:c7:c8:39:5d:22 by local choice (reason=3)

deauthenticating from d8:c7:c8:39:5d:22 by local choice (reason=3)

Reason#3: Sending station has left or is leaving IBSS or ESS

- The AP is experiencing congestion and channel-hopping and you got
dropped out.
- The AP's mode [n/b/g] or implementation of that mode is not compatible
with your Supplicant.  
    - This is more common than most people think.  Don't buy cheap or
wierdo-brand APs.   Linksys made several series of APs that are plagued
with compatibility issues [AP541N,....]
    - Or it could be configured that way - a 2.4GHz AP configured to
only actually offer one mode, as that helps performance, but that mode
is one your supplicant does not support, or your supplicant is so stupid
it is just trying an unavailable mode anyway [more common than most
people think].

-- 
Adam Tauno Williams <mailto:awilliam at whitemice.org> GPG D95ED383
Systems Administrator, Python Developer, LPI / NCLA


From lvl at omnitec.net  Sat Sep 20 13:00:26 2014
From: lvl at omnitec.net (L. V. Lammert)
Date: Sat, 20 Sep 2014 12:00:26 -0500 (CDT)
Subject: [GRLUG] WiFi Weirdness
In-Reply-To: <1411123012.2865.1.camel@whitemice.org>
References: <Pine.BSO.4.53.1409181700010.7984@Mail.omnitec.net>
 <1411123012.2865.1.camel@whitemice.org>
Message-ID: <Pine.BSO.4.53.1409201158140.7984@Mail.omnitec.net>

On Fri, 19 Sep 2014, Adam Tauno Williams wrote:

> deauthenticating from d8:c7:c8:39:5d:22 by local choice (reason=3)
>
> Reason#3: Sending station has left or is leaving IBSS or ESS
>
> - The AP is experiencing congestion and channel-hopping and you got
> dropped out.
>
That is definiately the reason, .. the main question I had is why can an
Apple system connect right away, while a standard Linux stack (SuSE 13.1)
never receives an IP.

The test situation was after a session disbanded, and there were less than
10 folks in the room with open laptops - I asked the chap sitting nearby
if he had been getting a connection, so he opened his MacBook (or whatever
model) and logged right in, all the while I could not get an IP.

	Thanks!

	Lee

From mikemol at gmail.com  Mon Sep 22 17:00:46 2014
From: mikemol at gmail.com (Michael Mol)
Date: Mon, 22 Sep 2014 17:00:46 -0400
Subject: [GRLUG] Friday After Five
Message-ID: <CA+czFiDr3-U5joYcYH09McQb1QOD-8r8DKdFBh0bUhXCQJrVcg@mail.gmail.com>

We here at Virtual Interconnect are hosting the Grand Rapids Linux
User's Group for weekly socials. Mike and myself serve as anchors; at
least one of us will be here during the event.

Time: 5PM-7PM Fridays, every week

Location: 315 Richard Terrace, Grand Rapids MI 49506 (Not
handicapped-accessible, sorry.) Google Street View:
http://goo.gl/maps/CDOzO

Commute: Parking is on the south side of the building, and The #6 bus
route runs right in front of us, the #5 and #19 come close. Nearest
stops: http://bit.ly/QyS7RY

Food: Popcorn and water are free. Anything else is BYOB (No alcohol),
although something else may be arranged for in the future.

Entry: The door is always locked, unless it's propped open. Ring the
doorbell if it's shut.

Loitering: When Mike and I have to go, we have to go. There are
restaurants, cafes and bookstores all around, though.

-- 
:wq

From awilliam at whitemice.org  Mon Sep 22 21:32:24 2014
From: awilliam at whitemice.org (Adam Tauno Williams)
Date: Mon, 22 Sep 2014 21:32:24 -0400
Subject: [GRLUG] WiFi Weirdness
In-Reply-To: <Pine.BSO.4.53.1409201158140.7984@Mail.omnitec.net>
References: <Pine.BSO.4.53.1409181700010.7984@Mail.omnitec.net>
 <1411123012.2865.1.camel@whitemice.org>
 <Pine.BSO.4.53.1409201158140.7984@Mail.omnitec.net>
Message-ID: <20140922213224.Horde.kBHweZeICrNUIM2ot3v3qpA@aleph.wmmi.net>

Quoting "L. V. Lammert" <lvl at omnitec.net>:
> On Fri, 19 Sep 2014, Adam Tauno Williams wrote:
>> deauthenticating from d8:c7:c8:39:5d:22 by local choice (reason=3)
>> Reason#3: Sending station has left or is leaving IBSS or ESS
>> - The AP is experiencing congestion and channel-hopping and you got
>> dropped out.
> That is definiately the reason, .. the main question I had is why can an
> Apple system connect right away, while a standard Linux stack (SuSE 13.1)
> never receives an IP.

I wouldn't blame the OS.  It is more likely to be a firmware/chipset  
issue.  Sticking to a channel and handling congestion is a very NIC+AP  
specific thing.

> The test situation was after a session disbanded, and there were less than
> 10 folks in the room with open laptops - I asked the chap sitting nearby
> if he had been getting a connection, so he opened his MacBook (or whatever
> model) and logged right in, all the while I could not get an IP.




From jason.poort at gentex.com  Tue Sep 23 07:34:41 2014
From: jason.poort at gentex.com (Poort, Jason)
Date: Tue, 23 Sep 2014 11:34:41 +0000
Subject: [GRLUG] OEL kernel update
Message-ID: <9A9AAD641783184891E961B71285BD3F8D504318@ZVM204-MAILDB2.gentex.com>

Question for everyone.  I need to update the Unbreakable Linux Kernel for Oracle Enterprise Linux to a specific version (UEK R3 U1) for compatibility.  I have run the yum update for the kernel, but it installed the UEK R3 U3 kernel.  I have been asked to get the systems running on the U1 version, but I cannot find a way to get that kernel downloaded and installed.  Any help would be appreciated.  Currently, the system is running on this version of the RHEL kernel 2.6.32-279.el6.x86_64.  The server was upgraded from OEL 6.4 to 6.5 via yum update.

Thanks.

-Jason



THE INFORMATION CONTAINED IN THIS E-MAIL MESSAGE AND ANY ATTACHMENTS SENT FROM GENTEX CORPORATION IS GENTEX CONFIDENTIAL INFORMATION INTENDED ONLY FOR THE PERSONAL USE OF THE INDIVIDUAL OR ENTITY NAMED ABOVE. If you are not the intended recipient, you are hereby notified that any review, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender by return e-mail, and delete this e-mail message and any attachments from your computer.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20140923/34819741/attachment-0001.html>

From mfarver at mindbent.org  Tue Sep 23 07:58:26 2014
From: mfarver at mindbent.org (Mark Farver)
Date: Tue, 23 Sep 2014 07:58:26 -0400
Subject: [GRLUG] OEL kernel update
In-Reply-To: <9A9AAD641783184891E961B71285BD3F8D504318@ZVM204-MAILDB2.gentex.com>
References: <9A9AAD641783184891E961B71285BD3F8D504318@ZVM204-MAILDB2.gentex.com>
Message-ID: <CACNU6M62uXigfuW7vZq0+fqyhZyZj2QfJE9ooqEDnJ6CjW57GA@mail.gmail.com>

On Sep 23, 2014 7:34 AM, "Poort, Jason" <jason.poort at gentex.com> wrote:
>
> Question for everyone.  I need to update the Unbreakable Linux Kernel for
Oracle Enterprise Linux to a specific version (UEK R3 U1) for
compatibility.

Take a look at the yum-versionlock plugin.  You'll probably need to hand
download (or yum downgrade) the kernel then use version lock.

https://scottlinux.com/2013/03/18/red-hat-6-or-centos-6-yum-tips-lock-package-versions-and-only-apply-security-updates/

R3 will probably be compatible with R1 and will have security fixes you may
want.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20140923/cf24f390/attachment.html>

From awilliam at whitemice.org  Tue Sep 23 08:47:09 2014
From: awilliam at whitemice.org (Adam Tauno Williams)
Date: Tue, 23 Sep 2014 08:47:09 -0400
Subject: [GRLUG] OEL kernel update
In-Reply-To: <CACNU6M62uXigfuW7vZq0+fqyhZyZj2QfJE9ooqEDnJ6CjW57GA@mail.gmail.com>
References: <9A9AAD641783184891E961B71285BD3F8D504318@ZVM204-MAILDB2.gentex.com>
 <CACNU6M62uXigfuW7vZq0+fqyhZyZj2QfJE9ooqEDnJ6CjW57GA@mail.gmail.com>
Message-ID: <1411476429.3414.0.camel@whitemice.org>

> > Question for everyone.  I need to update the Unbreakable Linux
> Kernel for Oracle Enterprise Linux to a specific version (UEK R3 U1)
> for compatibility.  
> Take a look at the yum-versionlock plugin.  You'll probably need to
> hand download (or yum downgrade) the kernel then use version lock.
> https://scottlinux.com/2013/03/18/red-hat-6-or-centos-6-yum-tips-lock-package-versions-and-only-apply-security-updates/

+1

yum install yum-plugin-versionlock
yum versionlock add {package-pattern}

> R3 will probably be compatible with R1 and will have security fixes
> you may want.

+1

-- 
Adam Tauno Williams <mailto:awilliam at whitemice.org> GPG D95ED383
Systems Administrator, Python Developer, LPI / NCLA


From signals42 at gmail.com  Wed Sep 24 14:44:43 2014
From: signals42 at gmail.com (Kevin McCarthy)
Date: Wed, 24 Sep 2014 14:44:43 -0400
Subject: [GRLUG] CVE-2014-6271
Message-ID: <CAFoUb4RUuyoHupqaXnR=LP8Sc1w0JTMHemiNH6nsg5rb9Xk+5w@mail.gmail.com>

Figured I'd pass this along to the mailing list since it looks quite
serious:

http://www.csoonline.com/article/2687265/application-security/remote-exploit-in-bash-cve-2014-6271.html

Almost every Linux install is vulnerable to a potentially-remote execution
exploit involving bash. I know it has been patched in Gentoo and RHEL. It's
probably been fixed in most other distros by now, too. Time to patch!

-Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20140924/c1a83d92/attachment.html>

From john at wesorick.com  Wed Sep 24 14:49:38 2014
From: john at wesorick.com (John Wesorick)
Date: Wed, 24 Sep 2014 14:49:38 -0400
Subject: [GRLUG] CVE-2014-6271
In-Reply-To: <CAFoUb4RUuyoHupqaXnR=LP8Sc1w0JTMHemiNH6nsg5rb9Xk+5w@mail.gmail.com>
References: <CAFoUb4RUuyoHupqaXnR=LP8Sc1w0JTMHemiNH6nsg5rb9Xk+5w@mail.gmail.com>
Message-ID: <CACrkP+ENFcYPZhnYovjVoyV2svhry41UmLZYn0Yt44+HcsBhaw@mail.gmail.com>

Ubuntu <http://www.ubuntu.com/usn/usn-2362-1/> and Debian
<https://lists.debian.org/debian-security-announce/2014/msg00220.html> were
patched as well.

On Wed, Sep 24, 2014 at 2:44 PM, Kevin McCarthy <signals42 at gmail.com> wrote:

> Figured I'd pass this along to the mailing list since it looks quite
> serious:
>
>
> http://www.csoonline.com/article/2687265/application-security/remote-exploit-in-bash-cve-2014-6271.html
>
> Almost every Linux install is vulnerable to a potentially-remote execution
> exploit involving bash. I know it has been patched in Gentoo and RHEL. It's
> probably been fixed in most other distros by now, too. Time to patch!
>
> -Kevin
>
>
> _______________________________________________
> grlug mailing list
> grlug at grlug.org
> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20140924/5b0ecb7f/attachment.html>

From mfarver at mindbent.org  Wed Sep 24 15:08:42 2014
From: mfarver at mindbent.org (Mark Farver)
Date: Wed, 24 Sep 2014 15:08:42 -0400
Subject: [GRLUG] CVE-2014-6271
In-Reply-To: <CACrkP+ENFcYPZhnYovjVoyV2svhry41UmLZYn0Yt44+HcsBhaw@mail.gmail.com>
References: <CAFoUb4RUuyoHupqaXnR=LP8Sc1w0JTMHemiNH6nsg5rb9Xk+5w@mail.gmail.com>
 <CACrkP+ENFcYPZhnYovjVoyV2svhry41UmLZYn0Yt44+HcsBhaw@mail.gmail.com>
Message-ID: <CACNU6M713X1nHpWVgyQ0mcAs0V2xs5sJtBuqqK-gAX_C35EqFA@mail.gmail.com>

I think it is a stretch to label this remotely exploitable.  If an attacker
has remote control of environment variables you have bigger problems.

Mark
On Sep 24, 2014 2:50 PM, "John Wesorick" <john at wesorick.com> wrote:

> Ubuntu <http://www.ubuntu.com/usn/usn-2362-1/> and Debian
> <https://lists.debian.org/debian-security-announce/2014/msg00220.html>
> were patched as well.
>
> On Wed, Sep 24, 2014 at 2:44 PM, Kevin McCarthy <signals42 at gmail.com>
> wrote:
>
>> Figured I'd pass this along to the mailing list since it looks quite
>> serious:
>>
>>
>> http://www.csoonline.com/article/2687265/application-security/remote-exploit-in-bash-cve-2014-6271.html
>>
>> Almost every Linux install is vulnerable to a potentially-remote
>> execution exploit involving bash. I know it has been patched in Gentoo and
>> RHEL. It's probably been fixed in most other distros by now, too. Time to
>> patch!
>>
>> -Kevin
>>
>>
>> _______________________________________________
>> grlug mailing list
>> grlug at grlug.org
>> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>>
>
>
> _______________________________________________
> grlug mailing list
> grlug at grlug.org
> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20140924/c8db99f5/attachment-0001.html>

From mikemol at gmail.com  Wed Sep 24 16:24:01 2014
From: mikemol at gmail.com (Michael Mol)
Date: Wed, 24 Sep 2014 16:24:01 -0400
Subject: [GRLUG] CVE-2014-6271
In-Reply-To: <CACNU6M713X1nHpWVgyQ0mcAs0V2xs5sJtBuqqK-gAX_C35EqFA@mail.gmail.com>
References: <CAFoUb4RUuyoHupqaXnR=LP8Sc1w0JTMHemiNH6nsg5rb9Xk+5w@mail.gmail.com>
 <CACrkP+ENFcYPZhnYovjVoyV2svhry41UmLZYn0Yt44+HcsBhaw@mail.gmail.com>
 <CACNU6M713X1nHpWVgyQ0mcAs0V2xs5sJtBuqqK-gAX_C35EqFA@mail.gmail.com>
Message-ID: <9c62c874-8fb5-4857-be96-5c327e09041f@email.android.com>

dhcpd passes client-proved values to shell scripts as environment variables. Also going to be a concern in CGI setups.

On September 24, 2014 3:08:42 PM EDT, Mark Farver <mfarver at mindbent.org> wrote:
>I think it is a stretch to label this remotely exploitable.  If an
>attacker
>has remote control of environment variables you have bigger problems.
>
>Mark
>On Sep 24, 2014 2:50 PM, "John Wesorick" <john at wesorick.com> wrote:
>
>> Ubuntu <http://www.ubuntu.com/usn/usn-2362-1/> and Debian
>>
><https://lists.debian.org/debian-security-announce/2014/msg00220.html>
>> were patched as well.
>>
>> On Wed, Sep 24, 2014 at 2:44 PM, Kevin McCarthy <signals42 at gmail.com>
>> wrote:
>>
>>> Figured I'd pass this along to the mailing list since it looks quite
>>> serious:
>>>
>>>
>>>
>http://www.csoonline.com/article/2687265/application-security/remote-exploit-in-bash-cve-2014-6271.html
>>>
>>> Almost every Linux install is vulnerable to a potentially-remote
>>> execution exploit involving bash. I know it has been patched in
>Gentoo and
>>> RHEL. It's probably been fixed in most other distros by now, too.
>Time to
>>> patch!
>>>
>>> -Kevin
>>>
>>>
>>> _______________________________________________
>>> grlug mailing list
>>> grlug at grlug.org
>>> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>>>
>>
>>
>> _______________________________________________
>> grlug mailing list
>> grlug at grlug.org
>> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>grlug mailing list
>grlug at grlug.org
>http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20140924/9aa089b8/attachment.html>

From signals42 at gmail.com  Wed Sep 24 16:27:18 2014
From: signals42 at gmail.com (Kevin McCarthy)
Date: Wed, 24 Sep 2014 16:27:18 -0400
Subject: [GRLUG] CVE-2014-6271
In-Reply-To: <CACNU6M713X1nHpWVgyQ0mcAs0V2xs5sJtBuqqK-gAX_C35EqFA@mail.gmail.com>
References: <CAFoUb4RUuyoHupqaXnR=LP8Sc1w0JTMHemiNH6nsg5rb9Xk+5w@mail.gmail.com>
 <CACrkP+ENFcYPZhnYovjVoyV2svhry41UmLZYn0Yt44+HcsBhaw@mail.gmail.com>
 <CACNU6M713X1nHpWVgyQ0mcAs0V2xs5sJtBuqqK-gAX_C35EqFA@mail.gmail.com>
Message-ID: <CAFoUb4SYOxF91NYpxk7H+Y2ebpsGjhr46C2-SQ6aVQvj9yywXw@mail.gmail.com>

Well, the BIG one is CGI scripts from a web server which passes data via
environment variables. But OpenSSH could be vulnerable via TERM or anything
in AcceptEnv. I think you'd be surprised how many attack vectors there are
for this one.

-Kevin

On Wed, Sep 24, 2014 at 3:08 PM, Mark Farver <mfarver at mindbent.org> wrote:

> I think it is a stretch to label this remotely exploitable.  If an
> attacker has remote control of environment variables you have bigger
> problems.
>
> Mark
> On Sep 24, 2014 2:50 PM, "John Wesorick" <john at wesorick.com> wrote:
>
>> Ubuntu <http://www.ubuntu.com/usn/usn-2362-1/> and Debian
>> <https://lists.debian.org/debian-security-announce/2014/msg00220.html>
>> were patched as well.
>>
>> On Wed, Sep 24, 2014 at 2:44 PM, Kevin McCarthy <signals42 at gmail.com>
>> wrote:
>>
>>> Figured I'd pass this along to the mailing list since it looks quite
>>> serious:
>>>
>>>
>>> http://www.csoonline.com/article/2687265/application-security/remote-exploit-in-bash-cve-2014-6271.html
>>>
>>> Almost every Linux install is vulnerable to a potentially-remote
>>> execution exploit involving bash. I know it has been patched in Gentoo and
>>> RHEL. It's probably been fixed in most other distros by now, too. Time to
>>> patch!
>>>
>>> -Kevin
>>>
>>>
>>> _______________________________________________
>>> grlug mailing list
>>> grlug at grlug.org
>>> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>>>
>>
>>
>> _______________________________________________
>> grlug mailing list
>> grlug at grlug.org
>> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>>
>
> _______________________________________________
> grlug mailing list
> grlug at grlug.org
> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20140924/b6c69b61/attachment.html>

From mikemol at gmail.com  Wed Sep 24 16:30:08 2014
From: mikemol at gmail.com (Michael Mol)
Date: Wed, 24 Sep 2014 16:30:08 -0400
Subject: [GRLUG] CVE-2014-6271
In-Reply-To: <CAFoUb4SYOxF91NYpxk7H+Y2ebpsGjhr46C2-SQ6aVQvj9yywXw@mail.gmail.com>
References: <CAFoUb4RUuyoHupqaXnR=LP8Sc1w0JTMHemiNH6nsg5rb9Xk+5w@mail.gmail.com>
 <CACrkP+ENFcYPZhnYovjVoyV2svhry41UmLZYn0Yt44+HcsBhaw@mail.gmail.com>
 <CACNU6M713X1nHpWVgyQ0mcAs0V2xs5sJtBuqqK-gAX_C35EqFA@mail.gmail.com>
 <CAFoUb4SYOxF91NYpxk7H+Y2ebpsGjhr46C2-SQ6aVQvj9yywXw@mail.gmail.com>
Message-ID: <cba22757-3baf-4da9-9fa6-d4a3894b1582@email.android.com>

Nah, not going to be surprised. But don't you have to successfully auth to get anything AcceptEnv passed along? And sshd downgrades privileges by that point.

On September 24, 2014 4:27:18 PM EDT, Kevin McCarthy <signals42 at gmail.com> wrote:
>Well, the BIG one is CGI scripts from a web server which passes data
>via
>environment variables. But OpenSSH could be vulnerable via TERM or
>anything
>in AcceptEnv. I think you'd be surprised how many attack vectors there
>are
>for this one.
>
>-Kevin
>
>On Wed, Sep 24, 2014 at 3:08 PM, Mark Farver <mfarver at mindbent.org>
>wrote:
>
>> I think it is a stretch to label this remotely exploitable.  If an
>> attacker has remote control of environment variables you have bigger
>> problems.
>>
>> Mark
>> On Sep 24, 2014 2:50 PM, "John Wesorick" <john at wesorick.com> wrote:
>>
>>> Ubuntu <http://www.ubuntu.com/usn/usn-2362-1/> and Debian
>>>
><https://lists.debian.org/debian-security-announce/2014/msg00220.html>
>>> were patched as well.
>>>
>>> On Wed, Sep 24, 2014 at 2:44 PM, Kevin McCarthy
><signals42 at gmail.com>
>>> wrote:
>>>
>>>> Figured I'd pass this along to the mailing list since it looks
>quite
>>>> serious:
>>>>
>>>>
>>>>
>http://www.csoonline.com/article/2687265/application-security/remote-exploit-in-bash-cve-2014-6271.html
>>>>
>>>> Almost every Linux install is vulnerable to a potentially-remote
>>>> execution exploit involving bash. I know it has been patched in
>Gentoo and
>>>> RHEL. It's probably been fixed in most other distros by now, too.
>Time to
>>>> patch!
>>>>
>>>> -Kevin
>>>>
>>>>
>>>> _______________________________________________
>>>> grlug mailing list
>>>> grlug at grlug.org
>>>> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>>>>
>>>
>>>
>>> _______________________________________________
>>> grlug mailing list
>>> grlug at grlug.org
>>> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>>>
>>
>> _______________________________________________
>> grlug mailing list
>> grlug at grlug.org
>> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>grlug mailing list
>grlug at grlug.org
>http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20140924/e2588042/attachment-0001.html>

From awilliam at whitemice.org  Thu Sep 25 08:16:53 2014
From: awilliam at whitemice.org (Adam Tauno Williams)
Date: Thu, 25 Sep 2014 08:16:53 -0400
Subject: [GRLUG] CVE-2014-6271
In-Reply-To: <CACNU6M713X1nHpWVgyQ0mcAs0V2xs5sJtBuqqK-gAX_C35EqFA@mail.gmail.com>
References: <CAFoUb4RUuyoHupqaXnR=LP8Sc1w0JTMHemiNH6nsg5rb9Xk+5w@mail.gmail.com>
 <CACrkP+ENFcYPZhnYovjVoyV2svhry41UmLZYn0Yt44+HcsBhaw@mail.gmail.com>
 <CACNU6M713X1nHpWVgyQ0mcAs0V2xs5sJtBuqqK-gAX_C35EqFA@mail.gmail.com>
Message-ID: <1411647413.6473.1.camel@whitemice.org>

On Wed, 2014-09-24 at 15:08 -0400, Mark Farver wrote:
> I think it is a stretch to label this remotely exploitable. 

Ditto.  This is a theoretical exploit of a system that has issues.

On the other hand updating bash should be pretty non-invasive.

> If an attacker has remote control of environment variables you have
> bigger problems.

Especially if the attacker has SSH access to the box!

FYI:
  1. The default setting in modern SSH versions is 
"PermitUserEnvironment no"
  2. The default value of "AcceptEnv" is empty set.
  3. There has been a warning about pushing environment variables via
SSH since I can remember.

Shell scripts via CGI on the other hand.... just pretty bad idea all
around IMNSHO.

-- 
Adam Tauno Williams <mailto:awilliam at whitemice.org> GPG D95ED383
Systems Administrator, Python Developer, LPI / NCLA


From mikemol at gmail.com  Thu Sep 25 08:55:24 2014
From: mikemol at gmail.com (Michael Mol)
Date: Thu, 25 Sep 2014 08:55:24 -0400
Subject: [GRLUG] CVE-2014-6271
In-Reply-To: <1411647413.6473.1.camel@whitemice.org>
References: <CAFoUb4RUuyoHupqaXnR=LP8Sc1w0JTMHemiNH6nsg5rb9Xk+5w@mail.gmail.com>
 <CACrkP+ENFcYPZhnYovjVoyV2svhry41UmLZYn0Yt44+HcsBhaw@mail.gmail.com>
 <CACNU6M713X1nHpWVgyQ0mcAs0V2xs5sJtBuqqK-gAX_C35EqFA@mail.gmail.com>
 <1411647413.6473.1.camel@whitemice.org>
Message-ID: <CA+czFiCVWqGNQV438vcc1=PsmZfO94zvxsSgbGCvSCTYtbQhUw@mail.gmail.com>

On Thu, Sep 25, 2014 at 8:16 AM, Adam Tauno Williams
<awilliam at whitemice.org> wrote:
> On Wed, 2014-09-24 at 15:08 -0400, Mark Farver wrote:
>> I think it is a stretch to label this remotely exploitable.
>
> Ditto.  This is a theoretical exploit of a system that has issues.

I'd like to hear your explanation of this. Why would a system have to
have "issues" for this to be exploitable? (Outside of the obvious that
it's running a vulnerable version of bash.)

-- 
:wq

From mfarver at mindbent.org  Thu Sep 25 10:37:47 2014
From: mfarver at mindbent.org (Mark Farver)
Date: Thu, 25 Sep 2014 10:37:47 -0400
Subject: [GRLUG] CVE-2014-6271
In-Reply-To: <CA+czFiCVWqGNQV438vcc1=PsmZfO94zvxsSgbGCvSCTYtbQhUw@mail.gmail.com>
References: <CAFoUb4RUuyoHupqaXnR=LP8Sc1w0JTMHemiNH6nsg5rb9Xk+5w@mail.gmail.com>
 <CACrkP+ENFcYPZhnYovjVoyV2svhry41UmLZYn0Yt44+HcsBhaw@mail.gmail.com>
 <CACNU6M713X1nHpWVgyQ0mcAs0V2xs5sJtBuqqK-gAX_C35EqFA@mail.gmail.com>
 <1411647413.6473.1.camel@whitemice.org>
 <CA+czFiCVWqGNQV438vcc1=PsmZfO94zvxsSgbGCvSCTYtbQhUw@mail.gmail.com>
Message-ID: <CACNU6M6JjH6odeXdNrjAB=VaDgNsGyE4p=UWVU9ycNvdGW91zg@mail.gmail.com>

If an attacker has remote control of environment variables think of the
damage that can be done with LD_LIBRARY_PATH.  Upload a file to a harmless
path on webserver and use the library path to link it into an executable
running in a CGI env.  Instant remote code execution.

Many applications have buffer overflows in environment handling.  Remote
code execution or denial of service.

Basically environment variables are not terribly secure and have not
received a lot of security analysis.  If you let an attacker control them
for a process running as another user there are probably vectors there.

Mark
On Sep 25, 2014 8:55 AM, "Michael Mol" <mikemol at gmail.com> wrote:

> On Thu, Sep 25, 2014 at 8:16 AM, Adam Tauno Williams
> <awilliam at whitemice.org> wrote:
> > On Wed, 2014-09-24 at 15:08 -0400, Mark Farver wrote:
> >> I think it is a stretch to label this remotely exploitable.
> >
> > Ditto.  This is a theoretical exploit of a system that has issues.
>
> I'd like to hear your explanation of this. Why would a system have to
> have "issues" for this to be exploitable? (Outside of the obvious that
> it's running a vulnerable version of bash.)
>
> --
> :wq
> _______________________________________________
> grlug mailing list
> grlug at grlug.org
> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20140925/a4b079a0/attachment.html>

From awilliam at whitemice.org  Thu Sep 25 10:44:35 2014
From: awilliam at whitemice.org (Adam Tauno Williams)
Date: Thu, 25 Sep 2014 10:44:35 -0400
Subject: [GRLUG] CVE-2014-6271
In-Reply-To: <CACNU6M6JjH6odeXdNrjAB=VaDgNsGyE4p=UWVU9ycNvdGW91zg@mail.gmail.com>
References: <CAFoUb4RUuyoHupqaXnR=LP8Sc1w0JTMHemiNH6nsg5rb9Xk+5w@mail.gmail.com>
 <CACrkP+ENFcYPZhnYovjVoyV2svhry41UmLZYn0Yt44+HcsBhaw@mail.gmail.com>
 <CACNU6M713X1nHpWVgyQ0mcAs0V2xs5sJtBuqqK-gAX_C35EqFA@mail.gmail.com>
 <1411647413.6473.1.camel@whitemice.org>
 <CA+czFiCVWqGNQV438vcc1=PsmZfO94zvxsSgbGCvSCTYtbQhUw@mail.gmail.com>
 <CACNU6M6JjH6odeXdNrjAB=VaDgNsGyE4p=UWVU9ycNvdGW91zg@mail.gmail.com>
Message-ID: <1411656275.6473.7.camel@whitemice.org>

On Thu, 2014-09-25 at 10:37 -0400, Mark Farver wrote:
> If an attacker has remote control of environment variables think of
> the damage that can be done with LD_LIBRARY_PATH.  Upload a file to a
> harmless path on webserver and use the library path to link it into an
> executable running in a CGI env.  Instant remote code execution.

This.

I am not saying the reported exploit is not real or valid... but there
is nothing NEW here.  Everyone has known about this forever.

I attended GRCC where I took a UNIX admin class.  It was a really lousy
simplistic course.  But they even mentioned
environment-variables-are-a-security-problem in that class; one of the
about three security issues they bothered to mention.

This exploit seems to be about bash specifically, and specifically about
ways to set environment variables.  But really, I just don't want
set-an-environment-variable to ever happen.

> Basically environment variables are not terribly secure and have not
> received a lot of security analysis.  If you let an attacker control
> them for a process running as another user there are probably vectors
> there.  

-- 
Adam Tauno Williams <mailto:awilliam at whitemice.org> GPG D95ED383
Systems Administrator, Python Developer, LPI / NCLA


From mikemol at gmail.com  Thu Sep 25 13:02:57 2014
From: mikemol at gmail.com (Michael Mol)
Date: Thu, 25 Sep 2014 13:02:57 -0400
Subject: [GRLUG] CVE-2014-6271
In-Reply-To: <1411656275.6473.7.camel@whitemice.org>
References: <CAFoUb4RUuyoHupqaXnR=LP8Sc1w0JTMHemiNH6nsg5rb9Xk+5w@mail.gmail.com>
 <CACrkP+ENFcYPZhnYovjVoyV2svhry41UmLZYn0Yt44+HcsBhaw@mail.gmail.com>
 <CACNU6M713X1nHpWVgyQ0mcAs0V2xs5sJtBuqqK-gAX_C35EqFA@mail.gmail.com>
 <1411647413.6473.1.camel@whitemice.org>
 <CA+czFiCVWqGNQV438vcc1=PsmZfO94zvxsSgbGCvSCTYtbQhUw@mail.gmail.com>
 <CACNU6M6JjH6odeXdNrjAB=VaDgNsGyE4p=UWVU9ycNvdGW91zg@mail.gmail.com>
 <1411656275.6473.7.camel@whitemice.org>
Message-ID: <CA+czFiAOnnia947ziSugFDP753E=r94pXA8GdcwMaC=7ReM77w@mail.gmail.com>

It's not about control over environment variable names. It's about
*invalid parsing* of environment variable contents as they're being
passed.

>From here: https://access.redhat.com/node/1200223

env x='() { :;}; echo vulnerable'  bash -c "echo this is a test"

The problem is how the environment variable is parsed. The *name*
could be anything. It obviously doesn't have to be "x". It could be
"CLIENT_SELF_REPORTED_NAME" or "X_USER_AGENT" or whatever.

At least, that's how I understand it.


On Thu, Sep 25, 2014 at 10:44 AM, Adam Tauno Williams
<awilliam at whitemice.org> wrote:
> On Thu, 2014-09-25 at 10:37 -0400, Mark Farver wrote:
>> If an attacker has remote control of environment variables think of
>> the damage that can be done with LD_LIBRARY_PATH.  Upload a file to a
>> harmless path on webserver and use the library path to link it into an
>> executable running in a CGI env.  Instant remote code execution.
>
> This.
>
> I am not saying the reported exploit is not real or valid... but there
> is nothing NEW here.  Everyone has known about this forever.
>
> I attended GRCC where I took a UNIX admin class.  It was a really lousy
> simplistic course.  But they even mentioned
> environment-variables-are-a-security-problem in that class; one of the
> about three security issues they bothered to mention.
>
> This exploit seems to be about bash specifically, and specifically about
> ways to set environment variables.  But really, I just don't want
> set-an-environment-variable to ever happen.
>
>> Basically environment variables are not terribly secure and have not
>> received a lot of security analysis.  If you let an attacker control
>> them for a process running as another user there are probably vectors
>> there.
>
> --
> Adam Tauno Williams <mailto:awilliam at whitemice.org> GPG D95ED383
> Systems Administrator, Python Developer, LPI / NCLA
>
> _______________________________________________
> grlug mailing list
> grlug at grlug.org
> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug



-- 
:wq

From mikemol at gmail.com  Thu Sep 25 13:05:02 2014
From: mikemol at gmail.com (Michael Mol)
Date: Thu, 25 Sep 2014 13:05:02 -0400
Subject: [GRLUG] CVE-2014-6271
In-Reply-To: <CA+czFiAOnnia947ziSugFDP753E=r94pXA8GdcwMaC=7ReM77w@mail.gmail.com>
References: <CAFoUb4RUuyoHupqaXnR=LP8Sc1w0JTMHemiNH6nsg5rb9Xk+5w@mail.gmail.com>
 <CACrkP+ENFcYPZhnYovjVoyV2svhry41UmLZYn0Yt44+HcsBhaw@mail.gmail.com>
 <CACNU6M713X1nHpWVgyQ0mcAs0V2xs5sJtBuqqK-gAX_C35EqFA@mail.gmail.com>
 <1411647413.6473.1.camel@whitemice.org>
 <CA+czFiCVWqGNQV438vcc1=PsmZfO94zvxsSgbGCvSCTYtbQhUw@mail.gmail.com>
 <CACNU6M6JjH6odeXdNrjAB=VaDgNsGyE4p=UWVU9ycNvdGW91zg@mail.gmail.com>
 <1411656275.6473.7.camel@whitemice.org>
 <CA+czFiAOnnia947ziSugFDP753E=r94pXA8GdcwMaC=7ReM77w@mail.gmail.com>
Message-ID: <CA+czFiB2YGTODHWw4Jic8KHypS05NTKEZfVc3Ts8a6K-nha7TA@mail.gmail.com>

Oh, and from the same link:

CUPS - It is believed that CUPS is affected by this issue. Various
user supplied values are stored in environment variables when cups
filters are executed.

On Thu, Sep 25, 2014 at 1:02 PM, Michael Mol <mikemol at gmail.com> wrote:
> It's not about control over environment variable names. It's about
> *invalid parsing* of environment variable contents as they're being
> passed.
>
> From here: https://access.redhat.com/node/1200223
>
> env x='() { :;}; echo vulnerable'  bash -c "echo this is a test"
>
> The problem is how the environment variable is parsed. The *name*
> could be anything. It obviously doesn't have to be "x". It could be
> "CLIENT_SELF_REPORTED_NAME" or "X_USER_AGENT" or whatever.
>
> At least, that's how I understand it.
>
>
> On Thu, Sep 25, 2014 at 10:44 AM, Adam Tauno Williams
> <awilliam at whitemice.org> wrote:
>> On Thu, 2014-09-25 at 10:37 -0400, Mark Farver wrote:
>>> If an attacker has remote control of environment variables think of
>>> the damage that can be done with LD_LIBRARY_PATH.  Upload a file to a
>>> harmless path on webserver and use the library path to link it into an
>>> executable running in a CGI env.  Instant remote code execution.
>>
>> This.
>>
>> I am not saying the reported exploit is not real or valid... but there
>> is nothing NEW here.  Everyone has known about this forever.
>>
>> I attended GRCC where I took a UNIX admin class.  It was a really lousy
>> simplistic course.  But they even mentioned
>> environment-variables-are-a-security-problem in that class; one of the
>> about three security issues they bothered to mention.
>>
>> This exploit seems to be about bash specifically, and specifically about
>> ways to set environment variables.  But really, I just don't want
>> set-an-environment-variable to ever happen.
>>
>>> Basically environment variables are not terribly secure and have not
>>> received a lot of security analysis.  If you let an attacker control
>>> them for a process running as another user there are probably vectors
>>> there.
>>
>> --
>> Adam Tauno Williams <mailto:awilliam at whitemice.org> GPG D95ED383
>> Systems Administrator, Python Developer, LPI / NCLA
>>
>> _______________________________________________
>> grlug mailing list
>> grlug at grlug.org
>> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>
>
>
> --
> :wq



-- 
:wq

From signals42 at gmail.com  Thu Sep 25 13:19:32 2014
From: signals42 at gmail.com (Kevin McCarthy)
Date: Thu, 25 Sep 2014 13:19:32 -0400
Subject: [GRLUG] CVE-2014-6271
In-Reply-To: <CACNU6M6JjH6odeXdNrjAB=VaDgNsGyE4p=UWVU9ycNvdGW91zg@mail.gmail.com>
References: <CAFoUb4RUuyoHupqaXnR=LP8Sc1w0JTMHemiNH6nsg5rb9Xk+5w@mail.gmail.com>
 <CACrkP+ENFcYPZhnYovjVoyV2svhry41UmLZYn0Yt44+HcsBhaw@mail.gmail.com>
 <CACNU6M713X1nHpWVgyQ0mcAs0V2xs5sJtBuqqK-gAX_C35EqFA@mail.gmail.com>
 <1411647413.6473.1.camel@whitemice.org>
 <CA+czFiCVWqGNQV438vcc1=PsmZfO94zvxsSgbGCvSCTYtbQhUw@mail.gmail.com>
 <CACNU6M6JjH6odeXdNrjAB=VaDgNsGyE4p=UWVU9ycNvdGW91zg@mail.gmail.com>
Message-ID: <CAFoUb4SM4FW3WX3kv7LDRCQfKSZm5pF_s8YqZhLa5S5hM-jaGg@mail.gmail.com>

>
> If an attacker has remote control of environment variables think of the
> damage that can be done with LD_LIBRARY_PATH.
>

The issue here is that it can be expolited through ANY environment
variable. So, the env variables that pass things to CGI are vulnerable. You
can exploit it with a variable called X. TERM even works.

This exploit seems to be about bash specifically, and specifically about
> ways to set environment variables.  But really, I just don't want
> set-an-environment-variable to ever happen.
>

I agree, I don't WANT it to happen either. But, what I want, and what
actually happens within my organization are two completely different
things. I've got several pieces of commercial off-the-shelf software
running on multiple servers that make use of CGI scripts. I don't have the
ability to tell my customers that they can't have that software anymore,
and I don't have the resources (or legal right in many cases) to modify it
to do something saner than CGI. Best practice != real environment.

But, whatever... It's probably a big issue for most enterprises; the
information is out there, so patch if you think it important enough... Or
don't.



On Thu, Sep 25, 2014 at 10:37 AM, Mark Farver <mfarver at mindbent.org> wrote:

> If an attacker has remote control of environment variables think of the
> damage that can be done with LD_LIBRARY_PATH.  Upload a file to a harmless
> path on webserver and use the library path to link it into an executable
> running in a CGI env.  Instant remote code execution.
>
> Many applications have buffer overflows in environment handling.  Remote
> code execution or denial of service.
>
> Basically environment variables are not terribly secure and have not
> received a lot of security analysis.  If you let an attacker control them
> for a process running as another user there are probably vectors there.
>
> Mark
> On Sep 25, 2014 8:55 AM, "Michael Mol" <mikemol at gmail.com> wrote:
>
>> On Thu, Sep 25, 2014 at 8:16 AM, Adam Tauno Williams
>> <awilliam at whitemice.org> wrote:
>> > On Wed, 2014-09-24 at 15:08 -0400, Mark Farver wrote:
>> >> I think it is a stretch to label this remotely exploitable.
>> >
>> > Ditto.  This is a theoretical exploit of a system that has issues.
>>
>> I'd like to hear your explanation of this. Why would a system have to
>> have "issues" for this to be exploitable? (Outside of the obvious that
>> it's running a vulnerable version of bash.)
>>
>> --
>> :wq
>> _______________________________________________
>> grlug mailing list
>> grlug at grlug.org
>> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>>
>
> _______________________________________________
> grlug mailing list
> grlug at grlug.org
> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20140925/adcf2610/attachment.html>

From signals42 at gmail.com  Thu Sep 25 13:27:05 2014
From: signals42 at gmail.com (Kevin McCarthy)
Date: Thu, 25 Sep 2014 13:27:05 -0400
Subject: [GRLUG] CVE-2014-6271
In-Reply-To: <CAFoUb4SM4FW3WX3kv7LDRCQfKSZm5pF_s8YqZhLa5S5hM-jaGg@mail.gmail.com>
References: <CAFoUb4RUuyoHupqaXnR=LP8Sc1w0JTMHemiNH6nsg5rb9Xk+5w@mail.gmail.com>
 <CACrkP+ENFcYPZhnYovjVoyV2svhry41UmLZYn0Yt44+HcsBhaw@mail.gmail.com>
 <CACNU6M713X1nHpWVgyQ0mcAs0V2xs5sJtBuqqK-gAX_C35EqFA@mail.gmail.com>
 <1411647413.6473.1.camel@whitemice.org>
 <CA+czFiCVWqGNQV438vcc1=PsmZfO94zvxsSgbGCvSCTYtbQhUw@mail.gmail.com>
 <CACNU6M6JjH6odeXdNrjAB=VaDgNsGyE4p=UWVU9ycNvdGW91zg@mail.gmail.com>
 <CAFoUb4SM4FW3WX3kv7LDRCQfKSZm5pF_s8YqZhLa5S5hM-jaGg@mail.gmail.com>
Message-ID: <CAFoUb4QVvRxG_aO1j4hTG81rTXvbC5cFd5mWvkPJB53_BEvaUA@mail.gmail.com>

BTW, It looks like I'll be patching it again on the RHEL systems:

https://access.redhat.com/security/cve/CVE-2014-7169

The quick-fix from yesterday didn't completely deal with the issue, so you
should probably check with your vendors and see if you need to apply
another one today. Thank goodness for Satellite/Spacewalk.

-Kevin

On Thu, Sep 25, 2014 at 1:19 PM, Kevin McCarthy <signals42 at gmail.com> wrote:

> If an attacker has remote control of environment variables think of the
>> damage that can be done with LD_LIBRARY_PATH.
>>
>
> The issue here is that it can be expolited through ANY environment
> variable. So, the env variables that pass things to CGI are vulnerable. You
> can exploit it with a variable called X. TERM even works.
>
> This exploit seems to be about bash specifically, and specifically about
>> ways to set environment variables.  But really, I just don't want
>> set-an-environment-variable to ever happen.
>>
>
> I agree, I don't WANT it to happen either. But, what I want, and what
> actually happens within my organization are two completely different
> things. I've got several pieces of commercial off-the-shelf software
> running on multiple servers that make use of CGI scripts. I don't have the
> ability to tell my customers that they can't have that software anymore,
> and I don't have the resources (or legal right in many cases) to modify it
> to do something saner than CGI. Best practice != real environment.
>
> But, whatever... It's probably a big issue for most enterprises; the
> information is out there, so patch if you think it important enough... Or
> don't.
>
>
>
> On Thu, Sep 25, 2014 at 10:37 AM, Mark Farver <mfarver at mindbent.org>
> wrote:
>
>> If an attacker has remote control of environment variables think of the
>> damage that can be done with LD_LIBRARY_PATH.  Upload a file to a harmless
>> path on webserver and use the library path to link it into an executable
>> running in a CGI env.  Instant remote code execution.
>>
>> Many applications have buffer overflows in environment handling.  Remote
>> code execution or denial of service.
>>
>> Basically environment variables are not terribly secure and have not
>> received a lot of security analysis.  If you let an attacker control them
>> for a process running as another user there are probably vectors there.
>>
>> Mark
>> On Sep 25, 2014 8:55 AM, "Michael Mol" <mikemol at gmail.com> wrote:
>>
>>> On Thu, Sep 25, 2014 at 8:16 AM, Adam Tauno Williams
>>> <awilliam at whitemice.org> wrote:
>>> > On Wed, 2014-09-24 at 15:08 -0400, Mark Farver wrote:
>>> >> I think it is a stretch to label this remotely exploitable.
>>> >
>>> > Ditto.  This is a theoretical exploit of a system that has issues.
>>>
>>> I'd like to hear your explanation of this. Why would a system have to
>>> have "issues" for this to be exploitable? (Outside of the obvious that
>>> it's running a vulnerable version of bash.)
>>>
>>> --
>>> :wq
>>> _______________________________________________
>>> grlug mailing list
>>> grlug at grlug.org
>>> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>>>
>>
>> _______________________________________________
>> grlug mailing list
>> grlug at grlug.org
>> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20140925/75bfd077/attachment-0001.html>

From awilliam at whitemice.org  Thu Sep 25 13:56:08 2014
From: awilliam at whitemice.org (Adam Tauno Williams)
Date: Thu, 25 Sep 2014 13:56:08 -0400
Subject: [GRLUG] CVE-2014-6271
In-Reply-To: <CA+czFiB2YGTODHWw4Jic8KHypS05NTKEZfVc3Ts8a6K-nha7TA@mail.gmail.com>
References: <CAFoUb4RUuyoHupqaXnR=LP8Sc1w0JTMHemiNH6nsg5rb9Xk+5w@mail.gmail.com>
 <CACrkP+ENFcYPZhnYovjVoyV2svhry41UmLZYn0Yt44+HcsBhaw@mail.gmail.com>
 <CACNU6M713X1nHpWVgyQ0mcAs0V2xs5sJtBuqqK-gAX_C35EqFA@mail.gmail.com>
 <1411647413.6473.1.camel@whitemice.org>
 <CA+czFiCVWqGNQV438vcc1=PsmZfO94zvxsSgbGCvSCTYtbQhUw@mail.gmail.com>
 <CACNU6M6JjH6odeXdNrjAB=VaDgNsGyE4p=UWVU9ycNvdGW91zg@mail.gmail.com>
 <1411656275.6473.7.camel@whitemice.org>
 <CA+czFiAOnnia947ziSugFDP753E=r94pXA8GdcwMaC=7ReM77w@mail.gmail.com>
 <CA+czFiB2YGTODHWw4Jic8KHypS05NTKEZfVc3Ts8a6K-nha7TA@mail.gmail.com>
Message-ID: <1411667768.2234.1.camel@whitemice.org>

On Thu, 2014-09-25 at 13:05 -0400, Michael Mol wrote: 
> Oh, and from the same link:
> CUPS - It is believed that CUPS is affected by this issue. Various
> user supplied values are stored in environment variables when cups
> filters are executed.

Agree, that one is ugly.  

I'm not a fan of using environment variables for IPC - but CUPS does
exactly that.  I have seen the same kind of approach used for
sub-process kinds of stuff as well - this exploit certainly effects
those use cases.

-- 
Adam Tauno Williams <mailto:awilliam at whitemice.org> GPG D95ED383
Systems Administrator, Python Developer, LPI / NCLA


From lvl at omnitec.net  Mon Sep 29 17:48:02 2014
From: lvl at omnitec.net (L. V. Lammert)
Date: Mon, 29 Sep 2014 16:48:02 -0500 (CDT)
Subject: [GRLUG] Ncurses
Message-ID: <Pine.BSO.4.53.1409291642050.2558@Mail.omnitec.net>

Riddle - why would ncurses display correctly on one machine, but not
another?

	TERM 		xterm
	TERMINFO	<blank>
	encoding	utf-8
	Locale Settings
	  for user root	ctype only
	Detailed Locle
	  Settings	en_US

Accessing both via ssh from the same workstation.

Only difference between them - one is the Host, one is a VM. XFCE
installed and running on both:

/usr/bin/X :0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch

Suggestions?

	Thanks!

	Lee

From megadave at gmail.com  Tue Sep 30 00:27:52 2014
From: megadave at gmail.com (Dave Chiodo)
Date: Tue, 30 Sep 2014 00:27:52 -0400
Subject: [GRLUG] Ncurses
In-Reply-To: <Pine.BSO.4.53.1409291642050.2558@Mail.omnitec.net>
References: <Pine.BSO.4.53.1409291642050.2558@Mail.omnitec.net>
Message-ID: <CAFP7keuKv_bag8=5A4tuVOp05j_XiLGsjcst9LD0c-U1AP2=Fw@mail.gmail.com>

same version/flavor of curses installed on both systems?

same version/flavor of other libraries which curses depends on?

Anything different in the ".profile" ".login", ".bashrc", and other
shell/login scripts for the user accounts at each of the two machines which
might be related to terminal controls?

On Mon, Sep 29, 2014 at 5:48 PM, L. V. Lammert <lvl at omnitec.net> wrote:

> Riddle - why would ncurses display correctly on one machine, but not
> another?
>
>         TERM            xterm
>         TERMINFO        <blank>
>         encoding        utf-8
>         Locale Settings
>           for user root ctype only
>         Detailed Locle
>           Settings      en_US
>
> Accessing both via ssh from the same workstation.
>
> Only difference between them - one is the Host, one is a VM. XFCE
> installed and running on both:
>
> /usr/bin/X :0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
>
> Suggestions?
>
>         Thanks!
>
>         Lee
> _______________________________________________
> grlug mailing list
> grlug at grlug.org
> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20140930/e10ef340/attachment.html>