Modem Conexant Accessrunner su Linux

[akyra]

posto qui per tutti quelli che in privato mi hanno chiesto info su come far funzionare i modem usb basati su chipset Conexant Acessrunner.
Premetto che io ho un modem Hamlet hdsl 640 che funziona correttamente sotto Slackware 10, col kernel 2.4.26, per cui la guida si riferisce a quella distro con quel kernel, anche se altre distro con lo STESSO kernel dovrebbero funzionare correttamente, se seguite ed installare tutto quello che vi viene richiesto.
L'how to prevede operazioni come "compilazione e installazione da sorgenti", ed anche "ricompilazione Kernel", tutti argomenti che qui non vengono trattati.

l'how to si trova
qui

linux-atm-2.4.1.tar.gz

libcap-0.8.3

ppp-2.4.2.cnl.tar.gz

cxacru-2003-10-5.src.tgz


a me funziona tutto correttamente, quindi non vedo il motivo per cui anche agli altri non dovrebbe funzionare...

[DnA[TF]]

l'how dov'è + precisamente?? link esatto please

Ps: secondo te partendo da 0 posso capirci qlc???

[akyra]

il link a me funziona...
comunque, lo allego anche qui se serve.

Per installare il modem, come per poter usare linux con profitto (del resto) bisogna affrontare alcuni preconcetti che non possono essere ignorati, tipo la compilazione e l'installazione di programmi da sorgenti...per cui se sei alle prime armi, l'installazione del modem sarà ostica, non lo nego...

[ilsensine]

Originariamente inviato da akyra
il link a me funziona...

Neanche a me funziona boh...

comunque, lo allego anche qui se serve

Accettiamo anche .tar.gz

[akyra]

Originariamente inviato da ilsensine
Neanche a me funziona boh...

Accettiamo anche .tar.gz

è vero, non avevo visto....
(e sarebbe anche più consono visto che parliamo di Linux....)

comunque se fate "save link target as..." il link funzia!

[ilsensine]

Alcune note sull'howto, per semplificare un pò le cose:
- libpcap sono già fornite con le distribuzioni; c'è un motivo specifico per usare la ver. 0.8.3 e non (ad es.) la 0.8.1?
- pppd 2.4.2 dovrebbe essere disponibile nelle ultime distribuzioni. A meno che quello che hai linkato non contiene patch particolari, non è necessario ricompilarlo. E' necessario ovviamente inserire il percorso corretto per pppatm.so nel file di configurazione.
- Ricompilare il kernel non è necessario, non ne vedo il motivo

Quindi, con un pò di fortuna, tutto potrebbe ridursi a installare il driver cxacru. Quetso driver _richiede_ la presenza dei sorgenti del kernel in esecuzione, che normalmente sono forniti dalle distribuzioni.

Puoi verificare le fesserie che ho detto?

[ilsensine]

Originariamente inviato da akyra
comunque se fate "save link target as..." il link funzia!

-ENOBRAIN

[akyra]

Originariamente inviato da ilsensine
Alcune note sull'howto, per semplificare un pò le cose:
- libpcap sono già fornite con le distribuzioni; c'è un motivo specifico per usare la ver. 0.8.3 e non (ad es.) la 0.8.1?
- pppd 2.4.2 dovrebbe essere disponibile nelle ultime distribuzioni. A meno che quello che hai linkato non contiene patch particolari, non è necessario ricompilarlo. E' necessario ovviamente inserire il percorso corretto per pppatm.so nel file di configurazione.
- Ricompilare il kernel non è necessario, non ne vedo il motivo

Quindi, con un pò di fortuna, tutto potrebbe ridursi a installare il driver cxacru. Quetso driver _richiede_ la presenza dei sorgenti del kernel in esecuzione, che normalmente sono forniti dalle distribuzioni.

Puoi verificare le fesserie che ho detto?

effettivamente quello che hai detto tu è corretto, sia riguardo a libcap che a linux-atm.

Per quel che riguarda il demone pppd, che gestisce il collegamento, purtroppo bisogna installare proprio quella versione, e disinstallare quella già presente, in quanto è l'unico che possiede il plugin "pppoatm.so"....almeno è l'unico che funziona correttamente col driver "cxacru-2003-10-5".....avrei potuto fare una patch che inserisse il plugin, ma così sono andato più sul sicuro...

per quanto riguarda il kernel bisogna dire che il driver, a me, funziona solo con la versione 2.4.x, per cui nel caso uno possegga Mandrake 10.1 che è fornita col kernel 2.6.x, il driver non compila, e deve per forza scaricarsi i sorgenti della 2.4....a dirla tutta, il driver dovrebbe funzionare anche col kernel 2.6.x, ma io per ora non ci sono riuscito, anche se non è che c'abbia provato tanto, visto che una volta che ho fatto partire il modem col 2.4.26 non vedevo il motivo di rifare il tutto per installare il kernel 2..6....comunque se uno volesse far andare il driver col kernel 2.6 c'è un sito che spiega come, anche se non è proprio semplicissimo:

http://www.zullinux.it/linux/accessrunner.html

P.S.

Puoi verificare le fesserie che ho detto?

mai sentito dire fesserie da te...anzi, sei una delle voci più autorevoli di questa sezione!

[ilsensine]

Originariamente inviato da akyra
Per quel che riguarda il demone pppd, che gestisce il collegamento, purtroppo bisogna installare proprio quella versione, e disinstallare quella già presente, in quanto è l'unico che possiede il plugin "pppoatm.so"....almeno è l'unico che funziona correttamente col driver "cxacru-2003-10-5".....avrei potuto fare una patch che inserisse il plugin, ma così sono andato più sul sicuro...

Avrei giurato che il 2.4.2 avesse di per se il plugin atm...non è escluso che alcune distro lo forniscano già con questo plugin, è assurdo non includerlo.

per quanto riguarda il kernel bisogna dire che il driver, a me, funziona solo con la versione 2.4.x, per cui nel caso uno possegga Mandrake 10.1 che è fornita col kernel 2.6.x, il driver non compila

Interessante. Proverò a dare una occhiata al driver, se è una cosa facilmente risolvibile.

[ilsensine]

Il driver in kernel space mi si compila correttamente sul kernel 2.6.8.1...
(non è quello della mdk 10.1 cmq)
Puoi verificarlo con "make CX_MODULE2"

[akyra]

Originariamente inviato da ilsensine
Il driver in kernel space mi si compila correttamente sul kernel 2.6.8.1...
(non è quello della mdk 10.1 cmq)
Puoi verificarlo con "make CX_MODULE2"

effettivamente compila correttamente....anzi, ho provato ad installare il modem sul PC dove ho una slackware 10 col kernel 2.6.9, e riesco effettivamente a far funzionare il modem, unico dettaglio (cosa più importante) è che il server non mi assegna un IP, quindi non riesco a navigare.

Infatti, quando faccio partire il modem, lo script di avvio "cxstart.sh" conclude con successo, soltanto che se controllo con "ifconfig ppp0" non ricevo nessun IP dal server....infatti in /var/log/message trovo queste diciture:

using interface ppp0
connect ppp0 <--> 8.35
connection terminated



non riesco a capire cos'ho dimenticato....mi sembra di aver sbagliato qualche dettaglio....magari tu puoi illuminare la mia testa ottenebrata

[ilsensine]

Attiva il debug di pppd e posta tutto il postabile.
Allega file di configurazione per pppd, ecc.

Non ho quel modem, ma posso vedere se qualcosa suona storto.

[DnA[TF]]

Spero che tu o ilsensine mi contatti via ICQ!!!!
Non ci capisco una mazza!!!!!

Vieni a casa miaaaaaa!!!!

[akyra]

Originariamente inviato da ilsensine
Attiva il debug di pppd e posta tutto il postabile.
Allega file di configurazione per pppd, ecc.

Non ho quel modem, ma posso vedere se qualcosa suona storto.

allora, in /var/log/messages trovo ora queste parole:

lugin /home/dave/Desktop/usr/src/ppp-2.4.2/pppd/plugins/pppoa/pppoatm.so loaded.
Dec 2 16:22:12 opopomoz pppd[3541]: In pppoatm_process_extra_options
Dec 2 16:22:12 opopomoz pppd[3541]: In pppoatm_check_options
Dec 2 16:22:12 opopomoz pppd[3542]: pppd 2.4.2 started by root, uid 0
Dec 2 16:22:12 opopomoz pppd[3542]: In pppoatm_connect
Dec 2 16:22:12 opopomoz pppd[3542]: In pppoatm_establish_ppp
Dec 2 16:22:12 opopomoz pppd[3542]: Using interface ppp0
Dec 2 16:22:12 opopomoz pppd[3542]: Connect: ppp0 <--> 8.35
Dec 2 16:22:12 opopomoz pppd[3542]: In pppoatm_send_config
Dec 2 16:22:12 opopomoz pppd[3542]: In pppoatm_recv_config
Dec 2 16:22:42 opopomoz pppd[3542]: Connection terminated.

da come vedo succede qualcosa che non mi permette di creare una connessione tra la mia interfaccia ppp0 e il router nella subnet...cosa può essere che lo impedisce?
l'autenticazione avviene tramite "PAP", e i dati in /etc/ppp/pap-secret sono corretti...
non so cos'altro postare? cosa potrebbe essere utile?
sto alla canna del gas


ah..visto che ci sono posto anche il file di configurazione di pppd (/etc/ppp/options):

# /etc/ppp/options
#
# $Id: options,v 1.4 1996/05/01 18:57:04 alvar Exp $
#
# Originally created by Jim Knoble <jmknoble@mercury.interpath.net>
# Modified for Debian by alvar Bray <alvar@meiko.co.uk>
# Modified for PPP Server setup by Christoph Lameter <clameter@debian.org>
# Modified for Slackware by Pat Volkerding <volkerdi@slackware.com>
#
# Use the command egrep -v '#|^ *$' /etc/ppp/options to quickly see what
# options are active in this file.

# Specify which DNS Servers the incoming Win95 or WinNT Connection should use
# Two Servers can be remotely configured
# dns-addr 192.168.1.1
# dns-addr 192.168.1.2

# Specify which WINS Servers the incoming connection Win95 or WinNT should use
# wins-addr 192.168.1.50
# wins-addr 192.168.1.51

# Run the executable or shell command specified after pppd has
# terminated the link. This script could, for example, issue commands
# to the modem to cause it to hang up if hardware modem control signals
# were not available.
#disconnect "chat -- \d+++\d\c OK ath0 OK"

# async character map -- 32-bit hex; each bit is a character
# that needs to be escaped for pppd to receive it. 0x00000001
# represents '\x01', and 0x80000000 represents '\x1f'.
asyncmap 0

# Require the peer to authenticate itself before allowing network
# packets to be sent or received.
# For a PPP Server with script based logins not using PAP or CHAP
# you need to disable this setting.
#auth

# Do not require the other end of the connection to authenticate itself.
# This option is dangerous if pppd is setuid.
# If you also have ethernet and are having problems getting PPP to connect
# over a modem, try this option.
#noauth

# Use hardware flow control (i.e. RTS/CTS) to control the flow of data
# on the serial port.
crtscts

# Use software flow control (i.e. XON/XOFF) to control the flow of data
# on the serial port.
#xonxoff

# Specifies that certain characters should be escaped on transmission
# (regardless of whether the peer requests them to be escaped with its
# async control character map). The characters to be escaped are
# specified as a list of hex numbers separated by commas. Note that
# almost any character can be specified for the escape option, unlike
# the asyncmap option which only allows control characters to be
# specified. The characters which may not be escaped are those with hex
# values 0x20 - 0x3f or 0x5e.
#escape 11,13,ff

# Don't use the modem control lines.
#local

# Specifies that pppd should use a UUCP-style lock on the serial device
# to ensure exclusive access to the device.
lock
defaultroute
noipdefault
noauth
nopcomp
holdoff 4
persist
maxfail 25
lcp-echo-interval 2
lcp-echo-failure 7
user mioUSERNAME #naturalmente non voglio che si veda....
plugin ~/Desktop/usr/src/ppp-2.4.2/pppd/plugins/pppoa/pppoatm.so #non sapevo dove metterlo
8.35
# Use the modem control lines. On Ultrix, this option implies hardware
# flow control, as for the crtscts option. (This option is not fully
# implemented.)
#modem

# Set the MRU [Maximum Receive Unit] value to <n> for negotiation. pppd
# will ask the peer to send packets of no more than <n> bytes. The
# minimum MRU value is 128. The default MRU value is 1500. A value of
# 296 is recommended for slow links (40 bytes for TCP/IP header + 256
# bytes of data).
#mru 542

# Set the interface netmask to <n>, a 32 bit netmask in "decimal dot"
# notation (e.g. 255.255.255.0).
#netmask 255.255.255.0

# Disables the default behaviour when no local IP address is specified,
# which is to determine (if possible) the local IP address from the
# hostname. With this option, the peer will have to supply the local IP
# address during IPCP negotiation (unless it specified explicitly on the
# command line or in an options file).
#noipdefault

# Enables the "passive" option in the LCP. With this option, pppd will
# attempt to initiate a connection; if no reply is received from the
# peer, pppd will then just wait passively for a valid LCP packet from
# the peer (instead of exiting, as it does without this option).
#passive

# With this option, pppd will not transmit LCP packets to initiate a
# connection until a valid LCP packet is received from the peer (as for
# the "passive" option with old versions of pppd).
#silent

# Don't request or allow negotiation of any options for LCP and IPCP
# (use default values).
#-all

# Disable Address/Control compression negotiation (use default, i.e.
# address/control field disabled).
#-ac

# Disable asyncmap negotiation (use the default asyncmap, i.e. escape
# all control characters).
#-am

# Don't fork to become a background process (otherwise pppd will do so
# if a serial device is specified).
#-detach

# Disable IP address negotiation (with this option, the remote IP
# address must be specified with an option on the command line or in an
# options file).
#-ip

# Disable magic number negotiation. With this option, pppd cannot
# detect a looped-back line.
#-mn

# Disable MRU [Maximum Receive Unit] negotiation (use default, i.e.
# 1500).
#-mru

# Disable protocol field compression negotiation (use default, i.e.
# protocol field compression disabled).
#-pc

# Require the peer to authenticate itself using PAP.
#+pap

# Don't agree to authenticate using PAP.
#-pap

# Require the peer to authenticate itself using CHAP [Cryptographic
# Handshake Authentication Protocol] authentication.
#+chap

# Don't agree to authenticate using CHAP.
#-chap

# Disable negotiation of Van Jacobson style IP header compression (use
# default, i.e. no compression).
#-vj

# Increase debugging level (same as -d). If this option is given, pppd
# will log the contents of all control packets sent or received in a
# readable form. The packets are logged through syslog with facility
# daemon and level debug. This information can be directed to a file by
# setting up /etc/syslog.conf appropriately (see syslog.conf(5)). (If
# pppd is compiled with extra debugging enabled, it will log messages
# using facility local2 instead of daemon).
debug

# Append the domain name <d> to the local host name for authentication
# purposes. For example, if gethostname() returns the name porsche,
# but the fully qualified domain name is porsche.Quotron.COM, you would
# use the domain option to set the domain name to Quotron.COM.
#domain <d>

# Enable debugging code in the kernel-level PPP driver. The argument n
# is a number which is the sum of the following values: 1 to enable
# general debug messages, 2 to request that the contents of received
# packets be printed, and 4 to request that the contents of transmitted
# packets be printed.
#kdebug n

# Set the MTU [Maximum Transmit Unit] value to <n>. Unless the peer
# requests a smaller value via MRU negotiation, pppd will request that
# the kernel networking code send data packets of no more than n bytes
# through the PPP network interface.
#mtu <n>

# Enforce the use of the hostname as the name of the local system for
# authentication purposes (overrides the name option).
#usehostname

# Set the assumed name of the remote system for authentication purposes
# to <n>.
#remotename <n>

# Add an entry to this system's ARP [Address Resolution Protocol]
# table with the IP address of the peer and the Ethernet address of this
# system.
proxyarp

# Use the system password database for authenticating the peer using
# PAP. Note: mgetty already provides this option. If this is specified
# then dialin from users using a script under Linux to fire up ppp wont work.
# login

# If this option is given, pppd will send an LCP echo-request frame to
# the peer every n seconds. Under Linux, the echo-request is sent when
# no packets have been received from the peer for n seconds. Normally
# the peer should respond to the echo-request by sending an echo-reply.
# This option can be used with the lcp-echo-failure option to detect
# that the peer is no longer connected.
lcp-echo-interval 30

# If this option is given, pppd will presume the peer to be dead if n
# LCP echo-requests are sent without receiving a valid LCP echo-reply.
# If this happens, pppd will terminate the connection. Use of this
# option requires a non-zero value for the lcp-echo-interval parameter.
# This option can be used to enable pppd to terminate after the physical
# connection has been broken (e.g., the modem has hung up) in
# situations where no hardware modem control lines are available.
lcp-echo-failure 4

# Set the LCP restart interval (retransmission timeout) to <n> seconds
# (default 3).
#lcp-restart <n>

# Set the maximum number of LCP terminate-request transmissions to <n>
# (default 3).
#lcp-max-terminate <n>

# Set the maximum number of LCP configure-request transmissions to <n>
# (default 10).
#lcp-max-configure <n>

# Set the maximum number of LCP configure-NAKs returned before starting
# to send configure-Rejects instead to <n> (default 10).
#lcp-max-failure <n>

# Set the IPCP restart interval (retransmission timeout) to <n>
# seconds (default 3).
#ipcp-restart <n>

# Set the maximum number of IPCP terminate-request transmissions to <n>
# (default 3).
#ipcp-max-terminate <n>

# Set the maximum number of IPCP configure-request transmissions to <n>
# (default 10).
#ipcp-max-configure <n>

# Set the maximum number of IPCP configure-NAKs returned before starting
# to send configure-Rejects instead to <n> (default 10).
#ipcp-max-failure <n>

# Set the PAP restart interval (retransmission timeout) to <n> seconds
# (default 3).
#pap-restart <n>

# Set the maximum number of PAP authenticate-request transmissions to
# <n> (default 10).
#pap-max-authreq <n>

# Set the CHAP restart interval (retransmission timeout for
# challenges) to <n> seconds (default 3).
#chap-restart <n>

# Set the maximum number of CHAP challenge transmissions to <n>
# (default 10).
#chap-max-challenge

# If this option is given, pppd will rechallenge the peer every <n>
# seconds.
#chap-interval <n>

# With this option, pppd will accept the peer's idea of our local IP
# address, even if the local IP address was specified in an option.
#ipcp-accept-local

# With this option, pppd will accept the peer's idea of its (remote) IP
# address, even if the remote IP address was specified in an option.
#ipcp-accept-remote

[DnA[TF]]

Io ragazzo mio sto peggio di te!!!

[ilsensine]

Originariamente inviato da akyra
allora, in /var/log/messages trovo ora queste parole:

Inutiliora. Devi aggiungere "debug" nel file di configurazione.

ah..visto che ci sono posto anche il file di configurazione di pppd (/etc/ppp/options):

Aggiungi almeno "+pap"...

[akyra]

Originariamente inviato da ilsensine
Inutiliora. Devi aggiungere "debug" nel file di configurazione.


Aggiungi almeno "+pap"...

infatti il debug l'ho attivato:

Increase debugging level (same as -d). If this option is given, pppd
# will log the contents of all control packets sent or received in a
# readable form. The packets are logged through syslog with facility
# daemon and level debug. This information can be directed to a file by
# setting up /etc/syslog.conf appropriately (see syslog.conf(5)). (If
# pppd is compiled with extra debugging enabled, it will log messages
# using facility local2 instead of daemon).
debug

anche +pap ho provato ad attivarlo, ma le cose non cambiano....

ah...il file /var/log/syslog mi da codesti output:

usb 3-2.2: usbfs: interface 0 claimed while 'cxioctl' sets config #1
Dec 2 16:22:42 opopomoz pppd[3542]: LCP: timeout sending Config-Requests
Dec 2 16:23:16 opopomoz pppd[3542]: LCP: timeout sending Config-Requests
Dec 2 16:24:24 opopomoz last message repeated 2 times
Dec 2 16:24:58 opopomoz pppd[3542]: LCP: timeout sending Config-Requests
Dec 2 16:26:06 opopomoz last message repeated 2 times
Dec 2 16:27:15 opopomoz last message repeated 2 times
Dec 2 16:28:23 opopomoz last message repeated 2 times
Dec 2 16:28:57 opopomoz pppd[3542]: LCP: timeout sending Config-Requests

[ilsensine]

Ah quindi pppd prova a inviare pacchetti lcp, ma il peer non se lo caga...potrebbe essere un problema del driver.
Intanto, per escludere definitivamente problemi grossolani di pppd, dovresti riprodurre il "malfunzionamento" con lo stesso file options di una macchina funzionante. Temo che non ti sarà difficile.
Poi cominceremo a indagare su questo:

usb 3-2.2: usbfs: interface 0 claimed while 'cxioctl' sets config #1

che è l'unico indizio concreto che abbiamo. Verifica anche che questo messaggio non è presente sul PC funzionante.

[AnonimoVeneziano]

Ovviamente controlla di non aver dimenticato qualcosa di fondamentale nel Kernel ,come ad esempio il supporto ATM o robe del genere

Ciao

[akyra]

Originariamente inviato da ilsensine
Ah quindi pppd prova a inviare pacchetti lcp, ma il peer non se lo caga...potrebbe essere un problema del driver.
Intanto, per escludere definitivamente problemi grossolani di pppd, dovresti riprodurre il "malfunzionamento" con lo stesso file options di una macchina funzionante. Temo che non ti sarà difficile.
Poi cominceremo a indagare su questo:

che è l'unico indizio concreto che abbiamo. Verifica anche che questo messaggio non è presente sul PC funzionante.

allora, per quel che riguarda il file "options" l'unica cosa che faccio è aggiungere quelle righe scritte sull'how to, per cui il file è lo stesso sia nella macchina in cui il modem funziona sia in quella in cui non funziona .

per quanto riguarda la stringa che compare in /var/log/syslog, sul PC dove il modem funziona non compare,come mi hai chiesto di controllare...