Elf

Members
  • Content count

    63
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Elf

  • Rank
    HACK THE PLANET!

Contact Methods

  • ICQ
    0
  1. Not that it isn't a nice test set (I was considering buying one of those myself but ended up with a Harris TS30, which I like a lot), but it isn't going to make calls on T1 lines. You would need some sort of an add/drop mux/CSU and DS0 adapter, or one of the larger T1 test sets (that usually do BERTs and so on) to talk over a T1 channel. The "digital" in the product description just means it doesn't interfere with digital lines if you happen to sit on one, the voice part itself is still analog, with heavy bandpass filtering.
  2. You could construct a simple bandpass filter to clean up the PWM audio, if you wanted. It would obviously add a few extra (passive) components, but can make it sound as good as a pure sine wave oscillator.
  3. A cheap way to do this is to use a 600:600 ohm transformer, the line straight on one winding (no DC filter capacitor), and two ~1.7V zener diodes facing each other across the other winding. The DC resistance of the transformer should put the line off-hook, tripping any ring, and anything that gets past the transformer will be shunted to a maximum of ~2.4 volts via the two zeners. You should make sure that the transformer is designed for POTS telephony applications though, so it can handle the DC current. Smaller transformers usually become magnetically saturated by the loop current. Example: Digikey MT4135-ND If you wanted to be extra careful, you could also add a 100mA fuse between the line and the transformer.
  4. Thanks for the link -- I had actually known about that procedure, but unfortunately it clears the rate table, things like PBX dial 9, and so on, so the phone would still need to be reprogrammed. The documentation seems inconsistent as to what actually happens when the memory is cleared -- some things say that the phone won't dial out until reprogrammed, and some say that it defaults to 25 cents flat for everything.
  5. If anyone has Elcotel PNM+ and could give it to me, that would be great. I bought a payphone with an elcotel brain, and it has several annoying settings I wish to get rid of (redirects 1-800 numbers for collect services to some dodgy alternate operator service, and so on). Barring being able to satisfactorily reprogram it I will probably just end up throwing the brain away, which would be unfortunate
  6. The difference between Cat 3 / Cat 5 is largely the quality of the copper and the twist ratio -- that is, how many twists there are per foot in your twisted pair. The difference between either should not be noticeable in the voice band. The reason Cat 3 is recommended for DSL is because DSL uses frequencies well above the voice band, and poor grade phone wiring such as Quad (red/green, etc.) wire is often untwisted, leading to higher crosstalk or noise. Generally, the higher up the "Cat" rating system you go, the better the cable will perform at higher frequencies. If you want specifics, you can look up the relevant TIA/EIA standards. Cat 3 should be considered more than sufficient for POTS voice. If I were doing a new installation, I would probably run Cat 5e for voice/data 1/data 2 jacks, since what is a POTS "voice" line today may become a VoIP data line in the future. There are slight tradeoffs to using a higher rated cable. It can be more expensive, or with Cat 6 more difficult to work with. Or for example the higher twist ratio of Cat 5 vs. Cat 3 can effectively make a cable longer internally per foot run, and so some people seem to be religious about only using Cat 3 for POTS voice to keep the loss down. I don't think this really matters in the scope of a typical home installation.
  7. There are various add on schemes such as DomainKeys or SPF that ensure a message originated from the proper MX, but then it's really up to that MX to ensure the accuracy of the sender information, which many don't seem to do.
  8. Recently I got a Western Electric 145A loop test set. It is one of the old lunchpail style sets that can perform a number of useful tests on copper pairs. I noticed that similar to a kick meter, it can use capacitance to determine the length of an open pair. However it appears to be much more accurate (for this purpose) than a kick meter, and can read down to a resolution of feet with a constant meter indication, in contrast to a kick meter which is more useful for measuring in the hundreds of feet and requires you to estimate a peak reading. I was reading through the manual and noticed that this reading appears to be based on a capacitance of 0.083uF/mile. Although I obviously have a great appreciation for the phone side of things, my actual job deals mostly with data, and so I started wondering how useful this would be for modern cat 5e installations. After pulling up some specs and doing unit conversions, it turns out that this is exactly the pair capacitance of modern cat 5e cable. So how accurate is this classic equipment? TDRs (time domain reflectometers) are the modern tool for determining the length (and other incidents) of a cable. Version 2 of the WE 145A manual says it was printed in August of 1979. TDR number 1: (25.9 meters) TDR number 2: (25.6 meters) Western Electric 145A: (~84 feet) 25.75 meters is 84.48 feet. Good enough for me. The Fluke meters are fancy and obviously do a lot of important qualification for data networking that the 145A won't, but I have no reservations using this almost 30 year old piece of equipment today. Not bad at all; Western Electric really does mean quality!
  9. VoIP calls into the PSTN usually aren't VoIP all the way through. Eventually they terminate somewhere where rates / space / etc. are favorable. From there they could get carried as digital TDM, analog, or whatever paths happen to be available. It sounds like it's getting dropped off at an exchange before going on some really long copper pairs, and you're getting crosstalk between the pairs, etc.
  10. Military field phones are fun, too. I have a pair set up back to back in the office; pick up one and the other rings. All you need is wire and a -48V supply. The newer ones like in the photos below are digital though, appear to signal digits outside of the voice band (no DTMF), and use some diphase signaling at 16 or 32kbps.
  11. C coders may be getting better about sanity checking and use of fixed length buffers, so sure, that one method of exploitation may be getting less attention. However as others have pointed out, with the new "everyone's a programmer" web environment, it would seem that there are actually more holes than before. Watch any security lists and you'll be overwhelmed by the number of exploits for "Joe's Discount Guestbook" or whatever other dodgy web application someone has slapped together. Also as per the topic, hackers die every day! It's only natural.
  12. I haven't seen that place before, but have seen other lists of route servers. The AT&T (route-server.ip.att.net) one has been handy for me. Those interested in the general structure of the internet may also enjoy BGP looking glasses.
  13. I follow NANOG and other backbone operator groups and quite honestly I haven't seen sight of too much being wrong with the actual protocols or infrastructure. Most of the problems on todays internet come from clueless network or machine administrators, not technical problems. Old and already existent technologies like uRPF and prefix filtering, while minimal to implement, can cut down the majority of spoofed traffic. Secure end to end communication is more or less a solved problem with IPSEC, SSL, and other higher layers. Packet prioritization is more a matter of knowing what to trust than some inherent deficiency with IP. We will need to crack down on ISPs who knowingly spew huge volumes of bad traffic with no effort on their part to clean things up. We will need to move to 32 bit ASNs. People with large chunks of unused IPv4 space will need to give it up. DNS may need to be reworked to guarantee a better level of security. SMTP needs an overhaul period. All in all, not problems with IP or routing infrastructure. Sounds like hype to me, honestly. For whatever you want to say, there is probably a Vint Cerf quote to pull out of context and back your point up.
  14. Just an interesting observation here; a lot of people are advocating learning "higher level" (abstracted programming languages, GUIs) concepts first, as opposed to "lower level" (command lines, machine languages). Since this discussion is already way off track, I don't feel too bad about derailing it. I've always thought that where computers are concerned, like many other subjects, it would be proper to learn lower level concepts first, to ensure that concepts are learned more correctly. This is an approach that many other subjects take. For example, you learn your alphabet before sentence structure, and sentence structure before essay composition; atoms and electrons before ions, ions before salts, salts before organic chemistry; addition before calculus and so on. Most traditional subjects don't try to hide what's "under the hood" from the learner, they dive right into things at the most basic level, and I think computer science should as well. The current approach of teaching high level abstracted languages seems to me to lead to people making many incorrect assumptions about how things are actually happening. For example, I've had many acquaintances go through traditional CS programs, learning Java, thinking that a "string" was something that a computer just dealt with. When it came time to learn C or assembly, they were at an utter loss trying to figure out why there was no "magic string." Similarly I've seen people who learn BASIC think that the CPU actually executed instructions in BASIC. Trying to clear them of these misconceptions was a very time consuming process. I strongly believe that people should learn about computers from the ground up. First, they should be acquainted with the basics of electronics, (digital logic, system architecture, and so on) up to machine language, then C, C++ or another mildly OO language, then on to a scripting language, operating system environment, high level application design concepts, etc. This is obviously not for people who want instant gratification. It will take a few years of experience to even get to the "hello world" stage (hello blinking LED might be a more common experience), but I think anyone who comes out of such an educational system would have a very solid and proper understanding of all the concepts involved, and would likely be a much higher grade of graduate than most of the CS curriculums nowdays. I've met people (many of them academics) who strongly agree, but obviously a majority don't. Maybe I'm just being unrealistic in my expectations of a system that values a quickly employable workforce over a more educated populace, or maybe I'm just completely backwards. If it wasn't clear, this doesn't mean I think an operating system is a good first / newbie project. Operating systems are, in general, one of those subjects where "if you have to ask, you aren't ready."
  15. Very true; but don't discount even the knowledge that comes from more abstracted solutions. For example, when installing premade parts you may be more likely to gain knowledge about the installation/installation design process vs. the process of antenna design. There's a lot of knowledge to be had at all levels. It's always good to acquire as much as possible, but sometimes it isn't practical. I'm an avid low level assembly programmer; I like dealing directly with the hardware. I think it is something everyone who uses a computer should know, but at the same time I realize most people (even "power users") simply want to accomplish a task rather than sit back and contemplate the beauty of their system's architecture. Thankfully for most OS users, the nitty gritties of the architecture can be ignored, and they can spend time concentrating and learning about higher level tasks It doesn't mean they should, but horses for courses and all that.