Slashdot Mirror

... I've been a firewall jockey and the logs were fraught (new word of the day) with attempts to penetrate.

Particularly interesting were the pokes at RDP (standard port 3389).

I used RDP a lot back then but I went to the registry and changed the port to the last four digits of our firm's phone number as a mnemonic.

So,

mstsc /v:joemcnamara.trandoninc.com:8192

gets Joe to his desktop.

Another common attack point was FTP.

When I first started to buy SSD's for my school, I tried to do some research and quickly became confused about the differences between TLC, MLC, and SLC. I found various sites like this one that gave a good overview, but I didn't find very many that really analyzed the performance differences.

I settled on the Kingston V300 series of disks, an MLC unit that seemed to get decent reviews. It's been treating us well, but I always wonder whether the MLC was worth the extra money over the UV400, a slightly cheaper TLC variant.

Has anyone ever used both MLC and TLC drives and care to comment about whether the differences in performance justify the cost?

I had the problem. Resetting in CMD didn't work, but when I tried resetting in PowerShell, I was able to reconnect. http://www.speedguide.net/faq/...

That shouldn't be a problem. Simply turn off the wi-fi radios on the router, but leave DHCP and other services on (usually, there is no way to turn off those anyways), then setup your new wi-fi router as strictly an access point rather than a router. There is like a million tutorials out there. E.g.

http://www.speedguide.net/arti...

Tepples see subject-line above: Hosts != a "MITM" by any means, proof here -> http://www.speedguide.net/arti...

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\ServiceProvider]
"Class"=dword:00000008
"DnsPriority"=dword:00000006
"HostsPriority"=dword:00000005
"LocalPriority"=dword:00000007
"NetbtPriority"=dword:00000008
"Name"="TCP/IP"

( LOWER NUMBER = HIGHER PRIORITY )

HECK - they're even using MY NUMBERS, not the default 500/600/700 etc. MS gives you over @ speedguide.net, except I change mine SLIGHTLY favoring hosts cached into RAM vs. using the slower usermode dnscache service (which is FAULTY with large hosts due to POOR DESIGN by MS, & I've pointed it out to them, with other flaws regarding hosts (0 allowed in Win2k/XP/Server2003 but not in VISTA onwards after MS Patch Tuesday 12/09/2009))!

APK

P.S.=> Hope you learned something from that - it's only truth! apk

His comment was that 2.4 doesn't travel very far, and 5ghz doesn't go as far as 2.4. I challenged that by posting over a 150+ mile link. What did you miss here? .

I didn't miss anything. Its an established fact that 5Ghz has less range than 2.4Ghs. Range of 5Ghs is usually less than half the range of 2.4.

So what he said was true.

And what you said didn't matter, because if that extreme example were repeated with 2.4Ghz devices it would be even more successful than the 5Ghz devices. So it was a complete non sequitur. (The test was also run in an environment where nothing else existed on 5Ghz. Those days are long gone.

Linux isn't good?

Here in the Netherlands a large cable TV and Internet service provider called Ziggo is doing a pilot program with turning everybody's home cable modem into a public wireless access point. They plan on rolling this out to their entire service area. Of course the public traffic is kept completely separated from the cable modem owner's private Internet connection, and Ziggo say that it won't affect their connection speed. I don't know whether the public Internet access offered this way is actually free (I suspect not, you'll probably have to pay Ziggo). More information: http://www.speedguide.net/news/companies-to-provide-wireless-internet-access-by-4933.

I played with one of these back in the 90s that did the same thing. http://www.speedguide.net/reviews/webramp-700s-89

I wonder if any of these can take new firmware:

http://www.speedguide.net/broadband-list.php?cat=50

ALSO - Wouldn't using Tcp1323Opts = 0 & SynAttackProtect = 2 work to stop "silly window syndrome" & 'scaling/sliding windows' in TCP/IP per RFC1323 "High-Performance TCP/IP features" it implements?

Think about this, & comment please:

1.) This DOS/DDOS attack utilizes an API call with a 0 window size parameter -> setsockopt 0

----

2.) TCP "Silly Window Syndrome" and Changes To the Sliding Window System For Avoiding Small-Window Problems - which is what this attack sounds as if it is exploiting:

KEYWORD = SLIDING WINDOW SYSTEM (for TCP/IP) -> Tcp Scaling

http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow-4.htm [tcpipguide.com]

PERTINENT CONCEPT QUOTE -> "Key Concept: Modern TCP implementations incorporate a set of SWS avoidance algorithms. When receiving, devices are programmed not to advertise very small windows, waiting instead until there is enough room in the buffer for one of a reasonable size. Transmitters use Nagles algorithm to ensure that small segments are not generated when there are unacknowledged bytes outstanding."

Which, per the setsockopt 0 call & parameter?

Does sound a LOT like this problem is, via setsockopt 0 calls issued by an attacking malware to exploit this for DDOS/DOS attacks!

----

3.) SynAttackProtect, here -> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters STOPS TCP WINDOWS SCALING, per this MS article on it:

http://msdn.microsoft.com/en-us/library/aa302363.aspx [microsoft.com]

PERTINENT QUOTE -> "NOTE: The following socket options no longer work on any socket when you set the SynAttackProtect value to 2: Scalable windows"

-----

4.) Tcp1323Opts, here -> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters STOPS TCP WINDOWS SCALING - This also turns off the RFC 1323 "Hi-Performance TCP/IP" options like "Scalable Windows" (sliding Windows noted in "silly window syndrome") also, & though you may go slower, you would be safer on a Windows 2000 machine because of it no longer allowing the TcpWindowSize to be reset by this attack (that uses that to its advantage via setsockopt 0).

The ONLY thing I am not certain of, is does this disallow SMALLER windows being negotiated, such as the setsockopt 0 uses in this type of DOS/DDOS attack. This I need feedback on, thanks.

http://www.speedguide.net/read_articles.php?id=157

Tcp1323Opts is a necessary setting in order to enable Large TCP Window support as described in RFC 1323. Without this parameter, the TCP Window is limited to 64K.

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Tcp1323Opts="1" (DWORD, recommended setting is 1. The possible settings are 0 - Disable RFC 1323 options, 1 - Window scaling but no Timestamp options, 3 - Window scaling and Time stamp options.)

Like SynAttackProtect = 2? Tcp1323Opts = 0 "turns off" the ability to use "scalable windows" that RFC1323 allows, & which it appears that this setsockopt 0 command exploits, via the "Silly Window Syndrome"...

----

Thus, if you have a 'hardcoded' TcpWindowSize in the registry, & one set to a PRE-DEFINED value/size, & "sliding window sizes" for TCP are 'turned off' by SynAttackProtect = 2 and Tcp1323Opts = 0? The ability to use setsockopt 0 (which seems to exploit "scaling windows"/"sliding windows" per "Silly Window Syndrome", which this seems to exploit) should, in theory, be utterly nullified.

APK

P.S.=> I can't think of anything better than this but the evidence above tends to show that IF you use SynAttackProtect = 2 (which works vs. types of DOS/DDOS attacks, as is) and Tcp1323Opts

Wouldn't using Tcp1323Opts = 0 & SynAttackProtect = 2 work to stop "silly window syndrome" & 'scaling/sliding windows' in TCP/IP per RFC1323 "High-Performance TCP/IP features" it implements?

Think about this, & comment please:

1.) This DOS/DDOS attack utilizes an API call with a 0 window size parameter -> setsockopt 0

----

2.) TCP "Silly Window Syndrome" and Changes To the Sliding Window System For Avoiding Small-Window Problems - which is what this attack sounds as if it is exploiting:

KEYWORD = SLIDING WINDOW SYSTEM (for TCP/IP) -> Tcp Scaling

http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow-4.htm

PERTINENT CONCEPT QUOTE -> "Key Concept: Modern TCP implementations incorporate a set of SWS avoidance algorithms. When receiving, devices are programmed not to advertise very small windows, waiting instead until there is enough room in the buffer for one of a reasonable size. Transmitters use Nagles algorithm to ensure that small segments are not generated when there are unacknowledged bytes outstanding."

Which, per the setsockopt 0 call & parameter?

Does sound a LOT like this problem is, via setsockopt 0 calls issued by an attacking malware to exploit this for DDOS/DOS attacks!

----

3.) SynAttackProtect, here -> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters STOPS TCP WINDOWS SCALING, per this MS article on it:

http://msdn.microsoft.com/en-us/library/aa302363.aspx

PERTINENT QUOTE -> "NOTE: The following socket options no longer work on any socket when you set the SynAttackProtect value to 2: Scalable windows"

-----

4.) Tcp1323Opts, here -> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters STOPS TCP WINDOWS SCALING - This also turns off the RFC 1323 "Hi-Performance TCP/IP" options like "Scalable Windows" (sliding Windows noted in "silly window syndrome") also, & though you may go slower, you would be safer on a Windows 2000 machine because of it no longer allowing the TcpWindowSize to be reset by this attack (that uses that to its advantage via setsockopt 0).

http://www.speedguide.net/read_articles.php?id=157

Tcp1323Opts is a necessary setting in order to enable Large TCP Window support as described in RFC 1323. Without this parameter, the TCP Window is limited to 64K.

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Tcp1323Opts="1" (DWORD, recommended setting is 1. The possible settings are 0 - Disable RFC 1323 options, 1 - Window scaling but no Timestamp options, 3 - Window scaling and Time stamp options.)

Like SynAttackProtect = 2? Tcp1323Opts = 0 "turns off" the ability to use "scalable windows" that RFC1323 allows, & which it appears that this setsockopt 0 command exploits, via the "Silly Window Syndrome"...

----

Thus, if you have a 'hardcoded' TcpWindowSize in the registry, & one set to a PRE-DEFINED value/size, & "sliding window sizes" for TCP are 'turned off' by SynAttackProtect = 2 and Tcp1323Opts = 0? The ability to use setsockopt 0 (which seems to exploit "scaling windows"/"sliding windows" per "Silly Window Syndrome", which this seems to exploit) should, in theory, be utterly nullified.

APK

P.S.=> I can't think of anything better than this but the evidence above tends to show that IF you use SynAttackProtect = 2 (which works vs. types of DOS/DDOS attacks, as is) and Tcp1323Opts = 0 which STALLS "SLIDING WINDOW SIZES" (Tcp Scaling in other words), then, this attack (which seems like it is using the "Silly Window Syndrome" per the above) cannot work...

(As "setsockopt 0" cannot reset/renegotiate the TcpWindowSize & the sy

RFC1323 - TCP Extensions for High Performance: -> http://www.faqs.org/rfcs/rfc1323.html

Specifically, as regards "Window Scaling", & these pertinent quotes (& how Tcp123Opts = 0 shuts off ALL of these hi-performance TCP/IP options (slower, but sounds like a safety measure vs. this setsockopt 0 "silly windows syndrome" attack))

Please, read on:

"The window scale extension expands the definition of the TCP window to 32 bits and then uses a scale factor to carry this 32-bit value in the 16-bit Window field of the TCP header (SEG.WND in RFC-793). The scale factor is carried in a new TCP option, Window Scale. This option is sent only in a SYN segment (a segment with the SYN bit on), hence the window scale is fixed in each direction when a connection is opened

(Note that LAST bolded statement? THAT only "holds true", IF these RFC1323 options are 'turned on', first of all, & what turns them COMPLETELY off (@ the price of performance, perhaps, but not of safety vs. this "sliding windows scale/sliding windows/silly window syndrome" attack? Tcp1323Opts does))

http://www.speedguide.net/read_articles.php?id=157

Tcp1323Opts is a necessary setting in order to enable Large TCP Window support as described in RFC 1323. Without this parameter, the TCP Window is limited to 64K.

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Tcp1323Opts="1" (DWORD, recommended setting is 1. The possible settings are 0 - Disable RFC 1323 options, 1 - Window scaling but no Timestamp options, 3 - Window scaling and Time stamp options.)

Like SynAttackProtect = 2?

Tcp1323Opts = 0 "turns off" the ability to use "scalable windows" that RFC1323 allows, & which it appears that this setsockopt 0 command exploits, via the "Silly Window Syndrome"...

So, by setting them properly against this attack, by altering them, here -> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters accordingly.

http://msdn.microsoft.com/en-us/library/aa302363.aspx

PERTINENT QUOTE -> "NOTE: The following socket options no longer work on any socket when you set the SynAttackProtect value to 2: Scalable windows"

You can nullify this attack it seems, because SynAttackProtect = 2 AND Tcp1323Opts = 0 (& using a set TcpWindowSize also) can stall out "sliding/scaling TCP Window Sizes", which this attack seems to exploit a vulnerability of via setsockopt 0 calls...!

APK

P.S.=> See my point now? Using Tcp1323Opts = 0, SynAttackProtect =2, & setting a TcpWindowSize to 64k (or whatever)? This setsockopt 0 type DOS/DDOS attack may be nullified it appears, because "sliding windows/tcp scaling" doesn't even take effect anymore, & this "setsockopt 0" seems to exploit it, via the "silly window syndrome" here -> http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow-4.htm

PERTINENT CONCEPT QUOTE -> "Key Concept: Modern TCP implementations incorporate a set of SWS avoidance algorithms. When receiving, devices are programmed not to advertise very small windows, waiting instead until there is enough room in the buffer for one of a reasonable size. Transmitters use Nagles algorithm to ensure that small segments are not generated when there are unacknowledged bytes outstanding."

Which, per the setsockopt 0 call & parameter?

Does sound a LOT like this problem is, via setsockopt 0 calls issued by an attacking malware to exploit this for DDOS/DOS attacks!

Hope you see my point... &, again, I'd like your "Feedback/Thoughts" on this as well - Thanks for your time, because I am trying to figure out a way, hopefully, to stall this attack on Windows 2000 rigs (I h

First and foremost: remember, we're talking about Windows 2000 and Windows XP below.

CVE-2008-4609 documents a problem with TCP stacks where established connections (meaning the initial SYN, SYN+ACK, ACK have already been experienced) can renegotiate their TCP receive window size to a small value (no idea what "small" means) or zero, the result being the number of available sockets on the machine becomes exhausted over time. Since TCP window sizes are negotiated, but not necessarily respected, there's really nothing one can do about this other than fix the stack, or allow added tuning for this. You can force window sizes (like you mention in your post), but that does not guarantee the remote end will honour them. This is Normal(tm).

CVE-2009-1925 documents a much more serious problem with the Windows TCP stack: "a remote code execution vulnerability exists in the Windows TCP/IP stack due to the TCP/IP stack not cleaning up state information correctly. This causes the TCP/IP stack to reference a field as a function pointer when it actually contains other information." There's nothing one can do about this one other than fix the TCP stack. End of discussion.

CVE-2009-1926 documents a problem with the Windows TCP stack where an already established TCP connection, with an agreed upon small (again, no idea what "small" is) or zero-sized TCP receive window, is closed with data still pending on the socket (likely shown as SendQ). When this scenario occurs, the Windows TCP stack never removes this entry from the state table. There's no indication or documentation from Microsoft as to whether or not this applies to sockets which have a) already gone through the FIN, ACK, FIN+ACK, FIN+ACK handshake, or b) is stuck in a "half-open" state where either the teardown handshake is severed/botched in mid-stream, c) is stuck in a "half-open" state elsewhere before socket teardown, or d) is stuck in a "half-open" state during RST.

I think you're focusing on CVE-2009-1926, since you have excessive focus on "half-open" connections, but then simultaneously you switch to focusing on SYN.

> TcpMaxHalfOpen
> TcpMaxHalfOpenRetried
>
> Also have to be considered as well (these determine how long before SynAttackProtect "kicks in", vs. the DOS/DDOS attack that could occur)

"Half-open" can refer to one of two things, depending on who you talk to: where from a source, SYN has been sent but has not received a SYN+ACK back (Windows calls this state SYN_RECEIVE, *IX calls this SYN_RECV) -- or -- a socket that has already been established but during tear-down never completes the full 4-way handshake (see above).

> P.S.=> Also, "hardcoding" the TcpWindowSize & GlobalTcpWindowSize settings in the registry in TCP/IP Parameters (see registry path above)
> SHOULD also help here also, for servers that can accept MANY connections from MANY clients, worldwide, as your specific constraints specify...

Please do not follow this advice. It has been stated by Microsoft in numerous KB articles that people should not use GlobalTcpWindowSize. The registry entry in question has been deprecated with the introduction of Windows 2000 and beyond; you should be using this.

Secondly, increasing/forcing/making static the TCP window size permitted does not "harden" the stack at all, or provide any direct effect on security. Instead, stop that and enable RFC1323 instead. There are numerous sites that describe this process. On servers in this day and age, RFC1323 is more or less mandatory, ideally if you're serving large content (greater than 64KB). Here's some links that describe RFC1323 in Windows:

http://searchnetworking.techtarget.com.au/tips/27055-How-to-use-TCP-RFC-1323-to-improve-Windows-XP-s-network-performance
h

Increase the number of connections in Windows XP post SP2.

But it's fairly trivial to remove the limit. Surely anybody tech-savvy enough to run a server could work this out?

All those updates were generally through Microsoft Update. Except maybe a fluke here&there, none of those updates themselves really broke anything in the upgrade process itself. That's because these are all the same "lineage".

In that case several linux distributions have Windows beat hands down. I have little experience with Ubuntu but in SuSE, Fedora, RHEL, and CentOS not only do you easily get updates for the lineage of OS your running but the updates for virtually all of the installed applications. Whether its a desktop application like firefox, gimp, blender, rythmbox, etc. or its a server application like mysql, postgresql, apache, openssl, etc. all that is required is a few clicks through the desktop menus and entering the root password or on a server a command line yum update. After you finish with your Windows updates you still have to worry about all the other applications your running on your Windows OS as well as malware, spyware, virus scanning software and their databases.

I will not tolerate random breakages.

In that case I would suggest avoiding the distributions that are on the edge, i.e. Fedora, and opt for something more stable and tested like CentOS or RHEL.

You know, funny thing is, although I'm not a big Windows user myself I have assisted with at least one debacle cause by one of the Microsoft patches you listed. I assisted in resolving the sudden death of a Windows cluster that was configured to perform processor intensive modeling for libraries used to measure profiles on a broadband spectrophotometry measurement tool. It turned out that the installation of SP2 on the cluster made it impossible to do its job because the central machine storing the data to be processed could no longer accept the connections needed to support the clusters running the modeling. I'm not sure which is more absurd, the breakage caused by the Microsoft patch or the fact that the only work arounds were to either remove the SP2 patch or hack a Windows OS system file with a hex editor. Heh, and people pay for that crap.

There's no fallacy in there. Even if it was under warranty when my cable modem failed I could have had it replaced as quickly as I did, nor would I have gotten a faster one as a replacement.

If you buy a new modem off the shelf, based on your own research and subject to your own maintenance, it's unlikely it would just flame out after a year.

And you don't think a cable company modem wouldn't last a year?

you can really tune the performance and get measurable speed increases 24/7.

You can tune performance using company owned modems as well. At the tyme the modem I had failed, when the tech replaced it he offered to do a tuneup but I said I'd do it myself. Speedguide.net can help as can others.

Falcon

Conventionally, clock rates, bitrates, bandwidths, and other networking and data rates are understood to use decimal prefixes (i.e., 1 kb/s = 1000 b/s), RAM is understood to use binary prefixes (i.e., 1 MB/MiB = 1024 kB/KB/KiB), and storage devices use both in different places (the OS or the packaging).

Random sources that back this up:
http://www.speedguide.net/read_articles.php?id=115
http://www.pcguide.com/intro/fun/bindec-c.html
http://www.cknow.com/refs/BitsBytesandMultipleBytes.html
http://en.wikipedia.org/wiki/Bit_rate#Prefixes
http://en.wikipedia.org/wiki/Binary_prefix#Usage_notes

Its common knowledge that Windows has an inefficient TCP stack as far as higher speed broadband connections go.

Unblocka and TCP Optimizer are two apps commonly mentioned on the Australian Whirlpool forums.

I decided to use OpenDNS to get around the Verizon DNS redirects (they even redirected my own domain!). The redirects were very poorly implemented, often times just replacing image sources, other times redirecting entire domains, never consistantly, I found it difficult to do normal web browsing in many cases.

To make matter worse, I decided to set the DNS in my ActionTec router they provided (despite the fact I specifically asked for a dumb bridge ahead of time) to OpenDNS, turns out the ActionTec's are rigged to use ISP DNS anyways, and it's not just the 704s, they sabotage their own equipment!

Since I wanted a dumb bridge and to manage everything with my Linksys to begin with, I ordered an ancient Westel off of eBay. Since doing that and setting everything in my Linksys router everything is smooth. I would have ditched Verizon a long time ago if there wasn't a regional monopoly where I live. Cable wasn't even an option when I moved in, it might be now, but if it is, it's Comcast who isn't any more reputable.

It's starting to look to me like QoS from Comcast is luck of the draw.

They don't really give a shit at all.

Agreed. I own an RCA DCW615 cable modem, and have run into the issue where I can no longer control it[1], because Comcast has sent some specific data down the wire to change its function from "Residential Gateway" mode to "Cable Modem" mode. I don't know a whole lot about this, but you can see from this post that several others have run into the issue.

I called them last week to ask about this. The fucking lady hung up on me halfway through the conversation. (No, I didn't get her employee number... Always get the person's full name, employee number, and supervisor when you begin a conversation.)

I haven't called back yet; I tried calling RCA, but they told me they no longer handle this, I need to call Thompson. I will, one of these days when I have free time during working hours...

[1]: When I saw "can no longer control it" I mean: 1. I cannot log in to it any more (always comes back with the login dialog, and if I hit Esc it gives me an error message). 2. Even trying the factory reset, it doesn't, and I still can't log in.

Well, if what you're saying is true, it runs contrary to what I've read in the past, and every bit of info that I just found via a quick Google search on the matter. Also, you'll find that many high end LCDs for graphics work are S-IPS, or some variant there of, such as the LaCie 319.

Do you have any sources to back up your claims? If not, I'm afraid I'll have to stick with my original statement.

I have machine envy now.

I know you don't have a large investment in making Windows behave better, but I wonder if you could create a RAM disk in Windows and put your pagefile there, thereby eliminating the actual slowdown due to paging.

Something like:
* RAMDISK: http://www.speedguide.net/read_articles.php?id=131 or http://www.codeguru.com/cpp/w-p/system/devicedrive rdevelopment/article.php/c5789/
* Plus Moving Pagefile instructions: http://support.microsoft.com/kb/307886/ and if you print often move the spool too: http://support.microsoft.com/kb/308666/

If you weren't going to use the default desktop manager in Solaris (and I'm not) what would you use?

having done work on cable and sattelite systems as part of my profession, I've learned quite a bit.

1. Cable companies' signal sucks because of all the splitters. Many technicians will come up and put in 2way after 2way after 2way, and put the digital boxes on the last ones... WTF are they thinking? the proper way is to do a 2 way (one to your cable modem, rest for TV), an amp for the TV signals, and then all the TVs off of one big splitter. I've found this to be the best way for most houses since the cable companies don't amp the signals the way they should. If you're lucky enough though, you can get away with just one big splitter if the original signal into your house is strong enough.

2. on modems you can check your signal, go to 192.168.100.1 and you can see all of the diagnostic stuff. see http://www.speedguide.net/read_articles.php?id=119 7 for more information on what a nominal signal level is.

3. tcniso.net offers an interesting deal (the "company" itself is cheezy, but the end product is nice) it's rather illegal, but I err, know a guy who knows a guy, that uses it and he doesn't have any port limitations and gets 9mbps down and 1mbps up, hosts some websites, and has yet to be shutdown, filtered, or anything!

4. Dish sattelite trumps all other services for picture quality and quantity of HD channels

5. Most security systems have a hard time working with VoIP systems do to the way the compression works, and most companies will not support someone who wants to use their security system with VoIP due the the lack of reliability.

6. I should really stop reading/posting to slashdot right now because I'm going to be late for school... :/

7. check out avsforum.com and search for your cable service thread, there's usually TONS of great information and tips about how to improve your signal, any upcoming issues that the cable co's don't want you to really know about, etc.

http://www.speedguide.net/read_articles.php?id=108

Those modems never materialized.

...but it's why I'm still on SP1 myself. Everything I have on my machine (including some graphics-intensive Win95/98 era stuff) runs beautifully. Many, many of the things I use often (like the old UnrealEd for Unreal1, UT99, and Deus Ex) refuse to work on any of the computers my friends have. On the other hand, Freespace always seems to work, but admittedly, that's due to a weird thing with the way-too-damn-many fonts installed on my machine. Also, doesn't SP2 refuse to allow more than 10 outgoing connection attempts at a time? I know Azureus mentions such in the settings.

Also, more seriously, XP SP2 broke the ability of my parents' virus scanner to keep an active monitor running. Which in turn quickly led to the near-total destruction of the computer before I came home for the holidays last year and fixed it (it arose again like a Phoenix, though key things in Windows are still missing . . . nothing important, actually, mainly stuff that was annoying and unable to be removed with any ease before, so in a way that's kindof a plus!)

Alot more stuff is broken, I just don't recall quite what. Hmm, maybe a quick google search will clarify:

Microsoft's own list of broken apps
Also,
SP2 removes the ability of users to send raw TCP segments
It also breaks Captive-NTFS
It can break the Group Policy Object Editor
And as mentioned above, it limits TCP to 10 outgoing attempts (link also includes methods of disabling this; more detailed information on the issue can be found here.
Here's a forum in which people describe a few of the more technical problems and their solutions for SP2

I could go on, but you get the idea. There are some serious drawbacks to SP2. I could go on about how the supposed security features don't exactly impress me (and honestly, all the third-party security programs on my computer have never had to do much, since I run it very securely anyways, and they could handle it even if I didn't), but again, you can probably elaborate on your own.

My point, really, is just that parent is being truthful! Hell, it doesn't even matter if you argue that SP2 doesn't break anything worth fretting about, the perception, with enough evidence to hold sway, still exists, so it's still a huge reason for lack of adoption. Maybe parent is flamebait as well, but sometimes truth == flamebait!

As far as the Windows registry settings?

Start right here @ "the horses mouth" for Windows NT-based Os':

http://support.microsoft.com/default.aspx?scid=kb; EN-US;q120642

(That's a starting point for BOTH Tcp & NetBT & that tends to be "NT/2000 centric" but, most of it applies to Windows XP/Server 2003 as well!)

Here are more, & the very ones I used to define & understand the .reg files entries on that site:

Microsoft Windows Server 2003 TCP/IP Implementation Details MAIN PAGE:

http://www.microsoft.com/technet/prodtechnol/windo wsserver2003/technologies/networking/tcpip03.mspx

Microsoft Windows Server 2003 TCP/IP Implementation Details Parameters:

http://www.microsoft.com/technet/prodtechnol/windo wsserver2003/technologies/networking/tcpip03.mspx# ECAA

SECURITY CONSIDERATIONS FOR NETWORK ATTACKS:

http://www.microsoft.com/technet/archive/security/ prodtech/windows/iis/dosrv.mspx

TCP Transport Entries (all esoteric/unusual settings found here):

http://support.microsoft.com/kb/q102973/

TCP/IP Exploits and Countermeasures for Windows 2000 Server:

http://www.microsoft.com/technet/security/guidance /secmod150.mspx

Network Hardening and Security - Packet filtering Udp/Tcp - PortsAllowed + EnableSecurityFilters:

http://www.microsoft.com/technet/security/guidance /legsgch3.mspx

Prevent Session Hijacking

http://www.microsoft.com/technet/technetmag/issues /2005/01/sessionhijacking/default.aspx

ADDITIONAL REGISTRY SETTINGS - FOR AFD SETTINGS (ESPECIALLY):

http://www.microsoft.com/technet/security/guidance /secmod57.mspx

FOR TUNING PARAMETERS FOR SPEED FOR CABLEMODEM/DSL vs. 57.6k/33.6k/28.8k/14.4k DIALUP MODEMS:

http://www.speedguide.net/

* ENJOY! Those will define the settings altered/hardened & also explain EACH in detail as needed for your reference.

APK

P.S.=> What's in my initial URL is years of research since the NT 4.x-2000 days, & still works/applies to XP/Server 2003, & has had any added info. possible for them as well as the older NT-based OS' also... apk

This is a good site to check your relative security: http://www.speedguide.net/scan.php They also have a speed test if you are curious what your actual download speeds are. Try it several times to get an average. The time of day definitely makes a difference!

Windws XP SP2 introduces a few new twists to TCP/IP in order to babysit users and "reduce the threat" of worms spreading fast without control. In one such attempt, the devs seem to have limited the number of possible TCP connection attempts per second to 10 (from unlimited in SP1). This argumentative feature can possibly affect server and P2P programs that need to open many outbound connections at the same time.

Another option, for the more adventurous is to modify your tcpip.sys file manually, using a hex editor. The following instructions refer to the final release of XP SP2, with a tcpip.sys file of exactly 359,040 bytes, CRC-32 is 8042A9FB, and MD5 is 9F4B36614A0FC234525BA224957DE55C. Even thouh there might be multiple tcpip.sys files in your system, make sure to work with the one in c:\windows\system32\drives\ directory.

To remove the tcpip.sys socket creation limit:
- Backup your original tcpip.sys file before editing please, this is somewhat important !
- In your hex editor, go to offset 4F322 hex (or 324386 decimal).
- Change 0a 00 00 00 to 00 00 0a 00

All done !

When are we going to see decent upstream at the home? 128kbps doesn't cut it. I rarely see any offering at all over 256kbps upstream. OOL offers 1024 but as soon as you begin actually USING it they cap you back to 150 to keep the network from congesting to death.

But Joe McSixpack doesn't care about that, he just wants to grab porn faster and maybe let his kids get on aol and watch some crappy realvideo trash without whining. The ISPs are so paranoid about people running servers on their networks and losing their ability to charge 5000% markup for the same connection for "business" users even though they still block ports like 80 and 25. Woe betide the industry if people realised that 1.5mbps T-1 they've been paying hundreds or thousands a month for since the early 90s is now SLOW.

It's gotten to the point where I've pretty much given up hope of ever seeing a real broadband connection in my lifetime. By the time I can afford something with decent upstream, the idiots in washington will have ISPs so paranoid that everyone will be mandatorily placed behind a NAT and their servers will continually portscan you looking for servers and p2p apps.

ummm.....

8 bits = 1 byte

or...

1 bit = .125 bytes

either way you look at it, 92 bits DOES NOT EQUAL 19 bytes.

Try this on for size: http://www.speedguide.net/conversion.php

Informative my ass.

hmm, The computer that I was using there last year was configured for broadband with all realivent tweaks from speedguide.net some of which may have messed with the MTU, but maybe in the other direction
I remember I couldn't even ping the router, so i don't know how AOL got through but tiny pings wouldn't. That network was pretty messed up to begin with. Also it was kinda funny when I did a little test, how less than 15 seconds after I share a folder without a password I got a .eml file with nimda in each sub-dir of the folder. I'm not saying setting my MTU lower wouldn't do anything, but I know the kids using AOL could load web pages and I couldn't even ping the router
Ok, maybe all i've established is that AOL's default browser is better configured than M$'s.

Ok after sniffing around IRC (including the said hackers channel) and various boards this secret "underground" program the securityfocus guy quotes doesn't exist , its vapourware.

what does exist is a kludge of tftp servers,query utils and glorified DOCSIS editors that with 20minutes and a *lot* of messing about you can change your config settings and then only until the ISP check your modem (automated) via SNMP , deny this and your cut off, accept it and it will detect your hacked config and cut you off...permanently
so you are screwed either way.

not to mention that most of the cable modem companies are using MD5 hashes to validate the config files integrity (MIC (Message Integrity Check)), other than a severe hardware hack your not going to crack much with this verification.

i came accross tco-iso's website quite a while ago and after a few visits over the months it seemed to of ground to a halt when they realised that MD5 was involved, they even mentioned the possibility of brute forcing the hash which raised a smile from a few of us.

They point to their IRC channel for files but the *only* files that exist are just mirrors of the files their site links to, no "onestep" or 30mb files and certainly nothing special in the files (other than someone knows how to use a hexeditor on PD software)

some people dont understand how uncapping really works but i think speedguide's article seems to sum it up nicely.

Have you applied all of these tweaks or these and maybe these? I had similar problems with my cable modem. I was getting about 1.8 Mbps with my Win2K machine and 4.5 Mbps with my Linux boxes. Adding the appropriate registry tweaks gave me about equivalent performance with the W2K machine. Note that not all of these tweaks are good for all types of network access, so depending on your usage patterns, your mileage may vary.

Have you applied all of these tweaks or these and maybe these? I had similar problems with my cable modem. I was getting about 1.8 Mbps with my Win2K machine and 4.5 Mbps with my Linux boxes. Adding the appropriate registry tweaks gave me about equivalent performance with the W2K machine. Note that not all of these tweaks are good for all types of network access, so depending on your usage patterns, your mileage may vary.

Have you applied all of these tweaks or these and maybe these? I had similar problems with my cable modem. I was getting about 1.8 Mbps with my Win2K machine and 4.5 Mbps with my Linux boxes. Adding the appropriate registry tweaks gave me about equivalent performance with the W2K machine. Note that not all of these tweaks are good for all types of network access, so depending on your usage patterns, your mileage may vary.

Actually, ever since I installed the registry speed tweaks, I had been getting over 500k/sec on occasion to my FTP at college. no more... :(

The tweaking is easy stuff and it is worth 15 minutes of work. Don't let the man keep you down with false bandwidth caps! =D

For information and reviews of some of these items, try SpeedGuide.net or Practically Networked.

Just Call me Mr. Been There, done that...

Actually, some of the 'cable modem booster' registry tweaks do make a difference... at least they did under Windows 98SE on my box. I did the tweaks listed at speedguide.net in their Cable and DSL Tweaks section and was able to get a 30% increase in throughput. (based on actual tests) Most noticable at 3am... but hey, I'm on then alot.

As an ex-@home (att) employee, I can tell you that the blocking of ports is, for the most part, a myth. I only dealt with AT&T@Home, so I don't know about the other cable providers, but I can personally attest that no att customer has *any* blocked ports. If there is a service blocking ports, it's becuase the cable company themselves blocked those ports. Excite@Home has nothing to do with how the MSO's configure their hardware.

On the issue of security, it's almost funny to hear people talk about how dangerous it is to leave your computer on if you have cable or dsl.
SpeedGuide.net has a good article abnout cable/dsl security.

To sum up the security issue; there is no discernable difference between the security of a cable modem and the security of a 56k, aside from the VLAN (virtual local area network) setup of a cable modem.

Want to protect yourself? Disable file and print sharing, don't accept files from people you don't know, scan for viruses every so often, and avoid emails with a subject line of "I Love You". It really is that simple, believe it or not.