[conspire] Breezy Badger /Netzero

[Daniel Gimpelevich]

On Fri, 16 Dec 2005 15:55:39 -0800, Rick Moen wrote:

> John, I might be able to help you, but this is going to come along with 
> what'll come across as a complaint (it's not!) about some of the quirks
> of language in your posts.  I'm going to make some suggestions about 
> your approach to seeking help in the future, solely with the aim of
> helping you more efficiently get assistance in the future, OK?  Please 
> don't take any of this as personal criticism.
> 
> Please don't get frustrated:  We'll help you on your problem!  I'd just
> also like to help prospectively with debugging tips.

This is perfectly true, but I am in possession of some of the information
that he left out, because I know what I did to his system and how it
behaved after that.
 
> Quoting John Andrews (jla1200 at netzero.net):
> 
>> I did ln -s tty0 /dev/modem but that didn't work.
>              ^^^^
> 
> First and foremost, your problem may be as simple as specifying the
> right device name.  /dev/tty0 is not a serial port; it's a _terminal_
> device.  You probably meant "/dev/ttyS0", which is the machine's first
> serial port, the one that in MS-DOS is called COM1.
> 
> But I'm betting that you wrote your help request some while _after_ you
> did your efforts to make things work, rather than contemporaneously with
> them, right?  Your descriptions have the rather fuzzy feeling about them
> that is characteristic of a write-up someone created from vague memory
> (which is bad, as the inevitably inaccuracies prevent effective help) as
> opposed to using diligent notes or copying and pasting directly from
> your diagnostic attempts.
> 
> That is, you might have actually done this:
> 
> $ su -
> # cd /dev
> # ln -s ttyS0 modem
> # exit
> $
> 
> ...but then (maybe) you didn't accurately remember what you typed, after
> the fact.  The _exact_ contents of what you did are important, which is
> why it wastes a lot of time when questioners get those details wrong.

I took all of that into account in my reply, but thanks for illustrating
what I had to think about in the process. One of the last things I did to
his system was "sudo ln -s ttyS0 /dev/modem" but did not retest the
NetZero client after that because he had not brought his modem with him
anyway. I also warned him that I did not know whether that symlink would
survive a reboot in the presence of udev. I now know that it would not, so
the symlink I created went away almost immediately, thus leaving the
NetZero client no more nor less functional as when I tested it.

> Second, your phrase "didn't work" is one of a long series of common
> phrases that are actively harmful to diagnosis, because they omit what
> is really important.  (Others are "crashed", "bombed", "failed", etc.)
> What's omitted, and what's really important, is _what actually
> happened_.
> 
> To clarify that point, I tend to tell querents "Techies are from
> Missouri." That is, you need to _show them_.  If you did something that
> is important at the command line, _show_ the entire command-line
> sequence to the people you want to help you, using cut-and-paste.  E.g.:
> 
> $ su -
> Password:
> # cd /dev
> # ls -l modem
> ls: modem: No such file or directory
> # ln -s ttyS0 modem
> # ls -l modem
> lrwxrwxrwx    1 rute     root            5 Dec 17 07:03 modem -> ttyS0 #
> exit
> $
> 
> Notice how I take a couple of extra steps to show that no symbolic link
> exists when I started, and the exact nature of what was created when I
> finished.  Given that information, a technician whom I've asked to help
> me would know objectively exactly what I've done and where the "modem"
> symlink points to.

Yes, this would all be ideal, but one has to keep in mind that one of the
manifestations of the problem at hand is that he cannot access his e-mail
and his Linux installation at the same time. If I had his phone number, I
could try to give some of this a more real-time approach, but the most
real-time approach would of course be tomorrow's SVLUG installfest.

> Third (and as an extension of the "Show me" point), you're displaying
> the very, very common, but problematic trait of telling us your
> _interpretations_ rather than the raw data.  Technicians need raw data;
> it's not good for them to have to rely on your interpretations.  E.g.:
> 
> 
>> When I try to start Netzero client from the desktop, it does not
>> recognize the modem.
> 
> Your phrase "does not recognize" is your _interpretation_.  You don't
> state what sequence of events happened that lead you to that conclusion.
> The latter is the raw data, and is what technicians need.

Yes, it's his interpretation, but I think it's reasonable for me to assume
that it's an interpretation of events identical to what I saw first hand
when I tested to see how well the NetZero client would work, which was
that everything was fine until it tried to access /dev/modem, which didn't
exist.

> Because technicians are not present in the room with you, your
> description has to compensate for our inability to see what you're
> seeing.  Except in the case of baseline tools that are on every Linux
> system, you shouldn't assume that we all have the software you're using,
> either.
> 
> If your case, I believe the "Netzero client" you speak of is a graphical
> proprietary application.  But you didn't say that -- and you really do
> need to say it.  You said you "started" it "from the desktop".  Started
> how?  What desktop?  Sometimes, for purposes of clarity in diagnostic
> situations, it's best to run even graphical applications of interest
> from a terminal session, e.g.:
> 
> $ netzero &
> $
> 
> (The "&" detaches the started-up process from the terminal, starting it
> in background, and giving you back your command prompt.
> 
> If you that, and copy and paste the command session, then technicians
> will know precisely what you did to launch such programs, and will have
> greater confidence that you didn't forget to mention something
> important.

This one's a no-brainer: He has an icon for the NetZero client on his KDE
desktop, because the name of the script that invokes it is not "netzero"
but something cryptic that I didn't bother to remember, and not even in
his $PATH, but buried somewhere in /opt. When the icon is opened, the
script is run, and what looks like it might be a Motif-based app appears.

> Does the Netzero client have a screen for configuration (aka
> "preferences")?  Does such a screen show a serial port that is to be
> used?  Does it say /dev/modem?

It does have configuration and preferences screens, but the serial port is
not among the options. Evidently, that's hardwired to /dev/modem,
presumably meaning that Linspire would have its own configuration and
preferences screens that control to what that symlink would point on such
a system. This is not an incompatibility with Kubuntu since Kubuntu also
has such a configuration option in /etc/udev/links.conf, but Kubuntu does
not have a graphical way to set that because it is not normally used in
that distribution.

>>The kppp recognizes the modem fine.
> 
> Again, it's really hard for us to know what this means.  You could mean
> that kppp dials, connects, negotiates your PPP login, and establishes
> full Internet connectivity that you confirmed by doing the following at
> a command prompt:
> 
> 
> $ ping www.apple.com
> PING www.apple.com.akadns.net (17.254.0.91) 56(84) bytes of data. 64
> bytes from www.apple.com (17.254.0.91): icmp_seq=1 ttl=241 time=617 ms
> 64 bytes from www.apple.com (17.254.0.91): icmp_seq=2 ttl=241 time=618
> ms 64 bytes from www.apple.com (17.254.0.91): icmp_seq=3 ttl=241
> time=622 ms
> 
> --- www.apple.com.akadns.net ping statistics --- 4 packets transmitted,
> 3 received, 25% packet loss, time 3697ms rtt min/avg/max/mdev =
> 617.394/619.272/622.122/2.147 ms $
> 
> 
> Doesn't kppp have a screen where the modem device can be specified? What
> does it say?  Maybe "/dev/ttyS0"?

Obviously, it's not all of that that kppp does, because NetZero is his
only ISP, and they don't accept standard PPP logins. The fact that kppp is
able to do any of it at all tells me that no kernel modules are at fault,
and that's pretty much the only useful information that could be gleaned
at this point from an attempt to use kppp. In light of all of the above, I
think it's reasonable to assume that kppp was configured to use /dev/ttyS0
and not /dev/modem, which is why I said to make sure it behaves
identically both ways.

>> I did ln -s tty0 /dev/modem but that didn't work.
> 
> Again, the biggest problem in the above, even worse than the fact that
> it's unclear what directory you were in, and thus unclear where "tty0"
> is, and even worse than /dev/tty0 (as opposed to /dev/ttyS0) making no
> sense as a serial device, is that we have no way of knowing what you
> mean when you say "didn't work".

The current working directory has no bearing on the creation of a symlink,
except of course that tab-completion will only work if you are in the
directory where the symlink will live.

> You were probably really clear in your mind about what you meant, but we
> can't read your mind -- or your screen.  ;->

Agreed, but it can't be helped in this case, for reasons I stated above.

>> I tried it from a terminal as root but that didn't matter except it
>> said DM is off. What does that mean.
> 
> Insufficient data.

Yes, I said as much.

>>     Any suggestions on getting the Netzero to work?
> 
> Yes.  What does the accompanying documentation state, about how to
> specify the serial port?

I did not detect the presence of any "accompanying documentation" for the
NetZero client. I am assuming that the port is specified by the
destination of the /dev/modem symlink, because when the symlink didn't
exist, the NetZero client complained that it couldn't find /dev/modem.