From: ibuprofin@painkiller.example.tld.invalid
On Mon, 29 Oct 2012, in the Usenet newsgroup alt.os.linux.mandriva, in article
, Adam wrote:
>Moe Trin wrote:
>> Thing is, it _is_ your job. You're not getting paid for it
>But I don't have to answer to anyone else about it, which is why to
>me it doesn't seem quite like a job.
Well, yeah - the pension and benefits plans stink, but it's still in
your court.
[slow dialup connections]
>> Depends on the data you're passing. The real difference between v.90
>> and v.92 is the data compression protocol (v.42bis verses v.44).
>Mueller also says v.92 has additional features, like modem-on-hold,
>but now I've got it configured to start with v.90. Given how seldom
>I'll be using dialup, I think that's good enough.
"modem-on-hold" requires you to buy additional services from your
telephone provider. There's also a "quick start" which assumes the
phone lines to the peer will "look" similar, making for shorter
training time. I can't say that I've seen that happen, and the
connection start times are no shorter (and _may_ be longer when/if the
quick-start feature fails). But if you've got v.90 working, that
probably good enough.
>> What are the "normal" permissions/ownership of the actual device?
>lrwxrwxrwx. 1 root root 8 Oct 29 12:29 /dev/modem -> ttySHSF0
>crw-rw----. 1 root dialout 240, 64 Oct 29 12:33 /dev/ttySHSF0
>Anything involving the modem has to be done as root. I added "echo
>AT+MS=V90 > /dev/modem" to rc.local on CentOS and that works.
Good - after login, a member of the 'dialout' group should be able to
do that, but having it done by the boot scripts is easier.
>I also put an additional command needed to start the wireless
>connection into rc.local which is later in the boot process than I'd
>like (e.g. after it's tried nfs).
I would have thought that would have been handled by the S??network
script, which should be run before S??netfs. If this is systemd or
upstart rather than the SysVInit, the NFS script needs to check that
"some" networking is up, rather than just Ethernet.
[Linuxant driver]
>I figured out why. The driver(s) from Linuxant haven't been updated
>since about 2010, and they're expecting to find system headers that
>aren't in newer kernels.
And given the declining importance of modems, I suspect they won't
be updating them either.
>IOW, without some work on Linuxant's or my part, their driver will
>only work on older kernels... such as the 2.6.32 my CentOS install is
>using, but not the 3.x that Fedora and Mageia are using on eris.
In theory, you could create those header files containing the needed
declarations, but I don't think it's worth the effort.
>Meanwhile, I have to keep reminding myself that getting a winmodem
>working, and getting connected to NetZero/Juno, are separate problems.
especially when you have external modems that work.
>>>> I had a [USR] 5686-03 for a while, and sold it for some reason.
>It's still in production:
That's certainly a modernized version, as I had the -03 back in 2003.
[netzero-juno.txt]
>> As long as it's able to continue working with the more modern Linux
>> distributions.
>AND NetZero/Juno continues to offer free dialup service (most free
>providers are long gone) AND their Linux software will work AND they
>still have the Linux software on their website.
picky, picky ;-)
>[root@stolid nzclient]# file nzppp
>nzppp: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
>dynamically linked (uses shared libs), for GNU/Linux 2.2.0, not
>stripped
>which is the program that actually makes the connection -- it's
>actually a modification of pppsetup-2.28.
which is also ancient
-rw-rw-r-- 1 keeper admin 7896 Jun 12 2001 pppsetup-2.28.tar.gz
that's in ./system/network/serial/ppp/ at sunsite - it's just a script
to create a wrapper.
>I suppose that when the shared libraries it uses no longer exist,
>their software won't work either. 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. The Filesystem Hierarchy Standard allows that
they can either be the actual library or a link to the actual library
and I think everyone has followed the link concept to allow for
updates.
>NewEgg still sells [the USR 5610C] too. The issue of "which modems
>are usable under Linux" is broad enough and confusing enough so that
>I think I'll stick to generalities and suggest a web search for any
>particular model.
A long time ago, Rob Clark created a database of modems, (externals,
ISA, PCI, PCMCIA and USB) divided into categories of "unknown", "real",
"winmodems" and "linmodems". The lists were last updated in December
2004, and then included a grand total of 1467 modems. (This is the
web page referred to in the Modem-HOWTO.) I doubt there will ever be
a comparable list again. The best that can be done is to refer them
to a search engine, looking for the make/model and the keyword "Linux".
>And I suppose SysVInit vs. systemd. I can either find a way to
>determine whether udev is involved, or just say "you may need to...".
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.
['route' vs 'ip route']
>> some distribution's scripts include a test to see which command is
>> present, and have both style of command.
>Yeah, gotta look into that too. I don't want to make my script too
>complicated, though.
if [ -x /sbin/ip ] ; then
GATEWAY=$(/sbin/ip route list | grep default | cut -d' ' -f 3)
/sbin/ip route del default
elif [ -x /sbin/route ] ; then
GATEWAY=$(/sbin/route -n | grep -E "^0\.0\.0\.0.*G" | \
tr -s ' ' | cut -d ' ' -f 2)
/sbin/route del default 2>/dev/null
else
echo "SCREWED!!!"
fi
and
if [ -x /sbin/ip ] ; then
[ -n "$GATEWAY" ] && /sbin/ip route add default via "$GATEWAY"
else
[ -n "$GATEWAY" ] && /sbin/route add default gw "$GATEWAY"
fi
a bit of complication, but I don't think it's that bad
>What about assuming that everybody will have "ip route" available,
>and the few who don't will know what changes to make?
Tempting, but I think the knowledge is unlikely.
[sandy]
>> You mentioned they were doing some trenching on the lawn - was that
>> finished?
>Yep, only along the side of my building closest to the creek, and I'm
>not really sure what they actually did. Well, power's already
>flickered a few times and the winds are picking up, so I guess I'd
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
