Let's Connect Our World

By "speed" we really mean the "data flow rate" but almost everybody incorrectly calls it speed. For all modern modems you have no choice of the speed that the modem uses on the telephone line since it will automatically choose the highest possible speed that is feasible under the circumstances. If one modem is slower than the other, then the faster modem will operate at the slower modem's speed. On a noisy line, the speed will drop still lower.

While the above speeds are selected automatically by the modems you do have a choice as to what speed will be used between your modem and your computer (PC-to-modem speed). This is sometimes called "DTE speed" where "DTE" stands for Data Terminal Equipment (Your computer is a DTE.) You need to set this speed high enough so this part of the signal path will not be a bottleneck. The setting for the DTE speed is the maximum speed of this link. Most of the time it will likely actually operate at lower speeds.

For an external modem, DTE speed is the speed (in bits/sec) of the flow over the cable between you modem and PC. For an internal modem, it's the same idea since the modem also emulates a serial port. It may seem ridiculous having a speed limit on communication between a computer and a modem card that is directly connected inside the computer to a much higher speed bus. But it's usually that way since the modem card probably includes a dedicated serial port which does have speed limits (and settable speeds). However, some software modems have no such speed limits.

Speed and Data Compression

What speed do you choose? If it were not for "data compression" one might try to choose a DTE speed exactly the same as the modem speed. Data compression takes the bytes sent to the modem from your computer and encodes them into a fewer number of bytes. For example, if the flow (speed) from the PC to the modem was 20,000 bytes/sec (bps) and the compression ratio was 2 to 1, then only 10,000 bytes/sec would flow over the telephone line. Thus for a 2:1 compression ratio you would need to set the DTE speed to double the maximum modem speed on the phone line. If the compression ratio were 3 to 1 you would need to set it 3 times faster, etc.

Where do I Set Speed ?

This DTE (PC-to-modem) speed is normally set by a menu in your communications program or by an option given to the getty command if someone is dialing in. You can't set the DCE modem-to-modem speed since this is set automatically by the modem to the highest feasible speed after negotiation with the other modem. Well, actually you can set the modem-to-modem speed with the S37 register but you shouldn't do it. If the two modems on a connection were to be set this way to different speeds, then they couldn't communicate with each other.

Can't Set a High Enough Speed

Speeds over 115.2kbps

The top speed of 115.2k has been standard since the mid 1990's. But by the year 2000, most new serial ports supported higher speeds of 230.4k and 460.8k. Some also support 921.6k. Unfortunately Linux seldom uses these speeds due to lack of drivers. Thus such ports behave just like 115.2k ports unless the higher speeds are enabled by special software. To get these speeds you need to compile the kernel with special patches or use modules until support is built into the kernel's serial driver.

Unfortunately serial port manufacturers never got together on a standard way to support high speeds, so the serial driver needs to support a variety of hardware. Once high speed is enabled, a standard way to choose it is to set baud_base to the highest speed with setserial (unless the serial driver does this for you). The software will then use a divisor of 1 to set the highest speed. All this will hopefully be supported by the Linux kernel sometime in 2003.

A driver for the w83627hf chip (used on many motherboards such as the Tyan S2460) is at https://www.muru.com/linux/w83627hf/

A non-standard way that some manufacturers have implemented high speed is to use a very large number for the divisor to get the high speed. This number isn't really a divisor at all since it doesn't divide anything. It's just serves as a code number to tell the hardware what speed to use. In such cases you need to compile the kernel with special patches.

One patch to support this second type of high-speed hardware is called shsmod (Super High Speed Mode). There are both Windows and Linux versions of this patch. See http://www.devdrv.com/shsmod/. There is also a module for the VIA VT82C686 chip http://www.kati.fi/viahss/. Using it may result in buffer overflow.

For internal modems, only a minority of them advertise that they support speeds of over 115.2k for their built-in serial ports. Does shsmod support these ??
How speed is set in hardware: the divisor and baud_base

Speed is set by having the serial port's clock change frequency. But this change happens not by actually changing the frequency of the oscillator driving the clock but by "dividing" the clock's frequency. For example, to divide by two, just ignore every other clock tick. This cuts the speed in half. Dividing by 3 makes the clock run at 1/3 frequency, etc. So to slow the clock down (meaning set speed), we just send the clock a divisor. It's sent by the serial driver to a register in the port. Thus speed is set by a divisor.

If the clock runs at a top speed of 115,000 bps (common), then here are the divisors for various speeds (assuming a maximum speed of 115,200): 1 (115.2k), 2 (57.6k), 3 (38.4k), 6 (19.2k), 12 (9.6k), 24 (4.8k), 48 (2.4k), 96 (1.2k), etc. The serial driver sets the speed in the hardware by sending the hardware only a "divisor" (a positive integer). This "divisor" divides the "maximum speed" of the hardware resulting in a slower speed (except a divisor of 1 obviously tells the hardware to run at maximum speed).

There are exceptions to the above since for certain serial port hardware, speeds above 115.2k are set by using a very high divisor. Keep that exception in mind as you read the rest of this section. Normally, if you specify a speed of 115.2k (in your communication program or by stty) then the serial driver sets the port hardware to divisor 1 which sets the highest speed.

Besides using a very high divisor to set high speed, the conventional way to do it is as follows: If you happen to have hardware with a maximum speed of say 230.4k (and the 230.4k speed has been enabled in the hardware), then specifying 115.2k will result in divisor 1. For some hardware this will actually give you 230.4k. This is double the speed that you set. In fact, for any speed you set, the actual speed will be double. If you had hardware that could run at 460.8k then the actual speed would be quadruple what you set. All the above assumes that you don't use "setserial" to modify things.
Setting the divisor, speed accounting

To correct this accounting (but not always fix the problem) you may use "setserial" to change the baud_base to the actual maximal speed of your port such as 230.4k. Then if you set the speed (by your application or by stty) to 230.4k, a divisor of 1 will be used and you'll get the same speed as you set.

If you have very old software which will not allow you to tell it such a high speed (but your hardware has it enabled) then you might want to look into using the "spd_cust" parameter. This allows you to tell the application that the speed is 38,400 but the actual speed for this case is determined by the value of "divisor" which has also been set in setserial. I think it best to try to avoid using this kludge.

There are some brands of UARTs that uses a very high divisor to set high speeds. There isn't any satisfactory way to use "setserial" (say set "divisor 32770") to get such a speed since then setserial would then think that the speed is very low and disable the FIFO in the UART.
Crystal frequency is higher than baud_base

Note that the baud_base setting is usually much lower than the frequency of the crystal oscillator since the crystal frequency of say 1.8432 MHz is divided by 16 in the hardware to get the actual top speed of 115.2k. The reason the crystal frequency needs to be higher is so that this high crystal speed can generate clock ticks to take a number of samples of each bit to determine if it's a 1 or a 0.

Actually, the 1.8432 MHz "crystal frequency" may be obtained from a 18.432 MHz crystal oscillator by dividing by 10 before being fed to the UART. Other schemes are also possible as long as the UART performs properly.

Speed Table

It's best to have at least a 16650 UART for a 56k modem but few modems or serial ports provide it. Second best is a 16550 that has been tweaked to give 230,400 bps (230.4 kbps). Most people still use a 16550 that is only 115.2 kbps but it's claimed to only slow down thruput by a few percent (on average). This is because a typical compression ratio is 2 to 1 and for downloading compressed files (packages) it's 1 to 1. There's no degradation for these cases. Here are some suggested speeds to set your serial line if your modem speed is:

• 56k (V.92): use 115.2 kbps or 230.4 kbps (best)
• 56k (V.90): use 115.2 kbps or 230.4 kbps (best)
• 33.6k (V.34bis): use 115.2 kbps
• 28.8k (V.34): use 115.2 kbps
• 14.4k (V.32bis): use 57600 bps
• 9.6k (V.32): use 38400 bps
• slower than a 9600 bps (V.32) modem: Set the speed to the same speed as the modem (unless you have data compression).

All the above speeds may use V.42bis data compression and V.42 error correction. If data compression is not used then the speed may be set lower so long as it's above the modem speed.

Read Users' Comments (0)

Many Winmodems Will Not Work with Linux

Unfortunately, some software modems (winmodems) will not work with Linux due to lack of Linux drivers. Configuring the software modems that can be made to work with Linux ranges from very easy (automatically) to difficult, depending on both the modem, your skills, and how easy it is to find info about your modem --info that is not all in this HOWTO. If you buy a new one that you're not sure will work under Linux, try to get an agreement that you can return it for a refund if it doesn't work out.

Even if your modem works with Linux it can't be used until the serial port it's located on is enabled and made known to the operating system. For a detailed explanation of this (or if boot-time messages don't show your modem's serial port) study this HOWTO or see Plug-and-Play-HOWTO.

External vs. Internal

A modem for a PC may be either internal, external serial, or external USB. The internal one is installed inside of your PC (you must remove screws, etc. to install it). An external one just plugs in to a cable: USB cable (USB modem) or to the serial port (RS-232 serial modem). As compared to external serial modems, the internal modems are less expensive, are less likely to to suffer data loss due to buffer overrun, and usually use less electricity. An internal modem obviously doesn't use up any desk space.

External serial modems are usually easier to install and usually has less configuration problems provided the serial port you'll connect it to is configured OK. External USB modems are more likely to be winmodems and are reportedly usually more difficult to deal with than external serial modems. External modems have lights which may give you a clue as to what is happening and aid in troubleshooting. The fact that the serial port and modem can be physically separated also aids in troubleshooting. External modems are easy to move to another computer. If you need to turn the power off to reset your modem (this is seldom necessary) then with an external you don't have to power down the entire PC.

Unfortunately, most external serial modems have no switch to turn off the power supply when not in use and thus are likely to consume a little electricity even when turned off (unless you unplug the power supply from the wall). Each watt they draw usually costs you over $1/yr. Another possible disadvantage of an external is that you will be forced to use an existing serial port which may not support a speed of over 115,200 bps (although as of late 2000 most new internal modems don't either --but some do). For details Can't Set a High Enough Speed

Is a Driver Needed ?

Any modem, of course, needs the serial driver that comes with Linux (either built into the kernel or as a module). For PCI, this driver should also detect the modem but it's not really a modem driver since it just detects which serial port the modem is on.

But what about modem drivers? Any software modem (winmodem, linmodem) must have a modem driver (if it exists for Linux). Hardware modems don't really need any modem driver unless you want to use special features such as voice and "modem on hold".

Software modems require software to run them and obviously do need a driver. The drivers for MS Windows are *.exe programs which will not run under Linux. So you must use a Linux driver (if it exists). See Software-based Modems

External Modems

Do they all work under Linux?

At one time (2002 ?) all external modems would work under Linux. But then came the controllerless external modem which wouldn't. If the box says it requires Windows with no mention of Linux it could mean just that. Could it be that Windows software is provided for "modem on hold" and for use as an answering machine, etc., but that otherwise it will work under Linux? Linux may not support these features very well if at all. If this is a recent version of Modem-HOWTO, let me know of your experience with this.
PnP External Modems

Many external modems are labeled "Plug and Play" (PnP). If they are hardware modems, they should all work as non-PnP modems. While the serial port itself may need to be configured (IRQ number and IO address) unless the default configuration is OK, an external modem uses no such IRQ/IO configuration. You just plug the modem into the serial port.

The PnP modem has a special PnP identification built into it that can be read (thru the serial port) by a PnP operating system. Such an operating system would then know that you have a modem on a certain port and would also know the id number. If it's a controllerless modem, it could try to locate a driver for it. It could also tell application programs what port your modem is on (such as /dev/ttyS2 or COM3). But Linux may not be able to do this. Thus you may need to configure your application program manually by giving it the ttyS number (such as /dev/ttyS2). Some programs like wvdial can probe for a modem on various ports.
Cabling & Installation

Connecting an external modem is simple compared to connecting most other devices to a serial port that require various types of "null modem" cables (which will not work for modems). Modems use a straight through cable, with no pins crossed over. Most computer stores should have one. Make sure you get the correct gender and number of pins. Hook up your modem to one of your serial ports. If you are willing to accept the default IRQ and IO address of the port you connect it to, then you are ready to start your communication program and configure the modem itself.
What the Lights (LED's) Mean (for some external modems)

• TM Test Modem
• AA Auto Answer (If on, your modem will answer an incoming call)
• RD Receive Data line = RxD
• SD Send Data line = TxD
• TR data Terminal Ready = DTR (set by your PC)
• RI Ring Indicator (If on, someone is "ringing" your modem)
• OH Off Hook (If off, your modem has hung up the phone line)
• MR Modem Ready = DSR ??
• EC Error Correction
• DC Data Compression
• HS High Speed (for this modem)

Internal Modems

An internal modem is installed in a PC by taking off the cover of the PC and inserting the modem card into a vacant slot on the motherboard. There are modems for PCI slots, other modems for the older ISA slots, and ARM software "modems" for the new small AMR slot. Only some newer PCs will have ARM slots. While external modems plug into the serial port (via a short cable) the internal modems have the serial port built into the modem. In other words, the modem card is both a serial port and a modem.

Setting the IO address and IRQ for a serial port was formerly done by jumpers on the card. These are little black rectangular "cubes" about 5x4x2 mm in size which push in over pins on the card. Plug-and-Play modems (actually the serial port part of the modems) don't use jumpers for setting these but instead are configured by sending configuration commands to them over the bus inside the computer. Such configuration commands can be sent by a PnP BIOS, by the isapnp program (for the ISA bus only), by setpci (PCI bus: can't set IRQs), or by newer serial of how to configure the ones that don't get io-irq configured by the serial driver.

1. ISA bus: Use "isapnp" which may be run automatically at every boot-time
2. Let a PnP BIOS do it, and then maybe tell setserial the IO and IRQ
3. PCI bus: Use lspci -vv to look at it and setpci to configure the IO only (can't set the IRQ).
See Quick Install for more details, especially for the PCI bus.

Software-based Modems (winmodems, linmodems)

Introduction to software modems (winmodems)

Software modems turn over some (or even almost all) of the work of the modem to the main processor (CPU) chip of your computer (such as a Pentium chip). This requires special software (a modem driver) to do the job. Until late 1999, such software was released only for MS Windows and wouldn't work with Linux. Even worse was that the maker of the modem kept the interface to the modem secret so that no one could write a Linux driver for it (even though a few volunteers were willing to write Linux drivers).

But things have improved some since then so that today (late 2001) many such modems do have a linux driver. There is no standard interface so that different brands/models of software-modems need different drivers (unless the different brands/models happen to use the same chipset internally). But some drivers may not work perfectly nor have all the features that a MS Windows driver has.

Another name for a software modem (used by MS) is "driver-based modem". The conventional hardware-based modem (that works with Linux) doesn't need a modem driver (but does use the Linux serial driver) After about mid-1998 most new internal modems were software modems.

Software modems fall into 2 categories: linmodems and winmodems. Winmodems will only work under MS Windows. Linmodems will work under Linux. They formerly were mostly winmodems so some also call them "winmodems". The term "Winmodem" is also a trademark for a certain model of "winmodem" but that's not the meaning of it in this document.
Linmodems

In late 1999, two software-based modems appeared that could work under Linux and were thus called "linmodems". Lucent Technologies (LT) unofficially released a Linux binary-only code to support most of its PCI modems. PC-TEL (includes "Zoltrix") introduced a new software-based modem for Linux. After that, interest increased for getting winmodems to work under linux. There is a GPL'ed driver for Intel's (Modem Silicon Operations) MD563x HaM chipset (nee Ambient division of Cirrus Logic). As of mid-2001 there are also drivers for: Conexant HSF and HCF, Motorola SM56 (support terminated), ESS (ISA only), and IBM's Mwave for Thinkpads 600+. See http://linmodems.org.

What percent of software modems now (2001) work under Linux? Well, there's a number of modem chips not supported: Lucent/Agere ARM (Scorpio), 3COM/US Robotics, some SmartLink (3 different chipsets), Ambient HSP, and possibly others. So it seems that over half the software modem chips were supported as of late 2001. As of 2005 it seems that the situation has gotten worse. Why? Well, Linux on the Desktop didn't grow as fast as expected and many PC users went for higher speed cable modems and DSL.

Another reason is that many of the drivers were written years ago and will only work for older versions of the Linux kernels. The driver code is secret and the companies don't want to update drivers for hardware they are no longer selling.

Be warned in advance that determining if your modem is a linmodem may not be very easy. You may need to first find out what chipset you have and who makes it. Just knowing the brand and model number of your modem may not be sufficient. One method is to download the scanModem tool from http://linmodems.org but the results may be hard to decipher and you may need to ask for help from the linmodems mailing list. Another way to find this out using say "lspci -v" and then looking up the chip maker using the long modem number. This requires checking a database or searching the Internet. Still another way is to look at the fine print on the chips on the modem card. All this is not always simple. It could happen that you will put a lot of effort into this only to get the bad news that your modem isn't supported. But even if it is supported, support may only be for an old version of the kernel. See Linmodem-HOWTO for more details.
Linmodem sites and documentation

• Linmodem-HOWTO
• Winmodems-and-Linux-HOWTO (not as well written as Linmodem-HOWTO)
• http://linmodems.org is a project to turn winmodems into linmodems. Has a mailing list.
• Conexant+Rockwell-modem-HOWTO
• old modem list Has links to linmodem info, but not maintained after 2003.
• PCTel-HSP-MicroModem-Configuration-mini-HOWTO

Software-based modem types

There are two basic types of software modems. In one type the software does almost all of the work. The other is where the software only does the "control" operations (which is everything except processing the digital waveshapes --to be explained later). Since the hardware doesn't do the control it's called a "controllerless" modem. The first type is an all-software modem (sometimes just called a software modem).

For both of these types there must be analog hardware in the modem (or on the motherboard) to generate an electrical waveshape to send out the phone line. It's generated from a digital signal (which is sort of a "digital waveshape"). It's something like the digital electronics creates a lot of discrete points on graph paper and then the modem draws a smooth voltage curve thru them. There must also be hardware to convert the incoming waveshape to digital. This is just analog-to-digital conversion (and conversely). It's done by a codec (coder-decoder).

The incoming digital waveshape must be converted to a data byte stream. This is part of the demodulation process. Recall that these data bytes have likely been compressed, so they are not at all like the original message. Turning data bytes into a digital waveshape is part of the modulation process. Even after demodulation is done, the modem can't just send the resulting incoming data byte stream to the serial port input buffers, but must first do decompression, error correction, and convert from serial to the parallel bus of the computer. But the modem may get the CPU to do the actual work. It's the reverse sequence for an outgoing data byte stream.

The difference between the two types of software-based modems is where the digital modulation takes place. In the all-software modem this modulation is done in the CPU and it's called a Host Signal Processor (HSP). In the controllerless modem it's done in the modem but all other digital work is done by the CPU. This other digital work consists of dealing with AT-commands, data compression, error correction, and simulating a serial port. In the all-software modem, there are still two items handled by hardware: the A/D conversion of waveshapes by the codec and echo cancellation.
Is this modem a software modem?

How do you determine if an internal modem is a software modem? First see if the name, description of it, or even the name of the MS Windows driver for it indicates it's a software modem: HSP (Host Signal Processor) , HCF (Host Controlled Family), HSF (Host Signal Family), controllerless, host-controlled, host-based, and soft-... modem. If it's one of these modem it will only work for the cases where a Linux driver is available. Since software modems cost less, a low price is a clue that it's a software modem.

If you don't know the model of the modem and you also have Windows on your Linux PC, click on the "Modem" icon in the "Control Panel". Then see the modem list (not maintained after 2003). If the above doesn't work (or isn't feasible), you can look at the package the modem came in (or a manual). Read the section on the package that says something like "Minimum System Requirements" or just "System Requirements".

A hardware modem will work fine on old CPUs (such as the 386 or better). So if it requires a modern CPU (such as a Pentium or other "high speed" CPU of say over 150 MHz) this is a clue that it's a all-software modem. If it only requires a 486 CPU (or better) then it's likely a host-controlled software modem. Saying that it only works with Windows is also bad news. However, even in this case there may be a Linux driver for it or it could be a mistake in labeling.

Otherwise, it may be a hardware modem if it fails to state explicitly that you must have Windows. By saying it's "designed for Windows" it may only mean that it fully supports Microsoft's plug-and-play which is OK since Linux uses the same plug-and-play specs (but it's harder to configure under Linux). Being "designed for Windows" thus gives no clue as to whether or not it will work under Linux. You might check the Website of the manufacturer or inquire via email. Some manufacturers are specifically stating that certain models work under Linux. Sometimes they are linmodems that require you to obtain and install a certain linmodem driver.
Should I get a software modem?

Only if you know there is a Linux driver for it that works OK. But there may be a problem if the driver isn't being maintained and as a result doesn't work with future versions of the kernel. Also, the driver may not have full functionality. Besides the problems of getting a satisfactory driver, what are the pros and cons of software modems? Since the software modem uses the CPU to do some (or all) of its work, the software modem requires less on-board electronics on the modem card and thus costs less. At the same time, the CPU work load is increased by the modem which may result in slower operation.

The percentage of loading of the CPU by the modem depends on both what CPU you have and whether or not it's an all-software modem. For a modern CPU and a modem that only uses the CPU as a controller, there's little loss of performance. Even if it's an all-software modem, you will not suffer a loss of performance if there are no other CPU-intensive tasks are running at the same time. Of course, when you're not using the software modem there is no degradation in performance at all.

Is the modem cost savings worth it? In many cases yes, especially if you don't use the modem much and/or are not running any other CPU intensive tasks when the modem is in use. The savings in modem cost could be used for a better CPU which would speed things up a little. But the on-board electronics of a hardware modem can do the job more efficiently than a general purpose CPU (except that it's not efficient at all when it's not in use). So if you use the modem a lot it's probably better to avoid all-software modems.

PCI Modems

A PCI modem card is one which inserts into a PCI-bus slot on the motherboard of a PC. While many PCI winmodems will not work under Linux (no driver available) other PCI modems will work under Linux. The Linux serial driver has been modified to support certain PCI hardware modem cards (but not winmodems/linmodems). If it's a linmodem, it will work only if you install a certain linmodem driver. If the Linux serial driver supports your hardware modem then the driver will set up the PnP configuration for you. See PCI Bus Support Underway. If no special support for your PCI hardware modem is in the Linux serial driver it may still work OK but you have to do some work to configure it.

AMR Modems

These are mainly used in laptops. They are all winmodems that insert into a special AMR (Audio Modem Riser) slot on the motherboard. Audio cards or combined audio-modem cards are sometimes used in this slot. The slot's main use is for HSF type modems where the CPU does almost all of the work. This results in a small "modem" card and thus a short AMR slot. The motherboard has a codec which takes digital output from the CPU and generates analog voltage waves at the ARM slot (and conversely). Thus the "modem" that plugs into the slot has little to do except to interface the telephone line with the codec. Linux supports at least one AMR modem. lspci -v should display it.

USB Modems

USB = Universal Serial Bus. Most USB modems are winmodems, so many will not work with Linux. Linux has support for modems that conform to the USB Communication Device Class Abstract Control Model (= USB CDC ACM). There's a module for ACM named acm.o. See the /usb/acm.txt document in the kernel documentation directory (/usr/share/doc/kernel-doc-2.6.x in Debian, perhaps /usr/doc/kernel... in some distributions). The ACM "serial port" for the first (0th) such modem is: /dev/usb/acm/0 or possibly /dev/usb/ttyACM0. This should be the case regardless of whether or not you use the new "device file system". It's not really a serial port, but the driver makes it look like a serial port to software which uses the modem.

Since the bandwidth on the USB is high it's possible to send a lot more that just data to a USB modem. This means that it's feasible to create a USB winmodem where the driver does most of the modem's work on the CPU and sends the results to the modem. So beware of USB winmodems (unless they have Linux support).

Which Internal Modems might not work with Linux

• Software-based Modems (winmodems, linmodems) Only about half have a Linux driver available.
• MWave and DSP Modems might work, but only if you first start Windows/Dos each time you power on your PC.
• Modems with Old Rockwell (RPI) Drivers work but with reduced performance.

MWave and some DSP Modems

Note that there's now a Linux driver for the ACP (Mwave) modem used in IBM Thinkpads 600+. See the mini-HOWTO: ACP-Modem.

While hardware modems used use DSPs (Digital Signal Processors) some of these DSPs are programmed by a driver which must be downloaded from the hard disk to the DSPs memory just before using the modem. Unfortunately, such downloading is normally done by Dos/Windows programs (which doesn't work for Linux). But there has been substantial success in getting some of these modems to work with Linux. For example, there is a Linux driver available to run a Lucent (DSP) modem.

Ordinary modems that work fine with Linux (without needing a driver for the modem) often have a DSP too (and may mention this on the packaging), but the program that runs the DSP is stored inside the modem. These work fine under Linux. An example of a DSP modem that has problems working under Linux is the old IBM's Aptiva MWAVE.

One way to get some DSP modems to work with Linux is to boot from DOS (if you have it on your Linux PC). You first install the driver under DOS (using DOS and not Window drivers). Then start Dos/Windows and start the driver for the modem so as to program the DSP. Then without turning off the computer, start Linux.

One may write a "batch" file (actually a script) to do this. Here is an example but you must modify it to suit your situation.

rem mwave is a batch file supplied by the modem maker
call c:\mww\dll\mwave start
rem loadlin.exe is a DOS program that will boot Linux from DOS (See
rem Config-HOWTO).
c:\linux\loadlin f:\vmlinuz root=/dev/hda3 ro

One may create an icon for the Window's desktop which points to such a batch file and set the icon properties to "Run in MSDOS Mode". Then by clicking on this icon one sets up the modem and goes to Linux. Another possible way to boot Linux from DOS is to press CTRL-ALT-DEL and tell it to reboot (assuming that you have set things up so that you can boot directly into Linux). The modem remains on the same com port (same IO address) that it used under DOS.

The Newcom ifx modem needs a small kernel patch to work correctly since its simulation of a serial port is non-standard. The patch and other info for using this modem with Linux is at http://quinine.pharmacy.ohio-state.edu/~ejolson/linux/newcom.html.
Old Rockwell (RPI) Drivers

Some older Rockwell chips need Rockwell RPI (Rockwell Protocol Interface) drivers for compression and error correction. They can still be used with Linux even though the driver software works only under MS Windows. This is because the MS Windows software (which you don't have) does only compression and error correction. If you are willing to operate the modem without compression and error correction then it's feasible to use it with Linux. To do this you will need to disable RPI by sending the modem (via the initialization string) a "RPI disable" command each time you power on your modem. On my old modem this command was +H0. Not having data compression available makes it slower to get webpages but is just as fast when downloading files that are already compressed.

Read Users' Comments (0)

International Mobile Telecommunications-2000 (IMT-2000), better known as 3G or 3rd Generation, is a family of standards for mobile telecommunication defined by the International Telecommunication Union,which includes GSM EDGE, UMTS, and CDMA 2000 as well as DECTWiMax. Services include wide-area wireless voice telephone, video calls, and wireless data, all in a mobile environment. Compared to 2G and 2,5G services, 3G allows simultaneous use of speech and data services and higher data rates (up to 14.0 Mbit/s on the downlink and 5.8 Mbit/s on the uplink with HSPA+). Thus, 3G networks enable network operators to offer users a wider range of more advanced services while achieving greater network capacity through improved spectral effeciency. and

History

The first pre-commercial 3G network was launched by NTT DoCoMo in Japan branded FOMA, in May 2001 on a pre-release of W-CDMA technology.The first commercial launch of 3G was also by NTT DoCoMo in Japan on 1 October 2001, although it was initially somewhat limited in scope,broader availability was delayed by apparent concerns over reliability.The second network to go commercially live was by SK Telecom in South Korea on the 1xEV-DO technology in January 2002. By May 2002 the second South Korean 3G network was by KT on EV-DO and thus the Koreans were the first to see competition among 3G operators.

The first European pre-commercial network was at the Isle of Man by Manx Telecom, the operator then owned by British Telecom, and the first commercial network in Europe was opened for business by Telenor in December 2001 with no commercial handsets and thus no paying customers. These were both on the W-CDMA technology.

The first commercial United States 3G network was by Monet Mobile Telecom, on CDMA 2000 1x EV-DO technology, but this network provider later shut down operations. The second 3G network operator in the USA was Verizon Wireless in October 2003 also on CDMA2000 1x EV-DO. AT&T Mobility is also a true 3G network, having completed its upgrade of the 3G network to HSUPA.

The first pre-commercial demonstration network in the southern hemisphere was built in Adelaide,South Australia by m.Net Corporation in February 2002 using UMTS on 2100 MHz. This was a demonstration network for the 2002 IT World Congress. The first commercial 3G network was launched by Hutchison Telecommunications branded as Three in March 2003.

In December 2007, 190 3G networks were operating in 40 countries and 154 HDSPA networks were operating in 71 countries, according to the Global Mobile Suppliers Association (GSA). In Asia, Europe, Canada and the USA, telecommunication companies use W-CDMA technology with the support of around 100 terminal designs to operate 3G mobile networks.

In Europe, mass market commercial 3G services were introduced starting in March 2003 by 3 (Part of Hutchison) in the UK and Italy. The European Union Council suggested that the 3G operators should cover 80% of the European national populations by the end of 2005.

Roll-out of 3G networks was delayed in some countries by the enormous costs of additional spectrum licensing fees. In many countries, 3G networks do not use the same radio frequencies as 2G, so mobile operators must build entirely new networks and license entirely new frequencies; an exception is the United States where carriers operate 3G service in the same frequencies as other services. The license fees in some European countries were particulary high, bolstered by government auctions of a limited number of licenses and sealed bid auctions, and initial excitement over 3G's potential. Other delays were due to the expenses of upgrading equipment for the new systems.

By June 2007 the 200 millionth 3G subscriber had been connected. Out of 3 billion mobile phone subscriptions worldwide this is only 6.7%. In the countries where 3G was launched first - Japan and South Korea - 3G penetration is over 70%.In Europe the leading country is Italy with a third of its subscribers migrated to 3G. Other leading countries by 3G migration include UK, Austria, Australia and Singapore at the 20% migration level. A confusing statistic is counting CDMA 2000 1x RTT customers as if they were 3G customers. If using this definition, then the total 3G subscriber base would be 475 million at June 2007 and 15.8% of all subscribers worldwide.

In Canada, Rogers Wireless was the first to implement 3G technology, with HSDPA services in eastern Canada in early 2007. Their subsidiary Fido Solutions offers 3G as well. Because they were the only incumbent carrier (out of 3) with UMTS/HSDPA capability, for 2 years Rogers was the sole provider of the popular Apple iPhone. Realizing they would miss out on roaming revenue from the 2010 Winter Olympics ,Bell and Telus formed a joint venture and rolled out a shared HDSPA network using Nokia Siemens technology. Bell launched their 3G wireless lineup on 4 November 2009, and Telus followed suit a day later on 5 November 2009. With these launches, the popular iPhone is now available on all 3 incumbent national carriers

Mobitel Iraq is the first mobile 3G operator in Iraq. It was launched commercially on February 2007.

China announced in May 2008, that the telecoms sector was re-organized and three 3G networks would be allocated so that the largest mobile operator, China Mobile, would retain its GSM customer base. China Unicom would retain its GSM customer base but relinquish its CDMA2000 customer base, and launch 3G on the globally leading WCDMA (UMTS) standard. The CDMA2000 customers of China Unicom would go to China Telecom, which would then launch 3G on the CDMA 1x EV-DO standard. This meant that China would have all three main cellular technology 3G standards in commercial use. Finally in January 2009, Ministry of industry and Information Technology of China has awarded licenses of all three standards，TD-SCDMA to China Mobile, WCDMA to China Unicom and CDMA2000 to China Telecom. The launch of 3G occurred on 1 October 2009, to coincide with the 60th Anniversary of the Founding of the People's Republic of China.

In November 2008, Turkey has auctioned four IMT 2000/UMTS standard 3G licenses with 45, 40, 35 and 25 MHz top frequencies.Turkcell has won the 45 MHz band with its €358 million offer followed by Vodavone and Avea leasing the 40 and 35 MHz frequencies respectively for 20 years. The 25 MHz top frequency license remains to be auctioned.

The first African use of 3G technology was a 3G videocall made in Johannesburg on the Vodacom in Mauritius in late March 2006, a 3G service was provided by the new company Wana. network in November 2004. The first commercial launch of 3G in Africa was by EMTEL on the W-CDMA standard. In north African Morroco

T-Mobile, a major Telecommunication services provider has recently rolled out a list of over 120 U.S. cities which will be provided with 3G Network coverage in the year 2009.

In 2008, India entered into 3G Mobile arena with the launch of 3G enabled Mobile services by Mahanagar Telephone Nigam Limited (MTNL).MTNL is the first Mobile operator in India to launch 3G services.

Features

ITU has not provided a clear definition of the data rate users can expect from 3G equipment or providers. Thus users sold 3G service may not be able to point to a standard and say that the rates it specifies are not being met. While stating in commentary that "it is expected that IMT-2000 will provide higher transmission rates: a minimum data rate of 2 Mbit/s for stationary or walking users, and 348 kbit/s in a moving vehicle,the ITU does not actually clearly specify minimum or average rates or what modes of the interfaces qualify as 3G, so various rates are sold as 3G intended to meet customers expectations of broadband data.

Security

3G networks offer a greater degree of security than 2G predecessors. By allowing the UE (User Equipment) to authenticate the network it is attaching to, the user can be sure the network is the intended one and not an impersonator. 3G networks use the KASUMI block crypto instead of the older A5/1 stream cipher. However, a number of serious weaknesses in the KASUMI cipher have been identified

In addition to the 3G network infrastructure security, end-to-end security is offered when application frameworks such as IMS are accessed, although this is not strictly a 3G property.

Applications

3G offers a wide range of applications. These applications are mainly made possible due to the enhanced data rates as a result of the 2Mbps bandwidth availabilities. Some of the applications are.

1. Mobile TV - Due to the high data transfer rate being offered due to 3G, TV can be viewed on Mobile Phones. For this have to tie up with a service provider, through which the content can be accessed. Eg.Apalya for BSNL(India).

2. Video Conferencing - It is possible to conduct a video conferencing using the available network, due to the 2 Mbps bandwidth.

3. Tele-medicine - This is an extended feature of video conferencing where a remote person can be given attention by a doctor located at a distant place.

4. Location Based Services - These are some services which can be accessed on the dependence of the service provider. These include weather updates, live road traffic view, and vehicle tracking.

5. Video on Demand - Videos can be viewed on demand from a service provider. For providing this service, the service provider should have collaborations with content providers such as Perceptknorigin (in India). This is again possible due to high buffering speed possible due to the 3G network.

Evolution from 2G

From 2G to 2.5G

The first major step in the evolution to 3G occurred with the introduction of General Packet Radio Service . So the cellular services combined with GPRS became '2.5G.'

GPRS could provide data rates from 56 kbit/s up to 114 kbit/s. It can be used for services such as Wireless Application Protocol (WAP) access, Multimedia Messaging Service (MMS), and for Internet communication services such as email and World Wide Web access. GPRS data transfer is typically charged per megabyte of traffic transferred, while data communication via traditional circuit switching is billed per minute of connection time, independent of whether the user actually is utilizing the capacity or is in an idle state.

From 2.5G to 2.75G (EDGE)

GPRS networks evolved to EDGE networks with the introduction of 8PSK encoding. Enhanced Data rates for GSM Evolution (EDGE), Enhanced GPRS (EGPRS), or IMT Single Carrier (IMT-SC) is a backward-compatible digital mobile phone technology that allows improved data transmission rates, as an extension on top of standard GSM. EDGE was deployed on GSM networks beginning in 2003—initially by Cingular (now AT&T) in the United States.

EDGE is standardized by 3GPP as part of the GSM family, and it is an upgrade that provides a potential three-fold increase in capacity of GSM/GPRS networks. The specification achieves higher data-rates by switching to more sophisticated methods of coding (8PSK), within existing GSM timeslots.

Evolution towards 4G

Both 3GPP and 3GGP2 are currently working on further extensions to 3G standards, named Long Term Evolution and Ultra Mobile Broadband, respectively. Being based on an all Ip Network Infrastructur and using advanced wireless technologies such as MIMO, these specifications already display features characteristic for IMT - Advanced (4G), the successor of 3G. However, falling short of the bandwidth requirements for 4G (which is 1 Gbit/s for stationary and 100 Mbit/s for mobile operation), these standards are classified as 3.9G or Pre 4G.

3GPP plans to meet the 4G goals with LTE Advanced, whereas Qualcomm has halted development of UMB in favour of the LTE family.

On December 14, 2009 Telia Sonera announced in an official press release that "We are very proud to be the first operator in the world to offer our customers 4G services.With the launch of their network, initially they are offering services in Stockholm, Sweden and Oslo, Norway.

Read Users' Comments (0)

Universal Plug and Play (UPnP) is a set of networking protocols promulgated by the UPnP forum. The goals of UPnP are to allow devices to connect seamlessly and to simplify the implementation of networks in the home (data sharing, communications, and entertainment) and in corporate environments for simplified installation of computer components. UPnP achieves this by defining and publishing UPnP device control protocols (DCP) built upon open, Internet-based communication standards.

The term UPnP is derived from plug and play, a technology for dynamically attaching devices directly to a computer, although UPnP is not directly related to the earlier plug-and-play technology. UPnP devices are "plug-and-play" in that when connected to a network they automatically announce their network address and supported device and services types, enabling clients that recognize those types to immediately begin using the device.

Overview

The UPnP architecture allows peer-to-peer networking of PCS, networked home appliance, CEwirelless devices. It is a distributed, open architecture protocol based on established standards such as TCP/IP, UDP, HTTP, XML, and SOAP. devices and

The UPnP architecture supports zero-configuration networking. A UPnP compatible device from any vendor can dynamically join a network, obtain an IP address, announce its name, convey its capabilities upon request, and learn about the presence and capabilities of other devices. DHCPDNS servers are optional and are only used if they are available on the network. Devices can leave the network automatically without leaving any unwanted state information behind. and

UPnP was published as a 73-part international standard, ISO/IEC 29341, in December, 2008.

Other UPnP features include:

Media and device independence

UPnP technology can run on many media that support IP including ethernet, fire wire, IR (IRda), home wiring (G.Hn) and RF (Bluetooth, WiFi). No special device driver support is necessary; common protocols are used instead.

UI Control

UPnP architecture enables devices to present a user interface through a web browser

Operating system and programming language independence

Any operating system and any programming language can be used to build UPnP products. UPnP does not specify or constrain the design of an API for applications running on control points; OS vendors may create APIs that suit their customer's needs.

Programmatic control

UPnP architecture also enables conventional application programmatic control.

Extensibility

Each UPnP product can have device-specific services layered on top of the basic architecture. In addition to combining services defined by UPnP Forum in various ways, vendors can define their own device and service types, and can extend standard devices and services with vendor-defined actions, state variables, data structure elements, and variable values.

Addressing

The foundation for UPnP networking is IP addressing. Each device must have a Dynamic Host Configuration Protocol (DHCP) client and search for a DHCP server when the device is first connected to the network. If no DHCP server is available, that is, the network is unmanaged, the device must assign itself an address. The process by which a UPnP device assigns itself an address is known within the UPnP Device Architecture as "AutoIP". In UPnP Device Architecture Version 1.0, AutoIP is defined within the specification itself; in UPnP Device Architecture Version 1.1, AutoIP references IETF RFC 3927. If during the DHCP transaction, the device obtains a domain name, for example, through a DNS server or via DNS fordwarding, the device should use that name in subsequent network operations; otherwise, the device should use its IP address.

Discovery

Given an IP address, the first step in UPnP networking is Discovery. The UPnP discovery protocol, defined in Section 1 of the UPnP Device Architecture, is known as the Simple Service Discovery Protocol (SSDP). When a device is added to the network, SSDP allows that device to advertise its services to control points on the network. Similarly, when a control point is added to the network, SSDP allows that control point to search for devices of interest on the network. The fundamental exchange in both cases is a discovery message containing a few, essential specifics about the device or one of its services, for example, its type, identifier, and a pointer to more detailed information.

Description

After a control point has discovered a device, the control point still knows very little about the device. For the control point to learn more about the device and its capabilities, or to interact with the device, the control point must retrieve the device's description from the URL provided by the device in the discovery message. The UPnP description for a device is expressed in XML and includes vendor-specific, manufacturer information like the model name and number, serial number, manufacturer name, URLs to vendor-specific web sites, etc. The description also includes a list of any embedded devices or services, as well as URLs for control, eventing, and presentation. For each service, the description includes a list of the commands, or actions, to which the service responds, and parameters, or arguments, for each action; the description for a service also includes a list of variables; these variables model the state of the service at run time, and are described in terms of their data type, range, and event characteristics

Control

Having retrieved a description of the device, the control point can send actions to a device's service. To do this, a control point sends a suitable control message to the control URL for the service (provided in the device description). Control messages are also expressed in XML using the Simple Object Access Protocol (SOAP). Much like function calls, the service returns any action-specific values in response to the control message. The effects of the action, if any, are modeled by changes in the variables that describe the run-time state of the service.

Event notification

The next step in UPnP networking is event notification, or "eventing". The event notification protocol defined in the UPnP Device Architecture is known as GENA, an acronym for "General Event Notification Architecture". A UPnP description for a service includes a list of actions the service responds to and a list of variables that model the state of the service at run time. The service publishes updates when these variables change, and a control point may subscribe to receive this information. The service publishes updates by sending event messages. Event messages contain the names of one or more state variables and the current value of those variables. These messages are also expressed in XML. A special initial event message is sent when a control point first subscribes; this event message contains the names and values for all evented variables and allows the subscriber to initialize its model of the state of the service. To support scenarios with multiple control points, eventing is designed to keep all control points equally informed about the effects of any action. Therefore, all subscribers are sent all event messages, subscribers receive event messages for all "evented" variables that have changed, and event messages are sent no matter why the state variable changed (either in response to a requested action or because the state the service is modeling changed).

Presentation

The final step in UPnP networking is presentation. If a device has a URL for presentation, then the control point can retrieve a page from this URL, load the page into a web browser, and depending on the capabilities of the page, allow a user to control the device and/or view device status. The degree to which each of these can be accomplished depends on the specific capabilities of the presentation page and device.

UPnP AV standards

UPnP AV stands for UPnP Audio and Video. On 12 July 2006 the UPnP Forum announced the release of version 2 of the UPnP Audio and Video specifications (UPnP AV v2), with new MediaServer version 2.0 and MediaRenderer version 2.0 classes. These enhancements are created by adding capabilities to the UPnP AV Media Server and MediaRenderer device classes that allow a higher level of interoperability between MediaServers and MediaRenderers from different manufacturers. Some of the early devices complying with these standards were marketed by Phillips under the Streamium brand name.

The UPnP AV standards have been referenced in specifications published by other organizations including Digital Living Network Alliance Networked Device Interoperability Guidelines,International Electrotechnical Commision IEC 62481-1, and Cable Televison Laboratories Open CAble Home Networking Protocol

UPnP AV components

• UPnP MediaServer DCP - which is the UPnP-server (a 'master' device) that media library information and streams media-data (like audio/video/picture/files) to UPnP-clients on the network.
• UPnP MediaServer ControlPoint - which is the UPnP-client (a 'slave' device) that can auto-detect UPnP-servers on the network to browse and stream media/data-files from them.
• UPnP MediaRenderer DCP - which is a 'slave' device that can render (play) content.
• UPnP RenderingControl DCP - control MediaRenderer settings; volume, brightness, RGB, sharpness, and more).
• UPnP Remote User Interface (RUI) client/server - which sends/receives control-commands between the UPnP-client and UPnP-server over network, (like record, schedule, play, pause, stop, etc.).
  • Web4CE (CEA 2014) for UPnP Remote UI- CEA-2014 standard designed by Consumer Electronic Association's R7 Home Network Committee. Web-based protocol and framework for Remote User Interface on UPnP networks and the internet interface (display and control options) as a web page to display on any other device connected to the home network. That means that you can control a home networking browser-based communications method for CE Devices on a UPnP home network using ethernet and a special version of HTML called CE-HTML. (Web4CE). This standard allows a UPnP-capable home network device to provide its device through any
• QoS (Quality of Service) - is an important (but not mandatory) service function for use with UPnP AV (Audio and Video). QoS(Quality of Service) refers to control mechanisms that can provide different priority to different users or data flows, or guarantee a certain level of performance to a data flow in accordance with requests from the application program. Since UPnP AV is mostly to deliver streaming media that is often near-real time or real-time audio/video data which it is critical to be delivered within a specific time or the stream is interrupted.Quality of Services guarantees are especially important if the network capacity is limited, for example public networks, like the internet.
• Quality of Services for UPnP consist of Sink Device (client-side/front-end) and Source Device (server-side/back-end) service functions. With classes such as; Traffic Class that indicates the kind of traffic in the traffic stream, (for example, audio or video). Traffic Identifier (TID) which identifies data packets as belonging to a unique traffic stream. Traffic Specification (TSPEC) which contains a set of parameters that define the characteristics of the traffic stream, (for example operating requirement and scheduling). Traffic Stream (TS) which is a unidirectional flow of data that originates at a source device and terminates at one or more sink device(s).

NAT traversal

One solution for Network Address Transmission traversal, called the Internet Gateway Protocol, is implemented via UPnP. Many routers and firewalls expose themselves as Internet Gateway Devices, allowing any local UPnP controller to perform a variety of actions, including retrieving the external IP address of the device, enumerate existing port mappings, and adding and removing port mappings. By adding a port mapping, a UPnP controller behind the IGD can enable traversal of the IGD from an external address to an internal client.

Problems with UPnP

Lack of Default Authentication

The UPnP protocol, as default, does not implement any authentication, so UPnP device implementations must implement their own authentication mechanisms, or implement the Device Security Service.There also exists a non-standard solution called UPnP-UP (Universal Plug and Play - User Profile) which proposes an extension to allow user authentication and authorization mechanisms for UPnP devices and applications.

Unfortunately, many UPnP device implementations lack authentication mechanisms, and by default assume local systems and their users are completely trustworthy.

Most notably, routers and firewalls running the UPnP IGD protocol are vulnerable to attack since the framers of the IGD implementation omitted a standard authentication method. For example, Adobe Flash programs are capable of generating a specific type of HTTP request. This allows a router implementing the UPnP IGD protocol to be controlled by a malicious web site when someone with a UPnP-enabled router simply visits that web site.The following changes can be made silently by code embedded in an Adobe Flash object hosted on a malicious website

• Port fordward internal services (ports) to the router external facing side (i.e. expose computers behind a firewall to the Internet).
• Port fordward the router's web administration interface to the external facing side.
• Port forwarding to any external server located on the Internet, effectively allowing an attacker to attack an Internet host via the router, while hiding their IP address.
• Change DNS server settings so that when victims believe they are visiting a particular site (such as an on-line bank), they are redirected to a malicious website instead.
• Change the DNS server settings so that when a victim receives any software updates (from a source that isn't properly verified via some other mechanism, such as a checking a digital certificate has been signed by a trusted source), they download malicious code instead.
• Change administrative credentials to the router/firewall.
• Change PPP settings.
• Change IP settings for all interfaces.
• Change WiFi settings.
• Terminate connections.

This only applies to the " firewall-hole-punching"-feature of UPnP ; it does not apply when the IGD does not support UPnP or UPnP has been disabled on the IGD. Also, not all routers can have such things as DNS server settings altered by UPnP because much of the specification (including LAN Host Configuration) is optional for UPnP enabled routers

Other Issues

• UPnP uses HTTP over UDP (known as HTTPU and HTTPMU for unicast and multicast), even though this is not standardized and is specified only in an Internet-Draft that expired in 2001.
• UPnP does not have a lightweight authentication protocol, while the available security protocols are complex. As a result, some UPnP devices ship with UPnP turned off by default as a security measure.

Future developments

UPnP continues to be actively developed. In fall 2008, the UPnP forum ratified the successor to UPnP 1.0, UPnP 1.1.

The standard DPWS was a candidate successor for UPnP, but UPnP 1.1 was selected by the forum.

UPnP InternetGatewaydevice's WANIPConnection service do have competitive solution known as NAT-PMP, is an IETF draft introduced by Apple inc. in 2005. However, NAT-PMP is focused only in NAT traversal. UPnP InternetGatewayDevice is currently being evolved to version 2 which preliminary content can be found from

Read Users' Comments (0)

In computing, plug and play is a term used to describe the characteristic of a computer bust, or device specification, which facilitates the discovery of a hardware component in a system, without the need for physical device configuration, or user intervention in resolving resource conflicts.

History of Device Configuration

In the beginnings of computing technology, the hardware logic was just a collection of building blocks, and the relationships between them had to be completely redesigned to accommodate different calculating operations. These changes were usually done by connecting some wires between modules and disconnecting others. The very earliest of mechanical computing devices such as the IBM punchcard accounting, tabulating and interpreting machines were programmed entirely in this manner, by the use of a quick-swap control panel wired to route signals between configuration sockets.

As general purpose computing devices developed, these connections and disconnections were instead used to specify locations in the system address spacecentral processing unit. If two or more of the same device were installed in one computer, it would be necessary to assign the second device to a separate, non-overlapping region of the system address space so that both could be accessible at the same time. where an expansion device should appear, in order for the device to be accessible by the

Some early microcomputing devices such as the Apple II required the end-user to physically cut some wires and solder others together to make these configuration changes. The changes were intended to be mostly permanent for the life of the hardware.

Over time the need developed for more frequent changes and for easier changes to be made by unskilled computer users. Rather than cutting and soldering connections, the header and jumper was developed. The header consists of two or more vertical pins arranged in an evenly-spaced grid. The jumper is a small conductive strip of metal clipped across the header pins. The conductive jumper strip is commonly encased in a plastic shell to help prevent electrical shorting between adjacent jumpers.

Jumpers have the unfortunate property of being easy to misplace if not needed, and are difficult to grasp in order to remove them from headers. To help make these changes easier, the DIP switch DIP switch was developed, also known as a dual in-line package switch. The DIP switch has small either rocker or sliding switches enclosed in a plastic shell and usually numbered for easy reference. DIP switches usually come in units of four or eight switches; longer rows of switches can be made by combining two or more units. DIP switches are particularly useful where a long string of jumpers would be closely packed together or where four or more jumpers would be used in combination to configure one device function. DIP switches also have a particular advantage for configuration settings which are likely to be changed more frequently than once every few years. (Because of the inconvenience of setting them, jumpers are typically used for settings that are not expected to need to be changed unless the device is removed from one computer and installed in another, an infrequent occurrence for internal devices in consumer desktop PCs.)

As computing devices spread further out into the general population, there was ever greater pressure developing to automate this configuration process. One of the first major industry efforts towards self-configuration was done by IBM with the creation of their Personal System/2 line of computers using the micro channel architecture (MCA). This took a giant leap forward, as expansion devices had absolutely no jumpers or DIP switches.

However, IBM's first attempt at self-configuration had a few major problems. In an attempt to simplify device setup, every piece of hardware was issued with a disk containing a special file used to auto-configure the hardware to work with the computer. (If the device required one or more drivers for specific operating systems, they were usually included on the same disk.) Without this disk the hardware would be completely useless and the computer would not boot at all until the unconfigured device was removed.

MCA also suffered for being a proprietary technology. Unlike their previous PC bus design, the AT bus, IBM did not publicly release specifications for MCA and actively pursued patents to block third parties from selling unlicensed implementations of it, and the developing PC Clone market did not want to pay royalties to IBM in order to use this new technology. The PC clone makers instead developed EISA, an extension to the existing old non-PnP AT bus standard, which they also further standardized and renamed ISA (to avoid IBM's "AT" trademark). With few vendors other than IBM supporting it with computers or cards, MCA eventually failed in the marketplace. Most vendors of PC-compatibles stayed largely with ISA and manual configuration, while EISA offered the same type of auto-configuration featured in MCA. (EISA cards required a configuration file as well.)

In time, many ISA cards incorporated, through proprietary and varied techniques, hardware to self-configure or to provide for software configuration; often the card came with a configuration program on disk that could automatically set the software-configurable (but not itself self-configuring) hardware. Some cards had both jumpers and software-configuration, with some settings controlled by each; this compromise reduced the number of jumpers that had to be set, while avoiding great expense for certain settings, e.g. nonvolatile registers for a base address setting. The problems of required jumpers continued on but slowly diminished as more and more devices, both ISA and other types, included extra self-configuration hardware. However, these efforts still did not solve the problem of making sure the end-user has the appropriate software driver for the hardware.

Read Users' Comments (0)

The Internet Protocol Suite (commonly known as TCP/IP) is the set of communications protocols Internet and other similar networks. It is named from two of the most important protocols in it: the Transmission Control Protocol (TCP) and the Internet Protocol (IP), which were the first two networking protocols defined in this standard. Today's IP networking represents a synthesis of several developments that began to evolve in the 1960s and 1970s, namely the Internet and LANs, which emerged in the mid- to late-1980s, together with the advent of the World Wide Web in the early 1990s. used for the

The Internet Protocol Suite, like many protocol suites, may be viewed as a set of layers. Each layer solves a set of problems involving the transmission of data, and provides a well-defined service to the upper layer protocols based on using services from some lower layers. Upper layers are logically closer to the user and deal with more abstract data, relying on lower layer protocol to translate data into forms that can eventually be physically transmitted.

The TCP/IP model consists of four layers.From lowest to highest, these are the link layer, the internet layer, the transport layer, and the application layer

History

The Internet Protocol Suite resulted from research and development conducted by the Defense Advanced Research Projects Agency (DARPA) in the early 1970s. After initiating the pioneering APARNET in 1969, DARPA started work on a number of other data transmission technologies. In 1972, Robert E. Kahn joined the DARPA Information Processing Technology Office, where he worked on both satellite packet networks and ground-based radio packet networks, and recognized the value of being able to communicate across both. In the spring of 1973, Vinton Cerf, the developer of the existing ARPANET network control program (NCP) protocol, joined Kahn to work on open-architecture interconnection models with the goal of designing the next protocol generation for the ARPANET.

By the summer of 1973, Kahn and Cerf had worked out a fundamental reformulation, where the differences between network protocols were hidden by using a common internetwork protocol, and, instead of the network being responsible for reliability, as in the ARPANET, the hosts became responsible. Cerf credits Hubert Zimmerman and Louis Pouzin, designer of the CYCLADES network, with important influences on this design.

The design of the network included the recognition that it should provide only the functions of efficiently transmitting and routing traffic between end nodes and that all other intelligence should be located at the edge of the network, in the end nodes. Using a simple design, it became possible to connect almost any network to the ARPANET, irrespective of their local characteristics, thereby solving Kahn's initial problem. One popular saying has it that TCP/IP, the eventual product of Cerf and Kahn's work, will run over "two tin cans and a string."

A computer called a router is provided with an interface to each network, and forwards packets back and forth between them. Requirements for routers are defined in (Request for Comments 1812).

The idea was worked out in more detailed form by Cerf's networking research group at Stanford in the 1973–74 period, resulting in the first TCP specification . (The early networking work at Xerox PARC, which produced the PARC Universal Packet protocol suite, much of which existed around the same period of time, was also a significant technical influence; people moved between the two.)

DARPA then contracted with BBN Technologies,Stanford University,and the University College London to develop operational versions of the protocol on different hardware platforms. Four versions were developed: TCP v1, TCP v2, a split into TCP v3 and IP v3 in the spring of 1978, and then stability with TCP/IP v4 — the standard protocol still in use on the Internet today.

In 1975, a two-network TCP/IP communications test was performed between Stanford and University College London (UCL). In November, 1977, a three-network TCP/IP test was conducted between sites in the US, UK, and Norway. Several other TCP/IP prototypes were developed at multiple research centres between 1978 and 1983. The migration of the ARPANET to TCP/IP was officially completed on January 1, 1983, when the new protocols were permanently activated.

In March 1982, the US Department of Defense declared TCP/IP as the standard for all military computer networking. In 1985, the Internet Architecture Board held a three day workshop on TCP/IP for the computer industry, attended by 250 vendor representatives, promoting the protocol and leading to its increasing commercial use.

Layers in the Internet Protocol Suite

The concept of layers

The TCP/IP suite uses encapsulation to provide abstraction of protocols and services. Such encapsulation usually is aligned with the division of the protocol suite into layers of general functionality. In general, an application (the highest level of the model) uses a set of protocols to send its data down the layers, being further encapsulated at each level.

This may be illustrated by an example network scenario, in which two Internet host computers communicate across local network boundaries constituted by their internetworking gateways (routers).

TCP/IP stack operating on two hosts connected via two routers and the corresponding layers used at each hop

Encapsulation of application data descending through the protocol stack.

The functional groups of protocols and methods are the application layer, the transport layer, the internet layer, and the link layer. It should be noted that this model was not intended to be a rigid reference model into which new protocols have to fit in order to be accepted as a standard.

Different authors have interpreted the RFCs differently regarding the question whether the Link Layer (and the TCP/IP model) covers physical layer issues, or if a hardware layer is assumed below the Link Layer. Some authors have tried to use other names for the Link Layer, such as network interface layer, in view to avoid confusion with the data link layer of the seven layer OSI model. Others have attempted to map the Internet Protocol model onto the OSI Model. The mapping often results in a model with five layers where the Link Layer is split into a Data Link Layer on top of a Physical Layer. In literature with a bottom-up approach to Internet communication, in which hardware issues are emphasized, those are often discussed in terms of Physical Layer and Data Link Layer.

The Internet Layer is usually directly mapped into the OSI Model's network layer, a more general concept of network functionality. The Transport Layer of the TCP/IP model, sometimes also described as the host-to-host layer, is mapped to OSI Layer 4 (Transport Layer), sometimes also including aspects of OSI Layer 5 functionality. OSI's application layer,presentation layer, and the remaining functionality of the Session Layer are collapsed into TCP/IP's Application Layer. The argument is that these OSI layers do usually not exist as separate processes and protocols in Internet applications.

However, the Internet protocol stack has never been altered by the Internet Engineering Task Force from the four layers defined in RFC 1122. The IETF makes no effort to follow the OSI model although RFCs sometimes refer to it. The IETF has repeatedly stated that Internet protocol and architecture development is not intended to be OSI-compliant.

R RFC 2439, addressing Internet architecture, contains a section entitled: "Layering Considered Harmful".

Implementations

Most operating systems in use today, including all consumer-targeted systems, include a TCP/IP implementation.

Unique implementations include Lightweight TCP/IP, an open source stack designed for embedded systems and KA9Q NOS, a stack and associated protocols for amateur packet raiopersonal computer connected via serial lines. systems and

Read Users' Comments (0)