Ciao UnixMan,
Miska mi ha risposto. Non mi ha fatto avere la versione 4.13.1 di HQP per Ubuntu, in quanto quando è stato rilasciato quest'ultimo era alla versione 20.04 LTS mentre io ho attualmente la 22.04 LTS.
Comunque, vorrei provare a chiedere nuovamente il tuo aiuto.
Facendo il ping dal NAA a Ubuntu, sull'interfaccia di rete eno1, ho avuto il seguente risultato (l'interfaccia non viene trovata):
debian@sr-imx6:~$ ping -I eno1 192.168.1.130
ping: SO_BINDTODEVICE eno1: No such device
Poi, in rete ho trovato che alcuni software non funzionano con alcuni nomi di interfaccia di rete e quindi ho cambiato il nome in eth0, che viene invece riconosciuto, ma HQP ha continuato a non vedere il NAA :
debian@sr-imx6:~$ ping -I eth0 192.168.1.130
PING 192.168.1.130 (192.168.1.130) from 192.168.1.233 eth0: 56(84) bytes of data.
64 bytes from 192.168.1.130: icmp_seq=1 ttl=64 time=3.52 ms
64 bytes from 192.168.1.130: icmp_seq=2 ttl=64 time=3.54 ms
64 bytes from 192.168.1.130: icmp_seq=3 ttl=64 time=3.68 ms
64 bytes from 192.168.1.130: icmp_seq=4 ttl=64 time=3.50 ms
64 bytes from 192.168.1.130: icmp_seq=5 ttl=64 time=3.53 ms
64 bytes from 192.168.1.130: icmp_seq=6 ttl=64 time=4.68 ms
64 bytes from 192.168.1.130: icmp_seq=7 ttl=64 time=3.53 ms
^C
--- 192.168.1.130 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6005ms
rtt min/avg/max/mdev = 3.504/3.710/4.681/0.400 ms
Prima di concludere, riporto altre interrogazioni (porte in ascolto):
su Ubuntu:
vincenzo@vincenzo-imedia-S3850:~$ sudo lsof -nP -iTCP -sTCP:LISTEN
[sudo] password di vincenzo:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
systemd 1 root 68u IPv6 22375 0t0 TCP *:6600 (LISTEN)
systemd-r 670 systemd-resolve 14u IPv4 22702 0t0 TCP 127.0.0.53:53 (LISTEN)
cupsd 966 root 6u IPv6 25636 0t0 TCP [::1]:631 (LISTEN)
cupsd 966 root 7u IPv4 25637 0t0 TCP 127.0.0.1:631 (LISTEN)
mpd 967 root 4u IPv6 22375 0t0 TCP *:6600 (LISTEN)
sshd 988 root 3u IPv4 24646 0t0 TCP *:22 (LISTEN)
sshd 988 root 4u IPv6 24648 0t0 TCP *:22 (LISTEN)
squeezebo 1086 squeezeboxserver 9u IPv4 26793 0t0 TCP *:3483 (LISTEN)
squeezebo 1086 squeezeboxserver 20u IPv4 25314 0t0 TCP *:9090 (LISTEN)
squeezebo 1086 squeezeboxserver 24u IPv4 26874 0t0 TCP *:9000 (LISTEN)
smbd 1153 root 43u IPv6 23532 0t0 TCP *:445 (LISTEN)
smbd 1153 root 44u IPv6 23533 0t0 TCP *:139 (LISTEN)
smbd 1153 root 45u IPv4 23534 0t0 TCP *:445 (LISTEN)
smbd 1153 root 46u IPv4 23535 0t0 TCP *:139 (LISTEN)
mympd 1213 mympd 4u IPv4 24989 0t0 TCP *:80 (LISTEN)
mympd 1213 mympd 5u IPv4 24990 0t0 TCP *:443 (LISTEN)
gnome-rem 1400 vincenzo 8u IPv6 28708 0t0 TCP *:3389 (LISTEN)
rygel 1951 vincenzo 11u IPv4 29731 0t0 TCP 127.0.0.1:44929 (LISTEN)
rygel 1951 vincenzo 25u IPv4 29733 0t0 TCP 192.168.1.130:43759 (LISTEN)
rygel 1951 vincenzo 26u IPv6 29734 0t0 TCP [::1]:43243 (LISTEN)
rygel 1951 vincenzo 27u IPv6 29737 0t0 TCP [fe80::158d:fbe0:940b:975d]:40507 (LISTEN)
hqplayer4 8827 vincenzo 36u IPv6 65322 0t0 TCP *:8088 (LISTEN)
hqplayer4 8827 vincenzo 38u IPv6 65324 0t0 TCP *:4321 (LISTEN)
hqplayer4 8827 vincenzo 40u IPv4 65326 0t0 TCP *:4321 (LISTEN)
sul NAA
debian@sr-imx6:~$ sudo lsof -nP -iTCP -sTCP:LISTEN
[sudo] password for debian:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
connmand 348 root 13u IPv4 9237 0t0 TCP 127.0.0.1:53 (LISTEN)
connmand 348 root 14u IPv6 9241 0t0 TCP [::1]:53 (LISTEN)
sshd 378 root 3u IPv4 8192 0t0 TCP *:22 (LISTEN)
sshd 378 root 4u IPv6 9218 0t0 TCP *:22 (LISTEN)
networkau 382 root 4u IPv6 8818 0t0 TCP *:43210 (LISTEN)
networkau 382 root 6u IPv4 8820 0t0 TCP *:43210 (LISTEN)
Faccio notare che Ubuntu vede la porta 43210 su cui è in ascolto il Network Audio Daemon:
vincenzo@vincenzo-imedia-S3850:~$ sudo nc -vz 192.168.1.233 43210
Connection to 192.168.1.233 43210 port [tcp/*] succeeded!
mentre viceversa il NAA non vede su Ubuntu le porte 4321 e 8088 su cui è in ascolto HQP:
debian@sr-imx6:~$ nc -vz 192.168.1.130 4321
nc: connect to 192.168.1.130 port 4321 (tcp) failed: No route to host
debian@sr-imx6:~$ nc -vz 192.168.1.130 8088
nc: connect to 192.168.1.130 port 8088 (tcp) failed: No route to host
Ti viene in mente qualche soluzione, grazie?
Saluti.
Vincenzo
quelle porte servono per il controllo remoto e l'invio di dati in streaming verso HQP da altri software (apposite app per dispositivi mobili, roon, ecc) e - per quanto ne so - non credo siano mai utilizzate dal NAA (la comunicazione verso quello è iniziata da HQP).
Non di meno, alla luce dei test precedenti, il fatto che non siano raggiungibili è a dir poco strano. Soprattutto il messaggio di errore - “No route to host ” - mi lascia molto perplesso. Perché quel messaggio non significa che "non vede" quelle porte, ma che il Kernel non sa proprio dove (su quale interfaccia, ed eventualmente a quale gateway) inviare i pacchetti per raggiungere quella macchina!
Il che implicherebbe un problema grave con la configurazione della rete del NAA, che spiegherebbe tutto.
Solo che c'è qualcosa che non torna. Un problema simile ovviamente si ripercuote su qualsiasi tipo di traffico di rete verso quell'indirizzo IP (e verosimilmente quanto meno verso l'intera sottorete a cui appartiene), rendendo impossibile qualsiasi comunicazione. Per cui non dovrebbe funzionare proprio niente. Né SSH, né ping, né altro.
Mentre mi pare di ricordare che ti avevo chiesto di fare un test di connessione SSH e, sempre se non ricordo male, questo aveva dato esito positivo. E questo è impossibile, se il Kernel non ha una route valida verso quell'host!
C'è qualquadra che non cosa...
Verifica attentamente la configurazione della rete del NAA. Assicurati di non aver dimenticato pezzi di configurazioni vecchie in giro, che il nome dell'interfaccia specificato nella configurazione sia quello giusto, e lo stesso ovunque, ecc.
Qualche comando da dare (da root):
/sbin/ifconfig
netstat -rn
ARGH, solo ora me ne avvedo: COME hai configurato la rete?! Mi pare di ricordare che dicevi di aver usato il metodo "tradizionale" di Debian, cioè il file "/etc/network/interfaces". Ma, dalla lista dei processi in ascolto, vedo che sta girando "connmand". Che è un deamon per la configurazione della rete (analogo a "Network-Manager", che è quello comunemente impiegato dalla maggior parte dei sistemi desktop odierni, incluso Ubuntu). E che NON usa gli script ed il file di configurazione tradizionali di Debian!
https://manpages.debian.org/stable/c...nman.8.en.html
https://git.kernel.org/pub/scm/netwo...man.git/about/
https://wiki.ubuntu.com/ConnMan
Se è così, sicuro c'è qualche pasticcio.
Se non hai / non ti serve il WiFi sul NAA (presumo di no...), suggerirei di disisntallare completamente connman (apt purge connman) e fare affidamento esclusivamente sul file di configurazione "tradizionale".
Ultima modifica di UnixMan : 11-06-2023 a 02:43
Ciao, Paolo.
«Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»
Ciao UnixMan,
avevo già intuito che connman potesse dare problemi e l'avevo disinstallato, installando poi networkmanager. HQP continua a non vedere il NAA. Dovrei, per caso, provare a disinstallare anche networkmanager e settare solo /etc/network/interfaces?
Vincenzo
Ciao, Paolo.
«Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»
Ho fatto di più rispetto a quanto da te consigliato. ipotizzando di aver potuto io incasinare l'o.s. del NAA, ho reinstallato sullo stesso Debian Bullseye da una immagine specifica per il Cubox, reperita sul sito della Solidrun, l'azienda che lo produce.
Ho poi installato il NAD ultima versione. L'o.s. non ha nè connman nè networkmanager per la gestione delle connessioni di rete, che è invece configurata, di default in DHCP, in /etc/network/interfaces.d/*.
Evidenzio che i ping sono ok, effettuati da Ubuntu verso il NAA e viceversa, direttamente sulle rispettive interfacce eth0, e HQP su Ubuntu continua a non vedere il NAA, mentre su Windows lo vede (come accaduto sia con l'o.s. installato con l'immagine di Miska che con l'o.s. installato da me in precedenza).
Per le mie poche competenze, non saprei più che fare.
Non avendolo fatto prima e ritenendo che magari te lo sei chiesto, specifico che sto insistendo sul cercare di far funzionare HQP+NAA su Ubuntu, in quanto preferisco nettamente il suono prodotto da Linux rispetto a quello prodotto da Windows.
Ti chiedo se ti viene in mente qualche altra soluzione (inizio a dubitare ce ne siano.....).
Saluti, Vincenzo
sicuramente la soluzione c'è... e probabilmente è anche banale... una volta capito qual è il problema. Che però si fa sempre più misterioso. Due cose, anzi tre:
1) disegnami uno schema di come è fatta la rete;
2) prova ad installare una versione diversa di HQP, ad es. la nuova 5, e vedi se cambia qualcosa.
3) se non lo hai già fatto, prova a dire ad HQP di usare IPv6 anziché IPv4.
Ciao, Paolo.
«Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»
Ciao, Paolo.
«Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»
Ci sono attualmente 5 utenti che stanno visualizzando questa discussione. (0 utenti e 5 ospiti)
|
nexthardware.com - © 2002-2022 |
Rispondi quotando