Re: [silug-discuss] [silug-discuss] Daily digest (9 messages) V1 #174

["Joe L." <nustar1@yahoo.com>]

--- silug-discuss-owner@silug.org wrote:

> [silug-discuss] Daily digest (9 messages)
> 
> This is Digest Volume 1 : Issue 174 : Digest Style "text"
> Below is a summary of all the messages, showing the subject of each
> post
> and who posted it, followed by the full text of all messages. 
> 200412/225: Re: Win2003 server/SMB -- key point:  works v. works as
> configured
>     "Bryan J. Smith" <b.j.smith@ieee.org>
>   200412/226: Re: Win2003 server/SMB -- 2003 changed the handshake
> (in violation
>     "Robert G. (Doc) Savage" <dsavage@peaknet.net>
>   200412/228: Re: Win2003 server/SMB -- a "meatball chart" was
> impossible for
>     "Bryan J. Smith" <b.j.smith@ieee.org>
>   200412/227: Re: Win2003 server/SMB -- 2003 changed the handshake
> (in violation
>     Robert Citek <rwcitek@alum.calberkeley.org>
>   200412/229: Re: Win2003 server/SMB -- that stupid BS won't shutup
> ;-)
>     "Bryan J. Smith" <b.j.smith@ieee.org>
>   200501/1  : Re: Win2003 server/SMB -- 2003 changed the handshake
> (in violation
>     Robert Citek <rwcitek@alum.calberkeley.org>
>   200501/2  : Re: Win2003 server/SMB -- SMB signing (different issue
> than
>     "Bryan J. Smith" <b.j.smith@ieee.org>
>   200412/230: Re: BitTorrent away (or not)!
>     bentley_rhodes <bentley.rhodes@gmail.com>
>   200501/3  : Re: BitTorrent away (or not)!
>     mike808@users.sourceforge.net
> 
>
----------------------------------------------------------------------
> 
> Date: Fri, 31 Dec 2004 08:50:31 -0800
> From: "Bryan J. Smith" <b.j.smith@ieee.org>
> To: silug-discuss@silug.org
> Subject: Re: Win2003 server/SMB -- key point:  works v. works as
> configured
> Message-ID:
> <1104511830.2688.287.camel@localhost.oviedo.smithconcepts.com>
> 
> On Fri, 2004-12-31 at 08:41, Bryan J. Smith wrote:
> > That's different.  There is a well documented change in how Windows
> > Server 2003 handles the SMB handshake in violation of its own,
> published
> > state diagram on the handshake.  In a nutshell, they now "skip a
> step." 
> > Windows clients silently error but continue.  Samba marks it as an
> > improper negotiation and a possible protocol/security issue.
> 
> This is the crux of my argument of Samba over native Windows SMB.
> 
> In many cases of Microsoft protocols, improper handshake and
> negotiation
> silently fails, ignores or otherwise negotiations/assumes another
> connection.  It's extremely difficult to find these issues when you
> use
> native Windows SMB servers.  Especially when a _lot_ of them are
> "false
> security"/"marketing" features that just don't work as advertised.
> 
> Microsoft has regularly been guilty of disabling encryption,
> signatures,
> password hashes, etc... when problems arise, but not failing.  In
> fact,
> they've even been guilty of silently disabling features for
> performance
> issues -- for benchmark purposes.  I've exposed a lot of these in
> various postings (SMB, Exchange, etc...).
> 
> Only when you either use a framegrabber like pcap (or front-end that
> use
> it like tcpdump or Ethereal) that you discover these details.  
> 
> This "default" is common outside of SMB as well.  E.g., MS IE _still_
> has an issue where it doesn't report that sub-frames aren't
> encrypted,
> when the entire site is supposed to be.  Mozilla/Netscape do.  Many
> companies that get calls from Mozilla/Netscape users who complain
> that
> they are getting a "low-grade" or "no encryption" warnings are
> dismissed
> with "we don't support Mozilla/Netscape."
> 
> It's not until someone like myself comes in and tells them "you are
> lacking encryption in one of the subframes on your site" that people
> stop and go, "ohhh...."
> 
> So don't confuse "it just works" with "it works as configured."  ;->
> 
> 
> -- 
> Bryan J. Smith                                    b.j.smith@ieee.org 
> -------------------------------------------------------------------- 
> Subtotal Cost of Ownership (SCO) for Windows being less than Linux
> Total Cost of Ownership (TCO) assumes experts for the former, costly
> retraining for the latter, omitted "software assurance" costs in 
> compatible desktop OS/apps for the former, no free/legacy reuse for
> latter, and no basic security, patch or downtime comparison at all.
> 
> 
> 
> 
> ------------------------------
> 
> Date: Fri, 31 Dec 2004 10:59:48 -0600
> From: "Robert G. (Doc) Savage" <dsavage@peaknet.net>
> To: silug-discuss@silug.org
> Subject: Re: Win2003 server/SMB -- 2003 changed the handshake (in
> violation
> Message-ID: <1104512388.2202.19.camel@lioness.protogeek.org>
> 
> On Fri, 2004-12-31 at 08:41 -0800, Bryan J. Smith wrote:
> > On Fri, 2004-12-31 at 08:15, Robert Citek wrote:
> > > From what I hear, all the Windows machines can connect to the
> Win2003 server 
> > > just fine.
> > 
> > Of course, with the default options.  All NT4+ clients are fairly
> good. 
> > 
> > It's the DOS7 (95/98/ME) and extended NT4 and NT5.0 (2000) options
> that
> > are problematic.  In a nutshell, Microsoft stopped bothering trying
> to
> > deal with all the "quirks" in each implementation.
> 
> Bryan,
> 
> Would it be possible for you to put together a "meatball chart" that
> shows version vs capability support for all this. I'm getting
> confused
> by all these details, but I think it's important that this
> information
> be made available in a compact, easy-to-follow format. You seem to
> know
> a lot more about this than most of the rest of us.
> 
> --Doc
> 
> 
> ------------------------------
> 
> Date: Fri, 31 Dec 2004 09:27:28 -0800
> From: "Bryan J. Smith" <b.j.smith@ieee.org>
> To: silug-discuss@silug.org
> Subject: Re: Win2003 server/SMB -- a "meatball chart" was impossible
> for
> Message-ID:
> <1104514048.2688.322.camel@localhost.oviedo.smithconcepts.com>
> 
> On Fri, 2004-12-31 at 08:59, Robert G. (Doc) Savage wrote:
> > Bryan,
> > Would it be possible for you to put together a "meatball chart"
> that
> > shows version vs capability support for all this.
> 
> Microsoft found it couldn't support all the variations.  That's why
> NT5.1 (XP/2003) is a "clean slate" feature implementation with only
> limited SMB feature support of prior versions.
> 
> The Samba team constantly finds more every day.  They are the only
> ones
> accommodating them.  This is a _massive_ effort, reverse engineering
> style.  It's not easy.
> 
> Yet you want me to put together a "meatball chart"?  ;->
> 
> > I'm getting confused by all these details,
> 
> Blame Microsoft, they are the ones that _lacked_ the control over
> their
> own protocol.  Most of it is due to the fact that the "Chicago" (DOS)
> team did what the hell they wanted, and the "Cairo" (NT) team ended
> up
> being unable to do anything new as they couldn't even keep up with
> what
> "Chicago" was up to with 1/10th the resources.
> 
> > but I think it's important that this information be made available
> in
> > a compact, easy-to-follow format.
> 
> Honestly, it would take me 5 years to dump the info.  And I would be
> "questioned" at every step of the way, just like I was here with the
> "FUD" comment.  I've been supporting every NT version since the NT
> 3.1
> _beta_.  Besides being their OS/2 expert at the time**, the reason is
> that I was working at the company with largest installed based of the
> very first native NT application, Bentley Systems Microstation, and
> had
> prototype Integraph PCs to play with.**
> 
> Right now I've got Microsoft's ear again.  Sure enough, it ain't
> doing
> any good.  In dealing with Microsoft over the years, I have
> consistently
> stated they need to "change their attitude" on how they develop
> software.  I've try to detail everything from SMB to how MAPI, ESMTP
> and
> other Exchange services work, to the lack of following the Win32
> security model in a majority of the DLLs that are in the clients
> (from
> MS IE, written for "Chicago" not NT).  I constantly get "brick wall"
> and
> other "FUD" arguments.
> 
> Which is why I consider "Longhorn" a joke.  Just as much as "Cario"
> was.  It doesn't matter how good the OS and core VS/library
> developers
> are, the application and RAD tool vendors keep using "Chicago" code. 
> which makes the whole Win32 and .NET--er, now "WinFX" APIs useless. 
> I've known numerous and _good_ people at Microsoft, and they _do_
> their
> best.  But the management is focused on what will sell or, worse yet,
> how they can use the distribution channel to force adoption, and not
> what is good for the OS and consumers.
> 
> BTW, the reason Microsoft has "re-engaged me" is over current and
> major
> security issues with Exchange 2003 -- stuff that hasn't been fixed
> since
> I found a lot of issues with with the Exchange 5.5 parser for its
> ESMTP
> service.  A new parser is due for Exchange 2005, but its release now
> been pushed back.  A new "pack" for Exchange 2003 is going to be
> released shortly, which means that Microsoft is really concerned with
> the massive number of buffer overflows in the current product.  Long
> story short, back in 1999/2000, when I first found the issues (18
> months
> before the first exploits, and 30 months before the first
> 0-day/administrative-privilege hack directly over network), I
> basically
> got laughed at and then threatened not to go to CERT (which I didn't
> out
> of fear).  My how times have changed.
> 
> No current shipping Microsoft OS or service has _ever_ been checked
> for
> buffer overflows _before_ release, only post-release and only in
> mid-2003+.  It took about 6 months after SQL Slammer for Microsoft to
> "get serious" about security (long story), but it has to do with the
> fact that they can't even manage patching their own systems
> internally. 
> E.g., they rely on Altaris and other 3rd parties to resolve
> inter-patch
> conflicts -- which was the #1 reason why SQL Slammer hit so hard --
> you
> were vunerable if you _were_ "current" (i.e., two latter patches
> uninstalled the fix from 4 months earlier that would have prevented
> SQL
> Slammer).
> 
> Some of the changes are good, as they are trying to address security.
> 
> In fact, XP SP2 is quite easy to understand.  The reason for
> incompatibility wasn't the new firewall and other security features,
> it's that Microsoft had to _reverse_ all the "hacks" it added to the
> NTkernel.EXE and network DLLs that by-pass the NT/Win32 security
> model
> for application compatibility.  These were added into NT5.1 from
> NT5.0,
> hence why pre-SP2 XP was more compatible with "Chicago" (DOS7 aka
> 95/98/ME) applications.
> 
> But a lot of the changes are because Microsoft has _no_ control over
> the
> previous and endless variants.  But when it would completely break
> something, they still haven't fixed the problem.  This includes
> details
> like the DLLs provided by Internet Explorer (which Microsoft
> previously
> required for _all_ new applications in order to "force" adoption of
> MS
> IE) written for "Chicago" that bypass NT/Win32 security, as well as
> the
> Outlook automation right down to how the Windows executive works.
> 
> The big one is how the Windows executive works and if they changed
> that,
> nothing would work.   ;->
> 
> > You seem to know a lot more about this than most of the rest of us.
> 
> That's because I lived it -- from the NT 3.1 beta on-ward.  I was an
> OS/2 and Solaris guy who also adopted NT and Linux in 1993.  I
> thought
> Linux was a cute project but nothing feasible and NT was going to be
> the
> future.  In 1994, when Gates move the reins from the NT to "Chicago"
> group, while saying "Cario" would solve everything with 1/10th the
> staff
> as "Chicago," I knew it was externally fsck'd versus even basic POSIX
> security in UNIX.  And that was at the same time Linux finally got
> its
> "killer app" in "A Patchy CERN httpd."
> 
> It was then I _knew_ Linux was the future.
> 
> Especially when Ray Noorda, the man who basically _made_ Novell, left
> Novell to start Caldera, after Novell dismissed Linux and bought
> UNIX(R)
> from USL.  Noorda knew what was coming.  Unfortunately, Novell
> wouldn't
> license what Noorda needed and the rest is history -- Novell was just
> 10
> years beyond Noorda.
> 
> BTW, Bill Gates deserves the title "Architect" -- because some of
> these
> decisions he made that have resulted in the non-sense were directly
> by
> him.
> 
> -- Bryan
> 
> **NOTE:  Talk about _stupid_ choices made directly by gates, unlike
> OS/2, NT can't boot into CMD.EXE without the GDI -- especially since
> the
> GDI is in the kernel NT4+.  Which is why when you can't get the GDI
> to
> boot, your own option to fix the registry and other files is to boot
> Linux.  Even the new NT5+ command console (would have _never_ been
> necessary had the GDI not be required) doesn't have _junk_.  The GDI
> is
> also why Citrix had to come up with the "MultiWin" hack (virtualized
> GDI) so WinFrame and, later, Terminal Services and MetaFrame were
> possible.
> 
> Not surprising this was based on Citrix's previous, proprietary
> integrations of MIT-licensed (i.e., leechable) X-Window code atop of
> OS/2, which doesn't need such a hack.  But in the end, I do have to
> admit that Citrix's ICA is pretty damn good improvement over even the
> latest X11 low-bandwidth implementations.
> 
> 
> -- 
> Bryan J. Smith                                    b.j.smith@ieee.org 
> -------------------------------------------------------------------- 
> Subtotal Cost of Ownership (SCO) for Windows being less than Linux
> Total Cost of Ownership (TCO) assumes experts for the former, costly
> retraining for the latter, omitted "software assurance" costs in 
> compatible desktop OS/apps for the former, no free/legacy reuse for
> latter, and no basic security, patch or downtime comparison at all.
> 
> 
> 
> 
> ------------------------------
> 
> Date: Fri, 31 Dec 2004 11:12:25 -0600
> From: Robert Citek <rwcitek@alum.calberkeley.org>
> To: silug-discuss@silug.org
> Subject: Re: Win2003 server/SMB -- 2003 changed the handshake (in
> violation
> Message-ID:
> <2418B08E-5B4F-11D9-BAEE-000A95880F88@alum.calberkeley.org>
> 
> 
> On Friday, Dec 31, 2004, at 10:41 US/Central, Bryan J. Smith wrote:
> > That's different.  There is a well documented change in how Windows
> > Server 2003 handles the SMB handshake in violation of its own, 
> > published
> > state diagram on the handshake.  In a nutshell, they now "skip a
> step."
> > Windows clients silently error but continue.  Samba marks it as an
> > improper negotiation and a possible protocol/security issue.
> >
> > I believe (?) Samba 2.2.8 or 2.2.9 fixed the problem.
> 
> Apparently so.  I tried connecting via smbclient on an FC1 machine 
> (samba-client-3.0.7-2.FC1) and it connects just fine.  Will working
> on 
> upgrading the other machines in a bit.
> 
> Thanks for the info Brian.  Owe you one next time you're in town.
> 
> Regards,
> - Robert
> http://www.cwelug.org/downloads
> Help others get OpenSource.  Distribute FLOSS for
> Windows, Linux, *BSD, and MacOS X with BitTorrent
> 
> 
> ------------------------------
> 
> Date: Fri, 31 Dec 2004 09:44:11 -0800
> From: "Bryan J. Smith" <b.j.smith@ieee.org>
> To: silug-discuss@silug.org
> Subject: Re: Win2003 server/SMB -- that stupid BS won't shutup ;-)
> Message-ID:
> <1104515051.2688.339.camel@localhost.oviedo.smithconcepts.com>
> 
> On Fri, 2004-12-31 at 09:12, Robert Citek wrote:
> > Apparently so.  I tried connecting via smbclient on an FC1 machine 
> > (samba-client-3.0.7-2.FC1) and it connects just fine.
> 
> All Samba 3.x version (sans maybe the original 3.0.0, maybe 3.0.1
> too?)
> should work.  Again, I think it was Samba 2.2.8 or 2.2.9 where it was
> fixed for the 2.2 series.  Remember, updates to Samba 2.2 continued
> concurrently with Samba 3.0's release until just very recently.
> 
> > Will working on upgrading the other machines in a bit.
> 
> Again, don't forget "Fedora Legacy," especially since Red Hat Linux 9
> (what I call CL3.1) is still being supported.  The Samba 2.2.12
> "Legacy"
> package updates are out there -- specifically so you can still use
> your
> existing smb.conf without change (unlike if you upgrade to Samba 3). 
> That's one thing I love about Debian, Fedora and a few, select
> projects
> -- they maintain very discrete release models, tagging, etc... and
> don't
> merely adopt the latest package.  There is a very sound reason why
> Red
> Hat switched the model before the actual name change to Fedora (that
> was
> just an additional consideration made later).**
> 
> > Thanks for the info Brian.  Owe you one next time you're in town.
> 
> No, you don't owe me at all.  We are _all_ here to help one another. 
> There is a reason I don't list my certs, resume, etc... in my
> signature,
> because we _all_ have an equal opportunity to help one another.  I am
> a
> firm believer that one _earns_ trust of one's knowledge over _time_,
> and
> I'm willing to take years in technically sound posts of knowledge to
> earn that trust.
> 
> All I ask is that people engage me on technical details, and don't
> merely dismiss my knowledge as FUD.  If you ask specific questions, I
> will answer.  I can't always think of all the details I should cover.
> 
> In fact, it's a catch-22 -- people regularly accuse me of being
> overly-verbose, and offering too much detail -- especially if a
> concept
> I cover is more "newbie" which only offends the more "veteran/
> experienced" reader (even if the answer wasn't directed towards
> them).
> 
> -- Bryan
> 
> **NOTE:  In a nutshell, it boils down to the fact that Red Hat got
> sick
> of supporting 6-7 revisions over only 2-3 years, because companies
> kept
> standardizing on ".0" or ".1" revisions.  By going to the
> Current-Legacy
> arrangement, Red Hat can support 2 "Current" reviusion as well as 2
> "Legacy" _versions_ (the last .2 or .3 revision) up to 5 years back. 
> Not surprisingly, the two current "Legacy" versions of ".2" or ".3"
> revision, are Red Hat Linux 7.3 and Fedora Core 1 -- which match
> updates
> for Red Hat Advanced Server / Enterprise Linux (RHAS/RHEL) 2.1 and
> Red
> Hat Enterprise Server (RHEL) 3, respectively.
> 
> Hence why I call Red Hat Linux 7.3 as "CL2.3" and Fedora Core 1 as
> "CL3.2".  It also explains why support for Red Hat Linux 8 (CL3.0)
> has
> been dropped from "Legacy," even though it is newer than Red Hat
> Linux
> 7.3.  And I hope Red Hat switches back to the revisioning with Fedora
> Core 5.0 -- because the next version, Fedora Core 5.1, will be the
> foundation for Red Hat Enterprise Linux 5.  Just like the current
> Fedora
> Core 3 (CL4.1) is the foundation for Red Hat Enterprise Linux 4.
> 
> Call "Fedora Legacy" something like "Red Hat Legacy" in your mind if
> you
> wish -- it's really all one big USPTO-effect change (the cause being
> due
> to Sun and other companies distributing modified Red Hat(R) Linux,
> and
> not so much because of Cheapbytes and others -- even Red Hat said
> Cheapbytes and mere "copy distributors" could use the trademark
> before
> the Fedora name change ;-).  Red Hat supports it, and the updates are
> even signed with their key (as are all "Official" Fedora
> repositories).
> 
> 
> -- 
> Bryan J. Smith                                    b.j.smith@ieee.org 
> -------------------------------------------------------------------- 
> Subtotal Cost of Ownership (SCO) for Windows being less than Linux
> Total Cost of Ownership (TCO) assumes experts for the former, costly
> retraining for the latter, omitted "software assurance" costs in 
> compatible desktop OS/apps for the former, no free/legacy reuse for
> latter, and no basic security, patch or downtime comparison at all.
> 
> 
> 
> 
> ------------------------------
> 
> Date: Sat, 1 Jan 2005 08:54:20 -0600
> From: Robert Citek <rwcitek@alum.calberkeley.org>
> To: silug-discuss@silug.org
> Subject: Re: Win2003 server/SMB -- 2003 changed the handshake (in
> violation
> Message-ID:
> <04537125-5C05-11D9-983B-000A95880F88@alum.calberkeley.org>
> 
> 
> On Friday, Dec 31, 2004, at 11:12 US/Central, Robert Citek wrote:
> > On Friday, Dec 31, 2004, at 10:41 US/Central, Bryan J. Smith wrote:
> >> I believe (?) Samba 2.2.8 or 2.2.9 fixed the problem.
> >
> > Apparently so.  I tried connecting via smbclient on an FC1 machine 
> > (samba-client-3.0.7-2.FC1) and it connects just fine.
> 
> Spoke a bit too soon.  While smbclient works just fine, smbmount does
> 
> not:
> 
> $ smbmount ...
> cli_negprot: SMB signing is mandatory and we have disabled it.
> 21137: protocol negotiation failed
> SMB connection failed
> 
> I've googled but haven't found any clear answers.  For example, some 
> sites suggest putting in 'client signing = yes' That didn't help.  
> Others suggested I use mount.cifs.  That didn't work either.  
> Apparently, the FC1 kernel I have does not support CIFS by default.  
> Unfortunately, I can't find a module to modprobe, either.
> 
> Still googling and reading.  Any pointers?
> 
> Regards,
> - Robert
> http://www.cwelug.org/downloads
> Help others get OpenSource.  Distribute FLOSS for
> Windows, Linux, *BSD, and MacOS X with BitTorrent
> 
> 
> ------------------------------
> 
> Date: Sat, 01 Jan 2005 10:00:29 -0800
> From: "Bryan J. Smith" <b.j.smith@ieee.org>
> To: silug-discuss@silug.org
> Subject: Re: Win2003 server/SMB -- SMB signing (different issue than
> Message-ID:
> <1104602429.2676.19.camel@localhost.oviedo.smithconcepts.com>
> 
> On Friday, Dec 31, 2004, at 11:12 US/Central, Robert Citek wrote:
> > Apparently so.  I tried connecting via smbclient on an FC1 machine 
> > (samba-client-3.0.7-2.FC1) and it connects just fine.
> 
> > On Sat, 2005-01-01 at 06:54, Robert Citek wrote:
> > Spoke a bit too soon.  While smbclient works just fine, smbmount
> does 
> > not:
> > $ smbmount ...
> > cli_negprot: SMB signing is mandatory and we have disabled it.
> 
> Now that's a different issue.  There is both the handshake change and
> then the SMB signing requirement.  SMB signing can be majorly
> _broken_
> in pre-NT5.1 (XP/2003) systems, even some elements in NT5.0 (2000).**
> 
> Remember, _only_ Linux offers the "smbfs" kernel VFS "hack" that
> allows
> it to use user-space "smbclient" to access SMB mounts.  If you are
> not
> running a "smbfs" kernel module that is compatible with the current
> userspace "smbclient," then you'll have issues like this.
> 
> In a nutshell, you probably need to rebuild your kernel with the
> newer
> kernel "smbfs" code from Samba 3.  And, again, this is a Linux-only
> hack, and not supported by any other UNIX.
> 
> Which is why Service for UNIX (SFU) is the best option for native
> Windows Servers that will serve UNIX/Linux clients in general.
> 
> Always provide the _native_ protocol the _client_ expects.  Because
> the
> server is just pushing out the data, but the client is running
> programs
> and doing RPCs and expects interfaces to be there.  Although Samba
> servers have UNIX/Linux extensions that solve most of these, native
> Windows servers do not.  Especially not Windows Server 2003.
> 
> > 21137: protocol negotiation failed
> > SMB connection failed
> > I've googled but haven't found any clear answers.  For example,
> some 
> > sites suggest putting in 'client signing = yes' That didn't help.  
> > Others suggested I use mount.cifs.  That didn't work either.  
> > Apparently, the FC1 kernel I have does not support CIFS by default.
>  
> > Unfortunately, I can't find a module to modprobe, either.
> 
> Have you updated your kernel for Fedora Core 1 to 2.4.22-1.2199?
> Or Red Hat Linux 9 to 2.4.20-37.9.legacy?
> 
> I'm not sure they will include the code.  I don't have a system in
> front
> of me to check.
> 
> > Still googling and reading.  Any pointers?
> 
> Yes, my first instinct is the kernel "smbfs" v. userspace "smbclient"
> difference.  It sounds like the former does not support the features
> of
> the latter.
> 
> Try updating _both_ your kernels _and_ your Samba versions on CL3.1
> (RHL9) and CL3.2 (FC1) to the _latest_ from FedoraLegacy.ORG.  It
> might
> be a good idea to get the kernel source and inspect the kernel
> "smbfs"
> module compatibility for Samba 2.2/3 with the SMB signing support.
> 
> Especially if you're going to have to rebuild anyway.
> 
> -- Bryan
> 
> **NOTE:
> One of the things that Microsoft _does_ is "auto-disable" this
> requirement on NT4 and DOS7 (95/98/ME).  I personally love how
> Microsoft
> silently disables security features for compatibility, without a bit
> of
> warning.  The Samba client, on the other hand, will notify you.
> 
> As I mentioned before, don't confuse "works" with "works as
> configured"
> -- or expect to be bitten and bitten hard by assumption.  Especially
> when you are configuring Windows servers with SMB signing and/or
> IPSec.
>  
> I was on a project where we were exchanging SMB signed and IPSec
> packets
> between a few platforms.  When the Windows Server stack got flustered
> with traffic, it would _silently_drop_both_ security features.  While
> other Windows systems cliently accepted the lack of security, our IBM
> AIX client did not, and barked when it no longer received IPSec
> packets.
> 
> Microsoft continually claimed it was an IBM issue.  And they will
> _never_ admit this is how, indeed, Windows Servers operate -- even
> through NT5.1 (XP/2003).
> 
> -- 
> Bryan J. Smith                                    b.j.smith@ieee.org 
> -------------------------------------------------------------------- 
> Subtotal Cost of Ownership (SCO) for Windows being less than Linux
> Total Cost of Ownership (TCO) assumes experts for the former, costly
> retraining for the latter, omitted "software assurance" costs in 
> compatible desktop OS/apps for the former, no free/legacy reuse for
> latter, and no basic security, patch or downtime comparison at all.
> 
> 
> 
> 
> ------------------------------
> 
> Date: Fri, 31 Dec 2004 13:53:52 -0600
> From: bentley_rhodes <bentley.rhodes@gmail.com>
> To: silug-discuss@silug.org
> Subject: Re: BitTorrent away (or not)!
> Message-ID: <41D5AE50.4060702@gmail.com>
> 
> It was asked if i were to do certain things would BT work. Well ... i
> 
> deleted everything out of my Router and i ended up with 1 seedling
> and 1 
> downloading, then 0 seedling and 2 downloading but even with 0
> seedlings 
> i had a 32 kb upload. i don't know but under Azureus the smiley faces
> 
> are green. So i'm leaving the command prompt window open to do its
> thing.
> 
> 
> ------------------------------
> 
> Date: Sat,  1 Jan 2005 14:38:00 -0600 (CST)
> From: mike808@users.sourceforge.net
> To: silug-discuss@silug.org
> Subject: Re: BitTorrent away (or not)!
> Message-ID: <1104611879.20133@uml.archlug.org>
> 
> > how do i open up tcp ports 6881:6889? ... i can download but i
> cannot upload.
> 
> The problem is that you are behind a NAT device. So when the peer
> asks for your IP address, you're giving them a non-routable 192.168
> or 10. address. So they can't reach you when they try to send you
> something.
> 
> You need to tell the remote peer and the tracker what your "real" IP
> address is.
> 
> There are options for the command line BT clients to do this, as well
> as to set it up within Azureus.
> 
> BTW, Azureus is a great BT client. It's written in Java, so it works
> fine in Linux. It also has a nifty PeerGuardian plugin to refuse to
> establish links to IP addresses you probably don't want to share with
> anyway. Those people are free to find content elsewhere. It's your
> machine and you can choose who you want to connect with over the
> Internet. :=)
> 
> mike/
> 
> ------------------------------
> 
> End of [silug-discuss] [silug-discuss] Daily digest (9 messages) V1
> #174
> **********
> 


-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.