<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>