From: ibuprofin@painkiller.example.tld.invalid   
      
   On Sun, 04 Nov 2012, in the Usenet newsgroup alt.os.linux.mandriva, in article   
   , Adam wrote:   
      
   >Moe Trin wrote:   
      
   [modem-on-hold]   
      
   >> From what I understand, this is part of the v.92 specification, and   
   >> the question is more if the ISP has enabled the function.   
      
   >According to AT+PCW and AT+PMH, the Linuxant driver on eris doesn't   
   >support it, but the USB modem does.   
      
   Minor but not totally unexpected surprise. I imagine the "quick   
   train" also isn't implemented. Speed, both the compression and uplink   
   rates are ``more important''.   
      
   >A NetZero web page says they support it, but the page is old,   
   >pre-2006. I'm also not sure whether their Linux software supports   
   >it. Again, doesn't sound worth it for me.   
      
   Only Linux specific would be "lcp-echo" interval and failure counts   
   (see the pppd man page - then try adding the "dump" option to check   
   what's set where), and the normal TCP or application timeouts when   
   the connection is "stalled".   
      
   >Another complication discovered: the winmodem only switches from   
   >(probably) v.34a to v.90 when it /connects/ as v.90. Although it now   
   >gets initialized to v.90, the NZ/J software first does an ATZ which   
   >resets that to v.92, so no connection is made using v.90 (unless I   
   >make one myself) and NZ/J has the v.92 setting but connects at 33.4k.   
      
   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?   
      
   >I suppose somewhere in the Linuxant software there's code that makes   
   >it default to v.92. Maybe someday I'll look at it and try to change   
   >it to v.90, or else disable the NZ/J software from sending ATZ (maybe   
   >just "AT " instead).   
      
   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".   
      
   [boot with wireless]   
      
   >> I don't have a CentOS to look at,. but "the Red Hat way" was   
      
   >Fedora and CentOS are slightly different. The problem was that   
   >CentOS had some of the files in /etc/sysconfig/network-scripts/   
   >named *-wireless and others were *-Wireless_connection_1 . Now that   
   >there are both versions of all three relevant files, it boots with   
   >wireless connected.   
      
   I'm sure of that they're different - but the "Red Hat way" I'm   
   referring to predates Fedora and RHEL (of which CentOS is a clone). I   
   think they actually started that back around 1996 (RH3.0.3). Around   
   RH8 (2002, which predates Fedora, but not RHEL) they started reworking   
   the scripts, moving them when they changed to the "Network Manager"   
   style tool. Same concept/style, but implemented slightly differently.   
      
   >Not as early in the boot process as I'd like (the boot messages still   
   >report failure), but by the time it gets to the login screen wireless   
   >is working.   
      
   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 (and   
   something else is timed to start after the "normal" delay)?   
      
   [which modems]   
      
   >> I was looking at new systems at Frys recently   
      
   >Considering getting one?   
      
   No, I just cruise the aisles to see what I can live without   
      
   >> none had an internal modem,   
      
   >Seems to be standard these days.   
      
   Not surprising - it seems that most domestic systems expect that there   
   is broad-band of some variety.   
      
   >> and the choices of externals is essentially limited now to the USB   
   >> interface.   
      
   >Well, USB hardware modems should work with any system with a USB   
   >port, regardless of OS. The local Best Buy now stocks only one   
   >modem, a USB hardware modem, and if it were my decision I'd say   
   >that's just about the right number of modems to carry nowadays given   
   >the limited shelf space of the store. I'd be surprised if they even   
   >sell one a week.   
      
   Again, that's the expectation that broadband is there. For a lot of   
   the more developed parts of the country, it's reasonable. But out in   
   "the country", this may not be the case. Sure, if you need the speed   
   of broadband, you can probably get satellite, but you've mentioned   
   relatives in Vermont where that isn't practical. But likewise, the   
   computer stores aren't out there in the country (implying that their   
   customers have got broadband), and other people are more likely to be   
   buying on-line rather than "driving into town".   
      
   >>>> 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 ]   
      
   >But [ -L /dev/modem ] would return true even if it was an incorrect or   
   >dangling link.   
      
   True - you could use "[ -c /dev/modem ]" which follows the link, but   
   the reason we're looking is because the event managing daemon (udevd   
   or hald, or what-ever) may not have created the link - not that the   
   device itself has changed or doesn't exist.   
      
   ['route' vs 'ip route']   
      
   >In the (current?) version of Debian on eris, /sbin/ip is a symlink to   
   >/bin/ip ; the others are in /sbin. I might as well check for both,   
   >and then just use 'ip route' to invoke whichever's first in the   
   >user's PATH.   
      
   Do all of your users have /sbin/ in their $PATH? Mine don't. And   
   don't forget that the 'test' or '[' function doesn't know about $PATH.   
      
   >>> The PA said I'm doing extremely well (going by lab work), and the   
   >>> surgeon wants me back in _six_ months. Last time it was four   
   >>> months, and before that three months.   
      
   >> that really is good to hear, and I know how good it must feel.   
      
   >Thanks! Actually my biggest worry about the kidney transplant is   
   >that for unknown reasons, many successful ones eventually stop   
   >working. I remember my nephrologist saying happily that I should be   
   >good for another 15-20 years, but even that would run out before I'm   
   >70.   
      
   That's still at least a dozen years down the pike, and a lot can   
   happen in that time. They may discover why the failures occur, and   
   can work around it.   
      
   >Some transplants have lasted considerably longer, and of course those   
   >were done years ago using older procedures and medications.   
      
   The old question always asked by the people on the hell-desk is "what   
   did you change"? Or in this case, "why"? Is this another case of a   
   different definition of "improvement"?   
      
   >> Ah, you would have to bring that up. I'm catching it from the   
   >> Primary Care that I really should loose a minimum of 10 pounds.   
      
   >I've gained at least 30 pounds just since the transplant, about one   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|