<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    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">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">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">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>
  </body>
</html>