Daemon News 199901 : A Remote Chance

A Remote Chance

Copyright © 1998 Wes Peters

An opportunity seized

Recently the engineer I share an office with had her main development machine upgraded to a laptop PC. She is a Java developer, and the laptop helps her work in our remote office, at home, and at the company's main facility. In order to work from home, she had the company IT department configure her laptop for PPP access, through one of the national internet service providers.

She struggled along with this, achieving terrible throughput and frequent line drops, for about two weeks before she asked me for help. I asked what she planned to do with her old desktop machine, a Pentium Pro 200, and she said I could have it if I could make her PPP link faster.

People really should avoid tempting me like that.

She wanted to keep the original NT installation, which occupied a 2 gigabyte partition on her 4 gigabtye ultra wide SCSI drive. I helped her move files she wanted to keep from the NT D: drive to the C: drive, then deleted the second DOS partition and popped in my FreeBSD 2.2.6 CD. I had recently upgraded to 2.2.7 at home, and had brought the 2.2.6 disks to work, where they seemed to multiply onto another system every couple of weeks.

In no time at all, we had FreeBSD 2.2.6 running on the PPro. Since this was to be a server machine, I eschewed running XFree86, but installed the libraries and applications in case I need to run a client (or Emacs) displaying on my own workstation. This system already had a 3Com Fast Etherlink XL (3c905B) card in it, so network connectivity was ready to roll.

Perusing the Handbook on my FreeBSD workstation across the office, I decided to use mgetty to handle the incoming PPP connection.

Poking around the office, I managed to scrounge up two external USRobotics Sportster 33.6 modems. (Yes, we're doing our fair share to keep 3Com in business, even though they are a competitor.) I installed and configured mgetty, plugged in the modems, punched the phone lines into the patch panel in our lab, and crossed my fingers. Retreating to my trusty laptop, the only win95 machine I have at work, I created a dial-up networking entry with our new phone number and clicked OK.

Nada.

Reviewing the logs, I learned that mgetty was attempting to start a login with a username of something like

{{{{{'{{{{{a{{{{~{{{

Thinking this looked awfully familiar, I decided it was time to call for...

Help!

Springing once again to my trusty FreeBSD workstation, I fired off an email asking for help to freebsd-questions and a networking list I am a member of. Within the hour, I had the answer from freebsd-questions. I had configured mgetty to use the AutoPPP feature, but AutoPPP is not compiled into the code by default. Disbelieving this silliness, I took matters into my own hands:

$ which mgetty
/usr/local/bin/mgetty
$ strings /usr/local/bin/mgetty | grep AutoPPP
$

Well now, that's a small problem. Following the advice of several of the messages from freebsd-questions, I compiled mgetty from the port and added the define to turn on this support.

$ su 
# cd /usr/ports/comms/mgetty+sendfax
# make 
make output elided...
# cd work/mgetty-1.11
# vi Makefile
added -DAUTO_PPP to CFLAGS...
# make
# cd ../..
# make install

Then I double-checked the new executable, to make sure I had not shot myself in the foot.

$ strings /usr/local/bin/mgetty | grep AutoPPP
/AutoPPP/
$

OK, ready to test again...

Back at the laptop, I clicked in the OK button on the dial-up networking dialog again. Watching the mgetty log file, I waited for the modems to answer, and...

Same thing. What?!?!?

Oh wait, it was still running the old mgetty. Try it one more time...

Voila!

Success! Within a minute, I was logged in and pinging away. Now, to enable the Microsoft extensions so remote users will get their DNS server, etc. Consulting the handbook, I added an

accept
dns

line to my configuration, and punched the dial button on my trusty laptop again.

No dice. PPP rejected the configuration line and kicked me off. I checked, and this system (2.2.6, remember?) had a pretty old version of PPP, too. Hopping back to my workstation, I surfed my way over to Brian Somer's PPP pages and downloaded the latest version of PPP. It took moments to untar, compile, and install the new version of PPP. Trying once again from my laptop, I got the DNS server automagically.

After trying again several times, I was convinced this was working well enough to announce to the company. This service has worked reliably for a month now. One user had a slight problem with DNS services, which turned out to be a win95 configuration problem. Everything else worked flawlessly, until...

Save it for a rainy day

My office partner called me on the phone one rainy Friday morning.

``I can't work this way,'' she said. ``I can't keep the connection up for more than 15 minutes at a time. What's wrong?'' Looking out my office window at the row of poplars blowing around in the wind, the answer was obvious. She lives in a suburb 10 miles north of the city, an area that received phone service in the early 1930s. Much of the wiring in her town still dates to the 30s, too. The phone wires, strung on above-ground poles, were dancing in the wind and dropping her connection.

I once again informed her of her poor choice of homesite, a topic we had discussed before. (I grew up in a town not far from her, and fought and bled many times on the soccer fields of her town in my youth.) After informing her the problem was the inferior phone equipment in her beloved little town, I told her a digital connection would probably be more reliable and certainly faster.

Did you say digital?

Yup, digital. Living in the territory served by USWest, or USWorst as it is often known here, is not generally something to be proud of. If you're into digital communications, however, USWest is rolling out DSL services faster than anyone else around. Not, unfortunately, to her little town. So she opted for ISDN. At US $76 per month, the tariffs are reasonable, and certainly cheaper than the gas to drive her Suburban to work every day.

So, a few days ago, I found myself in possession of two new 3Com (again!) Impact IQ terminal adapters, a USR/Megahertz PCCard ISDN adapter, various assorted cables, and no high-speed serial card. The serial card with dual 16c650 UARTs we had ordered, to plug the Impact IQs into the FreeBSD server, was back ordered.

Reminding myself not to panic, I took one of the modems off-line and plugged in one of the IQs on the unoccupied serial port. We had already configured the IQ using the clever win95 program SpidWizard included in the package. I killed and restarted mgetty, so it would immediately try to probe the IQ.

Nothing. mgetty began to loop, attempting to talk to the TA and failing about once a minute.

Back to the Net

Not knowing what to do next, I returned to email. Again soliciting help in freebsd-questions, I received several responses in the next couple of hours. Two contained some pretty detailed instructions on how to configure the Impact IQ. Since it was getting late, I decided to address the problem again the next day. I gave the ISDN numbers to a fellow engineer in the office who uses Linux and has ISDN at home.

That night, he played around with the Impact IQ settings a bit, and was able to dial in from his Linux system. The next day I came into the office, plugged the other Impact IQ into my laptop, configured it, and had PPP working in 20 minutes. Both B channels came up, and a quick speed test (ftp'ing a 1.2 megabyte file) showed a throughput of 11 K bytes/sec. Not bad, considering this was running at 115,200 bps on a 75 MHz 486 laptop running win95.

Happy as digital clams

My office partner is now happily working from home, using the second IQ. We haven't gotten the Megahertz PCCard to work yet, in my laptop or hers, and will probably return it for an Eicon PCCard.

As soon as the new, 16c650-based serial card arrives, we'll configure it into the FreeBSD system, put both of the TAs on it, and return the two modems to service.

In the four weeks this server has been up, we've added NIS (yellow pages directory) service, amd (automount) support, Samba services for PCs, and a printer queue for a previously unused laser printer. Next week, just in time for Christmas, I'll be adding a cache server for Usenet news. We're shopping for a CD writer for long-term backups and off-line storage. And we've discussed using one of the IQs as a backup for when our fractional T1 line to the home office fails, which happens all too often.

The response to this system has been amazing. My coworkers in this office are experienced network engineers who are familiar with and like UNIX. We even number amongst us the former CTO of a major Linux distributor. All except those familiar with FreeBSD and Linux are amazed at the flexibility and reliability of this system.

Everyone involved has been pleased with the level and expertise in the replies we've gotten from freebsd-questions. They're starting to realize that free software really does have better support than commercial products.

One young Linux programmer has stepped up to be the backup root for this machine, and wants me to help him upgrade the machine to -STABLE. He wants to learn more about how the FreeBSD distribution mechanisms work and how they compare to Linux development.

I keep telling him ``Never underestimate the power of the Lite side of the Source, Luke.''

Bibliography

The Awfulhak PPP pages, written by the maintainer of user-mode PPP, Brian Somers. This version of PPP now compiles and runs on both FreeBSD and OpenBSD.

FreeBSD Handbook section 15.1.5.3, Receiving incoming calls with PPP. The place to start building your own remote access server.

Mailing lists. freebsd-questions@freebsd.org is, as always, the best, fastest way to get your questions answered. For advice about equipment to buy, etc., you may want to ask on freebsd-isp@freebsd.org as well; they're chock full of knowledge about communications equipment.

	A Remote Chance Copyright © 1998 Wes Peters An opportunity seized Recently the engineer I share an office with had her main development machine upgraded to a laptop PC. She is a Java developer, and the laptop helps her work in our remote office, at home, and at the company's main facility. In order to work from home, she had the company IT department configure her laptop for PPP access, through one of the national internet service providers. She struggled along with this, achieving terrible throughput and frequent line drops, for about two weeks before she asked me for help. I asked what she planned to do with her old desktop machine, a Pentium Pro 200, and she said I could have it if I could make her PPP link faster. People really should avoid tempting me like that. She wanted to keep the original NT installation, which occupied a 2 gigabyte partition on her 4 gigabtye ultra wide SCSI drive. I helped her move files she wanted to keep from the NT D: drive to the C: drive, then deleted the second DOS partition and popped in my FreeBSD 2.2.6 CD. I had recently upgraded to 2.2.7 at home, and had brought the 2.2.6 disks to work, where they seemed to multiply onto another system every couple of weeks. In no time at all, we had FreeBSD 2.2.6 running on the PPro. Since this was to be a server machine, I eschewed running XFree86, but installed the libraries and applications in case I need to run a client (or Emacs) displaying on my own workstation. This system already had a 3Com Fast Etherlink XL (3c905B) card in it, so network connectivity was ready to roll. Perusing the Handbook on my FreeBSD workstation across the office, I decided to use `mgetty` to handle the incoming PPP connection. Poking around the office, I managed to scrounge up two external USRobotics Sportster 33.6 modems. (Yes, we're doing our fair share to keep 3Com in business, even though they are a competitor.) I installed and configured `mgetty`, plugged in the modems, punched the phone lines into the patch panel in our lab, and crossed my fingers. Retreating to my trusty laptop, the only win95 machine I have at work, I created a dial-up networking entry with our new phone number and clicked OK. Nada. Reviewing the logs, I learned that `mgetty` was attempting to start a login with a username of something like `{{{{{'{{{{{a{{{{~{{{` Thinking this looked awfully familiar, I decided it was time to call for... Help! Springing once again to my trusty FreeBSD workstation, I fired off an email asking for help to freebsd-questions and a networking list I am a member of. Within the hour, I had the answer from freebsd-questions. I had configured `mgetty` to use the AutoPPP feature, but AutoPPP is not compiled into the code by default. Disbelieving this silliness, I took matters into my own hands: $ which mgetty /usr/local/bin/mgetty $ strings /usr/local/bin/mgetty \| grep AutoPPP $ Well now, that's a small problem. Following the advice of several of the messages from freebsd-questions, I compiled `mgetty` from the port and added the define to turn on this support. $ su # cd /usr/ports/comms/mgetty+sendfax # make make output elided... # cd work/mgetty-1.11 # vi Makefile added -DAUTO_PPP to CFLAGS... # make # cd ../.. # make install Then I double-checked the new executable, to make sure I had not shot myself in the foot. $ strings /usr/local/bin/mgetty \| grep AutoPPP /AutoPPP/ $ OK, ready to test again... Back at the laptop, I clicked in the OK button on the dial-up networking dialog again. Watching the `mgetty` log file, I waited for the modems to answer, and... Same thing. What?!?!? Oh wait, it was still running the old `mgetty`. Try it one more time... Voila! Success! Within a minute, I was logged in and pinging away. Now, to enable the Microsoft extensions so remote users will get their DNS server, etc. Consulting the handbook, I added an `accept dns` line to my configuration, and punched the dial button on my trusty laptop again. No dice. PPP rejected the configuration line and kicked me off. I checked, and this system (2.2.6, remember?) had a pretty old version of PPP, too. Hopping back to my workstation, I surfed my way over to Brian Somer's PPP pages and downloaded the latest version of PPP. It took moments to untar, compile, and install the new version of PPP. Trying once again from my laptop, I got the DNS server automagically. After trying again several times, I was convinced this was working well enough to announce to the company. This service has worked reliably for a month now. One user had a slight problem with DNS services, which turned out to be a win95 configuration problem. Everything else worked flawlessly, until... Save it for a rainy day My office partner called me on the phone one rainy Friday morning. ``I can't work this way,'' she said. ``I can't keep the connection up for more than 15 minutes at a time. What's wrong?'' Looking out my office window at the row of poplars blowing around in the wind, the answer was obvious. She lives in a suburb 10 miles north of the city, an area that received phone service in the early 1930s. Much of the wiring in her town still dates to the 30s, too. The phone wires, strung on above-ground poles, were dancing in the wind and dropping her connection. I once again informed her of her poor choice of homesite, a topic we had discussed before. (I grew up in a town not far from her, and fought and bled many times on the soccer fields of her town in my youth.) After informing her the problem was the inferior phone equipment in her beloved little town, I told her a digital connection would probably be more reliable and certainly faster. Did you say digital? Yup, digital. Living in the territory served by USWest, or USWorst as it is often known here, is not generally something to be proud of. If you're into digital communications, however, USWest is rolling out DSL services faster than anyone else around. Not, unfortunately, to her little town. So she opted for ISDN. At US $76 per month, the tariffs are reasonable, and certainly cheaper than the gas to drive her Suburban to work every day. So, a few days ago, I found myself in possession of two new 3Com (again!) Impact IQ terminal adapters, a USR/Megahertz PCCard ISDN adapter, various assorted cables, and no high-speed serial card. The serial card with dual 16c650 UARTs we had ordered, to plug the Impact IQs into the FreeBSD server, was back ordered. Reminding myself not to panic, I took one of the modems off-line and plugged in one of the IQs on the unoccupied serial port. We had already configured the IQ using the clever win95 program `SpidWizard` included in the package. I killed and restarted `mgetty`, so it would immediately try to probe the IQ. Nothing. `mgetty` began to loop, attempting to talk to the TA and failing about once a minute. Back to the Net Not knowing what to do next, I returned to email. Again soliciting help in freebsd-questions, I received several responses in the next couple of hours. Two contained some pretty detailed instructions on how to configure the Impact IQ. Since it was getting late, I decided to address the problem again the next day. I gave the ISDN numbers to a fellow engineer in the office who uses Linux and has ISDN at home. That night, he played around with the Impact IQ settings a bit, and was able to dial in from his Linux system. The next day I came into the office, plugged the other Impact IQ into my laptop, configured it, and had PPP working in 20 minutes. Both B channels came up, and a quick speed test (ftp'ing a 1.2 megabyte file) showed a throughput of 11 K bytes/sec. Not bad, considering this was running at 115,200 bps on a 75 MHz 486 laptop running win95. Happy as digital clams My office partner is now happily working from home, using the second IQ. We haven't gotten the Megahertz PCCard to work yet, in my laptop or hers, and will probably return it for an Eicon PCCard. As soon as the new, 16c650-based serial card arrives, we'll configure it into the FreeBSD system, put both of the TAs on it, and return the two modems to service. In the four weeks this server has been up, we've added `NIS` (yellow pages directory) service, `amd` (automount) support, `Samba` services for PCs, and a printer queue for a previously unused laser printer. Next week, just in time for Christmas, I'll be adding a cache server for Usenet news. We're shopping for a CD writer for long-term backups and off-line storage. And we've discussed using one of the IQs as a backup for when our fractional T1 line to the home office fails, which happens all too often. The response to this system has been amazing. My coworkers in this office are experienced network engineers who are familiar with and like UNIX. We even number amongst us the former CTO of a major Linux distributor. All except those familiar with FreeBSD and Linux are amazed at the flexibility and reliability of this system. Everyone involved has been pleased with the level and expertise in the replies we've gotten from freebsd-questions. They're starting to realize that free software really does have better support than commercial products. One young Linux programmer has stepped up to be the backup root for this machine, and wants me to help him upgrade the machine to -STABLE. He wants to learn more about how the FreeBSD distribution mechanisms work and how they compare to Linux development. I keep telling him ``Never underestimate the power of the Lite side of the Source, Luke.'' Bibliography The Awfulhak PPP pages, written by the maintainer of user-mode PPP, Brian Somers. This version of PPP now compiles and runs on both FreeBSD and OpenBSD. FreeBSD Handbook section 15.1.5.3, Receiving incoming calls with PPP. The place to start building your own remote access server. Mailing lists. freebsd-questions@freebsd.org is, as always, the best, fastest way to get your questions answered. For advice about equipment to buy, etc., you may want to ask on freebsd-isp@freebsd.org as well; they're chock full of knowledge about communications equipment. Wes Peters wes@softweyr.com