SSH port 22: connection refused

[Joost996me]

Mijn vraag

Ik kan met mijn macbook niet meer in mijn headless raspi pi3 komen met Domoticz hierop. Port 22 is open, SSH draait op pi. Geen locale firewall. Kan er wel in met een andere mac en ook met PC. Dat bewijst mi dat dat het probleem niet aan de Raspi ligt.

Ik log in met username en password, dat klopt, want dat lukt me via de andere Mac...

Hopelijk kan iemand me verder helpen!

Dank!

[PhilipsFan]

Kun je 'm wel pingen? Zit je Macbook misschien op een ander wifi-netwerk, bijvoorbeeld voor de gasten?

[StarWing]

fail2ban ?

[Joost996me]

StarWing schreef op zondag 18 februari 2024 @ 17:29:
fail2ban ?

Nee die heb ik niet aanstaan. Kan andere pi's wel benaderen vanaf deze Macbook. Lukt me wel om de betreffende pi te pingen.

Dank voor het meedenken!

[vj_slof]

edit ~/.ssh/known_hosts bestand met nano als su en verwijder het ip-adres en key van de mac die problemen geeft en probeer opnieuw.

[MartinMeijerink]

Is de betreffende RPi net ietsje nieuwer dan die andere? En/of is de betreffende mac ietsje ouder dan de andere macs? Dan kan het zijn dat deze mac en de RPi geen gemeenschappelijk algoritme meer hebben.

Doe je het vanuit de terminal van je mac? Zo nee, doe dat eens dan. En wat voor melding geeft ie dan?
Nog beter is het om de optie -v te gebruiken, wat zegt ie als je bv. dit doet:

ssh -v <user>@<rpi3adres>

Daar is het antwoord nl. al uit te halen.

[nelizmastr]

vj_slof schreef op maandag 19 februari 2024 @ 09:06:
edit ~/.ssh/known_hosts bestand met nano als su en verwijder het ip-adres en key van de mac die problemen geeft en probeer opnieuw.

Dit was ook mijn eerste gedachte. Als de key van de Pi is veranderd (bijv. door omnummering van IP’s of anders) is deze niet meer vertrouwd en is het nodig de known hosts op te ruimen

[Joost996me]

vj_slof schreef op maandag 19 februari 2024 @ 09:06:
edit ~/.ssh/known_hosts bestand met nano als su en verwijder het ip-adres en key van de mac die problemen geeft en probeer opnieuw.

Had dat bestand al leeggemaakt, maar helaas geeft dat nog geen oplossing... Sorry had ik niet vermeld in de initiele post..

[Joost996me]

MartinMeijerink schreef op maandag 19 februari 2024 @ 09:23:
Is de betreffende RPi net ietsje nieuwer dan die andere? En/of is de betreffende mac ietsje ouder dan de andere macs? Dan kan het zijn dat deze mac en de RPi geen gemeenschappelijk algoritme meer hebben.

Doe je het vanuit de terminal van je mac? Zo nee, doe dat eens dan. En wat voor melding geeft ie dan?
Nog beter is het om de optie -v te gebruiken, wat zegt ie als je bv. dit doet:

ssh -v <user>@<rpi3adres>

Daar is het antwoord nl. al uit te halen.

Heeft altijd prima gewerkt tot paar weken geleden. Kan met de mac ook wel inloggen in andere pi4's, van zelfde leeftijd dus.

[eric.1]

nelizmastr schreef op maandag 19 februari 2024 @ 21:20:
[...]


Dit was ook mijn eerste gedachte. Als de key van de Pi is veranderd (bijv. door omnummering van IP’s of anders) is deze niet meer vertrouwd en is het nodig de known hosts op te ruimen

Dan krijg je over het algemeen geen 'connection refused' melding maar een 'The authenticity of host .... can't be established' melding, toch?

'connection refused' lijkt te duiden, imo, op een server-side 'probleem'. Ik zou zeggen, probeer in te loggen en bekijk de auth/sshd logs op de rpi.

[CH4OS]

Joost996me schreef op dinsdag 20 februari 2024 @ 09:23:
Heeft altijd prima gewerkt tot paar weken geleden. Kan met de mac ook wel inloggen in andere pi4's, van zelfde leeftijd dus.

En als je desondanks toch even met ssh -v naar de Pi probeert te connecten, wat is de output dan?

[ElCondor]

Weet je zeker dat je op de pi inlogt waarop je denkt in te loggen? Ik had er laatst een die niet meer zijn DHCP reservering respecteerde na een herinstallatie (Linux geeft tegenwoordig geen mac als identification aan DHCP door en de pi kreeg een heel ander adres). Het gereserveerde adres was op een andere pi terecht gekomen en ik bleek daarop pogingen te doen om in te loggen.. dat ging natuurlijk niet werken.
Best is om eens in je DHCP overizcht te kijken welk IP adres de pi heeft en dan expliciet in te loggen met <username>@<ip_adres> ipv <username>@<hostname>.

[CH4OS]

ElCondor schreef op dinsdag 20 februari 2024 @ 09:39:
Weet je zeker dat je op de pi inlogt waarop je denkt in te loggen? Ik had er laatst een die niet meer zijn DHCP reservering respecteerde na een herinstallatie (Linux geeft tegenwoordig geen mac als identification aan DHCP door en de pi kreeg een heel ander adres). Het gereserveerde adres was op een andere pi terecht gekomen en ik bleek daarop pogingen te doen om in te loggen.. dat ging natuurlijk niet werken.
Best is om eens in je DHCP overizcht te kijken welk IP adres de pi heeft en dan expliciet in te loggen met <username>@<ip_adres> ipv <username>@<hostname>.

Hoe kan het IP-adres op een andere Pi uitkomen, als je op het MAC adres een reservering hebt in de DHCP? Dan zou die andere Pi het IP-adres ook niet moeten krijgen, die geeft dan immers minstens een ander MAC-adres door aan de DHCP (als die schijnbaar dat nog wel doet).

Overigens wel gek als Linux geen MAC adres meer doorgeeft aan DHCP, want dat is waarop de reserveringen werken en waarop de IP-adressen uitgedeeld worden. Ik kan mij daarom ook niet helemaal voorstellen dat er gebeurd wat je omschrijft.

[ElCondor]

CH4OS schreef op dinsdag 20 februari 2024 @ 10:16:
[...]
Hoe kan het IP-adres op een andere Pi uitkomen, als je op het MAC adres een reservering hebt in de DHCP? Dan zou die andere Pi het IP-adres ook niet moeten krijgen, die geeft dan immers minstens een ander MAC-adres door aan de DHCP (als die schijnbaar dat nog wel doet).

Overigens wel gek als Linux geen MAC adres meer doorgeeft aan DHCP, want dat is waarop de reserveringen werken en waarop de IP-adressen uitgedeeld worden. Ik kan mij daarom ook niet helemaal voorstellen dat er gebeurd wat je omschrijft.

Hey, ik was even flabberghasted als jij... een behoorlijke head-scratcher...
Maar ik heb het zien gebeuren. Wat Linux tegenwoordig mee lijkt te sturen is een IAID of DUID.
Waarom het ip addres op een ander systeem terecht is gekomen, durf ik niet te zeggen. Het ging hier wel om een Windows DHCP server. De pi's hebben als ID een gelijkende string in het begin en als ik de volledige string als ID opgeef in de DHCP server dan klaagt hij erover dat het een ongeldige ID zou zijn. Ik vermoed zo maar eens dat hij alleen de eerste 16 bits daadwerkelijk gebruikt onder de motorkap, maar dat is een vermoeden.

Ik heb inmiddels gelezen dat je het gebruik van MAC adres kunt afdwingen door dit op te nemen in de dhcpd.conf. Dus dat ga ik maar eens doen.

[Joost996me]

ElCondor schreef op dinsdag 20 februari 2024 @ 09:39:
Weet je zeker dat je op de pi inlogt waarop je denkt in te loggen? Ik had er laatst een die niet meer zijn DHCP reservering respecteerde na een herinstallatie (Linux geeft tegenwoordig geen mac als identification aan DHCP door en de pi kreeg een heel ander adres). Het gereserveerde adres was op een andere pi terecht gekomen en ik bleek daarop pogingen te doen om in te loggen.. dat ging natuurlijk niet werken.
Best is om eens in je DHCP overizcht te kijken welk IP adres de pi heeft en dan expliciet in te loggen met <username>@<ip_adres> ipv <username>@<hostname>.

Weet ik zeker want ik gebruik zelfde ip (juiste dus) op andere mac en dan lukt het wel. Ip staat ook vast in router, maar goede suggestie! Thx

[Qwerty-273]

Heb je in sshd_config wellicht iets staan waardoor de gebruiker allen vanaf een bepaald IP kan inloggen? Of welke authenticatiemethodes gebruikt mogen worden vanaf een bepaald IP.

[Joost996me]

Qwerty-273 schreef op woensdag 21 februari 2024 @ 13:34:
Heb je in sshd_config wellicht iets staan waardoor de gebruiker allen vanaf een bepaald IP kan inloggen? Of welke authenticatiemethodes gebruikt mogen worden vanaf een bepaald IP.

Zie daar niks staan wat terug te voeren is op het lokaal IP van mijn niet werkende MAC. Jammer...

[ElCondor]

code:

ssh -v <user>@<rpi3adres>

Had je deze nu al eens getest? Post daar de output eens van?

[IVEL]

Ik lees in je openings post dat je wel vanaf een andere Mac en PC op de betreffende Pi met ssh kan inloggen. Heb je dat al eens gedaan, een tail op de sshd log gezet en dan een poging vanaf de niet-werkende Mac om in te loggen gedaan?

Wat zegt de sshd log over de niet-werkende inlog poging dan?

[Joost996me]

ElCondor schreef op donderdag 22 februari 2024 @ 13:42:

code:

ssh -v <user>@<rpi3adres>

Had je deze nu al eens getest? Post daar de output eens van?

Dank voor het meedenken!

OpenSSH_9.0p1, LibreSSL 3.3.6
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to 192.168.2.18 [192.168.2.18] port 22.
debug1: connect to address 192.168.2.18 port 22: Connection refused
ssh: connect to host 192.168.2.18 port 22: Connection refused

[Joost996me]

IVEL schreef op donderdag 22 februari 2024 @ 13:49:
Ik lees in je openings post dat je wel vanaf een andere Mac en PC op de betreffende Pi met ssh kan inloggen. Heb je dat al eens gedaan, een tail op de sshd log gezet en dan een poging vanaf de niet-werkende Mac om in te loggen gedaan?

Wat zegt de sshd log over de niet-werkende inlog poging dan?

Kan inderdaad vanaf andere Mac er probleemloos in. Dus poort, ssh en zo werken op de pi/netwerk. Wat bedoel je met een tail op de sshd log?

dank!

[eric.1]

Met een tail kijk je naar de laatste entries van een file, in dit geval de logs van sshd. `tail -f [filename]` en je zal de laatste entries voorgeschoteld blijven krijgen.

1.) probeer in te loggen met de problematische machine
2.) kijk daarna direct op de RPI in de logs omtrent sshd

Voor punt 2 kun je in principe het volgende uitvoeren op de RPI:

Bash:

journalctl -u ssh | tail -n 20

Of als je een `/var/log/auth.log`-bestand hebt

Bash:

cat /var/log/auth.log | tail -n 20

of

Bash:

tail -f /var/log/auth.log

Wanneer het goed gaat zie je iets als het volgende (indien je keys gebruikt ipv wachtwoorden)

Bash:

Feb 23 10:41:53 raspberrypi sshd[...]: Accepted publickey for [user1] from [ip]
...
Feb 23 10:41:53 raspberrypi sshd[...]: pam_unix(sshd:session): session opened for [user1](uid=....) by (uid=...)

Maar in jouw geval zal er een probleem worden gelogd, denk ik.

[Joost996me]

Ik zie in het log geen enkele melding binnen komen vanaf het lokale ip adres van de niet werkende Mac. Als ik met andere Mac inlog dan klopt het dat het te zien is in het log: session opened. Helaas dus ook niks gelogd waar ik iets verder mee kom.

Nogmaals dank voor het meedenken!

[eric.1]

Dan vraag ik me af of je wel het juiste aders benadert. Heb je iets van een firewall geconfigureerd welke op IP-basis blokkeert?

[Joost996me]

zeke r het juiste adres, zelfde als op andere mac. Dan werkt het wel. Heb geen firewall actief, staat als inactief in de mac. Heb ook geen fail2ban oid ingesteld...

[ElCondor]

Toch klopt er serieus iets niet. Kun je de ARP table eens opvragen op de Mac waar het niet werkt? Klopt het hardware adres dat bij het betreffende IP adres van de Pi vermeld wordt? Vergelijk dat eens met dezelfde ARP table op de Mac waar het wel werkt?

Het commando dat je op beide Macs uit moet voeren:

code:

arp -a

Heb je op de Mac waar het niet werkt wellicht een uitgaande Firewall regel ingesteld staan? (Sorry als dit al gevraagd is, het is vrijdag avond )

[Hero of Time]

Heb je niet iets met hosts.deny gedaan op je Pi en ben je vergeten dat je dit ooit hebt ingericht? Controleer dus even of dit bestand bestaat in /etc.

[deHakkelaar]

Joost996me schreef op vrijdag 23 februari 2024 @ 14:56:
Ik zie in het log geen enkele melding binnen komen vanaf het lokale ip adres van de niet werkende Mac. Als ik met andere Mac inlog dan klopt het dat het te zien is in het log: session opened. Helaas dus ook niks gelogd waar ik iets verder mee kom.

Nogmaals dank voor het meedenken!

Dan vraag ik me af ofdat SSH verkeer wel aankomt.
Wat laat een tcpdump zien op de Pi als je probeert te verbinden vanaf die probleem client?
Zoiets als onder waarbij je de SSH client waarmee je de tcpdump wilt uitvoeren uitsluit in de sniff output als je <IP> vervangt met die van deze client (dus niet het IP vd probleem client):

code:

sudo tcpdump -nti any tcp port 22 and not host <IP>

EDIT: Raspbian/Debian/Ubuntu of afgeleide?
Dan kun je tcpdump installeren met:

code:

sudo apt install tcpdump

[ Voor 7% gewijzigd door deHakkelaar op 24-02-2024 18:45 ]

[deHakkelaar]

ElCondor schreef op vrijdag 23 februari 2024 @ 20:52:

code:

arp -a

Ik geloof dat het arp commando alleen geldt voor IPv4.
Onder toont naast klasieke IPv4 ARP ook "neighbors" ontdekt via ICMPv6:

code:

ip -br neighbor

EDIT: Of korter

code:

ip -br n

[ Voor 6% gewijzigd door deHakkelaar op 24-02-2024 19:02 ]

[eric.1]

Welke OpenSSH-versie gebruikt de wel-werkende Mac (`ssh -V`) en RPI (`sshd -V`) trouwens? Aangezien het een RPI3 (aanname dat de software ook ietwat is verouderd) is zou het zonder meer kunnen dat de niet-werkende Mac (OpenSSH_9.0p1) bepaalde hash-algoritmes niet meer standaard ondersteunt waar de RPI gebruik van maakt.

Alsnog zou je wel iets meer moeten zien aan logs, dat blijft curieus.

[ Voor 9% gewijzigd door eric.1 op 24-02-2024 19:19 ]

[deHakkelaar]

ElCondor schreef op vrijdag 23 februari 2024 @ 20:52:

code:

arp -a

Op Debian Bookworm:

$ sudo arp
-bash: arp: command not found

$ apt-file search /usr/sbin/arp
[..]
net-tools: /usr/sbin/arp

$ apt show net-tools
[..]
Description: NET-3 networking toolkit
 This package includes the important tools for controlling the network
 subsystem of the Linux kernel.  This includes arp, ifconfig, netstat,
 rarp, nameif and route.  Additionally, this package contains utilities
 relating to particular network hardware types (plipconfig, slattach,
 mii-tool) and advanced aspects of IP configuration (iptunnel, ipmaddr).
 .
 In the upstream package 'hostname' and friends are included. Those are
 not installed by this package, since there is a special "hostname*.deb".

Al die binaries zijn inmiddels deprecated
arp --> ip
ifconfig --> ip
netstat --> ss
route --> ip

[CH4OS]

Joost996me schreef op vrijdag 23 februari 2024 @ 10:36:
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to 192.168.2.18 [192.168.2.18] port 22.
debug1: connect to address 192.168.2.18 port 22: Connection refused
ssh: connect to host 192.168.2.18 port 22: Connection refused

Zou het verbinden niet kunnen lukken door wat er op genoemde regel 54 staat? Wordt er geen ssh key afgedwongen op de server? Omdat de $SSH_SK_PROVIDER niet gezet is? Vergelijk dus de config van de niet werkende Mac eens met de wél werkende zou ik zeggen.

[ElCondor]

deHakkelaar schreef op zaterdag 24 februari 2024 @ 19:20:
[...]

Op Debian Bookworm:

$ sudo arp
-bash: arp: command not found

$ apt-file search /usr/sbin/arp
[..]
net-tools: /usr/sbin/arp

$ apt show net-tools
[..]
Description: NET-3 networking toolkit
 This package includes the important tools for controlling the network
 subsystem of the Linux kernel.  This includes arp, ifconfig, netstat,
 rarp, nameif and route.  Additionally, this package contains utilities
 relating to particular network hardware types (plipconfig, slattach,
 mii-tool) and advanced aspects of IP configuration (iptunnel, ipmaddr).
 .
 In the upstream package 'hostname' and friends are included. Those are
 not installed by this package, since there is a special "hostname*.deb".

Al die binaries zijn inmiddels deprecated
arp --> ip
ifconfig --> ip
netstat --> ss
route --> ip

Holy shit, ik begin oud te worden....

[DataGhost]

Connection refused is iets wat op TCP-niveau gebeurt (layer 4), daar komt heel SSH (layer 7) niet eens bij kijken. Als je met telnet of netcat probeert daarheen te verbinden zal dat ook niet lukken met "Connection refused". Dat ligt dus aan ofwel de service die niet draait ofwel een firewall die de verbinding weigert (inkomend/uitgaand) op een van de machines (server, client, andere tussenliggende devices).

Dus je zal inderdaad moeten onderzoeken of de machines wel op hetzelfde netwerk zitten, of de werkende en de niet-werkende client daadwerkelijk met hetzelfde IP en MAC proberen te verbinden, of er geen firewall-regels in het spel zijn, enz.

[deHakkelaar]

DataGhost schreef op zondag 25 februari 2024 @ 12:51:
Als je met telnet of netcat probeert daarheen te verbinden zal dat ook niet lukken met "Connection refused".

$ nc -vz 10.0.0.3 22
nas.home.dehakkelaar.nl [10.0.0.3] 22 (ssh) open

[deHakkelaar]

ElCondor schreef op zondag 25 februari 2024 @ 12:38:
[...]


Holy shit, ik begin oud te worden....

Ik maakte denk ik een vergissing.
De bedoeling was natuurlijk om de ARP cache/table uit te lezen op de probleem Mac.
Geen idee ofdat je daar het ip commando ter beschikking hebt?

EDIT: En ofdat de OP IPv6 aktief heeft op z'n netwerk???
IPv6 heeft meestal de voorkeur boven een IPv4 verbinding.

EDIT2: ow laat dat laatste maar, zo te zien via IPv4:

Joost996me schreef op vrijdag 23 februari 2024 @ 10:36:

debug1: Connecting to 192.168.2.18 [192.168.2.18] port 22.

[ Voor 33% gewijzigd door deHakkelaar op 25-02-2024 17:48 ]

[DataGhost]

deHakkelaar schreef op zondag 25 februari 2024 @ 17:09:
[...]

$ nc -vz 10.0.0.3 22
nas.home.dehakkelaar.nl [10.0.0.3] 22 (ssh) open

Dus als jij nu ssh 10.0.0.3 uitvoert krijg je ook "Connection refused" te zien bedoel je? Want dat was de context van dit topic. Als je geen firewallregels hebt die iets blokkeren en er een service op hebt luisteren zal het wel werken ja. Maar als je connection refused voor je kiezen krijgt wordt er uberhaupt geen verbinding gemaakt, niet met ssh, niet met netcat, niet met een browser, nergens mee. Als je dat niet gelooft, probeer maar eens ssh -p 1337 10.0.0.3 (of net welke poort connection refused geeft bij jou) en daarna nc -vz 10.0.0.3 1337, of iets als

iptables -A OUTPUT -p tcp --dport 22 -j REJECT
ssh 10.0.0.3
nc -vz 10.0.0.3 22
iptables -D OUTPUT -p tcp --dport 22 -j REJECT

dan zal je het zien.

Deze post is niet aan TS gericht trouwens.

[ Voor 15% gewijzigd door DataGhost op 25-02-2024 18:23 ]

[deHakkelaar]

@DataGhost , ik laat alleen zien hoe te doen met netcat

$ man nc
[..]
       -v           verbose [use twice to be more verbose]
[..]
       -z           zero-I/O mode [used for scanning]

Dat -z argument kijkt alleen ofdat er een TCP verbinding mogelijk is (FIN --> ACK) en sluit daarna de verbinding.

[DataGhost]

Bijster nuttig is dat verder ook niet, want we weten al dat er geen verbinding gemaakt wordt, dus dat testen met netcat heeft geen zin, de uitkomst is al bekend. Overigens is het SYN -> SYN-ACK maar goed (en in dit geval SYN -> RST). FIN is pas bij het sluiten van de verbinding.

[ Voor 5% gewijzigd door DataGhost op 25-02-2024 18:28 ]

[deHakkelaar]

DataGhost schreef op zondag 25 februari 2024 @ 18:26:
Overigens is het SYN -> SYN-ACK maar goed. FIN is pas bij het sluiten van de verbinding.

Sorry ik moest ook ff zoeken omdat ik het niet meer zeker wist (EDIT: ow onder was dus verkeerd opgezocht):

[ Voor 12% gewijzigd door deHakkelaar op 25-02-2024 18:46 ]

[Joost996me]

eric.1 schreef op zaterdag 24 februari 2024 @ 19:16:
Welke OpenSSH-versie gebruikt de wel-werkende Mac (`ssh -V`) en RPI (`sshd -V`) trouwens? Aangezien het een RPI3 (aanname dat de software ook ietwat is verouderd) is zou het zonder meer kunnen dat de niet-werkende Mac (OpenSSH_9.0p1) bepaalde hash-algoritmes niet meer standaard ondersteunt waar de RPI gebruik van maakt.

Alsnog zou je wel iets meer moeten zien aan logs, dat blijft curieus.

Mac:
OpenSSH_9.0p1, LibreSSL 3.3.6

RPi:
OpenSSH_7.9p1, open SSL 1.1.1n

[Joost996me]

DataGhost schreef op zondag 25 februari 2024 @ 18:15:
[...]

Deze post is niet aan TS gericht trouwens.

[DataGhost]

Joost996me schreef op zondag 25 februari 2024 @ 20:14:
[...]

DataGhost in "SSH port 22: connection refused"
Deze was wel aan jou gericht. Versies boeien helemaal niks want je hebt überhaupt geen verbinding. Je hebt op behoorlijk wat vragen in dit topic nog niet gereageerd.

Dus, je hebt machines A en B waarmee je kan verbinden, machine C waarmee je niet kan verbinden en machine P is je Pi.
* Wat voor firewall-regels zijn er op elk van deze machines A, B, C en ook op P actief? Ook al heb je zelf niks ingesteld wil dat niet zeggen dat er geen regels actief zijn. Kan ook zijn dat er toch met bijv. iptables het een en ander wordt tegengehouden dus probeer eens een iptables -L op alle machines. Of dat er op MacOS ook is weet ik niet maar je kan het altijd checken.
* Heb je op je Pi bestanden als /etc/hosts.deny en /etc/hosts.allow?
* Wat zijn de IP's van A, B, C en P?
* Met welk IP proberen A, B en C te verbinden (dus bijv. te zien met ssh -v wat je al gedaan had)?
* Welke MAC-adressen horen daarbij op machines A, B en C? Dus iets als ip neigh show 192.168.2.xxx, of anders met iets als arp 192.168.2.xxx of gewoon arp -a. En komt dat overeen met het MAC-adres van je Pi?
* Zitten ze op hetzelfde netwerk (wifi/kabel), of zit bijvoorbeeld C "anders" aangesloten dan A en B, dus bijv. met een extra switch ofzo ertussen? Is C misschien stiekem verbonden met een hotspot ofzo?
* Werkt het ook als je C aansluit met de netwerkkabel van A of B (als het bedraad is)?

[Joost996me]

Dus, je hebt machines A en B waarmee je kan verbinden, machine C waarmee je niet kan verbinden en machine P is je Pi.
* Wat voor firewall-regels zijn er op elk van deze machines A, B, C en ook op P actief? Ook al heb je zelf niks ingesteld wil dat niet zeggen dat er geen regels actief zijn. Kan ook zijn dat er toch met bijv. iptables het een en ander wordt tegengehouden dus probeer eens een iptables -L op alle machines. Of dat er op MacOS ook is weet ik niet maar je kan het altijd checken.

Geen regels op Rpi, MAC1 (werkt niet) en MAC2 (werkt wel) geen regel: command not found: iptables

* Heb je op je Pi bestanden als /etc/hosts.deny en /etc/hosts.allow?

Ja, maar beiden leeg. Het toevoegen van MAC1 lokaal ip in allow lost niks op.


* Wat zijn de IP's van A, B, C en P?

lokale ips;

MAC1 192.168.2.14
MAC2 192.168.2.44
Rpi 192.168.2.18

* Met welk IP proberen A, B en C te verbinden (dus bijv. te zien met ssh -v wat je al gedaan had)?
* Welke MAC-adressen horen daarbij op machines A, B en C? Dus iets als ip neigh show 192.168.2.xxx, of anders met iets als arp 192.168.2.xxx of gewoon arp -a. En komt dat overeen met het MAC-adres van je Pi?
* Zitten ze op hetzelfde netwerk (wifi/kabel), of zit bijvoorbeeld C "anders" aangesloten dan A en B, dus bijv. met een extra switch ofzo ertussen? Is C misschien stiekem verbonden met een hotspot ofzo?

heb 1 wifi en zitten ze allemaal op. Rpi bedraad naar router


* Werkt het ook als je C aansluit met de netwerkkabel van A of B (als het bedraad is)?

Op de mac kan ik geen Ethernet aansluiten....


Dank voor het meedenken. Reacties in de tekst hierboven.

[ Voor 9% gewijzigd door Joost996me op 26-02-2024 15:51 ]

[DataGhost]

Je vergeet toch de twee waarschijnlijk belangrijkste vragen te beantwoorden.

[ElCondor]

Lukt het met .18 wel om in te loggen en met .44 niet, toevallig?

Is het dan een subnet issue?
Welke subnet masks heb je ingesteld op:

• De Mac waar het niet mee lukt
• De Mac waar het wel mee lukt
• De RPi

_{Ik zou bijna vragen waar je woont om eens te komen buurten, want dit is echt een mysterie}

[Raymond P]

Geef die mac eens een power toggle?

[Joost996me]

ElCondor schreef op dinsdag 27 februari 2024 @ 10:27:
Lukt het met .18 wel om in te loggen en met .44 niet, toevallig?

Is het dan een subnet issue?
Welke subnet masks heb je ingesteld op:

• De Mac waar het niet mee lukt
• De Mac waar het wel mee lukt
• De RPi

_{Ik zou bijna vragen waar je woont om eens te komen buurten, want dit is echt een mysterie}

Allemaal op zelfde subnet 255.255.255.0

[Joost996me]

Beste allemaal,

Het werkt weer. Gisteren is de Mac die het niet deed, helemaal leeg geraakt en dus opnieuw opgestart. Toen heeft ie een nieuw ip adres gekregen van de DHCP server. En je raadt het nooit; het werkt weer!!!

Wat nu oorzaak was is en blijft me onduidelijk, maar het werkt weer!

Heel veel dank voor het meedenken allemaal!

[Hero of Time]

Dus je hebt nooit je apparaat herstart? Dat doe je in zo'n situatie toch als eerste?

Nu toch benieuwd wat er gebeurt als je je Mac een vast adres geeft, eerst het adres wat het nu heeft gekregen en daarna met wat je hiervoor van DHCP kreeg, uitgaande dat het geen conflict gaat geven. Werkt het dan nog steeds?

[Joost996me]

Hero of Time schreef op dinsdag 27 februari 2024 @ 19:20:
Dus je hebt nooit je apparaat herstart? Dat doe je in zo'n situatie toch als eerste?

Nu toch benieuwd wat er gebeurt als je je Mac een vast adres geeft, eerst het adres wat het nu heeft gekregen en daarna met wat je hiervoor van DHCP kreeg, uitgaande dat het geen conflict gaat geven. Werkt het dan nog steeds?

Zeker wel herstart, maar toen blijkbaar geen effect cq nieuwe configuratie gekregen...

Als ik m her-IP naar het oude IP dan doet ie het idd niet meer, dus ergens ligt daar wel een probleem

dank voor het meedenken allemaal

[Hero of Time]

En een ander systeem dat wel werkte het problematische IP geven? Werkt die dan niet meer?

Als dat het geval is, moet je toch echt gaan zoeken in /etc voor dat adres want je blokkeert die ergens.