Article:		Failing Miserably, If Not Inventively
Subject:		Look elsewhere
Date:		2004-02-06 22:57:18
From:		tlaurenzo
From your descriptions of your "routine", I have to say that I cannot understand it. Your descriptions of dial-up also confound me (I'm on a T3 9 hours a day and can't stand dial-up at home). However, to each his own, I guess. It is discouraging, though, that some minor feature changes in an otherwise very much improved OS were met with such a flame (with top billing on oreillynet) simply because they broke your extremely fragile routine. Ok. So there's my flame back. I really think you are looking in the wrong place here. The OSX dial-up infrastructure is really just our friend pppd and related programs. From what I remember, Apple patched pppd to accept an extra parameter which allows a user-defined plugin to be loaded for event notification. The Apple connect scripts pass in a system-defined plugin that makes sure the UI is always in sync (ie. displaying in the menu bar, keeping network preferences "live", etc). You can inspect these options by reading the pppd man page closely or passing the correct options to "ps" to get a look at what the Apple connect scripts are doing. I suggest that you look past the Apple GUI scripting you are doing and seek a more "Unixy" solution. I solved this exact same problem on Linux 4 years ago using a combination of pppd, diald and chat. It was a bit of a pain back then, but I know that things are somewhat easier now, especially if you can forgo the "automatic connection" and just force a connection manually, this is practically just a couple lines of script. Still I know that tautomatic connection is possible from a pure unix tools aproach (in fact I wouldn't be surprised if this is exactly how Apple implements it under the covers).

Showing messages 1 through 1 of 1.

• Look elsewhere
  2004-02-07 07:56:48  Kevin Hemenway [Reply | View]
  
  
  What don't you understand, or consider fragile, about the "routine"? That's a very small part of the automation I use, which all worked perfectly under Jaguar. Nor was it a flame toward Apple: I reported it as a bug in RADAR before writing the article, waited for their response before finishing the article ("it's been reported before, we're still looking into it"), and talked to a bunch of other people concerning possible fixes before revising said article. It's "top-billing" solely because it's the latest published article. Monday, they'll be a new "top-billing".
  
  Concerning pppd, I didn't know about the plugin architecture (save for the /etc/pppd directory). You think that the "if the user has manually disconnected, no longer dial automatically" is a simple turn-off-able flag in a ppd script? My impression was that the decision was made somewhere in a GUI library, which just stopped pppd from being called ever again (which can be confirmed by disconnected manually, then attempting to have an autoconnect occur, and NOT seeing pppd's fleeting absence in the logs or the ps).
  
  As for dialing purely with the pppd daemon, I've tried that. Capturing the output of the pppd with ps, as well as some CCLEngine script didn't prove very helpful: running the exact command shown in the ps didn't work, nor did passing STDIN or command line flags to the "real" pppd from my "fake" version. As the final paragraphs attest to, it's my ignorance of pppd that heightened my failure.