From: ibuprofin@painkiller.example.tld.invalid
On Thu, 01 Nov 2012, in the Usenet newsgroup alt.os.linux.mandriva, in article
, Adam wrote:
>Moe Trin wrote:
>> Adam wrote:
>> "modem-on-hold" requires you to buy additional services from your
>> telephone provider.
>I gather you mean "call waiting" which I already have (and pay for)
>although my NZ/J dialing string currently starts with "*70" to
>temporarily disable it.
Yup
>Personally I hate that "feature", but got it just in case I was on
>the phone when the transplant center called. I suppose if I wanted
>to use it, I'd have to see whether both the modem driver and the ISP
>support it too. Doesn't sound worth it.
From what I understand, this is part of the v.92 specification, and
the question is more if the ISP has enabled the function. It ties
up the phone line at the ISP end, so they may have some incentive to
not enable/permit it. Another concern is if your ppp setup is using
'lcp-echo' (essentially a link level 'ping' done in the background).
Some helper programs configure it, to permit detection of a link
failure other than by the modem control lines. With the modems on
hold, the echos fail, and ppp may decide to down the link.
>> But if you've got v.90 working, that probably good enough.
>Yes, since apart from testing I expect to use dialup at most a few
>times a year.
Mentioned, the only performance difference is the v.42bis verses v.44
data compression.
[boot with wireless]
>CentOS is still using SysVInit, but I'm not sure where in
>/etc/rc.d/init.d/network I should add that command. It's "iwconfig
>wlan0 essid abcdef" or whatever my ESSID is, which is why it couldn't
>be included in CentOS as shipped. I suppose I could add a line there
>calling some customized file if it exists, once I figure out where to
>add that line.
I don't have a CentOS to look at,. but "the Red Hat way" was that
/etc/rc.d/init.d/network eventually calls the script[s] in
/etc/sysconfig/network-scripts/ and works it's magic there. There
would be an "/etc/sysconfig/network-scripts/ifup-wireless" script
that does the actual dirty work. You MAY have some documentation in
/usr/share/doc/initscripts-*/ that helps, OR there may be a dummy
"ifup-wireless" script or template..
[Linuxant driver]
>> And given the declining importance of modems, I suspect they won't
>> be updating them either.
>I'm surprised their website is still up, as they don't seem to have
>done anything in the past few years.
While there are areas of this country that don't have broadband of
some form or another, modems are getting less and less common. I was
looking at new systems at Frys recently, and none had an internal
modem, and the choices of externals is essentially limited now to
the USB interface.
[pppsetup-2.28]
>> which is also ancient
>I have the C source for that, and it looks like the NZ/J file has a
>few text strings that aren't in the C source, at least not the source
>I found.
I had to grab a copy from sunsite - Kent Robotti is a rather prolific
contributor to the Free software scene.
>In fact, wouldn't NZ/J's modification without offering their source
>technically have been a license violation? (Not that I'm going to
>complain!)
Technically yes. The first few lines of the source contain the
2001 copyright declaration as well as the statement that it's
released under GPL. On the other hand, the people who known anything
about it at NetZero/Juno are likely long gone.
>>> From "strings", those seem to include /lib/ld-linux.so.2 and
>>> libc.so.6 although on my system they're both symlinks.
>> They're symlinks on all systems - they point to the actual version
>> of the various libraries.
>Okay -- so I can count on those "libraries" working on (nearly) all
>future distros and releases.
Until the world updates to libc7 or glibc3 or something. Long, long
ago, the Linux end of the world was compiled to 'a.out' binaries using
libc4. In 1995, we "improved" things by going to 'elf' binaries and
libc5. This was not very compatible with GNU, so we transitioned
again (late 1997) to 'glibc' and libc6 - more or less where we're at
now. For a while, we had "compatibility" libraries (libc4 up until
~2000, libc5 at least through 2003).
[which modems]
>> The best that can be done is to refer them to a search engine,
>> looking for the make/model and the keyword "Linux".
>Seems like every time I revise it, I cut out more information. :-)
I'm not sure of any other _practical_ solution. Actually, I wonder
how many people would know how to identify the make/model of model
they have unless it's still in the original box.
>> I suspect the latter - as far as I know, udev is here to stay, and
>> it's just how the individual distribution implements static device
>> links.
>Another "see your distro's documentation" item, then?
[ -L /dev/modem ] perhaps an rc.local thing - if the link doesn't
exist, you can then create it (assuming they've figured out where the
modem is going to show up).
['route' vs 'ip route']
>That looks reasonable -- I'm trying it out. Two things, though. The
>one existing file I've found that checks is
>/etc/avahi/avahi-autoipd.action (in several distros), and that has
>(excerpts):
>if [ -x /bin/ip -o -x /sbin/ip ] ; then
/bin : Essential user command binaries (for use by all users)
While the FHS says that (and doesn't mention the "ip" command), it's
not that much extra. One of the people at work says Debian/clones
puts "ip" in /bin, and retains /sbin/ifconfig and /sbin/route (both
of which "must" be in /sbin/ if the corresponding subsystem - which
I suppose means networking - is installed). Other distros follow the
spirit of the FHS, which puts "system binaries" "essential for booting"
in /sbin. You may find a "ip-cref" document ("ip command reference)
written by the program author (Alexey N. Kuznetsov), but it never
includes PATH data in the examples.
>Think it's important to check for 'ip' and 'route' in /bin as well as
>/sbin?
The FHS is specific that route and ifconfig belong in /sbin - but this
new-fangled 'ip' command...
>Another unexpected problem is that the current (test) version of the
>script doesn't run correctly if invoked by 'sudo' but runs correctly
>if invoked by "su -c". I haven't narrowed it down yet, but I thought
>that wasn't supposed to happen.
"doesn't run correctly"??? I'm not a sudo expert, but that could be
sudo noting you trying to run commands you're not authorized to in
/etc/sudoers. Anything in the logs?
[Hurricane Sandy]
>> My sister reported some wind damage, but the rainfall wasn't
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
