An Internet Service Provider (ISP) isn't involved in a point-point. It's just a service provider at that point. Multiple links from the telco for redundancy is silly as the vast majority of problems will take down both links (cut fiber, local CO issues, etc). If you're talking mixing Telco, Satellite and Cable for redundancy as someone else mentioned, then I'd guess you are are talking about an ISP and running VPN then? In that case there are options such as mlppp, etc.
Completely impossible if you use a One time Pad. If you use a secret key, and the display updates the code every 10 seconds, it is feasible that it would require the cracker to wait for several years or decades worth of data from the display in order to figure out what the secret key is.
you might be able to glitch the secure chip by playing with temperature, voltage, or cutting into the chip and injecting current to the IC itself while it is still running.
If you look at http://www.linuxsecurity.com/content/view/124176/2/, they simply sped the clock up and recorded all the possible outputs. In theory you could take a SecurID token, modify the clock long enough to spit out all the values and "wrap" around to the current time again.
Well that explains why your comment makes no sense. The system was showing a correct dosage, but was delivering something different since they had been dorking with the protocol definitions. In the Therac-25 case, the error was due to the operators using the program in an undocumented manner and the system incorrectly calculating the required exposures as a result. Also the operator doesn't arbitrarily set a level. He picks a specific protocol from a menu which already has the scanning pattern, timing, and power levels. Don't forget that dosage is power x time, so a low power level run for too long is also a problem.
If you didn't bother reading TFA, please don't bother posting. Whatever twit modded you insightful should be banned as well.
Exactly. You not might be able to prevent the first error that overdoses a patient, but you will have an independant measure of the actual dosage and you won't keep overdosing people on that particular protocol for the next 18-months.
If you really had a DOD background investigation done in the last few years, then I'm pretty sure you got fingerprinted. The few agencies that do the background checks absolutely require them. What's your name, soc number and home mailing address? I'll pull up your file and see if they're present.
I pity the person with the job of building a LiveCD that supports all permutations of hardware. Hardware compatibility is still not perfect with Linux.
It is mathematically impossible to find out what the secret key/OTP is on these devices from readouts on the display.
Not impossible, just not feasible.
in order to break into an account protected by a keyfob, one absolutely HAS to steal the actual keyfob.
Not true. It's still not secure if you're using a compromised computer. It just means the person who compromised your computer has to block your logon attempt (perhaps with a bogus system is offline message) and quickly logon themselves within the short window before the token updates. The hijack could even be scripted such that when the user attempts to logon, it waits until it suceeds, throws the user a system-offline message, and then proceeds to do a money transfer. Certainly not outside the realm of possible.
Its a device with a 1 time pad in rom (or similar). The 1 time pad could be easily read off of rom if you crack it open.
Not if they are done right. In a secure chip design, the rom and processing is all on one chip, and the rom can not be read back out once written. The cpu on the same chip is the only thing that can read the key, and the only thing it does is generate the numbers for the display. This is a similar concept to the smartcard or CAC cards employed by the DOD. The digital signing happens on the card and the private keys can not be retrieved once put on the card.
Why would you want a 1gig video card in what's essentially a monitor-less netbook? You certainly don't need it for the video storage, and it's not like this has enough horsepower to run an video intensive games. Seem like it would just drive the cost up needlessly.
It's already happened. Typically it was a result of incomplete reverse engineering of the protocol. The problem with reverse engineering from scratch is that the developers may have missed some little used and undocumented part of the protocol. A patch on the MS side of the house may have zero effect on the MS clients and servers as they still understand the protocol, but Samba may not. Often it's because Microsoft didn't strictly follow an established standard such as an RFC.
The perfect example is Samba not implementing NTLMv2 because forcing the authentication back to NTLM worked fine until NTLMv1 gets disabled per the security guideline that MS/NSA put out. Naturally people don't blame Microsoft when this happens, they blame Samba because it gets viewed as not really 100% compatible and in a constant state of trying to catch up.
What I find noteworthy here is that while MS isn't helping them rewrite Samba, they are providing additional documentation and debugging support.
Sorry no MCSE monkey here. I'm actually Redhat and Cisco certified with a crapload of enterprise experience and I feel perfectly comfortable within a shell and vi thank you. Of course a significant portion of the rest of the system admins out there are more comfortable with a nice easy to understand gui. Something the Linux community (and you by the sarcastic tone of your response) still fail to understand. Simplicity and idiot-proof is essential for market penetration. The moment you force a mid-level system admin into manually editing files and googling for instructions on tweaking ldap.conf you've failed in the mission to make it simple.
You can certainly authenticate against AD using Samba via Kerberos. Since Kerberos is an authentication protocol, just how do you do "password management" (okay, I'm being picky)? My point is that the end user shouldn't have to know the ins and outs of LDAP or be forced to google for a walkthrough. It should be simple and self-explanatory to setup, which it currently is not. It's slowly getting there as Swat evolves and you see some other tools such as smbldap-tools out there.
Funny how my first post is marked 5-interesting, but the last one is marked troll.
What're you talking about? Have you even tried doing those things? I had seamless client authentication, mapping, and granular permission setting via GUI working in Samba 3, almost a full 3 years ago. (No, it wasn't easy, but it's certainly doable.)
That is one the reason that you don't see widespread adoption of Samba. It's not easy to get setup. Sure the basic setup isn't too bad, but once you start trying to add it to a domain, run as a domain controller, or get granular file permissions working. I serious doubt you got samba configured as you say without a lot manual file editing, cursing, and trial-n-error until it worked. Compare that to using Microsoft where is is all truly gui-driven and reasonably idiot proof.
Yes, I have tried those things and have it working in various degrees on about 60 Sun, HP, and Linux boxes primarily as an alternative to NFS (now there's a f'd up protocol). I have a mix of clients with underlying accounts and generic user mapping. I also manage almost 3200 Windows boxes. Guess which ones take more time to manage? The Windows boxes are all managed centrally and I rarely have to manage an individual Windows client.
I'm tired of having to constantly go back and dork with Samba because something broke, or the end users can't set file permissions themselves. Better integration with AD might help all of this, but it's still not going to fix the underlying problem of poor integration and lack of centralized management.
I've ripped out a number of Linux boxes because the end users were not using them for anything but hosting file shares - something far easier to do with a Windows box.
I also have my share of Linux enthusiasts nuts that insist they have to have Linux on their desktop or server simply because they don't like Microsoft. If they have a valid reason like running a web server or needing Linux specific software, I let them. If not, I make them toe the company line and use an XP desktop and MS Office so I don't have to deal with everyone else complaining how their documents don't convert from OpenOffice correctly.
"If you are vaccinated with the injected vaccine, you have about a 70 percent chance of preventing influenza."
70% is a crap-shoot? Really?
Because the media would never misquote numbers right? http://www.cdc.gov/flu/about/qa/vaccineeffect.htm First, the flu shot will not completely prevent getting the flu. It most cases having had the right flu vacine to match the strain you are infected with will reduce the severity and duration That 30-70% figure the figure for how many people will experience reduced symptoms. This is still completely ignoring the fact that your odds of getting the right vacinne to match your particular strain are very low.
AD is just a recreation of LDAP with kerberos and a DNS implementation.
If only it were that simple, Samba would have managed a working clone by now. It's true that AD is basically built on a modified LDAP implementation and uses kerberos, but it really is more than that.
Samba's work makes it possible to build a mini domain controller in a low power appliance for use in a branch small branch office or something of that nature.
That's fine and dandy. It should work well there. Just don't delude yourself into thinking it will working in a large corporate environment where they need use all of the features of AD, beyond basic authentication. In that environment, integration with other software that uses AD is required. It's kind of ironic that you said "Samba's goal was always to be a file/print server" since printing support is not present in Samba4 yet.
At any rate, Samba4 doesn't appear to even have a stable release yet. I will be curious if it becomes stable enough, I may try it in some of the networks I support. For the most part, I just use it as clients to a real AD domain.
Samba 3 emulated the archaic NT4 domain and later scabbed on support for Kerberos and emulating a Win2k domain. It never fully implemented all the little features and protocols, but it was essentially functional. I could never get NTLMv2 to work consistently, and it broke several times after Microsoft patches. Management frequently required command-line work. I gave up even trying to get pki or integration with Exchange to work. Forget even trying to get file permissions to work seamlessly, including letting your users set granular file permissions.
From a business perspective, you can either pony up the money to buy the MS product and not worry whether it will work consistently, or you pay it in the long run with higher labor maintaining a Linux based solution that is guaranteed to have some speedbumps down the road..
Yes, Samba4 can emulate an AD server, if you don't mind having to maintain two sets of user and group accounts. Samba4 still requires either usermapping, or managing the linux users and groups separately. It simply lacks the nice seamless integration of AD, and does not fully implement GPOs inheritances, etc.
If you read the article, you'd see they barely got it to the point where a Win2008 server would talk to it enough to join the domain (not just replicate the LDAP database). That's a far cry full full interoperability.
If you want to go Linux simply because you don't like Microsoft, or think you might save money in the long runs (doubt it), then Samba is an option. It works fine for many uses. Just don't expect to have all of the features of a true AD server or guaranteed long term compatibility with Microsoft servers. Personally, I would never try to mix the two in a corp environment as it only takes one issue to kill the entire AD and I wouldn't want my ass being out there taking the blame for introducing the Linux box that was responsible.
Folks interested in saving a buck will start using Samba servers to either completely host or participate in Active Directory domains. The trap or catch will come further down the road when Microsoft patches something that breaks the functionality, at which point Microsoft will simply state that if you wanted something reliable you should have used genuine Windows servers. Don't believe me? The samba project is already rife with examples of this. Didn't we see Samba choke when enterprises tightening up security disabled ntlmv1?
I seriously doubt Samba-based AD servers will be fully functional anyway, just like Samba emulating an NT4 domain was just barely functional. Microsoft helped them figure out how to use the native Microsoft protocols to replicate the AD database instead of having to rely on the semi-functional openldap hack they had been using (actually be be more accurate, MS confirmed and correct their reverse engineering of the protocols).
Being able to replicating the AD database/ldap and form working trusts does not make Samba a good substitute for AD. It simply gives it an ability to co-exist with a real AD infrastructure. GPOs and most of the other desirable features of Active Directory are not implemented in Samba. Big businesses will still use MS boxes to ensure all the features work and its stable, since the cost of the software is not the driving factor.
What exactly do you mean by analog twisted pair, as that's not a normal term used by the telco industry? If you're talking about the unshielded twisted pair wire to the residence itself, then 2400bps is certainly not the limit. You can push a 45 mps DS3 up to 1/2 mile on copper, and a ISDN or T1 circuits for a few miles with no problems.
If you're talking about the usual equipment connected at the telco end of a FXS/B1 analog circuit, then 2400bps still is not the limit. It's the 56k as explained above for clean lines.
Also, although the spec says it possible, in practice you never see just a raw digital DS0 on a copper pair. It's usually part of a larger circuit such as a T1/DS1, sonet/atm, or larger circuit.
Compression has little to do with it. Off the shelf fax machines run speeds up to 14.4, typically 4800 or 9600. The compression is on top of the actual line rate.
Even if DSL operated in the 0-4000 Hz range, it would use the spectrum much more efficiently than would an analog signal sampled at n times a second.
Hit send to fast earlier. Sampling faster would not help, since the frequency range is still limited. A higher resolution sample, say 256 bit would let you pass more data but I think you'd run into issues "smearing" the signal too much to define descrete values.
The v.90 protocol is a trick to send a digital signal over an analog medium, avoiding the normal Nyquist sampling limitations that set 28.8k analog limit. Very clever piece of work I think.
As an example, image you have a light bulb that can go to 4 different levels of brightness and someone standing far away could distinguish what the 4 different levels were. For a modem, that's all done during that initial handshaking noise. The person seeing the light is basically getting a 2-bit digital signal.
If DSL was confined to 4000 hertz like your 56k digital dialup modem, it would still be limited to the same 7 bits * 4000 hertz * 2 == 56000 bits/second.
POTS samples the analog signal at an 8kHz rate, but the analog signal is filtered below around 3200 Hz to avoid Nyquist problems. The v90 relies on that 8k sample rate * num_usable_bits => bandwidth. For a perfect connection, if all 8-bits could get through you'd get 64k. As the phone connection travels digitally though the phone system, at least one bit usually gets "robbed" for phone system signaling. Usually it's more than one bit at various places.
Also during the handshake, the modems may decide that some of the 256 possible values of the signal (the constellation) are not usable, which further drops the data rate.
Verizon now insists you use their email proxy if you want to send out through a non-Verizon smtp email server. They're blocking port 25, and setup a proxy on a different port. Of course the spammers will catch on pretty quick and use the new port number if port 25 doesn't work.
Analog phone lines are indeed no faster than 56 kbits/second
For the sake of clarity analog phone lines are inherently limited to 2400 bits/second (bps). Better compression algorithms got us up to 56 kbps.
For the sake of clarity, you don't know what the fuck you're talking about. 56-kbits/second is the max because that's what the analog-digital converters within the telco are set for. A DS0 phone circuit is by definition a 56k or 64k digital channel (depends on inband or out-of-band signalling). The early 2400 and 4800 limits were due to poor quality lines and equipment that just wasn't setup to go faster. This was back when most users were just doing text and fax machines were the bandwidth intensive applications.
The magic of 56k comes from the users modem being able to synchronize its timing and discrete output levels (the "constellation") to match the analog-digital converter attached to the users phone line. The server end of the circuit must be digitally connected for this to work.
Yes it is using the same physical lines (although they may have to be cleaned up to remove loading coils or branched circuits). As you pointed out though, it not the same equipment at either end. Also, calling it an 8000 hertz bandwidth is rather misleading. It's an 8-bit sample taken at a sampling rate of 8000 hertz, not an 8k wide frequency range as your wording might imply. Its the sampling rate time the sample size that gives you a theoretical 64-kilobit/second limit, but other FCC and technical issues such as the typical robbed bit signaling end up dropping the max to 56k.
Typically, the DSLAM at the wiring closet or CO is connected via fiber to the rest of the infrastructure.
Obviously the prison didn't have anyone IT saavy or they never would have relied on an inmate. As I understand it, he simply changed some admin passwords and set the bios password. When they couldn't figure out how to change things back, they refused to let the guy show them how to fix it and hire an outside consultant.
Slashdot Mirror
An Internet Service Provider (ISP) isn't involved in a point-point. It's just a service provider at that point. Multiple links from the telco for redundancy is silly as the vast majority of problems will take down both links (cut fiber, local CO issues, etc). If you're talking mixing Telco, Satellite and Cable for redundancy as someone else mentioned, then I'd guess you are are talking about an ISP and running VPN then? In that case there are options such as mlppp, etc.
Jenny Jenny
008-67-5309
Bath Ruumstahl, NY
Jenny I got your number.....
Cisco is absent because they are a valid licensee. http://wifinetnews.com/archives/2008/10/different_interpretation_of_buffalo_csiro_patent_appeal.html
Completely impossible if you use a One time Pad. If you use a secret key, and the display updates the code every 10 seconds, it is feasible that it would require the cracker to wait for several years or decades worth of data from the display in order to figure out what the secret key is.
Two months of output is enough to crack 10% of the SecurID tokens. http://www.cosic.esat.kuleuven.be/publications/article-118.ps. So definitely possible, but not very feasible as I stated.
you might be able to glitch the secure chip by playing with temperature, voltage, or cutting into the chip and injecting current to the IC itself while it is still running.
If you look at http://www.linuxsecurity.com/content/view/124176/2/, they simply sped the clock up and recorded all the possible outputs. In theory you could take a SecurID token, modify the clock long enough to spit out all the values and "wrap" around to the current time again.
Didn't RTFA.
Well that explains why your comment makes no sense. The system was showing a correct dosage, but was delivering something different since they had been dorking with the protocol definitions. In the Therac-25 case, the error was due to the operators using the program in an undocumented manner and the system incorrectly calculating the required exposures as a result. Also the operator doesn't arbitrarily set a level. He picks a specific protocol from a menu which already has the scanning pattern, timing, and power levels. Don't forget that dosage is power x time, so a low power level run for too long is also a problem.
If you didn't bother reading TFA, please don't bother posting. Whatever twit modded you insightful should be banned as well.
Exactly. You not might be able to prevent the first error that overdoses a patient, but you will have an independant measure of the actual dosage and you won't keep overdosing people on that particular protocol for the next 18-months.
If you really had a DOD background investigation done in the last few years, then I'm pretty sure you got fingerprinted. The few agencies that do the background checks absolutely require them. What's your name, soc number and home mailing address? I'll pull up your file and see if they're present.
I pity the person with the job of building a LiveCD that supports all permutations of hardware. Hardware compatibility is still not perfect with Linux.
It is mathematically impossible to find out what the secret key/OTP is on these devices from readouts on the display.
Not impossible, just not feasible.
in order to break into an account protected by a keyfob, one absolutely HAS to steal the actual keyfob.
Not true. It's still not secure if you're using a compromised computer. It just means the person who compromised your computer has to block your logon attempt (perhaps with a bogus system is offline message) and quickly logon themselves within the short window before the token updates. The hijack could even be scripted such that when the user attempts to logon, it waits until it suceeds, throws the user a system-offline message, and then proceeds to do a money transfer. Certainly not outside the realm of possible.
Its a device with a 1 time pad in rom (or similar). The 1 time pad could be easily read off of rom if you crack it open.
Not if they are done right. In a secure chip design, the rom and processing is all on one chip, and the rom can not be read back out once written. The cpu on the same chip is the only thing that can read the key, and the only thing it does is generate the numbers for the display. This is a similar concept to the smartcard or CAC cards employed by the DOD. The digital signing happens on the card and the private keys can not be retrieved once put on the card.
Why would you want a 1gig video card in what's essentially a monitor-less netbook? You certainly don't need it for the video storage, and it's not like this has enough horsepower to run an video intensive games. Seem like it would just drive the cost up needlessly.
It's already happened. Typically it was a result of incomplete reverse engineering of the protocol. The problem with reverse engineering from scratch is that the developers may have missed some little used and undocumented part of the protocol. A patch on the MS side of the house may have zero effect on the MS clients and servers as they still understand the protocol, but Samba may not. Often it's because Microsoft didn't strictly follow an established standard such as an RFC.
The perfect example is Samba not implementing NTLMv2 because forcing the authentication back to NTLM worked fine until NTLMv1 gets disabled per the security guideline that MS/NSA put out. Naturally people don't blame Microsoft when this happens, they blame Samba because it gets viewed as not really 100% compatible and in a constant state of trying to catch up.
What I find noteworthy here is that while MS isn't helping them rewrite Samba, they are providing additional documentation and debugging support.
Sorry no MCSE monkey here. I'm actually Redhat and Cisco certified with a crapload of enterprise experience and I feel perfectly comfortable within a shell and vi thank you. Of course a significant portion of the rest of the system admins out there are more comfortable with a nice easy to understand gui. Something the Linux community (and you by the sarcastic tone of your response) still fail to understand. Simplicity and idiot-proof is essential for market penetration. The moment you force a mid-level system admin into manually editing files and googling for instructions on tweaking ldap.conf you've failed in the mission to make it simple.
You can certainly authenticate against AD using Samba via Kerberos. Since Kerberos is an authentication protocol, just how do you do "password management" (okay, I'm being picky)? My point is that the end user shouldn't have to know the ins and outs of LDAP or be forced to google for a walkthrough. It should be simple and self-explanatory to setup, which it currently is not. It's slowly getting there as Swat evolves and you see some other tools such as smbldap-tools out there.
Funny how my first post is marked 5-interesting, but the last one is marked troll.
What're you talking about? Have you even tried doing those things? I had seamless client authentication, mapping, and granular permission setting via GUI working in Samba 3, almost a full 3 years ago. (No, it wasn't easy, but it's certainly doable.)
That is one the reason that you don't see widespread adoption of Samba. It's not easy to get setup. Sure the basic setup isn't too bad, but once you start trying to add it to a domain, run as a domain controller, or get granular file permissions working. I serious doubt you got samba configured as you say without a lot manual file editing, cursing, and trial-n-error until it worked. Compare that to using Microsoft where is is all truly gui-driven and reasonably idiot proof.
Yes, I have tried those things and have it working in various degrees on about 60 Sun, HP, and Linux boxes primarily as an alternative to NFS (now there's a f'd up protocol). I have a mix of clients with underlying accounts and generic user mapping. I also manage almost 3200 Windows boxes. Guess which ones take more time to manage? The Windows boxes are all managed centrally and I rarely have to manage an individual Windows client.
I'm tired of having to constantly go back and dork with Samba because something broke, or the end users can't set file permissions themselves. Better integration with AD might help all of this, but it's still not going to fix the underlying problem of poor integration and lack of centralized management.
I've ripped out a number of Linux boxes because the end users were not using them for anything but hosting file shares - something far easier to do with a Windows box.
I also have my share of Linux enthusiasts nuts that insist they have to have Linux on their desktop or server simply because they don't like Microsoft. If they have a valid reason like running a web server or needing Linux specific software, I let them. If not, I make them toe the company line and use an XP desktop and MS Office so I don't have to deal with everyone else complaining how their documents don't convert from OpenOffice correctly.
From http://www.npr.org/templates/story/story.php?storyId=113154000,
"If you are vaccinated with the injected vaccine, you have about a 70 percent chance of preventing influenza."
70% is a crap-shoot? Really?
Because the media would never misquote numbers right? http://www.cdc.gov/flu/about/qa/vaccineeffect.htm First, the flu shot will not completely prevent getting the flu. It most cases having had the right flu vacine to match the strain you are infected with will reduce the severity and duration That 30-70% figure the figure for how many people will experience reduced symptoms. This is still completely ignoring the fact that your odds of getting the right vacinne to match your particular strain are very low.
AD is just a recreation of LDAP with kerberos and a DNS implementation.
If only it were that simple, Samba would have managed a working clone by now. It's true that AD is basically built on a modified LDAP implementation and uses kerberos, but it really is more than that.
Samba's work makes it possible to build a mini domain controller in a low power appliance for use in a branch small branch office or something of that nature.
That's fine and dandy. It should work well there. Just don't delude yourself into thinking it will working in a large corporate environment where they need use all of the features of AD, beyond basic authentication. In that environment, integration with other software that uses AD is required. It's kind of ironic that you said "Samba's goal was always to be a file/print server" since printing support is not present in Samba4 yet.
At any rate, Samba4 doesn't appear to even have a stable release yet. I will be curious if it becomes stable enough, I may try it in some of the networks I support. For the most part, I just use it as clients to a real AD domain.
Samba 3 emulated the archaic NT4 domain and later scabbed on support for Kerberos and emulating a Win2k domain. It never fully implemented all the little features and protocols, but it was essentially functional. I could never get NTLMv2 to work consistently, and it broke several times after Microsoft patches. Management frequently required command-line work. I gave up even trying to get pki or integration with Exchange to work. Forget even trying to get file permissions to work seamlessly, including letting your users set granular file permissions.
From a business perspective, you can either pony up the money to buy the MS product and not worry whether it will work consistently, or you pay it in the long run with higher labor maintaining a Linux based solution that is guaranteed to have some speedbumps down the road..
Yes, Samba4 can emulate an AD server, if you don't mind having to maintain two sets of user and group accounts. Samba4 still requires either usermapping, or managing the linux users and groups separately. It simply lacks the nice seamless integration of AD, and does not fully implement GPOs inheritances, etc.
If you read the article, you'd see they barely got it to the point where a Win2008 server would talk to it enough to join the domain (not just replicate the LDAP database). That's a far cry full full interoperability.
If you want to go Linux simply because you don't like Microsoft, or think you might save money in the long runs (doubt it), then Samba is an option. It works fine for many uses. Just don't expect to have all of the features of a true AD server or guaranteed long term compatibility with Microsoft servers. Personally, I would never try to mix the two in a corp environment as it only takes one issue to kill the entire AD and I wouldn't want my ass being out there taking the blame for introducing the Linux box that was responsible.
Folks interested in saving a buck will start using Samba servers to either completely host or participate in Active Directory domains. The trap or catch will come further down the road when Microsoft patches something that breaks the functionality, at which point Microsoft will simply state that if you wanted something reliable you should have used genuine Windows servers. Don't believe me? The samba project is already rife with examples of this. Didn't we see Samba choke when enterprises tightening up security disabled ntlmv1?
I seriously doubt Samba-based AD servers will be fully functional anyway, just like Samba emulating an NT4 domain was just barely functional. Microsoft helped them figure out how to use the native Microsoft protocols to replicate the AD database instead of having to rely on the semi-functional openldap hack they had been using (actually be be more accurate, MS confirmed and correct their reverse engineering of the protocols).
Being able to replicating the AD database/ldap and form working trusts does not make Samba a good substitute for AD. It simply gives it an ability to co-exist with a real AD infrastructure. GPOs and most of the other desirable features of Active Directory are not implemented in Samba. Big businesses will still use MS boxes to ensure all the features work and its stable, since the cost of the software is not the driving factor.
What exactly do you mean by analog twisted pair, as that's not a normal term used by the telco industry? If you're talking about the unshielded twisted pair wire to the residence itself, then 2400bps is certainly not the limit. You can push a 45 mps DS3 up to 1/2 mile on copper, and a ISDN or T1 circuits for a few miles with no problems.
If you're talking about the usual equipment connected at the telco end of a FXS/B1 analog circuit, then 2400bps still is not the limit. It's the 56k as explained above for clean lines.
Also, although the spec says it possible, in practice you never see just a raw digital DS0 on a copper pair. It's usually part of a larger circuit such as a T1/DS1, sonet/atm, or larger circuit.
Compression has little to do with it. Off the shelf fax machines run speeds up to 14.4, typically 4800 or 9600. The compression is on top of the actual line rate.
Even if DSL operated in the 0-4000 Hz range, it would use the spectrum much more efficiently than would an analog signal sampled at n times a second.
Hit send to fast earlier. Sampling faster would not help, since the frequency range is still limited. A higher resolution sample, say 256 bit would let you pass more data but I think you'd run into issues "smearing" the signal too much to define descrete values.
56k modems are not analog; they are digital.
The v.90 protocol is a trick to send a digital signal over an analog medium, avoiding the normal Nyquist sampling limitations that set 28.8k analog limit. Very clever piece of work I think.
As an example, image you have a light bulb that can go to 4 different levels of brightness and someone standing far away could distinguish what the 4 different levels were. For a modem, that's all done during that initial handshaking noise. The person seeing the light is basically getting a 2-bit digital signal.
If DSL was confined to 4000 hertz like your 56k digital dialup modem, it would still be limited to the same 7 bits * 4000 hertz * 2 == 56000 bits/second.
POTS samples the analog signal at an 8kHz rate, but the analog signal is filtered below around 3200 Hz to avoid Nyquist problems. The v90 relies on that 8k sample rate * num_usable_bits => bandwidth. For a perfect connection, if all 8-bits could get through you'd get 64k. As the phone connection travels digitally though the phone system, at least one bit usually gets "robbed" for phone system signaling. Usually it's more than one bit at various places.
Also during the handshake, the modems may decide that some of the 256 possible values of the signal (the constellation) are not usable, which further drops the data rate.
Verizon now insists you use their email proxy if you want to send out through a non-Verizon smtp email server. They're blocking port 25, and setup a proxy on a different port. Of course the spammers will catch on pretty quick and use the new port number if port 25 doesn't work.
Analog phone lines are indeed no faster than 56 kbits/second
For the sake of clarity analog phone lines are inherently limited to 2400 bits/second (bps). Better compression algorithms got us up to 56 kbps.
For the sake of clarity, you don't know what the fuck you're talking about. 56-kbits/second is the max because that's what the analog-digital converters within the telco are set for. A DS0 phone circuit is by definition a 56k or 64k digital channel (depends on inband or out-of-band signalling). The early 2400 and 4800 limits were due to poor quality lines and equipment that just wasn't setup to go faster. This was back when most users were just doing text and fax machines were the bandwidth intensive applications.
The magic of 56k comes from the users modem being able to synchronize its timing and discrete output levels (the "constellation") to match the analog-digital converter attached to the users phone line. The server end of the circuit must be digitally connected for this to work.
Yes it is using the same physical lines (although they may have to be cleaned up to remove loading coils or branched circuits). As you pointed out though, it not the same equipment at either end. Also, calling it an 8000 hertz bandwidth is rather misleading. It's an 8-bit sample taken at a sampling rate of 8000 hertz, not an 8k wide frequency range as your wording might imply. Its the sampling rate time the sample size that gives you a theoretical 64-kilobit/second limit, but other FCC and technical issues such as the typical robbed bit signaling end up dropping the max to 56k.
Typically, the DSLAM at the wiring closet or CO is connected via fiber to the rest of the infrastructure.
Obviously the prison didn't have anyone IT saavy or they never would have relied on an inmate. As I understand it, he simply changed some admin passwords and set the bios password. When they couldn't figure out how to change things back, they refused to let the guy show them how to fix it and hire an outside consultant.