<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Sorry für den Spam!</p>
<p>Enigmail scheint meine Thunderbird Installation zu crashen x)<br>
</p>
<div class="moz-cite-prefix">Am 24.11.2019 um 12:05 schrieb Jan
Philippi via freifunk-public:<br>
</div>
<blockquote type="cite"
cite="mid:8d6e0b02-f6e4-f63a-061d-c5dad5cdfe8f@philippi.pw">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Hi,</p>
<p>versuch mal MTU Probing zu aktivieren.</p>
<p>Hab ne Mail angehängt. :)</p>
<p>Liebe Grüße<br>
</p>
<div class="moz-cite-prefix">Am 23.11.2019 um 14:51 schrieb Fam.
Fontaine via freifunk-public:<br>
</div>
<blockquote type="cite"
cite="mid:17e2f72d-698c-4b36-08fb-cd480c9dc050@gmx.de">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
Hi,<br>
<br>
beim Testen mit der neuen Freifunk Firmware (r7835+25) habe ich
ein komisches Problem von meinem PI aus.<br>
Zum Hintergrund.<br>
Bei mir gib es eine zentrale Fritz-Box für den
Internetanschluss. Über einen Switch hängen daran zwei Knoten.<br>
<a moz-do-not-send="true"
href="https://mgmt.saar.freifunk.net/hopglass/#!v:m;n:50c7bf8f95a6">ffsaar-HammelsbergVc</a>
untern Dach (r7794+21)<br>
<a moz-do-not-send="true"
href="https://mgmt.saar.freifunk.net/hopglass/#!v:m;n:18d6c7f39bfc">ffsaar-HammelsbergVa</a>
steht in der Küche (experimentel: r7835+25)<br>
Beide Knoten strahlen sowohl die Freifunk SSID aus, wie auch die
private.<br>
<br>
Beim Nachbar steht der dritte Knoten der lokalen Wolke:<br>
<a moz-do-not-send="true"
href="https://mgmt.saar.freifunk.net/hopglass/#!v:m;n:704f572e9af4">ffsaar-HammelsbergVb</a>
(r7794+21)<br>
<br>
Wenn ich jetzt mit dem Laptop in der SSID des privaten WLAN
eingelogged bin, dann komme ich per ssh nicht auf die Knoten die
bei mir stehen, wohl aber auf die beim Nachbarn.<br>
Vom Raspberry-PI aus (Model B2, hängt per Kabel am gleichen
Switch wie die Knoten) ist es das gleiche Problem.<br>
Bin ich mit dem Laptop im FF-Netz, dann komme ich problemlos
drauf, egal mit welchem Knoten ich mich verbinde.<br>
Ping geht in allen Fällen.<br>
<br>
Die IPv6 Adresse steht in der /etc/hosts, sowohl am Laptop wie
im PI<br>
root@sfpi:/home/pi# ifconfig -a<br>
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500<br>
inet 192.168.178.8 netmask 255.255.255.0 broadcast
192.168.178.255<br>
inet6 fe80::8a4e:e1b0:fb8c:f4e7 prefixlen 64 scopeid
0x20<link><br>
inet6 2003:da:72b:f200:5ca3:9be3:a0ae:ac5f prefixlen
64 scopeid 0x0<global><br>
ether b8:27:eb:9d:69:c5 txqueuelen 1000 (Ethernet)<br>
RX packets 25851014 bytes 2359445771 (2.1 GiB)<br>
RX errors 0 dropped 0 overruns 0 frame 0<br>
TX packets 9788035 bytes 6241957294 (5.8 GiB)<br>
TX errors 0 dropped 0 overruns 0 carrier 0 collisions
0<br>
root@sfpi:/home/pi# uname -a<br>
Linux sfpi 4.19.57+ #1244 Thu Jul 4 18:42:50 BST 2019 armv6l
GNU/Linux<br>
root@sfpi:/home/pi# head -1 /etc/os-release<br>
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"<br>
root@sfpi:/home/pi# cat /sys/firmware/devicetree/base/model<br>
Raspberry Pi Model B Rev 2<br>
<br>
Hat jemand eine Idee woran das liegen könnte?<br>
<br>
<table width="100%" cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<td valign="top"><br>
</td>
<td valign="top"><font color="#ff0000">ffsaar-HammelsbergVa</font><br>
</td>
<td valign="top"><font color="#ff0000">ffsaar-HammelsbergVc</font><br>
</td>
<td valign="top"><font color="#009900">ffsaar-HammelsbergVb</font><br>
</td>
</tr>
<tr>
<td valign="top">ping (PI)<br>
</td>
<td valign="top">root@sfpi:/home/pi# ping -c 3
ffsaar-HammelsbergVa<br>
PING ffsaar-HammelsbergVa(ffsaar-HammelsbergVa
(2a03:2260:3009:100:1ad6:c7ff:fef3:9bfc)) 56 data bytes<br>
64 bytes from ffsaar-HammelsbergVa
(2a03:2260:3009:100:1ad6:c7ff:fef3:9bfc): icmp_seq=1
ttl=255 time=21.0 ms<br>
64 bytes from ffsaar-HammelsbergVa
(2a03:2260:3009:100:1ad6:c7ff:fef3:9bfc): icmp_seq=2
ttl=255 time=20.4 ms<br>
64 bytes from ffsaar-HammelsbergVa
(2a03:2260:3009:100:1ad6:c7ff:fef3:9bfc): icmp_seq=3
ttl=255 time=20.5 ms<br>
<br>
--- ffsaar-HammelsbergVa ping statistics ---<br>
3 packets transmitted, 3 received, 0% packet loss, time
5ms<br>
rtt min/avg/max/mdev = 20.440/20.651/21.026/0.313 ms<br>
</td>
<td valign="top">root@sfpi:/home/pi# ping -c 3
ffsaar-HammelsbergVa<br>
PING ffsaar-HammelsbergVa(ffsaar-HammelsbergVa
(2a03:2260:3009:100:1ad6:c7ff:fef3:9bfc)) 56 data bytes<br>
64 bytes from ffsaar-HammelsbergVa
(2a03:2260:3009:100:1ad6:c7ff:fef3:9bfc): icmp_seq=1
ttl=255 time=21.0 ms<br>
64 bytes from ffsaar-HammelsbergVa
(2a03:2260:3009:100:1ad6:c7ff:fef3:9bfc): icmp_seq=2
ttl=255 time=20.4 ms<br>
64 bytes from ffsaar-HammelsbergVa
(2a03:2260:3009:100:1ad6:c7ff:fef3:9bfc): icmp_seq=3
ttl=255 time=20.5 ms<br>
<br>
--- ffsaar-HammelsbergVa ping statistics ---<br>
3 packets transmitted, 3 received, 0% packet loss, time
5ms<br>
rtt min/avg/max/mdev = 20.440/20.651/21.026/0.313 ms<br>
</td>
<td valign="top">root@sfpi:/home/pi# ping -c 3
ffsaar-HammelsbergVa<br>
PING ffsaar-HammelsbergVa(ffsaar-HammelsbergVa
(2a03:2260:3009:100:1ad6:c7ff:fef3:9bfc)) 56 data bytes<br>
64 bytes from ffsaar-HammelsbergVa
(2a03:2260:3009:100:1ad6:c7ff:fef3:9bfc): icmp_seq=1
ttl=255 time=21.0 ms<br>
64 bytes from ffsaar-HammelsbergVa
(2a03:2260:3009:100:1ad6:c7ff:fef3:9bfc): icmp_seq=2
ttl=255 time=20.4 ms<br>
64 bytes from ffsaar-HammelsbergVa
(2a03:2260:3009:100:1ad6:c7ff:fef3:9bfc): icmp_seq=3
ttl=255 time=20.5 ms<br>
<br>
--- ffsaar-HammelsbergVa ping statistics ---<br>
3 packets transmitted, 3 received, 0% packet loss, time
5ms<br>
rtt min/avg/max/mdev = 20.440/20.651/21.026/0.313 ms<br>
</td>
</tr>
<tr>
<td valign="top">ssh (pi)<br>
</td>
<td valign="top">root@sfpi:/home/pi# ssh -v -l root
ffsaar-HammelsbergVa<br>
OpenSSH_7.9p1 Raspbian-10, OpenSSL 1.1.1c 28 May 2019<br>
debug1: Reading configuration data /etc/ssh/ssh_config<br>
debug1: /etc/ssh/ssh_config line 19: Applying options
for *<br>
debug1: Connecting to ffsaar-hammelsbergva
[2a03:2260:3009:100:1ad6:c7ff:fef3:9bfc] port 22.<br>
<b>debug1: Connection established.</b><br>
debug1: identity file /root/.ssh/id_rsa type 0<br>
debug1: identity file /root/.ssh/id_rsa-cert type -1<br>
debug1: identity file /root/.ssh/id_dsa type 1<br>
debug1: identity file /root/.ssh/id_dsa-cert type -1<br>
debug1: identity file /root/.ssh/id_ecdsa type 2<br>
debug1: identity file /root/.ssh/id_ecdsa-cert type -1<br>
debug1: identity file /root/.ssh/id_ed25519 type -1<br>
debug1: identity file /root/.ssh/id_ed25519-cert type -1<br>
debug1: identity file /root/.ssh/id_xmss type -1<br>
debug1: identity file /root/.ssh/id_xmss-cert type -1<br>
debug1: Local version string SSH-2.0-OpenSSH_7.9p1
Raspbian-10<br>
debug1: Remote protocol version 2.0, remote software
version dropbear<br>
debug1: no match: dropbear<br>
debug1: Authenticating to ffsaar-hammelsbergva:22 as
'root'<br>
debug1: SSH2_MSG_KEXINIT sent<br>
debug1: SSH2_MSG_KEXINIT received<br>
debug1: kex: algorithm: <a
class="moz-txt-link-abbreviated"
href="mailto:curve25519-sha256@libssh.org"
moz-do-not-send="true">curve25519-sha256@libssh.org</a><br>
debug1: kex: host key algorithm: ssh-rsa<br>
debug1: kex: server->client cipher: aes128-ctr MAC:
hmac-sha2-256 compression: none<br>
debug1: kex: client->server cipher: aes128-ctr MAC:
hmac-sha2-256 compression: none<br>
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY<br>
<br>
-> die Antwort vom Knoten kommt irgendwie nicht
zurück, obwohl eine erste Kommunikation ja aufgebaut
wurde<br>
</td>
<td valign="top">root@sfpi:/home/pi# ssh -v -l root
ffsaar-HammelsbergVc<br>
OpenSSH_7.9p1 Raspbian-10, OpenSSL 1.1.1c 28 May 2019<br>
debug1: Reading configuration data /etc/ssh/ssh_config<br>
debug1: /etc/ssh/ssh_config line 19: Applying options
for *<br>
debug1: Connecting to ffsaar-hammelsbergvc
[2a03:2260:3009:100:52c7:bfff:fe8f:95a6] port 22.<br>
<b>debug1: Connection established.</b><br>
debug1: identity file /root/.ssh/id_rsa type 0<br>
debug1: identity file /root/.ssh/id_rsa-cert type -1<br>
debug1: identity file /root/.ssh/id_dsa type 1<br>
debug1: identity file /root/.ssh/id_dsa-cert type -1<br>
debug1: identity file /root/.ssh/id_ecdsa type 2<br>
debug1: identity file /root/.ssh/id_ecdsa-cert type -1<br>
debug1: identity file /root/.ssh/id_ed25519 type -1<br>
debug1: identity file /root/.ssh/id_ed25519-cert type -1<br>
debug1: identity file /root/.ssh/id_xmss type -1<br>
debug1: identity file /root/.ssh/id_xmss-cert type -1<br>
debug1: Local version string SSH-2.0-OpenSSH_7.9p1
Raspbian-10<br>
debug1: Remote protocol version 2.0, remote software
version dropbear<br>
debug1: no match: dropbear<br>
debug1: Authenticating to ffsaar-hammelsbergvc:22 as
'root'<br>
debug1: SSH2_MSG_KEXINIT sent<br>
debug1: SSH2_MSG_KEXINIT received<br>
debug1: kex: algorithm: <a
class="moz-txt-link-abbreviated"
href="mailto:curve25519-sha256@libssh.org"
moz-do-not-send="true">curve25519-sha256@libssh.org</a><br>
debug1: kex: host key algorithm: ssh-rsa<br>
debug1: kex: server->client cipher: aes128-ctr MAC:
hmac-sha2-256 compression: none<br>
debug1: kex: client->server cipher: aes128-ctr MAC:
hmac-sha2-256 compression: none<br>
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY<br>
<br>
-> die Antwort vom Knoten kommt irgendwie nicht
zurück, obwohl eine erste Kommunikation ja aufgebaut
wurde</td>
<td valign="top">root@sfpi:/home/pi# ssh -v -l root
ffsaar-HammelsbergVb<br>
OpenSSH_7.9p1 Raspbian-10, OpenSSL 1.1.1c 28 May 2019<br>
debug1: Reading configuration data /etc/ssh/ssh_config<br>
debug1: /etc/ssh/ssh_config line 19: Applying options
for *<br>
debug1: Connecting to ffsaar-hammelsbergvb
[2a03:2260:3009:100:724f:57ff:fe2e:9af4] port 22.<br>
<b>debug1: Connection established.</b><br>
debug1: identity file /root/.ssh/id_rsa type 0<br>
debug1: identity file /root/.ssh/id_rsa-cert type -1<br>
debug1: identity file /root/.ssh/id_dsa type 1<br>
debug1: identity file /root/.ssh/id_dsa-cert type -1<br>
debug1: identity file /root/.ssh/id_ecdsa type 2<br>
debug1: identity file /root/.ssh/id_ecdsa-cert type -1<br>
debug1: identity file /root/.ssh/id_ed25519 type -1<br>
debug1: identity file /root/.ssh/id_ed25519-cert type -1<br>
debug1: identity file /root/.ssh/id_xmss type -1<br>
debug1: identity file /root/.ssh/id_xmss-cert type -1<br>
debug1: Local version string SSH-2.0-OpenSSH_7.9p1
Raspbian-10<br>
debug1: Remote protocol version 2.0, remote software
version dropbear<br>
debug1: no match: dropbear<br>
debug1: Authenticating to ffsaar-hammelsbergvb:22 as
'root'<br>
debug1: SSH2_MSG_KEXINIT sent<br>
debug1: SSH2_MSG_KEXINIT received<br>
debug1: kex: algorithm: <a
class="moz-txt-link-abbreviated"
href="mailto:curve25519-sha256@libssh.org"
moz-do-not-send="true">curve25519-sha256@libssh.org</a><br>
debug1: kex: host key algorithm: ssh-rsa<br>
debug1: kex: server->client cipher: aes128-ctr MAC:
hmac-sha2-256 compression: none<br>
debug1: kex: client->server cipher: aes128-ctr MAC:
hmac-sha2-256 compression: none<br>
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY<br>
debug1: Server host key: ssh-rsa
SHA256:bv0ibYdyplEE6BbThAIRsLcTQDU1JuW8Ex+B1NDlwUI<br>
debug1: Host 'ffsaar-hammelsbergvb' is known and matches
the RSA host key.<br>
debug1: Found key in /root/.ssh/known_hosts:782<br>
debug1: rekey after 4294967296 blocks<br>
debug1: SSH2_MSG_NEWKEYS sent<br>
debug1: expecting SSH2_MSG_NEWKEYS<br>
debug1: SSH2_MSG_NEWKEYS received<br>
debug1: rekey after 4294967296 blocks<br>
debug1: Skipping ssh-dss key /root/.ssh/id_dsa - not in
PubkeyAcceptedKeyTypes<br>
debug1: Will attempt key: /root/.ssh/id_rsa RSA
SHA256:LYjgpsx0wpbSphCDVARMKYnsNd2530z/ky5QEhcrMP8<br>
debug1: Will attempt key: /root/.ssh/id_ecdsa ECDSA
SHA256:BuJZUjVPX0T9nUQXuedETaatOwTCVo8EFwnaYuxbVos<br>
debug1: Will attempt key: /root/.ssh/id_ed25519 <br>
debug1: Will attempt key: /root/.ssh/id_xmss <br>
debug1: SSH2_MSG_SERVICE_ACCEPT received<br>
debug1: Authentications that can continue:
publickey,password<br>
debug1: Next authentication method: publickey<br>
debug1: Offering public key: /root/.ssh/id_rsa RSA
SHA256:LYjgpsx0wpbSphCDVARMKYnsNd2530z/ky5QEhcrMP8<br>
debug1: Server accepts key: /root/.ssh/id_rsa RSA
SHA256:LYjgpsx0wpbSphCDVARMKYnsNd2530z/ky5QEhcrMP8<br>
debug1: Authentication succeeded (publickey).<br>
Authenticated to ffsaar-hammelsbergvb
([2a03:2260:3009:100:724f:57ff:fe2e:9af4]:22).<br>
debug1: channel 0: new [client-session]<br>
debug1: Entering interactive session.<br>
debug1: pledge: network<br>
debug1: Sending environment.<br>
debug1: Sending env LANG = de_DE.UTF-8<br>
<br>
<br>
BusyBox v1.28.4 () built-in shell (ash)<br>
<br>
_______ ________ __<br>
| |.-----.-----.-----.| | | |.----.| |_<br>
| - || _ | -__| || | | || _|| _|<br>
|_______|| __|_____|__|__||________||__| |____|<br>
|__| W I R E L E S S F R E E D O M<br>
-----------------------------------------------------<br>
OpenWrt 18.06-SNAPSHOT, r7794+21-fc1dae5be7<br>
-----------------------------------------------------<br>
root@ffsaar-HammelsbergVb:~# <br>
</td>
</tr>
<tr>
<td valign="top">Kommentar<br>
</td>
<td valign="top">beim ssh via Laptop sieht das genauso
aus, wenn ich im privaten WLAN bin, unabhängig davon ob
es das WLAN des einen oder anderen Knoten ist (glaubte
an Routing-Probleme zurück zu sich selbst). Auch wenn
ich sicher an der Fritz-Box verbunden bin habe ich das
Problem, deshalb glaube ich nicht mehr an die Routing
Theorie. <br>
</td>
<td valign="top">Mit der neuen Firmware kann es auch
nichts zu tun haben, denn es tritt ja auch beim Knoten
mit der alten Firmware auf. Es ist mir halt erst jetzt
so deutlich aufgefallen als ich genauer getestet habe.<br>
</td>
<td valign="top"><br>
</td>
</tr>
</tbody>
</table>
<br>
bin für jede Rückmeldung dankbar!<br>
<br>
Grüße<br>
Sebastian Fontaine<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
</blockquote>
</body>
</html>