From: ibuprofin@painkiller.example.tld.invalid
On Wed, 07 Nov 2012, in the Usenet newsgroup alt.os.linux.mandriva, in article
, Adam wrote:
>Moe Trin wrote:
[modem-init]
>> I'm lost here - I thought you said that ATZ wasn't mucking with the
>> AT+MS=V90 because that +MS setting wasn't in NVRAM. If you set it
>> on power-up, how is it being reset AFTER that?
>On the winmodem, the +MS setting isn't stored in "NVRAM", but both ATZ
>and AT&F reset it to V92.
Got it - that sorta makes sense.
>> Some modems take "ATZ" to mean "reset to NVRAM _and_ empty the
>> command buffer", such that anything following the "Z" in a command
>> is lost. I'd suggest resetting the init-string from "ATZ" to
>> "ATF1+MS=V90".
>Yep, ATZ does empty the command buffer. I'd expect AT&F to do the
>same, but it doesn't.
I don't think I've ever heard of a modem doing that on an AT&F - and
I've been using that style of command for more than 25 years.
if [ $QUIET = "1" ] ; then
INITSTR="AT\&F1M0"
elif [ $QUIET = "2" ] ; then
INITSTR="AT\&F1L0"
else
INITSTR="AT\&F1"
fi
"QUIET" is set based on the name used to call the script ("dialin"
vs. "dialinlow" vs "dialinlower" - the latter being links that point
to "dialin").
>It turns out that 'nzppp' (their modified pppsetup) gets the init
>string from a separate file (a one-line text file called 'mdminit'),
>so I changed the init strings (for both NZ & J) to "AT&FW1+MS=V90" so
>it now connects to NZ/J at v.90.
Great! That makes life a lot easier.
>The "W1" isn't necessary, but gives me more info on the connection
>when I look at the NZ/J log afterward.
[fermi ~]$ tail -1 /usr/local/bin/dialin
/usr/sbin/pppd $DEV ipparam $IPPAR user $USERNAME connect
"/usr/sbin/chat REPORT CONNECT ABORT \"NO DIALTONE\" ABORT BUSY \"\"
$INITSTR OK ATDT$PHNUM CONNECT \"\d\c\""
[fermi ~]$
chat: Nov 06 21:07:13 CONNECT 42666/ARQ/V92/LAPM/V44
Serial connection established.
Yes, I'm using the command line, but the "REPORT CONNECT" tells chat
to stick the modem connection stanza to /dev/stderr - the terminal I'm
connecting from. See also the -r option to chat.
>mdminit' will /definitely/ get mentioned in netzero-juno.txt 1.3.1!
suggest using AT&F vs ATZ - explain that ATZ resets
to NVRAM, which may have had a strange configuration saved to it, vs
setting to "factory defaults" - but some modems want AT&F0, while some
want AT&F1... decisions, decisions!
[boot with wireless]
>> Is this because the /etc/rc.d/rc?.d/S??network is starting later
>> than you want/need, or because the act of bringing up the wireless
>> link is taking longer than it took to bring up the Ethernet
>> interface
>Under CentOS, it's S10network so I assume it's started fairly early on.
Yeah - on the typical Red Hat setup, that's usually one of the first
"S" scripts run.
>The boot messages still report failure both for the wireless device
>and for ntpd, but by the time it gets to the level 3 login prompt
>there's a message that wlan0 is up.
OK - slow bringing things up - In theory, you could put a 'wait'
delay in S??ntpd and/or S??ntpdate. We've had this kind of problem
with network file systems as well. Normally, the delay bringing up
the network is due to DHCP, and using a static address scheme usually
gets around it, but adding a delay to the NFS startup also does the
trick at relatively minor cost. The parallel boot scheme (upstart
or systemd) can have a "condition" added - such that NTPD (or a
network file system) waits until the network is "up" before starting.
>In /etc/sysconfig/network-scripts/ifcfg-Wireless_connecection_1 I
>tried changing IPV4_FAILURE_FATAL to "no" and also tried adding
>NETWORKDELAY=30s (which did /not/ cause a delay during startup) but
>neither prevented those failure messages.
No idea - don't have the CentOS to look at
>OTOH since wireless is up by the time I'm logging in, I don't think
>it's worth worrying about.
Minor concern - if your hardware clock is "wrong", you'll boot with
that time, rather than correcting things using NTP. Your choice.
>BTW my neighbor on SSID "frrggl" has switched to channel 4, which I'd
>guess had something to do with my using channel 9. The other 4 or 5
>neighbors with Wi-Fi are still on 1, 6 or 11.
Depends - mentioned before, using 4 catches interference from both
1 and 6, while 9 catches it on 6 and 11. But using channel N doesn't
mean you must be the _ONLY_ user on that channel to avoid interference.
The typical free wireless hot-spot at the coffee shop or library may
have a few dozen users all on the same channel and speaking to the
same access-point. Like classical coax Ethernet, it's just more people
on the same wire at the same time.
[new systems not coming with internal modems]
>> Not surprising - it seems that most domestic systems expect that
>> there is broad-band of some variety.
>It also saves the manufacturer a few bucks, because (I'd guess) most
>users don't care that it comes without any dialup modem, and dialup
>modems are still available separately (for a cost) for anyone who
>wants one.
Less parts, less labor, less warranty costs
>Dialup is sufficient for my aunt and uncle (who just celebrated their
>64th anniversary BTW).
Wow! Congrats to them. The November issue of AARP Bulletin mentions
a Pew Research Center study that concluded more than half US seniors
over 65 are on-line - news, search-engines, and social sites.
>Satellite /might/ be possible for some of their Vermont neighbors.
>Also, they're snowbirds, and have enough problems getting their POTS
>activated and suspended each year.
Only use it for a month or few? Some providers (especially in
vacation homes regions) have a low year round rate, with minimal
connect time before a "normal" (higher) rate kicks in.
>Or else because there aren't enough potential customers in the country.
Recently read "The American Home Front: 1941-1942" by Alistair Cooke
(ISBN 978-0-87113-939-9, 2006) where he was touring the US (by car).
One person he spoke to was a farmer somewhere out in the Boonies who
was looking over guidance material from Washington that was
recommending "ride sharing" - except that his nearest neighbor was
50 miles away.
['route' vs 'ip route']
> Do all of your users have /sbin/ in their $PATH? Mine don't.
>"All of your users" means anyone who tries to use that script, so I
>can't predict anything. However, since it /has/ to be run as root, I
>think it's a safe assumption that /sbin will be in the PATH. I've
>decided to just check for /sbin/ip.
That's a good point - but how is the user becoming root to run this?
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
