Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.hardware > #2861 > unrolled thread

Talk to modem with USB to serial adapter: fail

Back to article view | Back to comp.os.linux.hardware

Contents

  Talk to modem with USB to serial adapter: fail Mike Spencer <mds@bogus.nodomain.nowhere> - 2015-08-12 03:03 -0300
    Re: Talk to modem with USB to serial adapter: fail Jerry Peters <jerry@example.invalid> - 2015-08-12 20:36 +0000
      Re: Talk to modem with USB to serial adapter: fail Mike Spencer <mds@bogus.nodomain.nowhere> - 2015-08-13 04:19 -0300
        Re: Talk to modem with USB to serial adapter: fail Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2015-08-13 21:17 +0000
          Re: Talk to modem with USB to serial adapter: fail Mike Spencer <mds@bogus.nodomain.nowhere> - 2015-08-15 02:26 -0300
            Re: Talk to modem with USB to serial adapter: fail Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2015-08-16 00:45 +0000
              Re: Talk to modem with USB to serial adapter: fail Mike Spencer <mds@bogus.nodomain.nowhere> - 2015-08-16 00:43 -0300
                Re: Talk to modem with USB to serial adapter: fail Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2015-08-16 20:09 +0000
              Re: Talk to modem with USB to serial adapter: fail Mike Spencer <mds@bogus.nodomain.nowhere> - 2015-08-16 01:41 -0300
                Re: Talk to modem with USB to serial adapter: fail Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2015-08-16 20:10 +0000
                  Re: Talk to modem with USB to serial adapter: fail Mike Spencer <mds@bogus.nodomain.nowhere> - 2015-08-16 22:28 -0300
                    Re: Talk to modem with USB to serial adapter: fail Michael Black <et472@ncf.ca> - 2015-08-16 22:48 -0400
                      Re: Talk to modem with USB to serial adapter: fail Mike Spencer <mds@bogus.nodomain.nowhere> - 2015-08-17 03:35 -0300
                  Re: Talk to modem with USB to serial adapter: fail Mike Spencer <mds@bogus.nodomain.nowhere> - 2015-08-17 03:22 -0300
                    Re: Talk to modem with USB to serial adapter: fail Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2015-08-17 23:50 +0000
                      Re: Talk to modem with USB to serial adapter: fail Mike Spencer <mds@bogus.nodomain.nowhere> - 2015-08-18 16:16 -0300
                        Re: Talk to modem with USB to serial adapter: fail Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2015-08-21 03:31 +0000
                          Re: Talk to modem with USB to serial adapter: fail Mike Spencer <mds@bogus.nodomain.nowhere> - 2015-08-25 01:58 -0300
                            Re: Talk to modem with USB to serial adapter: fail Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2015-08-27 02:28 +0000
                              All better now (Re: Talk to modem with USB to serial adapter: fail) Mike Spencer <mds@bogus.nodomain.nowhere> - 2015-09-03 18:53 -0300
                                Re: All better now (Re: Talk to modem with USB to serial adapter: fail) Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2015-09-04 20:00 +0000
                                  Re: All better now (Re: Talk to modem with USB to serial adapter: fail) Richard Kettlewell <rjk@greenend.org.uk> - 2015-09-04 21:09 +0100
                                    Re: All better now (Re: Talk to modem with USB to serial adapter: fail) Mike Spencer <mds@bogus.nodomain.nowhere> - 2015-09-04 23:14 -0300
                                      Re: All better now (Re: Talk to modem with USB to serial adapter: fail) Richard Kettlewell <rjk@greenend.org.uk> - 2015-09-05 10:08 +0100
                                    Re: All better now (Re: Talk to modem with USB to serial adapter: fail) Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2015-09-05 18:08 +0000
                                      Re: All better now (Re: Talk to modem with USB to serial adapter:  fail) Mike Spencer <mds@bogus.nodomain.nowhere> - 2015-09-06 01:31 -0300
                                        Re: All better now (Re: Talk to modem with USB to serial adapter:  fail) Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2015-09-06 19:17 +0000
                                          Re: All better now (Re: Talk to modem with USB to serial adapter:   fail) Mike Spencer <mds@bogus.nodomain.nowhere> - 2015-09-17 01:26 -0300
                                            Re: All better now (Re: Talk to modem with USB to serial adapter:   fail) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-09-17 05:53 +0000
                                              Re: All better now (Re: Talk to modem with USB to serial adapter:    fail) Mike Spencer <mds@bogus.nodomain.nowhere> - 2015-09-17 04:02 -0300
                                                Re: All better now (Re: Talk to modem with USB to serial adapter:    fail) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-09-17 18:02 +0000
                                                  Re: All better now (Re: Talk to modem with USB to serial adapter:     fail) Mike Spencer <mds@bogus.nodomain.nowhere> - 2015-09-18 02:05 -0300
                                                Re: All better now (Re: Talk to modem with USB to serial adapter:    fail) Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2015-09-17 19:14 +0000
                                                  Re: All better now (Re: Talk to modem with USB to serial adapter:    fail) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-09-18 01:55 +0000
                                                    Re: All better now (Re: Talk to modem with USB to serial adapter:    fail) Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2015-09-18 21:22 +0000
                                            Re: All better now (Re: Talk to modem with USB to serial adapter:   fail) Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2015-09-17 19:12 +0000

Page 1 of 2  [1] 2  Next page →

#2861 — Talk to modem with USB to serial adapter: fail

I want to use a USR 56K serial modem with a late-model Acer laptop (no
serial port).  Nothing seems to reaching the modem.

lsusb see the adapter as:

  Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
  USB ID 0403:6001

The system seems to see it as /dev/ttyUSB0. "echo at > /dev/ttyUSB0"
exits with no error but no lights blink on the modem.

cat /proc.tty/usbserial replies:

    usbserinfo:1.0 driver:2.0
    0: module:ftdi_sio name:"FTDI USB Serial Device" 
    vendor:0403 product:6001 num_ports:1 port:0 path:usb-0000:00:10.0-2

and lsmod |grep serial shows:

    usbserial              19969  3 ftdi_sio

Using the scripts that work fine from a desktop with a standard serial
port, pppd appears to exit 0 without doing anything.

In the past, I've used minicom to test modem connections. But, after
telling minicom to talk to /dev/ttyUSB0, minicom echoes non-ASCII
chars in response to lower case (a=degree-symbol, t=phi or maybe
slashed 0) and doesn't respond at all to upper case.  In any case,
nothing seems to get to the modem.

Same thing happens in an xterm or in a console. /dev/ttyUSB0 is
rw-rw-rw, pppd is suid.  Excepting the substitution of ttyUSB0for
ttyS0, details are the same as on the working desktop system.

Running Slackware 14.1 but with a 3.16.1 kernel.

Has anybody dealt with this, have a tidy solution?

Yes, I have some things to verify, such as the RS232 plug sex
adapter. Just hoping there's a wizard out there with a fix.

Tnx,

-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [next] | [standalone]

#2863

Mike Spencer <mds@bogus.nodomain.nowhere> wrote:
> 
> I want to use a USR 56K serial modem with a late-model Acer laptop (no
> serial port).  Nothing seems to reaching the modem.
> 
> lsusb see the adapter as:
> 
>  Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
>  USB ID 0403:6001
> 
> The system seems to see it as /dev/ttyUSB0. "echo at > /dev/ttyUSB0"
> exits with no error but no lights blink on the modem.
> 
> cat /proc.tty/usbserial replies:
> 
>    usbserinfo:1.0 driver:2.0
>    0: module:ftdi_sio name:"FTDI USB Serial Device" 
>    vendor:0403 product:6001 num_ports:1 port:0 path:usb-0000:00:10.0-2
> 
> and lsmod |grep serial shows:
> 
>    usbserial              19969  3 ftdi_sio
> 
> Using the scripts that work fine from a desktop with a standard serial
> port, pppd appears to exit 0 without doing anything.
> 
> In the past, I've used minicom to test modem connections. But, after
> telling minicom to talk to /dev/ttyUSB0, minicom echoes non-ASCII
> chars in response to lower case (a=degree-symbol, t=phi or maybe
> slashed 0) and doesn't respond at all to upper case.  In any case,
> nothing seems to get to the modem.
> 
> Same thing happens in an xterm or in a console. /dev/ttyUSB0 is
> rw-rw-rw, pppd is suid.  Excepting the substitution of ttyUSB0for
> ttyS0, details are the same as on the working desktop system.
> 
> Running Slackware 14.1 but with a 3.16.1 kernel.
> 
> Has anybody dealt with this, have a tidy solution?
> 
> Yes, I have some things to verify, such as the RS232 plug sex
> adapter. Just hoping there's a wizard out there with a fix.
> 
> Tnx,
> 

I used to use a serial adapter to a modem when I'd visit my parents in
Florida, never had any problems, it all just worked. I don't remember
which serial adapters I used (I had 2 different ones) but it wasn't an
fdti. Before spending too much time I'd suggest trying a different
serial adapter. Just a thought, does the fdti need firmware? modinfo
should show if it does.

[toc] | [prev] | [next] | [standalone]

#2864

Jerry Peters <jerry@example.invalid> writes:

> Mike Spencer <mds@bogus.nodomain.nowhere> wrote:
>
>> I want to use a USR 56K serial modem with a late-model Acer laptop (no
>> serial port).  Nothing seems to reaching the modem.
>> 
>> lsusb see the adapter as:
>> 
>>  Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
>>  USB ID 0403:6001
>
> I used to use a serial adapter to a modem when I'd visit my parents in
> Florida, never had any problems, it all just worked. I don't remember
> which serial adapters I used (I had 2 different ones) but it wasn't an
> fdti. Before spending too much time I'd suggest trying a different
> serial adapter. Just a thought, does the fdti need firmware? modinfo
> should show if it does.

I should have had a clue. Kind persons from another group reminded me
that I shoud use stty on /dev/ttyUSB0 and sure enough, the adapter
defaults to 9600. Reset that to 115200 with stty and minicom(1) works
as expected.

So the hardware -- USB/serial adapter, cable, sex change plug and
modem all work.

But chat(8) invoked by pppd from dialer script fails.  It appears
that, using chat, no replies are getting back to chat and the modem
isn't responding to AT-commands sent.  Using two shells, one to echo
"AT" to /dev/ttyUSB0 and one to cat /dev/ttyUSB0, the only thing that
comes back from the cat is "AT". So minicom is doing *something* right
that neither chat(8) nor echo/cat are doing.

Probably not a hardware problem any more but any advice welcome
nevertheless.  I'm still stuck, just not head-down. :-)

Tnx,
-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [prev] | [next] | [standalone]

#2865

On 13 Aug 2015, in the Usenet newsgroup comp.os.linux.hardware, in article
<8737zn3bb5.fsf@bogus.nodomain.nowhere>, Mike Spencer wrote:

>> Mike Spencer <mds@bogus.nodomain.nowhere> wrote:

>>> I want to use a USR 56K serial modem with a late-model Acer laptop
>>> (no serial port).  Nothing seems to reaching the modem.

>I should have had a clue. Kind persons from another group reminded me
>that I shoud use stty on /dev/ttyUSB0 and sure enough, the adapter
>defaults to 9600. Reset that to 115200 with stty and minicom(1) works

OK

>But chat(8) invoked by pppd from dialer script fails.  It appears
>that, using chat, no replies are getting back to chat and the modem
>isn't responding to AT-commands sent.

Commands used?  Options?    What is in the logs?

----------------------------------------------------------------------
/usr/sbin/pppd user ibuprofin@example.com lock crtscts nodetach 115200
defaultroute modem noipdefault /dev/ttyACM0 connect "/usr/sbin/chat -v
ABORT BUSY \"\" AT\&F1 OK ATDT2662902 CONNECT \"\d\c\""
----------------------------------------------------------------------

That's one long (199 character) line, with a USR 5637 USB modem rather
than an adapter, and /etc/ppp/options is renamed to get it out of the
way.    /var/log/messages then shows

Aug 13 12:25:37 planck chat[4933]: abort on (BUSY)
Aug 13 12:25:37 planck chat[4933]: send (AT&F1^M)
Aug 13 12:25:37 planck chat[4933]: expect (OK)
Aug 13 12:25:38 planck chat[4933]: AT&F1^M^M
Aug 13 12:25:38 planck chat[4933]: OK
Aug 13 12:25:38 planck chat[4933]:  -- got it
Aug 13 12:25:38 planck chat[4933]: send (ATDT2662902^M)
Aug 13 12:25:38 planck chat[4933]: expect (CONNECT)
Aug 13 12:25:38 planck chat[4933]: ^M
Aug 13 12:26:01 planck chat[4933]: ATDT2662902^M^M
Aug 13 12:26:01 planck chat[4933]: CONNECT
Aug 13 12:26:01 planck chat[4933]:  -- got it
Aug 13 12:26:01 planck chat[4933]: send (\d)
Aug 13 12:26:02 planck pppd[4929]: Serial connection established.

You might also add "dryrun" or "dump" to the pppd command to see what
magic spells you are calling from where, and then compare that data to
your minicom setup.

        Old guy

[toc] | [prev] | [next] | [standalone]

#2866

Hi Old Guy --

Coming to my rescue again?  I'm still grateful for last time.

"Last time", though, was problem with the new operators of an ISP
firing up software out of the box without anyone there having a clue
about how the system worked. (Compounded by their trashing their
authentication system at the same time.)

This time it appears to be about making the USB/serial adapter and the
tty that it presents to the Linux system work right.

Moe Trin <ibuprofin@painkiller.example.tld.invalid> writes:

> Commands used?  Options?    What is in the logs?

Lets go right to the logs.  I'll append the pppd command and the
chat(8) script below. I have a shell script that invokes pppd with
options, one of which is a separate chat script.

(I know, I have to tweak syslog.conf to get pppd logging in one
place.)

After running my script, syslog says:

   Aug 15 00:45:20 roadgrime pppd[14015]: Connect script failed

/var/log/debug says:

   Aug 15 00:45:20 roadgrime pppd[14015]: Script /home/mds/bin/ppp-on-dialer
                   finished (pid 14020), status = 0x3

No other data from pppd or chat is logged. When pppd runs and tries
to run the chat script, DTR lights on the modem.  Then there is one
blink on RD and one on SD. And that's it; hangs, then exits with
error 3. I never get far enough to have a problem with the config of
pppd itself.

Exit code 3 for chat(8) means:

    3   A timeout event occurred when there was an expect string
        without having a "-subsend" string. This may mean that you did
        not program the script correctly for the condition or that
        some unexpected event has occurred and the expected string
        could not be found.

If I set up two shells and do this:

   Shell-1: echo at > /dev/ttyUSB0

   Shell-2: cat /dev/ttyUSB0

   at
   Ê      <- Non-ASCII char here, E-with-a-hat

   OK

That E-with-a-hat line appears to be 0x81 0xCA 0x0A followed by
another extraneous 0x0A.  Might that cause chat to give up?  "...some
unexpected event has occurred and the expected string could not be
found."  It seems like I should be able to run down what 0x81CA is and
where it's coming from but I'm not having much luck.

Minicom works as expected, the "0x81 0xCA 0x0A" doesn't appear nor
does the extra newline after that; just:

   at
   OK

comes back.

Tnx,
- Mike

--- Begin shell script that invokes pppd ---

#!/bin/tcsh -f
#
# TEST TEST: CALLS ppp-on-dialer-test!  
# ------------------------------------
#
#  NOTE Adapter appears to be /dev/ttyUSB0. With cable plugged in but modem
#       not on, cat /proc/tty/driver/serial replies:
# 
#  NOTE That pppd has to be suid root for this to work.
#  NOTE That "noauth" has to be enabled in /etc/ppp/options. Doing it
#       from the command line is allowed only for root.
#
#   Wed 12 Aug 2015
#

setenv TELEPHONE 902-xxx-xxxx        # The telephone number for the connection

setenv  ACCOUNT [my-ISP-username]      # The account name for logon 

set LOCAL_IP = 0.0.0.0       # Local IP address if known. Dynamic = 0.0.0.0
set REMOTE_IP = 0.0.0.0      # Remote IP address if desired. Normally 0.0.0.0
set NETMASK = 255.255.255.0  # The proper netmask if needed
#
# Get a password without putting in this file in plaintext
#

[ shell code to get $PASSWORD from keyboard; elided]

# This is the location of the script which dials the phone and logs
# in. 

set DIALER_SCRIPT = /home/mds/bin/ppp-on-dialer-test



eval /usr/sbin/pppd  debug lock modem crtscts /dev/ttyUSB0 115200 \
     asyncmap 20A0000 escape FF kdebug 0 ${LOCAL_IP}:$REMOTE_IP \
     noipdefault netmask $NETMASK defaultroute connect $DIALER_SCRIPT &

[ shell code to log the connection in ~/; elided]

--- End shell script that invokes pppd ---

--- Begin chat script ---

#!/bin/sh
#
# TALLSHIPS VERSION -- Looks for "Login:" instead of Username:" 
#
# This is part 2 of the ppp-on script. It will perform the connection
# protocol for the desired connection.
#

exec /usr/sbin/chat  -e -V -v                   \
    ECHO ON                                     \
    TIMEOUT      10                             \
    ABORT        '\nBUSY\r'                     \
    ABORT        '\nNO ANSWER\r'                \
    ABORT        '\nNO DIALTONE\r'              \
    ABORT        '\nRINGING\r\n\r\nRINGING\r'   \
    ''           '\rATZ'                        \
    'OK-+++\c-OK' "ATV1Q0&C1&D2X4S0=0H0s7=60"   \
    TIMEOUT        80                           \
    OK        "ATDT$TELEPHONE"                  \
    CONNECT        ''                           \
    ogin:--ogin: $ACCOUNT                       \
    ECHO OFF                                    \
    assword:    $PASSWORD                       \
    SAY "\nChat script done\n"

--- End chat script ---


-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [prev] | [next] | [standalone]

#2867

On 15 Aug 2015, in the Usenet newsgroup comp.os.linux.hardware, in article
<87wpwx86lf.fsf@bogus.nodomain.nowhere>, Mike Spencer wrote:

>Coming to my rescue again?  I'm still grateful for last time.

Well, there's only so many people still using dialin   ;-)

>I have a shell script that invokes pppd with options, one of which is
>a separate chat script.

[planck ~]$ wc /usr/local/bin/dialin
 194  598 5517 /usr/local/bin/dialin
[planck ~]$ wc /etc/ppp/options
  0 0 0 /etc/ppp/options
[planck ~]$

Everything is in the one file, but that's because there are 16 phone
numbers used in rotation.  I created that one 20 years ago, and just
tweak it when I move to a new ISP, distribution/release or computer.

>No other data from pppd or chat is logged. When pppd runs and tries
>to run the chat script, DTR lights on the modem.  Then there is one
>blink on RD and one on SD. And that's it; hangs, then exits with
>error 3. I never get far enough to have a problem with the config of
>pppd itself.

OK - that answers one of my questions - you are able to talk TO the
modem, but it sounds as if the modem can't talk back to you.   Question
for you - what is minicom using for an init-string (minicom -s -> Modem
and dialing -> A)?

>That E-with-a-hat line appears to be 0x81 0xCA 0x0A followed by
>another extraneous 0x0A.  Might that cause chat to give up?

Perhaps - but that MAY be a "locale" problem (isn't "i18n" wonderful?)
with your shell. Redirect the 'cat' output to a file, then use
'/usr/bin/hexdump' to view the file.  It would help to get syslog
configured (depending on your distro, it could be /etc/rsyslog.conf, or
some other strange filename), as what we're interested in is the "chat
-v" dialog.    Chat is ROUGHLY running a language called "expect" and
you see this in the log outputs:

Aug 13 12:25:37 planck chat[4933]: send (AT&F1^M)
Aug 13 12:25:37 planck chat[4933]: expect (OK)
Aug 13 12:25:38 planck chat[4933]: AT&F1^M^M
Aug 13 12:25:38 planck chat[4933]: OK
Aug 13 12:25:38 planck chat[4933]:  -- got it

You might understand it as "grep -q" - where it's looking for a string
of characters that might be buried in a ton of other noise.   Lessee...

  Aug 15 08:26:13  planck chat[19634]: CONNECT

but using a "REPORT CONNECT" string to chat, I see the modem said

  chat:  Aug 15 08:26:13 CONNECT 45333/ARQ/V92/LAPM/V44

so the extra characters are ignored.  It's looking for "CONNECT" and
that's all, and will wait up to TIMEOUT seconds for it before tossing
in the towel.   If you are actually getting a non-ascii sequence, it's
most likely a framing setup with your serial port or something, because
I doubt the modem is speaking Esperanto or Klingon.   Minicom here is
reporting (minicom -s  -> "Serial Port setup") 115200 8N1, but I don't
know enough about the 'stty' command to say what you may need to kick,
or even if that is the right tool (as opposed to perhaps ldattach(8)).

>--- Begin shell script that invokes pppd ---

>#  NOTE That "noauth" has to be enabled in /etc/ppp/options. Doing it
>#       from the command line is allowed only for root.

COMMENT: noauth shouldn't be needed - it's for the case where your
routing table shows a _pre-existing_ route to the IP of the peer, or a
_pre-existing_ default route (where pppd then assumes you're acting as
an ISP, and gets paranoid).  Not hurting anything.

I'm still amazed you can get a working text based login twenty years
after microsoft invented dial-up access (or what-ever).

>eval /usr/sbin/pppd  debug lock modem crtscts /dev/ttyUSB0 115200 \ 
>     asyncmap 20A0000 escape FF kdebug 0 ${LOCAL_IP}:$REMOTE_IP \  
>     noipdefault netmask $NETMASK defaultroute connect $DIALER_SCRIPT &

COMMENT: (it's not causing problem, but) asyncmap, escape, kdebug, the
LOCAL:REMOTE and netmask are not needed.   The 'modem' and 'crtscts'
_MIGHT_ be a problem due to the adapter (a USB port doesn't have the
control wires, even though the serial modem does). I'm not sure how the
/dev/USBn device looks to the kernel - as mentioned, I'm now using a
USB modem directly after the ancient laptop with a USR 5686 external I
was using as a firewall box finally died.

>exec /usr/sbin/chat  -e -V -v                   \ 

COMMENT: (as above) not sure the -e is needed.   Also, that script has
some rather old chestnuts in it.

>    TIMEOUT      10

Used to was, a (conventional) serial port with the IRQ set to the
wrong one would cause a problem here - the old (1.x and 2.x) kernel
would check the serial port for data every twenty-ish seconds - but
this timeout would prevent you from identifying the problem. I've
always left the TIMEOUTs at the default (45 seconds) as altering them
does nothing useful in a "working" system.

>    ABORT        '\nRINGING\r\n\r\nRINGING\r'   \ 
>    ''           '\rATZ'                        \ 
>    'OK-+++\c-OK' "ATV1Q0&C1&D2X4S0=0H0s7=60"   \ 

Your USR is _likely_ to "need" only "AT&F1" to set it to a sane
condition.  (In minicom, "AT$" will most likely return a quick command
reference and "ATI4" will probably show the "current settings" - and
AT&F1 should set things to "factory defaults with hardware flow
control".)  The "HO" command in the init string ("hang up the phone")
is a little counter-intuitive, but I doubt it's breaking anything. The
rest of the string is the same as the factory defaults.  (While "ATZ"
is pretty much a universal init-string, it _resets_ the modem to a user
defined state that was saved to NVRAM with AT&W0 - and that _could_ be
garbage that mis-configures the modem, such as setting ATQ1 which
disables result codes.)

That 'OK-+++\c-OK' sequence came from Al Longyear back in ppp-2.2.0 in
1995.  I don't know about his telco, but if I keep the line "off-hook"
with the modem and not using it, they will eventually disconnect me
and send out a service tech, then bill me for that and the time the
line is off-hook, not in actual use.  I'd much rather know about that
right now (so I can correct the problem) than when I get an
eleventyseven dollar charge I could have avoided.   What your log will
eventually show is something akin to

   chat[4933]: send (ATZ^M)
   chat[4933]: expect (OK)
   chat[4933]: alarm
   chat[4933]: Failed
   chat[4933]: Exit.

with the exit caused by the TIMEOUT expiring without seeing a response
from the modem.

Bottom line - I'd suggest it's still something about the way the serial
line is set up, although it could be a modem or crtscts option not
working as desired or (heck of a slim chance) something dodgy saved to
NVRAM on the modem.  You could try deleting those two options and set
the init string to AT&F1 (rather than ATZ) to see if you can get any
response from the modem.

        Old guy

[toc] | [prev] | [next] | [standalone]

#2868

Moe Trin <ibuprofin@painkiller.example.tld.invalid> writes:

> On 15 Aug 2015, in the Usenet newsgroup comp.os.linux.hardware, in article
> <87wpwx86lf.fsf@bogus.nodomain.nowhere>, Mike Spencer wrote:
> 
>>Coming to my rescue again?  I'm still grateful for last time.
> 
> Well, there's only so many people still using dialin   ;-)

There are so many that *aren't* that we get forgotten.  Grumble.

>> No other data from pppd or chat is logged. When pppd runs and tries
>> to run the chat script, DTR lights on the modem.  Then there is one
>> blink on RD and one on SD. And that's it; hangs, then exits with
>> error 3. I never get far enough to have a problem with the config of
>> pppd itself.
> 
> OK - that answers one of my questions - you are able to talk TO the
> modem, but it sounds as if the modem can't talk back to you. 

Yes, that seems to be the case.  Or rather, that chat doesn't
understand what the modem sends back. 

> Question for you - what is minicom using for an init-string (minicom
> -s -> Modem and dialing -> A)?

Default is s7=45 S0=0 L1 V1 X4 &c1 E1 Q0.  Inserting that into the
very first line of the chat script doesn't help.

> 
> >That E-with-a-hat line appears to be 0x81 0xCA 0x0A followed by
> >another extraneous 0x0A.  Might that cause chat to give up?
> 
> Perhaps - but that MAY be a "locale" problem (isn't "i18n" wonderful?)
> with your shell. Redirect the 'cat' output to a file, then use
> '/usr/bin/hexdump' to view the file. 

That's essentially how I got the hex values cited.

> It would help to get syslog configured (depending on your distro, it
> could be /etc/rsyslog.conf, or some other strange filename), as what
> we're interested in is the "chat -v" dialog.  Chat is ROUGHLY
> running a language called "expect" and you see this in the log
> outputs:

Did that. And it looks like I may have progress to report after making
a tiny change in the chat script.  But of course, I can only test it
on the *other* modem, the one not connected to the phone line because,
you know, I'm *using* the phone line to read c.o.l.h.

> COMMENT: noauth shouldn't be needed - it's for the case where your
> routing table shows a _pre-existing_ route to the IP of the peer, or a
> _pre-existing_ default route (where pppd then assumes you're acting as
> an ISP, and gets paranoid).  Not hurting anything.

I have a default route to my LAN router.  pppd insisted it didn't want
to play without nouauth.

> I'm still amazed you can get a working text based login twenty years
> after microsoft invented dial-up access (or what-ever).

Yeah.  Local ISP is keeping it simple.  The last problem was with our
*other* ISP, a big corporation that apparently whapped all of an
existing ISP's system into their own hardware (among other
corp/contract/biz-related problems.)

> Bottom line - I'd suggest it's still something about the way the serial
> line is set up...

My thought, too.  But I see that I'm getting more blinkenlights and
more logged chat(8) data than before so I'm keen to get off line, plug
in the other modem and see what that means.

More later...

-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [prev] | [next] | [standalone]

#2870

On 16 Aug 2015, in the Usenet newsgroup comp.os.linux.hardware, in article
<877fovgapa.fsf@bogus.nodomain.nowhere>, Mike Spencer wrote:

>Moe Trin <ibuprofin@painkiller.example.tld.invalid> writes:

>> Question for you - what is minicom using for an init-string (minicom
>> -s -> Modem and dialing -> A)?

>Default is s7=45 S0=0 L1 V1 X4 &c1 E1 Q0.  Inserting that into the
>very first line of the chat script doesn't help.

Now THAT'S strange.   I'm somewhat surprised it works, because USRs
didn't like "mixed case" commands.  Lessee:

  command                       set here     AT&F1 default
   E1 Echo Command Chars            1              1
   L1 Speaker Volume                1 (low)        2 (medium)
   Q0 Result Codes On               0              0
   S0 rings to answer (0=off)       0              0
   S7 no answer timeout            45             60
   V1 Verbal Responses              1              1
   X4 Advanced Result Codes         4              4
  &C1 Modem Controls CD             1              1

so the only differences are speaker volume and the time that the modem
waits before giving up. Your dialing script sets the timeout to 80
seconds, so the modem will give up before the chat script times out
(and give a "NO ANSWER" result code for chat to abort on).

>And it looks like I may have progress to report after making a tiny
>change in the chat script.  But of course, I can only test it on the
>*other* modem, the one not connected to the phone line because, you
>know, I'm *using* the phone line to read c.o.l.h.

Yeah - it's always those "tiny" things. I used to run a program called
"slrnpull"

[planck ~]$ whatis slrnpull
slrnpull (1)         - Pull a small newsfeed for offline reading.
[planck ~]$

which allowed me to read off-line. Now, I simply save a copy of what I
want to reply to, and compose off-line.

>I have a default route to my LAN router.  pppd insisted it didn't want
>to play without nouauth.

Yup - and that's a problem (second reply).

>> Bottom line - I'd suggest it's still something about the way the
>> serial line is set up...

>My thought, too.  But I see that I'm getting more blinkenlights and
>more logged chat(8) data than before so I'm keen to get off line, plug
>in the other modem and see what that means.

Like "Progress" - even if I don't work for G.E.  ;-)

        Old guy

[toc] | [prev] | [next] | [standalone]

#2869

Got  it!  

In my chat(8) script, the initial expect sequence was:

  ''     '\rATZ'

No recollection of why I have the '\r' there -- lost in the mists of
time and it has worked that way on sevral versions of Slackware and
different computers.

Changed it to:

  ''     'ATZ'

and everything proceeds as it should, dialing, logging into the ISP
and passing control to pppd. I have *no* *idea* why '\r' works on
bogus (desktop) but not on roadgrime (laptop) with the same model of
modem. 

Now I have another problem but it's nothing to do with hardware.  It's
something to do with my route setup.  I've had no trouble with routes
using the laptop on my LAN, on cabled broadband at a friend's or at
wifi points.  But successful connection of ppp0 to my ISP's host
leaves me cut off from all the net but the machine that hosts the
other end of ppp.

Well, a different problem.  The USB/serial tech is working.

Moe Trin <ibuprofin@painkiller.example.tld.invalid> writes:

> [lots of suggestions and some yarns as well.]

Thanks for your attention, OG.

Best,
-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [prev] | [next] | [standalone]

#2871

On 16 Aug 2015, in the Usenet newsgroup comp.os.linux.hardware, in article
<8737zjg7zz.fsf@bogus.nodomain.nowhere>, Mike Spencer wrote:

>Got  it!  

GREAT!

>In my chat(8) script, the initial expect sequence was:
>
>  ''     '\rATZ'
>
>No recollection of why I have the '\r' there -- lost in the mists of
>time and it has worked that way on sevral versions of Slackware and
>different computers.

I was going to say that's Al Longyear (the guy who adapted ppp for
Linux), but I think that actually came from the original PPP-HOWTO by
Robert Hart from the mid-90s.

>Changed it to:
>
>  ''     'ATZ'
>
>and everything proceeds as it should,

Great!   Mentioned - I'd recommend making that 'AT&F1'

>I have *no* *idea* why '\r' works on bogus (desktop) but not on
>roadgrime (laptop) with the same model of modem. 

It's likely the adapter, but not a big deal.  \r is a carriage return
likely left in the UART from a previous command.  Not a good thing to
be looking for, as what you are actually looking for is "" (nothing)
before sending the first command.

>Now I have another problem but it's nothing to do with hardware.  It's
>something to do with my route setup.  I've had no trouble with routes
>using the laptop on my LAN, on cabled broadband at a friend's or at
>wifi points.  But successful connection of ppp0 to my ISP's host
>leaves me cut off from all the net but the machine that hosts the
>other end of ppp.

Yup, there should be an error message - "pppd not replacing an existing
default route". The "ANU" version of PPP was written by people with
paranoia, and having a default route when an existing local network is
present is often a security issue (back-door around the firewall on the
LAN).   Some versions of pppd have a "replacedefaultroute" option, but
it's very distribution dependent, and the ANU authors (Paul Mackerras
and James Carlson) declined to have anything to do with that idea.   My
way "around" this is

[planck ~]$ head -6  /usr/local/bin/dialin
#!/bin/bash
/sbin/route | /bin/grep -q "default"
if [ $? -eq 0 ] ; then
  echo "Pre-existing default route - delete that"
  exit 1
fi
[planck ~]$

(I was a network admin before I retired, so I appreciate the security
concerns of the pppd authors).   It's even more of a mess, because the
way the routing code in the kernel works.   When there are two or more
routes to the "same" place with equal metrics and network mask, it uses
the "last" one declared, under the philosophy that the admin had screwed
up the first route command, and was correcting the mistake (and failed
to delete the mistake in the hurry to get things working).

The concept is something like if you have an existing default route,
why are you wasting time/effort to create a second using pppd, and if
the existing default doesn't lead to the world, why is it there?    ;-)
I'm old fashioned here, and use static addressing on my lan, and the
box with the modem is a firewall.  Hosts on the LAN all have that box
as their default route.  Two of the laptops also have modem setups,
which is not used that often (but that's the reason for those six lines
above) as they usually are connected with Ethernet to the LAN.

        Old guy

[toc] | [prev] | [next] | [standalone]

#2872

Moe Trin <ibuprofin@painkiller.example.tld.invalid> writes:

> (I was a network admin before I retired, so...

Oh, good.  I was a blacksmith before I retired.  (Well, I'm still a
blacksmith but I'm slacking off.)  So your comments on the routing fail
after modem connect saved for reference.

I'll see what I can do.  Watch this space. :-)

-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [prev] | [next] | [standalone]

#2873

On Sun, 16 Aug 2015, Mike Spencer wrote:

>
> Moe Trin <ibuprofin@painkiller.example.tld.invalid> writes:
>
>> (I was a network admin before I retired, so...
>
> Oh, good.  I was a blacksmith before I retired.  (Well, I'm still a
> blacksmith but I'm slacking off.)  So your comments on the routing fail
> after modem connect saved for reference.
>
For some reason, I thought you'd taken up blacksmithing in retirement.

   Michael

> I'll see what I can do.  Watch this space. :-)
>
> -- 
> Mike Spencer                  Nova Scotia, Canada
>

[toc] | [prev] | [next] | [standalone]

#2875

Michael Black <et472@ncf.ca> writes:

> On Sun, 16 Aug 2015, Mike Spencer wrote:
> 
>> Moe Trin <ibuprofin@painkiller.example.tld.invalid> writes:
>>
>>> (I was a network admin before I retired, so...
>>
>> Oh, good.  I was a blacksmith before I retired.  (Well, I'm still a
>> blacksmith but I'm slacking off.)
> 
> For some reason, I thought you'd taken up blacksmithing in retirement.

Nope.  Bert Shaw gave me some pointers in '67, bought a forge and
anvil the same year, started trying to make money with smithing in
'69, attended the first big international blacksmithing conference in
'76 in Carbondale, Ill.  That was an enormous inspiration, bought a
big old general store for a studio in '77.  Been doing it ever since.
Built a new shop at home in 2003.

See my web page:

    http://home.tallships.ca/mspencer/index.html

Pretty pics at:

    http://home.tallships.ca/mspencer/gallery.html

My original, pre-1977 shop:

    http://home.tallships.ca/mspencer/temp/shed.html

-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [prev] | [next] | [standalone]

#2874

Moe Trin <ibuprofin@painkiller.example.tld.invalid> writes:

> On 16 Aug 2015, in the Usenet newsgroup comp.os.linux.hardware, in article
> <8737zjg7zz.fsf@bogus.nodomain.nowhere>, Mike Spencer wrote:
> 
>> Now I have another problem but it's nothing to do with hardware.  It's
>> something to do with my route setup.  I've had no trouble with routes
>> using the laptop on my LAN, on cabled broadband at a friend's or at
>> wifi points.  But successful connection of ppp0 to my ISP's host
>> leaves me cut off from all the net but the machine that hosts the
>> other end of ppp.
> 
> Yup, there should be an error message - "pppd not replacing an existing
> default route". 

Just so.

> (I was a network admin before I retired, so I appreciate the security
> concerns of the pppd authors).   It's even more of a mess, because the
> way the routing code in the kernel works.   When there are two or more
> routes to the "same" place with equal metrics and network mask, it uses
> the "last" one declared, under the philosophy that the admin had screwed
> up the first route command, and was correcting the mistake (and failed
> to delete the mistake in the hurry to get things working).

Interesting. I don't fully understand how to make the route(8) command
do the right thing but I took your advice and did "route del
default".  And the laptop->adapter->modem->dialin->ppp->internet
process is working.  And the laptop still talks to my localnet as it
should.  I could have posted this from the laptop but I like to have
my Usenet interaction logged on my main machine do I didn't.  

> I'm old fashioned here, and use static addressing on my lan...

Me too.  And I have masquerade working and can do it that way.  I just
wanted have this dialup functionality available, too.

> ...and the box with the modem is a firewall.  Hosts on the LAN all
> have that box as their default route.  Two of the laptops also have
> modem setups, which is not used that often (but that's the reason
> for those six lines above) as they usually are connected with
> Ethernet to the LAN.

Thanks for your help & best wishes,  Old guy.

-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [prev] | [next] | [standalone]

#2876

On 17 Aug 2015, in the Usenet newsgroup comp.os.linux.hardware, in article
<87io8e4ep6.fsf@bogus.nodomain.nowhere>, Mike Spencer wrote:

>Moe Trin <ibuprofin@painkiller.example.tld.invalid> writes:

>>Mike Spencer wrote:

>>> I've had no trouble with routes using the laptop on my LAN, on
>>> cabled broadband at a friend's or at wifi points.  But successful
>>> connection of ppp0 to my ISP's host leaves me cut off from all the
>>> net but the machine that hosts the other end of ppp.

>> Yup, there should be an error message - "pppd not replacing an
>> existing default route". 

>Just so.

Almost had to be

>I don't fully understand how to make the route(8) command
>do the right thing

----------
# Version:      @(#)/etc/rc.d/rc.inet1  1.01    05/27/93

# Edit for your setup.

IPADDR="192.168.1.2"       # REPLACE with YOUR IP address!
NETMASK="255.255.255.0"    # REPLACE with YOUR netmask!
NETWORK="192.168.1.0"      # REPLACE with YOUR network address!
BROADCAST="192.168.1.255"  # REPLACE with YOUR broadcast address if you
                           # have one. If not, leave blank and edit
                           # below.
#GATEWAY="128.253.154.1"   # REPLACE with YOUR gateway address!

# Uncomment these to set up your IP routing table.

/sbin/route add -net ${NETWORK} netmask ${NETMASK} eth0
#/sbin/route add default gw ${GATEWAY} netmask 0.0.0.0 metric 1

# End of rc.inet1
----------

Notice the two lines dealing with GATEWAY are commented out.  Oh, wait,
you're probably not running Slackware 2.3 any more... ;-)  Most distros
today use some variation of NetworkMismanager originally created by
Robert Love for SuSE, or have their own distro-specific tool (that
they're sure is better than those other distributions methods, but
that's been common for many years).    If your local setup has no route
to the world, you should not declare a "GATEWAY".  If the LAN does have
one, why are you mucking around...   ;-)   Since about linux-2.2.0 or
so, the "ifconfig" command automatically added a network route when you
brought up an Ethernet or loopback interface, so "route -n" might look
like (although the loopback may not be shown on newer kernels):

[van-allen ~]$ /sbin/route -n
Kernel IP routing table
Destination   Gateway       Genmask        Flags Metric Ref   Use Iface
192.168.1.0   0.0.0.0       255.255.255.0  U     0      0    4198 eth0
127.0.0.0     0.0.0.0       255.0.0.0      U     0      0      20 lo
[van-allen ~]$

This would handle all "local" traffic.  If you have a "route to the
world", it's then declared using the "/sbin/route add default" stanza.
A minor problem is lazy admins, who use the "default" as a shotgun when
adding a second or third LOCAL network (perhaps wireless, or a DMZ or
something).  That should be done without using that "default" keyword.

[example ~]$ /sbin/route -n
Kernel IP routing table
Destination   Gateway       Genmask        Flags Metric Ref   Use Iface
192.168.1.0   0.0.0.0       255.255.255.0  U     0      0   89948 eth0
192.168.2.0   192.168.1.6   255.255.255.0  UG    0      0   32165 eth0
127.0.0.0     0.0.0.0       255.0.0.0      U     0      0     388 lo
0.0.0.0       192.168.1.248 0.0.0.0        UG    0      0    2673 eth0
[example ~]$

Here, a second local net (192.168.2.0/24) is reachable through a
router at 192.168.1.6.  That's obviously quite different than the route
to the world reachable through 192.168.1.248.  The second route was
created with the command

  /sbin/route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.1.6

The use of the "netmask" indicates the reachable address range (as
opposed to the "netmask 0.0.0.0" and/or "default" above).  You may also
have a route looking like

169.254.0.0   0.0.0.0       255.255.0.0    U     1      0       0 eth0

which is a Apple/microsoft thing called LinkLocal (RFC3927) also called
ZeroConf, meant for situations where there is no (routable) network
configuration. This is the same concept as the IPv6 addresses in the
"fe80::" range (RFC4291). 

Some people prefer to use the "ip(8)" command rather than "route(8)",
while others prefer to let the install program set up NotworkManager
and hope for the best. Others use DHCP, in which case virtually all the
details are handled in the DHCP server (which is often the router or
"modem" provided by the ISP).

Notwithstanding the disparaging comments about NetworkMismanager, it
often comes in handy on a laptop that is meant to operate at public
hotspots away from home IN ADDITION TO operating on the Ethernet LAN
at home.  Being old-fashioned (and having the root password), I prefer
to do things "manually" (static Ethernet setup, and essentially DHCP
for the rare occasions when the laptops are "outside".

>I took your advice and did "route del default".  And the
>laptop->adapter->modem->dialin->ppp->internet process is working.  And
>the laptop still talks to my localnet as it should.

Yup.  Long ago when broadband wasn't as reliable, it was fairly common
to have a dialin as a backup.  People usually wanted it to be a
transparent thing, but that is easier said than done.  Merely switching
the default route (from the "router" to a box with a modem) is much
simpler to do.  Any existing downloads (or equal) would have to be
restarted, because the world would see you at a "new" IP address.

>> I'm old fashioned here, and use static addressing on my lan...

>Me too.  And I have masquerade working and can do it that way.  I just
>wanted have this dialup functionality available, too.

So you have a route to the world via the LAN, and this dialup would
be something like a backup?  What I usually recommend for that is to
manually down the Ethernet (or just the default) route before running
pppd, and manually bring it back up afterwards.  It _can_ be done via
the /etc/ppp/ip-{up|down}{|.local} scripts, but it's a bit of a hassle.

        Old guy

[toc] | [prev] | [next] | [standalone]

#2877

Moe Trin <ibuprofin@painkiller.example.tld.invalid> writes:

> Most distros today use some variation of NetworkMismanager
> originally created by Robert Love for SuSE, or have their own
> distro-specific tool (that they're sure is better than those other
> distributions methods, but that's been common for many years).

Slack 14 came with Networkmanager and wicd.  Networkmanager won't work
unless you have a "task bar" to which it can, I'm supposing, iconify
itself.  I use X all the time but with twm window manager: no task
bar.  So I use wicd with curses in an xterm.  On my LAN I kill wicd
and let the config in rc.inet1.conf take over using static local
addresses and a cable to a pretty ancient router.  Elsewhere, I run
wicd which allows me to select from whatever cabled or wifi access is
available, ignoreing the config in /etc/rc.d/inet*.


> If your local setup has no route to the world, you should not
> declare a "GATEWAY".

That's the usual, default setup.

> If the LAN does have one, why are you mucking around...  ;-)

No connection to the world unless I've started ppp (home) or wicd
(laptop, away).  I don't recall exactly what problems I've had with
route(8) in the past.  I think maybe getting a box at home to talk to
the wireless router via wifi.  I forget.  Your remarks saved for when
the problem arises again.


> Some people prefer to use the "ip(8)" command rather than
> "route(8)"... 

Ah, another new one for me.  Jeez, the manpage looks even more
intimidating than the route(8) manpage.  But I'll give it a scrute.


> Notwithstanding the disparaging comments about NetworkMismanager, it
> often comes in handy on a laptop that is meant to operate at public
> hotspots away from home IN ADDITION TO operating on the Ethernet LAN
> at home.  Being old-fashioned (and having the root password), I prefer
> to do things "manually" (static Ethernet setup, and essentially DHCP
> for the rare occasions when the laptops are "outside".

Same, except s/NetworkMismanager/wicd/.

>>> I'm old fashioned here, and use static addressing on my lan...
> 
>> Me too.  And I have masquerade working and can do it that way.  I just
>> wanted have this dialup functionality available, too.
> 
> So you have a route to the world via the LAN, and this dialup would
> be something like a backup?

Backup in case the main desktop itself fails.  There's a "route to the
world" via the LAN if and only if the my main desktop is connected by
ppp.  I'm running Slackware 11, 2.4 kernel, a couple of really old
browsers on the main box. On a very few occasions, I need to have the
services of a much more recent browser, one that won't run with the
2.4 kernel's libs.  Annoyingly enough, even that failed recently.  The
version of Firefox distributed with the most recent Slackware release
(14.1) failed to render readably the particular data I was after.  Had
to save the page as a collection of files, find the right file, hand
it to lynx -dump to get a few lines of critical text.  Normally I
simply forego anything that has too much cute for the old browser to
render it readbly (albeit without eyecandy) but this was an unusual
case.


Tnx,
-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [prev] | [next] | [standalone]

#2878

On 18 Aug 2015, in the Usenet newsgroup comp.os.linux.hardware, in article
<871tf0wgoq.fsf@bogus.nodomain.nowhere>, Mike Spencer wrote:

>I use X all the time but with twm window manager: no task bar.  So I
>use wicd with curses in an xterm.

"A mouse is a device used to point at the xterm you want to type in."

>On my LAN I kill wicd and let the config in rc.inet1.conf take over
>using static local addresses and a cable to a pretty ancient router.
>Elsewhere, I run wicd which allows me to select from whatever cabled
>or wifi access is available, ignoreing the config in /etc/rc.d/inet*.

It's only the laptops here that go walkies - and that's not all that
common.

>> If the LAN does have one, why are you mucking around...  ;-)

>No connection to the world unless I've started ppp (home)

man pppd    and look at the following options:

   active-filter filter-expression
   demand
   holdoff n
   idle n 

Essentially, you start pppd at boot, and it remains inactive until there
is traffic that will need the pppd link (which then brings up the link),
"idle" then brings the link down so many seconds after traffic
("controlled" by the active-filter) and keeps it off for "holdoff"
seconds if it needs to be brought back up quickly.   Your aps on the
other systems have to be a little tolerant of the start-up delay.
Another way to do it is to have a log-reader on the box with the modem
(something along the concept of "blockhosts", "denyhosts", "fail2ban" or
"sshguard" or similar) and have that tools bring up the link when you
hit the box with a packet to an otherwise closed port - with a script
that uses something like netcat (nc) to generate the trigger packet.  Of
course, you _could_ always walk over to the box with the modem in it...

>I don't recall exactly what problems I've had with route(8) in the
>past.  I think maybe getting a box at home to talk to the wireless
>router via wifi.  I forget.

That's the usual. The rule is basically "one declared route (working or
not) to any destination". If you have a default route on the LAN, you've
got to do "something" to bring that down in order to use any other
(wifi, on-board modem, or a different router).

>> Some people prefer to use the "ip(8)" command

>Ah, another new one for me.  Jeez, the manpage looks even more
>intimidating than the route(8) manpage.  But I'll give it a scrute.

It has it's uses, but I tend to remain with ifconfig(8) and route(8).
Old habits and all that...

>> So you have a route to the world via the LAN, and this dialup would
>> be something like a backup?

>Backup in case the main desktop itself fails.  There's a "route to the
>world" via the LAN if and only if the my main desktop is connected by
>ppp.

Gotcha!  Yeah, the only real solution there is to manually down the
default route on the backup box when you want to use it for dial-out.

        Old guy

[toc] | [prev] | [next] | [standalone]

#2879

Moe Trin <ibuprofin@painkiller.example.tld.invalid> writes:

> "A mouse is a device used to point at the xterm you want to type in."

Ah, a fellow KISS fan. :-) I got started on Unix by going from CP/M at
home to hanging out, circa '89, with some folks who sat me in front of
a 21" color monitor connected to a MicroVAX or the like, (very hot,
not to mention expensive, stuff at the time, like getting out of a '59
Volkswagen and into the cockpit of the space shuttle), gave me a few
manuals and said, "Do Something interesting".  Those machines use a
Posix non-compliant wm (uwm, Ultrix Window Manager, IIRC) with no
borders, buttons or other trim.  With Linux at home, I've moved up to
twm and stuck there.

> It's only the laptops here that go walkies - and that's not all that
> common.

Same here.

> man pppd    and look at the following options:
> 
>    active-filter filter-expression
>    demand
>    holdoff n
>    idle n 
> 
> Essentially, you start pppd at boot, and it remains inactive until there
> is traffic that will need the pppd link (which then brings up the link),
> "idle" then brings the link down so many seconds after traffic
> ("controlled" by the active-filter) and keeps it off for "holdoff"
> seconds if it needs to be brought back up quickly. 

I don't do it that way.  But normally, I access the net (from home,
via ppp) with only my main box.  That's gradually changing because
there's one site -- there'll eventually be more -- for which I have to
use the recent browser on the laptop to render it readably.  Normally,
I connect, do mail, news, web etc. just from the one machine with a
modem plugged into it. (And use a very old browser, so old that it
doesn't support any of the popular attack vectors.)


>> [Modem & dialup from laptop is] Backup in case the main desktop
>> itself fails.  There's a "route to the world" via the LAN if and
>> only if the my main desktop is connected by ppp.
> 
> Gotcha!  Yeah, the only real solution there is to manually down the
> default route on the backup box when you want to use it for dial-out.

Right. All your remarks and pointers saved for lookup next time.  And
there's always a next time.  :-) I once asked, on our local Linux
mailing list, about implementing analog audio from a CD drive. Was
instructed about installing the right cable that was missing.  Did
that, all was well.  Some weeks later I was gently reproved for asking
what appeared to be the same question over again.  But it wasn't the
same.  I had bought a new internal CD drive, found and plugged in the
right cable, got no sound.  Eventually, after grovelling around the
net, found the mfgr's manual for the drive.  The physical plug for
analog audio was provided on the drive but marked on the manual's
diagram as "not implemented".  Grumble.  The fellow who had reproved
me opined that that was "not fair" by way of apology. :-)

-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [prev] | [next] | [standalone]

#2880

On 25 Aug 2015, in the Usenet newsgroup comp.os.linux.hardware, in article
<8737z82ccz.fsf@bogus.nodomain.nowhere>, Mike Spencer wrote:

Moe Trin <ibuprofin@painkiller.example.tld.invalid> writes:

>> "A mouse is a device used to point at the xterm you want to type in."

>Ah, a fellow KISS fan. :-) I got started on Unix by going from CP/M at
>home to hanging out, circa '89, with some folks who sat me in front of
>a 21" color monitor connected to a MicroVAX or the like,

I honestly don't recall when I started with CP/M - I was a government
contractor in the 1970s, and was prohibited from working from home (and
not supposed to do more than 5 8 hour days a week). I finally got an
Osborne 1 in mid 1981.  I'd been clanking away on a ASR-33 connected to
a PDP-11 running BSD4 at work, although that wasn't my primary job.

>gave me a few manuals and said, "Do Something interesting".

Place I worked at had a "requirement" that employees were to take
continuing education courses at local colleges, and I found an "Intro
To Unix" class, that was taught on SGI workstations running IRIX
4.something.  The instructor concentrated on shell scripting, which got
more and more complex as the course continued.   His major stress was
for you to actually look at the data you were working with, and think!

[planck ~]$ echo $HISTSIZE
1000
[planck ~]$ history | sed 's/[^|]//g' | grep -v '^$' | wc -c
98
[planck ~]$

So, of the last 1000 commands issued from "this" shell, I've used 98
pipes to take command output to another command input.  (Look at your
"history" output, then pipe it through the "sed", then pipe it through
the "grep -v" to see the progression.)

[demand mode ppp]

>I don't do it that way.  But normally, I access the net (from home,
>via ppp) with only my main box.

At the previous house, we had an unreliable broadband and three phone
lines (regular, plus one paid for by the company I worked for, and one
paid for by the company my wife worked for - the company lines being
used for dialup to the companies).  I wound up with a salvaged 386SX
laptop that had a broken display and an unreliable keyboard. I was
able to get two Ethernet ports working on it, plus the serial port.  It
became the rather dumb firewall as well as allowing dialup to an ISP
when the broadband was down.  The workstations were all pointed at the
firewall (which was masquerading), so they didn't care if the next hop
was broadband or wet string.

>That's gradually changing because there's one site -- there'll
>eventually be more -- for which I have to use the recent browser on the
>laptop to render it readably.

Is it because that site is paying attention to the "User Agent" string,
or because they want to use Java, Active-X or microsoft Virus Installer
Pro (Home Edition)?

[planck ~]$ cat ~/bin/mosaic
/usr/bin/wget -U Mosaic-2.6b1 $*
[planck ~]$

>Normally, I connect, do mail, news, web etc. just from the one machine
>with a modem plugged into it. (And use a very old browser, so old that
>it doesn't support any of the popular attack vectors.)

;-)

        Old guy

[toc] | [prev] | [next] | [standalone]

#2881 — All better now (Re: Talk to modem with USB to serial adapter: fail)

Moe Trin <ibuprofin@painkiller.example.tld.invalid> writes:

> On 25 Aug 2015, in the Usenet newsgroup comp.os.linux.hardware, in article
> <8737z82ccz.fsf@bogus.nodomain.nowhere>, Mike Spencer wrote:
> 
>> That's gradually changing because there's one site -- there'll
>> eventually be more -- for which I have to use the recent browser on
>> the laptop to render it readably.
> 
> Is it because that site is paying attention to the "User Agent" string,
> or because they want to use Java, Active-X or microsoft Virus Installer
> Pro (Home Edition)?

It's because it's heavy to javascript to create a cute interactive
site.  My usual browser, Netscape 4.76 for Linux, is so old that it's
notion of js is too primitive for current "web designer" hacks.

Which leads me to another problem that turned up last night.
Connecting to the Lee Valley tools site -- my very first attempt at
on-line shopping -- I was unable to complete the transaction using the
recent browser on the newish laptop when doing Masquerade/NAT through
my dialup-connected main box.  Disconnecting, reconnecting by using
dialup directly from the laptop (the successful consequence of our
recent exchange), everything worked as expected.  I suppose not a
hardware problem but why might a masqueraded connection hang?  Not a
firewall oversight since the iptables rules I set up for masquerade
were very simple.

So I got where I wanted to go but don't understand why masquerade hung
at the point of "check-out".

> [planck ~]$ cat ~/bin/mosaic
> /usr/bin/wget -U Mosaic-2.6b1 $*

Ha.  I've actually used Mosaic on some academic Unix workstations.
Watched part of a movie as part of the proof of concept setup on their
(quite sophisticated) local net.



-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.os.linux.hardware

csiph-web