He arribat fins al punt que realitza la connexió de xarxa (indica cobertura, autoassigna IP pròpia, porta d'enllaç i DNS), però aconsegueixo fer CAP comunicació via TCP, ICMP o DNS.
El «ping» es queda esperant sense resultat per a qualsevol adreça no-local que li demani (incloent a porta d'enllaç).
Algú sap com esbrinar on és ara el problema?
Am 06/02/2023 um 14:08 schrieb Narcis Garcia:
He arribat fins al punt que realitza la connexió de xarxa (indica cobertura, autoassigna IP pròpia, porta d'enllaç i DNS), però aconsegueixo fer CAP comunicació via TCP, ICMP o DNS.
El «ping» es queda esperant sense resultat per a qualsevol adreça no-local que li demani (incloent a porta d'enllaç).
Algú sap com esbrinar on és ara el problema?
Jo miraria amb un analitzador de tràfic tipus Wireshark què està
passant. Això per esbrinar tècnicament què passa.
A nivell pràctic, però, preguntaria a l'operadora si permeten usar la línia com a mòdem, perquè si es pot implementar qualsevol mesura que discrimini l'ús que es fa d'un servei, ho faran si veuen que pot reportar-los qualsevol benefici. I de vegades és millor sortir de dubtes
que trencar-se les banyes amb un problema (tot i que ho puguem trobar entretingut, divertit i satisfactori quan el solucionem).
No tinc ni idea de què fer amb Wireshark per a comprovar no sé el què.
A GNU/Linux el dispositiu es configura (IP, porta, DNS), però no aconsegueixo arribar a cap servei extern, ni tan sols respon ping cap a
la porta d'enllaç ni els servidors DNS, ni aquests resolen adreces.
Com a molt la pròpia IP pública respon a ping, però qualsevol IP d'Internet ja no.
Am 16/03/2023 um 14:18 schrieb Narcis Garcia:
No tinc ni idea de què fer amb Wireshark per a comprovar no sé el què.
A GNU/Linux el dispositiu es configura (IP, porta, DNS), però no aconsegueixo arribar a cap servei extern, ni tan sols respon ping cap a
la porta d'enllaç ni els servidors DNS, ni aquests resolen adreces.
Com a molt la pròpia IP pública respon a ping, però qualsevol IP d'Internet ja no.
Hola Narcís,
en aquest cas, i havent provat que amb un altre sistema operatiu pot funcionar, cal descartar que l'operador posi pals a les rodes.
Jo et diria de comprovar si un tallafocs està impedint la connexió d'aquesta interfície de xarxa (amb això Wireshark podria ajudar veient
que s'envien paquets a l'altre extrem i veient si hi arriben o què passa
amb la resposta), però com que ho has provat amb un parell d'Ubuntus on entenc que el tallafocs ve desactivat per defecte, llavors no sabria què dir-te.
El que m'estranya és que el ping respongui a la IP pública mentre que no
ho faci a la porta d'enllaç; no li veig el sentit.
Jo analitzaria una connexió simple (ICMP, o sigui ping) contra un
dispositiu del mateix segment de xarxa amb el Wireshark, i
n'interpretaria els resultats. Que no funcioni res _ho puc arribar a entendre_, però que funcioni el ping només a la pròpia IP pública em desconcerta.
A veure si a algú més se li acut alguna altra cosa perquè puguis provar.
Am 16/03/2023 um 14:18 schrieb Narcis Garcia:
No tinc ni idea de què fer amb Wireshark per a comprovar no sé el què.
A GNU/Linux el dispositiu es configura (IP, porta, DNS), però no
aconsegueixo arribar a cap servei extern, ni tan sols respon ping cap
a la porta d'enllaç ni els servidors DNS, ni aquests resolen adreces.
Com a molt la pròpia IP pública respon a ping, però qualsevol IP
d'Internet ja no.
Hola Narcís,
en aquest cas, i havent provat que amb un altre sistema operatiu pot funcionar, cal descartar que l'operador posi pals a les rodes.
Jo et diria de comprovar si un tallafocs està impedint la connexió d'aquesta interfície de xarxa (amb això Wireshark podria ajudar veient
que s'envien paquets a l'altre extrem i veient si hi arriben o què passa
amb la resposta), però com que ho has provat amb un parell d'Ubuntus on entenc que el tallafocs ve desactivat per defecte, llavors no sabria què dir-te.
El que m'estranya és que el ping respongui a la IP pública mentre que no
ho faci a la porta d'enllaç; no li veig el sentit.
Jo analitzaria una connexió simple (ICMP, o sigui ping) contra un
dispositiu del mateix segment de xarxa amb el Wireshark, i
n'interpretaria els resultats. Que no funcioni res _ho puc arribar a entendre_, però que funcioni el ping només a la pròpia IP pública em desconcerta.
A veure si a algú més se li acut alguna altra cosa perquè puguis provar.
Hola, Adrià, Narcís,
A la feina ens vam trobar que a partir d'una determinada versió Ubuntu determinats USB 3G van deixar de funcionar.
Actualment s'utilitzen "encaminadors" amb bateria (que es carreguen per
USB) que porten la SIM i engegats do
Hola Josep, l'opció de l'encaminador no em convenç per dues raons:
Perquè es fa un altre salt amb comunicació enrutada (LAN) i aèria (la
qual cosa perd latència etc.) i també perquè cal carregar més trastos apart de l'ordinador. Per això ja em serviria el telèfon mòbil que té el mateix paper, i el què tinc em resulta lent.
El dispositiu es detecta en un primer moment com a emmagatzematge
(0685:2000 ZD Incorporated USB Qualcomm Storage), però en uns segons
canvia a modem (12d1:1001 Huawei Technologies Co., Ltd.
E161/E169/E620/E800 HSDPA Modem). Suposo que es tracta d'una correcció
que fa el udev o el què sigui que organitza els dispositius.
1. Utilitzo el NetworkManager. Com s'enumeren les connexions PPP?
És el què dóna «nmcli connection show» o com es distingeixen quan estan establertes com a PPP?
2. Amb la comanda «netstat -rn» veig que la ruta per defecte està definida, i al mateix espai d'adreces que el dispositiu modem:
$ ip address show dev wwan0
5: wwan0: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UNKNOWN group default qlen 1000
link/ether 96:75:07:e1:d1:29 brd ff:ff:ff:ff:ff:ff
inet 172.19.211.64/25 brd 172.19.211.127 scope global noprefixroute wwan0
valid_lft forever preferred_lft forever
$ ping -c 1 172.19.211.64
PING 172.19.211.64 (172.19.211.64) 56(84) bytes of data.
64 bytes from 172.19.211.64: icmp_seq=1 ttl=64 time=0.057 ms
--- 172.19.211.64 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.057/0.057/0.057/0.000 ms
$ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 172.19.211.1 0.0.0.0 UG 0 0 0 wwan0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 wwan0
172.19.211.0 0.0.0.0 255.255.255.128 U 0 0 0 wwan0
$ ping -c 1 172.19.211.1
PING 172.19.211.1 (172.19.211.1) 56(84) bytes of data.
--- 172.19.211.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
El 17/3/23 a les 11:35, Josep Lladonosa ha escrit:
Hola, Adrià, Narcís,
A la feina ens vam trobar que a partir d'una determinada versió Ubuntu determinats USB 3G van deixar de funcionar.
Actualment s'utilitzen "encaminadors" amb bateria (que es carreguen per USB) que porten la SIM i engegats donen una WiFi a la que diversos
equips poden connectar alhora.
Si no recordo malament, hi havia temes de reconeixement de dispositiu
com a emmagatzematge (que no seria el teu cas) i altres temes de com
s'usa el PPP.
Aquests adaptadors 3G/4G no deixen de ser aparells que estableixen connexions a l'estil dels "antics" mòdems. Podria ser que es faci la connexió PPP però a aquesta no se la definís com a ruta per defecte. Estic aportant des de la imaginació i aquest supòsit.
Cordialment,
Josep
On Fri, 17 Mar 2023 at 11:24, Adrià <adria@fsfe.org <mailto:adria@fsfe.org>> wrote:
Am 16/03/2023 um 14:18 schrieb Narcis Garcia:adreces.
> No tinc ni idea de què fer amb Wireshark per a comprovar no sé el
què.
> A GNU/Linux el dispositiu es configura (IP, porta, DNS), però no
> aconsegueixo arribar a cap servei extern, ni tan sols respon ping
cap a
> la porta d'enllaç ni els servidors DNS, ni aquests resolen
> Com a molt la pròpia IP pública respon a ping, però qualsevol IP
> d'Internet ja no.
Hola Narcís,
en aquest cas, i havent provat que amb un altre sistema operatiu pot
funcionar, cal descartar que l'operador posi pals a les rodes.
Jo et diria de comprovar si un tallafocs està impedint la connexióveient
d'aquesta interfície de xarxa (amb això Wireshark podria ajudar
que s'envien paquets a l'altre extrem i veient si hi arriben o quèon
passa
amb la resposta), però com que ho has provat amb un parell d'Ubuntus
entenc que el tallafocs ve desactivat per defecte, llavors no sabria
què
dir-te.
El que m'estranya és que el ping respongui a la IP pública mentre
que no
ho faci a la porta d'enllaç; no li veig el sentit.
Jo analitzaria una connexió simple (ICMP, o sigui ping) contra un
dispositiu del mateix segment de xarxa amb el Wireshark, i
n'interpretaria els resultats. Que no funcioni res _ho puc arribar a
entendre_, però que funcioni el ping només a la pròpia IP pública em
desconcerta.
A veure si a algú més se li acut alguna altra cosa perquè puguisprovar.
--
--
Salutacions...Josep
--
--
__________
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator should fix this against automated addresses collectors.
Hola, Narcís,
Quan he parlat de PPP em referia al fet que es fan servir els codis de configuració de connexions estil "mòdems". De fet, en principi, el NetworkManager no hauria de configurar res (tot i que a algun lloc en
parlen que podria fer la feina) ja que normalment s'usa el
"ModemManager" que és qui parla amb l'adaptador USB i configura aquesta connexió PPP (els paquets IP anirien dins aquesta). Per això em referia
que no sigui algun paràmetre de configuració d'aquest enllaç PPP.
He trobat aquest web que llista els adaptadors compatibles amb Linux:
https://www.freedesktop.org/wiki/Software/ModemManager/SupportedDevices/ <https://www.freedesktop.org/wiki/Software/ModemManager/SupportedDevices/>
Cordialment,
Josep
On Fri, 17 Mar 2023 at 16:13, Narcis Garcia <debianlists@actiu.net <mailto:debianlists@actiu.net>> wrote:
Hola Josep, l'opció de l'encaminador no em convenç per dues raons:
Perquè es fa un altre salt amb comunicació enrutada (LAN) i aèria (la
qual cosa perd latència etc.) i també perquè cal carregar més trastos
apart de l'ordinador. Per això ja em serviria el telèfon mòbil que
té el
mateix paper, i el què tinc em resulta lent.
El dispositiu es detecta en un primer moment com a emmagatzematge
(0685:2000 ZD Incorporated USB Qualcomm Storage), però en uns segons
canvia a modem (12d1:1001 Huawei Technologies Co., Ltd.
E161/E169/E620/E800 HSDPA Modem). Suposo que es tracta d'una correcció
que fa el udev o el què sigui que organitza els dispositius.
1. Utilitzo el NetworkManager. Com s'enumeren les connexions PPP?
És el què dóna «nmcli connection show» o com es distingeixen quan estan
establertes com a PPP?
2. Amb la comanda «netstat -rn» veig que la ruta per defecte està
definida, i al mateix espai d'adreces que el dispositiu modem:
$ ip address show dev wwan0
5: wwan0: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UNKNOWN group default qlen 1000
link/ether 96:75:07:e1:d1:29 brd ff:ff:ff:ff:ff:ff
inet 172.19.211.64/25 <http://172.19.211.64/25> brd
172.19.211.127 scope global noprefixroute
wwan0
valid_lft forever preferred_lft forever
$ ping -c 1 172.19.211.64
PING 172.19.211.64 (172.19.211.64) 56(84) bytes of data.
64 bytes from 172.19.211.64 <http://172.19.211.64>: icmp_seq=1
ttl=64 time=0.057 ms
--- 172.19.211.64 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.057/0.057/0.057/0.000 ms
$ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window
irtt
Iface
0.0.0.0 172.19.211.1 0.0.0.0 UG 0 0
0
wwan0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0
0
wwan0
172.19.211.0 0.0.0.0 255.255.255.128 U 0 0
0
wwan0
$ ping -c 1 172.19.211.1
PING 172.19.211.1 (172.19.211.1) 56(84) bytes of data.
--- 172.19.211.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
El 17/3/23 a les 11:35, Josep Lladonosa ha escrit:
> Hola, Adrià, Narcís,
>
> A la feina ens vam trobar que a partir d'una determinada versió
Ubuntu
> determinats USB 3G van deixar de funcionar.
> Actualment s'utilitzen "encaminadors" amb bateria (que es
carreguen per
> USB) que porten la SIM i engegats donen una WiFi a la que diversos
> equips poden connectar alhora.
>
> Si no recordo malament, hi havia temes de reconeixement de
dispositiu
> com a emmagatzematge (que no seria el teu cas) i altres temes de com
> s'usa el PPP.
> Aquests adaptadors 3G/4G no deixen de ser aparells que estableixen
> connexions a l'estil dels "antics" mòdems. Podria ser que es faci la
> connexió PPP però a aquesta no se la definís com a ruta per defecte.
> Estic aportant des de la imaginació i aquest supòsit.
>
> Cordialment,
> Josep
>
> On Fri, 17 Mar 2023 at 11:24, Adrià <adria@fsfe.org
<mailto:adria@fsfe.org>
> <mailto:adria@fsfe.org <mailto:adria@fsfe.org>>> wrote:
>
> Am 16/03/2023 um 14:18 schrieb Narcis Garcia:
> > No tinc ni idea de què fer amb Wireshark per a comprovar
no sé el
> què.
> > A GNU/Linux el dispositiu es configura (IP, porta, DNS),
però no
> > aconsegueixo arribar a cap servei extern, ni tan sols
respon ping
> cap a
> > la porta d'enllaç ni els servidors DNS, ni aquests resolen
adreces.
> > Com a molt la pròpia IP pública respon a ping, però
qualsevol IP
> > d'Internet ja no.
>
> Hola Narcís,
>
> en aquest cas, i havent provat que amb un altre sistema
operatiu pot
> funcionar, cal descartar que l'operador posi pals a les rodes.
>
> Jo et diria de comprovar si un tallafocs està impedint la
connexió
> d'aquesta interfície de xarxa (amb això Wireshark podria
ajudar veient
> que s'envien paquets a l'altre extrem i veient si hi arriben
o què
> passa
> amb la resposta), però com que ho has provat amb un parell
d'Ubuntus on
> entenc que el tallafocs ve desactivat per defecte, llavors no
sabria
> què
> dir-te.
>
> El que m'estranya és que el ping respongui a la IP pública mentre
> que no
> ho faci a la porta d'enllaç; no li veig el sentit.
>
> Jo analitzaria una connexió simple (ICMP, o sigui ping) contra un
> dispositiu del mateix segment de xarxa amb el Wireshark, i
> n'interpretaria els resultats. Que no funcioni res _ho puc
arribar a
> entendre_, però que funcioni el ping només a la pròpia IP
pública em
> desconcerta.
>
> A veure si a algú més se li acut alguna altra cosa perquè
puguis provar.
>
>
>
> --
> --
> Salutacions...Josep
> --
--
__________
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
--
--
Salutacions...Josep
--
Hi he donat moltes voltes, i no sé per on tirar.
Arreu hi ha gent que diu que amb el mateix dispositiu lt4112 aconsegueix funcionar amb GNU/Linux i des de fa anys, i no sembla que haguessin de superar la meva mateixa dificultat.
Estic travat amb què connecta, senyalitza el nivell de cobertura,
adquireix la configuració IP (IP, porta, DNS), però no hi ha comunicació més enllà de la IP pública.
Tampoc no es rebutja la comunicació, sinó que no assoleix cap destinació externa.
Ara ja només se m'acudeix provar amb més i més distribucions de GNU/Linux.
Gràcies als què heu intentat ajudar-me.
El 17/3/23 a les 22:04, Josep Lladonosa ha escrit:
Hola, Narcís,
Quan he parlat de PPP em referia al fet que es fan servir els codis de configuració de connexions estil "mòdems". De fet, en principi, el NetworkManager no hauria de configurar res (tot i que a algun lloc en parlen que podria fer la feina) ja que normalment s'usa el
"ModemManager" que és qui parla amb l'adaptador USB i configura aquesta connexió PPP (els paquets IP anirien dins aquesta). Per això em referia que no sigui algun paràmetre de configuració d'aquest enllaç PPP.
He trobat aquest web que llista els adaptadors compatibles amb Linux:
https://www.freedesktop.org/wiki/Software/ModemManager/SupportedDevices/https://www.freedesktop.org/wiki/Software/ModemManager/SupportedDevices/>
<
Cordialment,
Josep
On Fri, 17 Mar 2023 at 16:13, Narcis Garcia <debianlists@actiu.net <mailto:debianlists@actiu.net>> wrote:
Hola Josep, l'opció de l'encaminador no em convenç per dues raons:
Perquè es fa un altre salt amb comunicació enrutada (LAN) i aèria (la
qual cosa perd latència etc.) i també perquè cal carregar més trastos
apart de l'ordinador. Per això ja em serviria el telèfon mòbil que
té el
mateix paper, i el què tinc em resulta lent.
El dispositiu es detecta en un primer moment com a emmagatzematgecorrecció
(0685:2000 ZD Incorporated USB Qualcomm Storage), però en uns segons
canvia a modem (12d1:1001 Huawei Technologies Co., Ltd.
E161/E169/E620/E800 HSDPA Modem). Suposo que es tracta d'una
que fa el udev o el què sigui que organitza els dispositius.
1. Utilitzo el NetworkManager. Com s'enumeren les connexions PPP?estan
És el què dóna «nmcli connection show» o com es distingeixen quan
establertes com a PPP?
2. Amb la comanda «netstat -rn» veig que la ruta per defecte està
definida, i al mateix espai d'adreces que el dispositiu modem:
$ ip address show dev wwan0
5: wwan0: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UNKNOWN group default qlen 1000
link/ether 96:75:07:e1:d1:29 brd ff:ff:ff:ff:ff:ff
inet 172.19.211.64/25 <http://172.19.211.64/25> brd
172.19.211.127 scope global noprefixroute
wwan0
valid_lft forever preferred_lft forever
$ ping -c 1 172.19.211.64
PING 172.19.211.64 (172.19.211.64) 56(84) bytes of data.
64 bytes from 172.19.211.64 <http://172.19.211.64>: icmp_seq=1
ttl=64 time=0.057 ms
--- 172.19.211.64 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.057/0.057/0.057/0.000 ms
$ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window
irtt
Iface
0.0.0.0 172.19.211.1 0.0.0.0 UG 0 0
0
wwan0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0
0
wwan0
172.19.211.0 0.0.0.0 255.255.255.128 U 0 0
0
wwan0
$ ping -c 1 172.19.211.1
PING 172.19.211.1 (172.19.211.1) 56(84) bytes of data.
--- 172.19.211.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
El 17/3/23 a les 11:35, Josep Lladonosa ha escrit:com
> Hola, Adrià, Narcís,
>
> A la feina ens vam trobar que a partir d'una determinada versió
Ubuntu
> determinats USB 3G van deixar de funcionar.
> Actualment s'utilitzen "encaminadors" amb bateria (que es
carreguen per
> USB) que porten la SIM i engegats donen una WiFi a la que diversos
> equips poden connectar alhora.
>
> Si no recordo malament, hi havia temes de reconeixement de
dispositiu
> com a emmagatzematge (que no seria el teu cas) i altres temes de
> s'usa el PPP.la
> Aquests adaptadors 3G/4G no deixen de ser aparells que estableixen
> connexions a l'estil dels "antics" mòdems. Podria ser que es faci
> connexió PPP però a aquesta no se la definís com a ruta perdefecte.
> Estic aportant des de la imaginació i aquest supòsit.mentre
>
> Cordialment,
> Josep
>
> On Fri, 17 Mar 2023 at 11:24, Adrià <adria@fsfe.org
<mailto:adria@fsfe.org>
> <mailto:adria@fsfe.org <mailto:adria@fsfe.org>>> wrote:
>
> Am 16/03/2023 um 14:18 schrieb Narcis Garcia:
> > No tinc ni idea de què fer amb Wireshark per a comprovar
no sé el
> què.
> > A GNU/Linux el dispositiu es configura (IP, porta, DNS),
però no
> > aconsegueixo arribar a cap servei extern, ni tan sols
respon ping
> cap a
> > la porta d'enllaç ni els servidors DNS, ni aquests resolen
adreces.
> > Com a molt la pròpia IP pública respon a ping, però
qualsevol IP
> > d'Internet ja no.
>
> Hola Narcís,
>
> en aquest cas, i havent provat que amb un altre sistema
operatiu pot
> funcionar, cal descartar que l'operador posi pals a les rodes.
>
> Jo et diria de comprovar si un tallafocs està impedint la
connexió
> d'aquesta interfície de xarxa (amb això Wireshark podria
ajudar veient
> que s'envien paquets a l'altre extrem i veient si hi arriben
o què
> passa
> amb la resposta), però com que ho has provat amb un parell
d'Ubuntus on
> entenc que el tallafocs ve desactivat per defecte, llavors no
sabria
> què
> dir-te.
>
> El que m'estranya és que el ping respongui a la IP pública
> que nocontra un
> ho faci a la porta d'enllaç; no li veig el sentit.
>
> Jo analitzaria una connexió simple (ICMP, o sigui ping)
> dispositiu del mateix segment de xarxa amb el Wireshark, i
> n'interpretaria els resultats. Que no funcioni res _ho puc
arribar a
> entendre_, però que funcioni el ping només a la pròpia IP
pública em
> desconcerta.
>
> A veure si a algú més se li acut alguna altra cosa perquè
puguis provar.
>
>
>
> --
> --
> Salutacions...Josep
> --
--
__________administrator
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive
should fix this against automated addresses collectors.
--
--
Salutacions...Josep
--
--
__________
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator should fix this against automated addresses collectors.
<div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 20 Mar 2023 at 18:56, Narcis Garcia <<a href="mailto:debianlists@actiu.net">debianlists@actiu.net</a>> wrote:<br></div><blockquote class="gmail
Hola, Narcís,
Se'm va passar de comentar-te que aquestes adreces IP que apareixen (172.19.x.x) són adreces IP privades.
Ho dic perquè comentaves sobre "adreça pública"... Realment obté el teu aparell una adreça IP pública? Que no sigui el tema d'usuari/contrasenya del PPP (gestor de mòdem) que depèn del proveïdor de connexió i que, en no facilitar la correcta, et quedes amb una adreça IP d'enllaç amb el servei d'autenticació -l'adreça inicial- i prou (la seva "intranet",
vaja, com l'antiga "Infovía" anys enrere en l'ADSL/XDSI de la Telefónica).
Cordialment,
Josep
On Mon, 20 Mar 2023 at 18:56, Narcis Garcia <debianlists@actiu.net <mailto:debianlists@actiu.net>> wrote:
Hi he donat moltes voltes, i no sé per on tirar.
Arreu hi ha gent que diu que amb el mateix dispositiu lt4112
aconsegueix
funcionar amb GNU/Linux i des de fa anys, i no sembla que haguessin de
superar la meva mateixa dificultat.
Estic travat amb què connecta, senyalitza el nivell de cobertura,
adquireix la configuració IP (IP, porta, DNS), però no hi ha
comunicació
més enllà de la IP pública.
Tampoc no es rebutja la comunicació, sinó que no assoleix cap
destinació
externa.
Ara ja només se m'acudeix provar amb més i més distribucions de
GNU/Linux.
Gràcies als què heu intentat ajudar-me.
El 17/3/23 a les 22:04, Josep Lladonosa ha escrit:
> Hola, Narcís,
>
> Quan he parlat de PPP em referia al fet que es fan servir els
codis de
> configuració de connexions estil "mòdems". De fet, en principi, el
> NetworkManager no hauria de configurar res (tot i que a algun
lloc en
> parlen que podria fer la feina) ja que normalment s'usa el
> "ModemManager" que és qui parla amb l'adaptador USB i configura
aquesta
> connexió PPP (els paquets IP anirien dins aquesta). Per això em
referia
> que no sigui algun paràmetre de configuració d'aquest enllaç PPP.
>
> He trobat aquest web que llista els adaptadors compatibles amb Linux:
>
>
https://www.freedesktop.org/wiki/Software/ModemManager/SupportedDevices/ <https://www.freedesktop.org/wiki/Software/ModemManager/SupportedDevices/>
>
<https://www.freedesktop.org/wiki/Software/ModemManager/SupportedDevices/ <https://www.freedesktop.org/wiki/Software/ModemManager/SupportedDevices/>>
>
> Cordialment,
> Josep
>
>
>
> On Fri, 17 Mar 2023 at 16:13, Narcis Garcia
<debianlists@actiu.net <mailto:debianlists@actiu.net>
> <mailto:debianlists@actiu.net <mailto:debianlists@actiu.net>>> wrote:
>
> Hola Josep, l'opció de l'encaminador no em convenç per dues
raons:
> Perquè es fa un altre salt amb comunicació enrutada (LAN) i
aèria (la
> qual cosa perd latència etc.) i també perquè cal carregar més
trastos
> apart de l'ordinador. Per això ja em serviria el telèfon
mòbil que
> té el
> mateix paper, i el què tinc em resulta lent.
>
> El dispositiu es detecta en un primer moment com a emmagatzematge
> (0685:2000 ZD Incorporated USB Qualcomm Storage), però en uns
segons
> canvia a modem (12d1:1001 Huawei Technologies Co., Ltd.
> E161/E169/E620/E800 HSDPA Modem). Suposo que es tracta d'una
correcció
> que fa el udev o el què sigui que organitza els dispositius.
>
> 1. Utilitzo el NetworkManager. Com s'enumeren les connexions PPP?
> És el què dóna «nmcli connection show» o com es distingeixen
quan estan
> establertes com a PPP?
> 2. Amb la comanda «netstat -rn» veig que la ruta per defecte està
> definida, i al mateix espai d'adreces que el dispositiu modem:
>
> $ ip address show dev wwan0
> 5: wwan0: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
> pfifo_fast state UNKNOWN group default qlen 1000
> link/ether 96:75:07:e1:d1:29 brd ff:ff:ff:ff:ff:ff
> inet 172.19.211.64/25 <http://172.19.211.64/25>
<http://172.19.211.64/25 <http://172.19.211.64/25>> brd
> 172.19.211.127 scope global noprefixroute
> wwan0
> valid_lft forever preferred_lft forever
>
> $ ping -c 1 172.19.211.64
> PING 172.19.211.64 (172.19.211.64) 56(84) bytes of data.
> 64 bytes from 172.19.211.64 <http://172.19.211.64
<http://172.19.211.64>>: icmp_seq=1
> ttl=64 time=0.057 ms
> --- 172.19.211.64 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 0.057/0.057/0.057/0.000 ms
>
> $ netstat -rn
> Kernel IP routing table
> Destination Gateway Genmask Flags MSS
Window
> irtt
> Iface
> 0.0.0.0 172.19.211.1 0.0.0.0 UG 0 0
> 0
> wwan0
> 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0
> 0
> wwan0
> 172.19.211.0 0.0.0.0 255.255.255.128 U 0 0
> 0
> wwan0
>
> $ ping -c 1 172.19.211.1
> PING 172.19.211.1 (172.19.211.1) 56(84) bytes of data.
> --- 172.19.211.1 ping statistics ---
> 1 packets transmitted, 0 received, 100% packet loss, time 0ms
>
>
>
> El 17/3/23 a les 11:35, Josep Lladonosa ha escrit:
> > Hola, Adrià, Narcís,
> >
> > A la feina ens vam trobar que a partir d'una determinada
versió
> Ubuntu
> > determinats USB 3G van deixar de funcionar.
> > Actualment s'utilitzen "encaminadors" amb bateria (que es
> carreguen per
> > USB) que porten la SIM i engegats donen una WiFi a la que
diversos
> > equips poden connectar alhora.
> >
> > Si no recordo malament, hi havia temes de reconeixement de
> dispositiu
> > com a emmagatzematge (que no seria el teu cas) i altres
temes de com
> > s'usa el PPP.
> > Aquests adaptadors 3G/4G no deixen de ser aparells que
estableixen
> > connexions a l'estil dels "antics" mòdems. Podria ser que
es faci la
> > connexió PPP però a aquesta no se la definís com a ruta
per defecte.
> > Estic aportant des de la imaginació i aquest supòsit.
> >
> > Cordialment,
> > Josep
> >
> > On Fri, 17 Mar 2023 at 11:24, Adrià <adria@fsfe.org
<mailto:adria@fsfe.org>
> <mailto:adria@fsfe.org <mailto:adria@fsfe.org>>
> > <mailto:adria@fsfe.org <mailto:adria@fsfe.org>
<mailto:adria@fsfe.org <mailto:adria@fsfe.org>>>> wrote:
> >
> > Am 16/03/2023 um 14:18 schrieb Narcis Garcia:
> > > No tinc ni idea de què fer amb Wireshark per a
comprovar
> no sé el
> > què.
> > > A GNU/Linux el dispositiu es configura (IP, porta,
DNS),
> però no
> > > aconsegueixo arribar a cap servei extern, ni tan sols
> respon ping
> > cap a
> > > la porta d'enllaç ni els servidors DNS, ni aquests
resolen
> adreces.
> > > Com a molt la pròpia IP pública respon a ping, però
> qualsevol IP
> > > d'Internet ja no.
> >
> > Hola Narcís,
> >
> > en aquest cas, i havent provat que amb un altre sistema
> operatiu pot
> > funcionar, cal descartar que l'operador posi pals a
les rodes.
> >
> > Jo et diria de comprovar si un tallafocs està impedint la
> connexió
> > d'aquesta interfície de xarxa (amb això Wireshark podria
> ajudar veient
> > que s'envien paquets a l'altre extrem i veient si hi
arriben
> o què
> > passa
> > amb la resposta), però com que ho has provat amb un parell
> d'Ubuntus on
> > entenc que el tallafocs ve desactivat per defecte,
llavors no
> sabria
> > què
> > dir-te.
> >
> > El que m'estranya és que el ping respongui a la IP
pública mentre
> > que no
> > ho faci a la porta d'enllaç; no li veig el sentit.
> >
> > Jo analitzaria una connexió simple (ICMP, o sigui
ping) contra un
> > dispositiu del mateix segment de xarxa amb el Wireshark, i
> > n'interpretaria els resultats. Que no funcioni res _ho puc
> arribar a
> > entendre_, però que funcioni el ping només a la pròpia IP
> pública em
> > desconcerta.
> >
> > A veure si a algú més se li acut alguna altra cosa perquè
> puguis provar.
> >
> >
> >
> > --
> > --
> > Salutacions...Josep
> > --
>
> --
>
>
> __________
> I'm using this express-made address because personal
addresses aren't
> masked enough at this mail public archive. Public archive
administrator
> should fix this against automated addresses collectors.
>
>
>
> --
> --
> Salutacions...Josep
> --
--
__________
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
--
--
Salutacions...Josep
--
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 125:10:18 |
| Calls: | 6,662 |
| Files: | 12,212 |
| Messages: | 5,334,849 |