DHCP in Leichlingen (und wahrscheinlich auch Burscheid) ist tot - 2nd try

PetaByteBoy · 8. März 2015 um 17:38

mit 2 gerade neu geflashten Routern an 2 verschiedenen Internetanschlüssen getestet - DHCP mit Leichlingen ist defenitiv überall tot
Nach weiterem Testing: Es ist nur DHCP, als gateway funktioniert alles. Das heißt wenn man einem PC ne feste Adresse im richtigen Bereich gibt, kann man raustelefonieren…
Als gateway habe ich sowohl 10.156.0.240 als auch 10.156.0.241 getestet.
Ich habe den Router bereits mehrmals neu gestartet und bis zu 15 min gewartet.
Würden euch irgendwelche logs weiterhelfen? Wie bekomme ich die vom Router?
Inzwischen steht wahrscheinlich „Leichlingen-Rathaus“ auch wirklich im Rathaus uns strahlt schlechten Ruf aus…

@DSchmidtberg und @phip lesen die PN nicht, also hier auch nochmal: Hat jemand ne Email-Adresse von @phip?

stefan · 8. März 2015 um 18:47

Selbes Problem in Troisdorf. DHCP funktioniert zwar, aber auf Anfragen kommt keine Antwort. Ich finde das für Domänen Admins nicht angebracht - freiwillig hin oder her!

Wir warten seit Wochen auf eine Antwort zu unserem IPv6 Problem!

PetaByteBoy · 8. März 2015 um 18:54

ich war ja am Freitag auch in Wuppertal und dann hieß es das wär gefixed ist es aber nicht

Freifunker · 8. März 2015 um 19:02

Ehm, das ist immer noch Freifunk und kein Internet Service Provider mit Hotline. Best Effort und so maximal. Und auch die Admins haben noch ein Leben neben dem „Hobby“ Freifunk.

stefan · 8. März 2015 um 19:06

Ich erwarte keine Lösung in 2h. Aber ne Antwort in 2 Wochen wäre schön angebracht. Und wenn sie nur lautet „Sorry keine Zeit“

PetaByteBoy · 8. März 2015 um 19:06

@Freifunker das ist uns schon klar nur wir tun ja auch etwas für FF und als ich hier den Typen von der Wirtschaftsförderung sitzen hatte und auf einmal lief FF nicht das war schon beschissen

Freifunker · 8. März 2015 um 19:10

Das hatte ich selber auch schon. Will man Freifunk vorführen und dann geht es nicht. Und ich bin selber Admin in unserer Community, aber unser Schweden VPN Tunnel Provider hatte just in dem Moment Probleme, so das ich auch nix machen konnte. Tja, Standort verbrannt, aber was solls. Shit happens.

PetaByteBoy · 8. März 2015 um 19:14

Mein Problem fängt jedenfalls da an, wo ich den Admin nicht mehr erreichen kann und halt nix tun kann. Der Standort ist übrigens noch lange nicht verbrannt nur wenn das so weiter geht dann wird es natürlich nichts…
Eben wie @stefan sagte ein einfaches „keine Zeit“ würde mir reichen…

Gleichzeitig kann ich es verstehen, dass @phip nicht die Zeit hat hier im Forum alles zu lesen. Vieles hier ist ja ziemlich unrelevant, aber wenn es dann mal drum geht ist er halt auch nicht erreichbar (nur Freitags in Wuppertal)

PetaByteBoy · 8. März 2015 um 19:18

Jedenfall nach noch einem Tag Testen hab ich doppelt und dreifach festgestellt, dass es an der FW liegen muss.

benutzen andere Communities wenn ich das richtig verstanden hab die gleichen Server (Burscheid, Bergisch Gladbach) und bei denen scheint es zu funktionieren (@Pinky?).
habe ich auf meinem Offloader eine IP bekommen

steneu · 8. März 2015 um 19:52

Was meinst du damit? Dass es jetzt wieder funktioniert?

steneu · 8. März 2015 um 20:11

Über die Konsole. Wie du da hin kommst steht z. B. hier: Konsole – wiki.freifunk.net

Dort dann logread eingeben

PetaByteBoy · 9. März 2015 um 06:51

Nein, es ist wirklich komisch… Offensichtlich werden DHCP broadcasts vom Router nicht an die Clients weitergeleitet. Die Nodes und Offloader bekommen ne IP.

PetaByteBoy · 9. März 2015 um 15:47

Hier ein Log:

Mon Feb  9 20:19:19 2015 daemon.notice netifd: Interface 'mesh_vpn' is enabled
Mon Feb  9 20:19:19 2015 daemon.notice netifd: Network device 'lo' link is up
Mon Feb  9 20:19:19 2015 daemon.notice netifd: Interface 'loopback' has link connectivity 
Mon Feb  9 20:19:19 2015 daemon.notice netifd: Network device 'mesh-vpn' link is up
Mon Feb  9 20:19:19 2015 daemon.notice netifd: Interface 'mesh_vpn' has link connectivity 
Mon Feb  9 20:19:19 2015 daemon.notice netifd: Interface 'mesh_vpn' is setting up now
Mon Feb  9 20:19:19 2015 kern.info kernel: [   23.750000] eth0: link up (1000Mbps/Full duplex)
Mon Feb  9 20:19:19 2015 daemon.notice netifd: Network device 'eth0' link is up
Mon Feb  9 20:19:19 2015 daemon.notice netifd: VLAN 'eth0.1' link is up
Mon Feb  9 20:19:19 2015 daemon.notice netifd: VLAN 'eth0.2' link is up
Mon Feb  9 20:19:19 2015 kern.info kernel: [   23.830000] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Mon Feb  9 20:19:19 2015 kern.info kernel: [   23.830000] br-client: port 1(eth0.1) entered forwarding state
Mon Feb  9 20:19:19 2015 kern.info kernel: [   23.840000] br-client: port 1(eth0.1) entered forwarding state
Mon Feb  9 20:19:19 2015 kern.info kernel: [   23.850000] IPv6: ADDRCONF(NETDEV_CHANGE): eth0.1: link becomes ready
Mon Feb  9 20:19:19 2015 kern.info kernel: [   23.850000] br-wan: port 1(eth0.2) entered forwarding state
Mon Feb  9 20:19:19 2015 kern.info kernel: [   23.860000] br-wan: port 1(eth0.2) entered forwarding state
Mon Feb  9 20:19:19 2015 kern.info kernel: [   23.860000] IPv6: ADDRCONF(NETDEV_CHANGE): eth0.2: link becomes ready
Mon Feb  9 20:19:19 2015 kern.info kernel: [   23.970000] IPv6: ADDRCONF(NETDEV_CHANGE): br-wan: link becomes ready
Mon Feb  9 20:19:19 2015 kern.info kernel: [   23.970000] IPv6: ADDRCONF(NETDEV_CHANGE): br-client: link becomes ready
Mon Feb  9 20:19:19 2015 kern.info kernel: [   24.010000] IPv6: ADDRCONF(NETDEV_CHANGE): local-node: link becomes ready
Mon Feb  9 20:19:19 2015 daemon.notice netifd: Bridge 'br-wan' link is up
Mon Feb  9 20:19:19 2015 daemon.notice netifd: Interface 'wan6' has link connectivity 
Mon Feb  9 20:19:19 2015 daemon.notice netifd: Interface 'wan6' is setting up now
Mon Feb  9 20:19:19 2015 daemon.notice netifd: Interface 'wan' has link connectivity 
Mon Feb  9 20:19:19 2015 daemon.notice netifd: Interface 'wan' is setting up now
Mon Feb  9 20:19:19 2015 daemon.notice netifd: Interface 'mesh_wan' has link connectivity 
Mon Feb  9 20:19:19 2015 daemon.notice netifd: Bridge 'br-client' link is up
Mon Feb  9 20:19:19 2015 daemon.notice netifd: Interface 'client' has link connectivity 
Mon Feb  9 20:19:19 2015 daemon.notice netifd: Interface 'client' is setting up now
Mon Feb  9 20:19:19 2015 daemon.notice netifd: MAC VLAN 'local-node' link is up
Mon Feb  9 20:19:19 2015 daemon.notice netifd: Interface 'local_node' has link connectivity 
Mon Feb  9 20:19:20 2015 kern.info kernel: [   24.340000] batman_adv: bat0: Adding interface: mesh-vpn
Mon Feb  9 20:19:20 2015 kern.info kernel: [   24.340000] batman_adv: bat0: The MTU of interface mesh-vpn is too small (1426) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem.
Mon Feb  9 20:19:20 2015 kern.info kernel: [   24.370000] batman_adv: bat0: Interface activated: mesh-vpn
Mon Feb  9 20:19:20 2015 daemon.notice netifd: Interface 'bat0' is enabled
Mon Feb  9 20:19:20 2015 kern.info kernel: [   24.400000] 8021q: adding VLAN 0 to HW filter on device bat0
Mon Feb  9 20:19:20 2015 kern.info kernel: [   24.400000] device bat0 entered promiscuous mode
Mon Feb  9 20:19:20 2015 kern.info kernel: [   24.410000] br-client: port 2(bat0) entered forwarding state
Mon Feb  9 20:19:20 2015 kern.info kernel: [   24.410000] br-client: port 2(bat0) entered forwarding state
Mon Feb  9 20:19:20 2015 daemon.notice netifd: Network device 'bat0' link is up
Mon Feb  9 20:19:20 2015 daemon.notice netifd: Interface 'bat0' has link connectivity 
Mon Feb  9 20:19:20 2015 daemon.notice netifd: Interface 'bat0' is setting up now
Mon Feb  9 20:19:20 2015 daemon.notice netifd: Interface 'bat0' is now up
Mon Feb  9 20:19:20 2015 daemon.notice netifd: Interface 'mesh_vpn' is now up
Mon Feb  9 20:19:21 2015 daemon.notice netifd: wan (1355): udhcpc (v1.22.1) started
Mon Feb  9 20:19:21 2015 user.emerg syslog: /etc/rc.d/S99alfred: starting alfred
Mon Feb  9 20:19:21 2015 user.emerg syslog: /etc/rc.d/S99alfred: starting batadv-vis
Mon Feb  9 20:19:21 2015 user.emerg syslog: - init complete -
Mon Feb  9 20:19:21 2015 kern.info kernel: [   25.840000] br-client: port 1(eth0.1) entered forwarding state
Mon Feb  9 20:19:21 2015 kern.info kernel: [   25.860000] br-wan: port 1(eth0.2) entered forwarding state
Mon Feb  9 20:19:21 2015 kern.info kernel: [   25.940000] cfg80211: Calling CRDA for country: DE
Mon Feb  9 20:19:21 2015 daemon.notice netifd: wan (1355): Sending discover...
Mon Feb  9 20:19:21 2015 daemon.notice netifd: wan (1355): Performing a DHCP renew
Mon Feb  9 20:19:21 2015 daemon.notice netifd: wan (1355): Sending discover...
Mon Feb  9 20:19:21 2015 daemon.notice netifd: wan (1355): Sending select for 192.168.2.19...
Mon Feb  9 20:19:21 2015 daemon.notice netifd: wan (1355): Lease of 192.168.2.19 obtained, lease time 268435455
Mon Feb  9 20:19:21 2015 kern.info kernel: [   26.000000] cfg80211: Regulatory domain changed to country: DE
Mon Feb  9 20:19:21 2015 kern.info kernel: [   26.000000] cfg80211:  DFS Master region: ETSI
Mon Feb  9 20:19:21 2015 kern.info kernel: [   26.010000] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
Mon Feb  9 20:19:21 2015 kern.info kernel: [   26.020000] cfg80211:   (2400000 KHz - 2483000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
Mon Feb  9 20:19:21 2015 kern.info kernel: [   26.020000] cfg80211:   (5150000 KHz - 5250000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
Mon Feb  9 20:19:21 2015 kern.info kernel: [   26.030000] cfg80211:   (5250000 KHz - 5350000 KHz @ 80000 KHz), (N/A, 2000 mBm), (0 s)
Mon Feb  9 20:19:21 2015 kern.info kernel: [   26.040000] cfg80211:   (5470000 KHz - 5725000 KHz @ 80000 KHz), (N/A, 2700 mBm), (0 s)
Mon Feb  9 20:19:21 2015 kern.info kernel: [   26.050000] cfg80211:   (57240000 KHz - 65880000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A)
Mon Feb  9 20:19:22 2015 kern.info kernel: [   26.410000] br-client: port 2(bat0) entered forwarding state
Mon Feb  9 20:19:22 2015 daemon.notice netifd: Interface 'wan' is now up
Mon Feb  9 20:19:22 2015 user.notice firewall: Reloading firewall due to ifup of local_node (local-node)
Mon Feb  9 20:19:22 2015 kern.info kernel: [   27.140000] batman_adv: bat0: Changing gw mode from: off to: client
Mon Feb  9 20:19:22 2015 kern.info kernel: [   27.190000] batman_adv: bat0: multicast_mode: Changing from: enabled to: disabled
Mon Feb  9 20:19:22 2015 kern.info kernel: [   27.190000] batman_adv: bat0: orig_interval: Changing from: 1000 to: 5000
Mon Feb  9 20:19:23 2015 kern.info kernel: [   27.490000] IPv6: ADDRCONF(NETDEV_UP): client1: link is not ready
Mon Feb  9 20:19:23 2015 kern.info kernel: [   27.530000] device client1 entered promiscuous mode
Mon Feb  9 20:19:23 2015 kern.info kernel: [   27.530000] br-client: port 3(client1) entered forwarding state
Mon Feb  9 20:19:23 2015 kern.info kernel: [   27.540000] br-client: port 3(client1) entered forwarding state
Mon Feb  9 20:19:23 2015 kern.info kernel: [   27.700000] br-client: port 3(client1) entered disabled state
Mon Feb  9 20:19:23 2015 kern.info kernel: [   27.770000] IPv6: ADDRCONF(NETDEV_UP): client0: link is not ready
Mon Feb  9 20:19:23 2015 kern.info kernel: [   27.780000] device client0 entered promiscuous mode
Mon Feb  9 20:19:23 2015 kern.info kernel: [   27.780000] br-client: port 4(client0) entered forwarding state
Mon Feb  9 20:19:23 2015 kern.info kernel: [   27.790000] br-client: port 4(client0) entered forwarding state
Mon Feb  9 20:19:23 2015 kern.info kernel: [   27.800000] device client1 left promiscuous mode
Mon Feb  9 20:19:23 2015 kern.info kernel: [   27.810000] br-client: port 3(client1) entered disabled state
Mon Feb  9 20:19:23 2015 daemon.notice netifd: radio1 (1252): Configuration file: /var/run/hostapd-phy1.conf
Mon Feb  9 20:19:23 2015 daemon.notice netifd: radio1 (1252): client1: interface state UNINITIALIZED->COUNTRY_UPDATE
Mon Feb  9 20:19:23 2015 daemon.notice netifd: radio1 (1252): client1: interface state COUNTRY_UPDATE->HT_SCAN
Mon Feb  9 20:19:23 2015 daemon.notice netifd: radio1 (1252): client1: interface state HT_SCAN->DFS
Mon Feb  9 20:19:23 2015 daemon.notice netifd: radio1 (1252): client1: DFS-CAC-START freq=5260 chan=52 sec_chan=1, width=0, seg0=0, seg1=0, cac_time=60s
Mon Feb  9 20:19:23 2015 daemon.notice netifd: radio1 (1252): DFS start_dfs_cac() failed, -1
Mon Feb  9 20:19:23 2015 daemon.notice netifd: radio1 (1252): Interface initialization failed
Mon Feb  9 20:19:23 2015 daemon.notice netifd: radio1 (1252): client1: interface state DFS->DISABLED
Mon Feb  9 20:19:23 2015 daemon.notice netifd: radio1 (1252): client1: AP-DISABLED 
Mon Feb  9 20:19:23 2015 daemon.notice netifd: radio1 (1252): hostapd_free_hapd_data: Interface client1 wasn't started
Mon Feb  9 20:19:23 2015 daemon.notice netifd: radio1 (1252): ELOOP: remaining socket: sock=18 eloop_data=0x85cc10 user_data=(nil) handler=0x413791
Mon Feb  9 20:19:23 2015 daemon.notice netifd: radio1 (1252): cat: can't open '/var/run/wifi-phy1.pid': No such file or directory
Mon Feb  9 20:19:23 2015 daemon.notice netifd: radio1 (1252): Command failed: Invalid argument
Mon Feb  9 20:19:23 2015 kern.info kernel: [   28.110000] IPv6: ADDRCONF(NETDEV_UP): client1: link is not ready
Mon Feb  9 20:19:24 2015 kern.info kernel: [   28.290000] IPv6: ADDRCONF(NETDEV_UP): mesh1: link is not ready
Mon Feb  9 20:19:24 2015 daemon.notice netifd: radio1 (1252): command failed: Invalid argument (-22)
Mon Feb  9 20:19:24 2015 daemon.notice netifd: Interface 'mesh_radio1' is enabled
Mon Feb  9 20:19:24 2015 daemon.notice netifd: Interface 'client' is now up
Mon Feb  9 20:19:24 2015 kern.info kernel: [   28.700000] br-client: port 4(client0) entered disabled state
Mon Feb  9 20:19:24 2015 kern.info kernel: [   28.720000] br-client: port 4(client0) entered forwarding state
Mon Feb  9 20:19:24 2015 kern.info kernel: [   28.730000] br-client: port 4(client0) entered forwarding state
Mon Feb  9 20:19:24 2015 kern.info kernel: [   28.730000] IPv6: ADDRCONF(NETDEV_CHANGE): client0: link becomes ready
Mon Feb  9 20:19:25 2015 kern.info kernel: [   29.210000] IPv6: ADDRCONF(NETDEV_UP): mesh0: link is not ready
Mon Feb  9 20:19:25 2015 kern.info kernel: [   29.230000] mesh0: Created IBSS using preconfigured BSSID 02:ca:ff:ee:51:42
Mon Feb  9 20:19:25 2015 kern.info kernel: [   29.240000] mesh0: Creating new IBSS network, BSSID 02:ca:ff:ee:51:42
Mon Feb  9 20:19:25 2015 kern.info kernel: [   29.330000] IPv6: ADDRCONF(NETDEV_CHANGE): mesh0: link becomes ready
Mon Feb  9 20:19:25 2015 daemon.notice netifd: Network device 'client0' link is up
Mon Feb  9 20:19:25 2015 daemon.notice netifd: Network device 'mesh0' link is up
Mon Feb  9 20:19:25 2015 daemon.notice netifd: Interface 'mesh_radio0' is enabled
Mon Feb  9 20:19:25 2015 daemon.notice netifd: Interface 'mesh_radio0' has link connectivity 
Mon Feb  9 20:19:25 2015 daemon.notice netifd: Interface 'mesh_radio0' is setting up now
Mon Feb  9 20:19:25 2015 kern.info kernel: [   29.490000] batman_adv: bat0: Adding interface: mesh0
Mon Feb  9 20:19:25 2015 kern.info kernel: [   29.500000] batman_adv: bat0: Interface activated: mesh0
Mon Feb  9 20:19:25 2015 daemon.notice netifd: Interface 'mesh_radio0' is now up
Mon Feb  9 20:19:25 2015 daemon.info dnsmasq[1722]: started, version 2.71 cachesize 150
Mon Feb  9 20:19:25 2015 daemon.info dnsmasq[1722]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC
Mon Feb  9 20:19:25 2015 daemon.info dnsmasq[1722]: using local addresses only for domain lan
Mon Feb  9 20:19:25 2015 daemon.warn dnsmasq[1722]: no servers found in /tmp/resolv.conf.auto, will retry
Mon Feb  9 20:19:25 2015 daemon.info dnsmasq[1722]: read /etc/hosts - 1 addresses
Mon Feb  9 20:19:26 2015 kern.info kernel: [   30.730000] br-client: port 4(client0) entered forwarding state
Mon Feb  9 20:19:27 2015 user.notice firewall: Reloading firewall due to ifup of wan (br-wan)
Mon Feb  9 20:19:28 2015 daemon.info dnsmasq[1095]: reading /var/gluon/wan-dnsmasq/resolv.conf
Mon Feb  9 20:19:28 2015 daemon.info dnsmasq[1095]: using nameserver 192.168.2.1#53
Mon Feb  9 20:19:29 2015 user.notice firewall: Reloading firewall due to ifup of client (br-client)
Mon Feb  9 20:19:39 2015 daemon.info fastd[1169]: resolving host `wupper1.gl.ffwtal.net' for peer <mesh_vpn_backbone_peer_wupper1>...
Mon Feb  9 20:19:39 2015 daemon.info fastd[1169]: resolved host `wupper1.gl.ffwtal.net' successfully
Mon Feb  9 20:19:40 2015 daemon.info fastd[1169]: resolving host `wupper7.gl.ffwtal.net' for peer <mesh_vpn_backbone_peer_wupper7>...
Mon Feb  9 20:19:40 2015 daemon.info fastd[1169]: resolved host `wupper7.gl.ffwtal.net' successfully
Mon Feb  9 20:19:40 2015 daemon.info fastd[1169]: resolving host `wupper0.gl.ffwtal.net' for peer <mesh_vpn_backbone_peer_wupper0>...
Mon Feb  9 20:19:40 2015 daemon.info fastd[1169]: resolved host `wupper0.gl.ffwtal.net' successfully
Mon Feb  9 20:19:41 2015 daemon.info fastd[1169]: resolving host `wupper8.gl.ffwtal.net' for peer <mesh_vpn_backbone_peer_wupper8>...
Mon Feb  9 20:19:42 2015 daemon.info fastd[1169]: resolving host `wupper8.gl.ffwtal.net' failed: Name or service not known
Mon Feb  9 20:19:42 2015 daemon.info fastd[1169]: resolving host `wupper9.gl.ffwtal.net' for peer <mesh_vpn_backbone_peer_wupper9>...
Mon Feb  9 20:19:42 2015 daemon.info fastd[1169]: resolving host `wupper9.gl.ffwtal.net' failed: Name or service not known
Mon Feb  9 20:19:59 2015 daemon.info fastd[1169]: sending handshake to <mesh_vpn_backbone_peer_wupper7>[37.120.168.152:42799]...
Mon Feb  9 20:19:59 2015 daemon.info fastd[1169]: resolving host `wupper7.gl.ffwtal.net' for peer <mesh_vpn_backbone_peer_wupper7>...
Mon Feb  9 20:19:59 2015 daemon.info fastd[1169]: resolved host `wupper7.gl.ffwtal.net' successfully
Mon Feb  9 20:19:59 2015 daemon.info fastd[1169]: resolving host `wupper8.gl.ffwtal.net' for peer <mesh_vpn_backbone_peer_wupper8>...
Mon Feb  9 20:19:59 2015 daemon.info fastd[1169]: resolving host `wupper8.gl.ffwtal.net' failed: Name or service not known
Mon Feb  9 20:20:00 2015 daemon.info fastd[1169]: sending handshake to <mesh_vpn_backbone_peer_wupper0>[37.252.124.141:42799]...
Mon Feb  9 20:20:00 2015 daemon.info fastd[1169]: resolving host `wupper0.gl.ffwtal.net' for peer <mesh_vpn_backbone_peer_wupper0>...
Mon Feb  9 20:20:00 2015 daemon.info fastd[1169]: resolved host `wupper0.gl.ffwtal.net' successfully
Mon Feb  9 20:20:00 2015 daemon.info fastd[1169]: received handshake response from <mesh_vpn_backbone_peer_wupper0>[37.252.124.141:42799] using fastd v16
Mon Feb  9 20:20:00 2015 daemon.info fastd[1169]: 37.252.124.141:42799 authorized as <mesh_vpn_backbone_peer_wupper0>
Mon Feb  9 20:20:00 2015 daemon.notice fastd[1169]: connection with <mesh_vpn_backbone_peer_wupper0> established.
Mon Feb  9 20:20:00 2015 daemon.info fastd[1169]: new session with <mesh_vpn_backbone_peer_wupper0> established using method `salsa2012+umac'.
Mon Feb  9 20:20:01 2015 daemon.info fastd[1169]: resolving host `wupper9.gl.ffwtal.net' for peer <mesh_vpn_backbone_peer_wupper9>...
Mon Feb  9 20:20:01 2015 daemon.info fastd[1169]: resolving host `wupper9.gl.ffwtal.net' failed: Name or service not known
Mon Feb  9 20:20:01 2015 daemon.info fastd[1169]: sending handshake to <mesh_vpn_backbone_peer_wupper1>[84.22.100.2:42799]...
Mon Feb  9 20:20:01 2015 daemon.info fastd[1169]: resolving host `wupper1.gl.ffwtal.net' for peer <mesh_vpn_backbone_peer_wupper1>...
Mon Feb  9 20:20:01 2015 daemon.info fastd[1169]: resolved host `wupper1.gl.ffwtal.net' successfully
Mon Feb  9 20:20:01 2015 daemon.info fastd[1169]: received handshake response from <mesh_vpn_backbone_peer_wupper1>[84.22.100.2:42799] using fastd v16
Mon Feb  9 20:20:02 2015 daemon.info fastd[1169]: 84.22.100.2:42799 authorized as <mesh_vpn_backbone_peer_wupper1>
Mon Feb  9 20:20:02 2015 daemon.notice fastd[1169]: connection with <mesh_vpn_backbone_peer_wupper1> established.
Mon Feb  9 20:20:02 2015 daemon.info fastd[1169]: new session with <mesh_vpn_backbone_peer_wupper1> established using method `salsa2012+umac'.
Mon Feb  9 20:20:35 2015 authpriv.info dropbear[2095]: Child connection from fe80::be5f:f4ff:fe8b:7740%br-wan:54325
Mon Feb  9 20:20:42 2015 authpriv.notice dropbear[2095]: Password auth succeeded for 'root' from fe80::be5f:f4ff:fe8b:7740%br-wan:54325
Mon Feb  9 20:21:04 2015 daemon.info hostapd: client0: STA 0c:1d:af:c4:8c:88 IEEE 802.11: authenticated
Mon Feb  9 20:21:04 2015 daemon.info hostapd: client0: STA 0c:1d:af:c4:8c:88 IEEE 802.11: associated (aid 1)
Mon Feb  9 20:21:34 2015 daemon.info hostapd: client0: STA 0c:1d:af:c4:8c:88 IEEE 802.11: disassociated
Mon Feb  9 20:21:35 2015 daemon.info hostapd: client0: STA 0c:1d:af:c4:8c:88 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mon Feb  9 20:21:37 2015 daemon.info hostapd: client0: STA 0c:1d:af:c4:8c:88 IEEE 802.11: authenticated
Mon Feb  9 20:21:37 2015 daemon.info hostapd: client0: STA 0c:1d:af:c4:8c:88 IEEE 802.11: associated (aid 1)
Mon Feb  9 20:22:07 2015 daemon.info hostapd: client0: STA 0c:1d:af:c4:8c:88 IEEE 802.11: disassociated
Mon Feb  9 20:22:08 2015 daemon.info hostapd: client0: STA 0c:1d:af:c4:8c:88 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mon Feb  9 20:22:10 2015 daemon.info hostapd: client0: STA 0c:1d:af:c4:8c:88 IEEE 802.11: authenticated
Mon Feb  9 20:22:10 2015 daemon.info hostapd: client0: STA 0c:1d:af:c4:8c:88 IEEE 802.11: associated (aid 1)
Mon Feb  9 20:22:41 2015 daemon.info hostapd: client0: STA 0c:1d:af:c4:8c:88 IEEE 802.11: disassociated
Mon Feb  9 20:22:42 2015 daemon.info hostapd: client0: STA 0c:1d:af:c4:8c:88 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mon Feb  9 20:22:43 2015 daemon.info hostapd: client0: STA 0c:1d:af:c4:8c:88 IEEE 802.11: authenticated
Mon Feb  9 20:22:43 2015 daemon.info hostapd: client0: STA 0c:1d:af:c4:8c:88 IEEE 802.11: associated (aid 1)

Wenn irgendwelche weiteren Infos weiterhelfen könnten einfach bescheid sagen…

Pinky · 9. März 2015 um 16:12

ob mein Problem mit den zwei Routern damit zusammenhängt, kann ich noch nicht sagen. Kann heute auch nichts machen.

Aber eine Idee zum Test: setz doch mal eine Router mit der Wuppertaler Firmware auf und schau, ob es damit klappt. Wenn ja, dann haben wir das Problem zumindest so weit eingegrenzt, dass wir wissen, es ist nur GL-wupper betreffend.

PetaByteBoy · 9. März 2015 um 16:15

Danke für die Idee, wird gemacht

Ergebnis: Mit Wuppertaler FW funzt alles

Ich kompiliere jetzt gerade mal selber mit Leichlinger site und probier das aus

Ergebnis: Selbstkompilat funzt auch nicht

PetaByteBoy · 9. März 2015 um 20:22

Also das Problem tritt auf allen jetzt neu angeschlossenen Routern mit Kennzeichen [GL] in der Domäne Wupper. @Pinky ich habe auch die Burscheider FW auf 2 verschiedenen Routern getestet und auch dort funktionierte nichts. Wuppertal ging aber.

Pinky · 11. März 2015 um 03:47

also, hab gerade was rumgetestet und mein Verdacht hat sich bestätigt:

Wir haben in Bensberg ja Mocca dranbekommen, der zuerst Burscheid installiert hatte, weil es da für Berg Gladbach noch nichts gab. Das war so um den 1.3. rum

Seit genau der Zeit versuche ich, meine 3 neuen Nodes anzuschliessen, erfolglos, obwohl bei mir lokal getestet.
Einfach kein DHCP, hatte ISP im Verdacht.

Ausserdem erfolgte zu dem selben Zeitpunk eine Änderung der Karten.Links bei freifunk-rheinland.de, wo nun bei „wupper“ nicht mehr alles von Wupper, sondern nur noch Wuppertal angezeigt wird.

Jetzt hab ich mir einen der nicht funktionierenden Router geschnappt und nach sysupgrade-Firmware geschaut und dabei gesehen, dass Phip per 8.3. Firmware für Bergisch Gladbach -GL in der Liste hat, das war neu für mich.

Die hab ich nun genommen und auf dem Router installiert, auch kein DHCP.

Jetzt teste ich Wuppertal

da geht auch nichts. Verblüffung.

d.h. die bestehenden Nodes mit Uplinks klappen und auch alle Nodes, die da dranhängen oder neu drangehängt werden, aber kein neuer Node mit neuem Uplink.

und jetzt komm ich mit 192.168.1.1 nicht mehr in meinen Testrouter.
Also Ende von Tests erst mal

Pinky · 11. März 2015 um 04:51

so, nach 20.000 Versuchen bin ich wieder in der Router-Config und nun hab ich - um die Tests komplett zu machen - mal Troisdorf aufgespielt, und siehe da, [TRO]test-burscheid / c4:6e:1f:d1:c7:58 klappt einwandfrei mit DHCP und Internet.

Mir scheint, Phip hat da wohl nicht nur einen schwachen Moment gehabt, sondern ist wohl ernsthaft ausser Gefecht. Aber das ist eigentlich um so mehr ein Grund, dass jemand aus Wuppertal mal eine Kurznachricht sendet.

Im Moment scheint es als wären wir alle erst mal total blockiert. Denn umschalten auf Troisdorf ist wohl keine Lösung. Obwohl das theoretisch ginge, weil das sich ja nicht mit Troidsorf meldet, sondern nur „Freifunk“ anzeigt.

Sollten wir mit den Troisdorfern mal diskutieren, als Notlösung für alle Fälle.

Edit
hab mal an Stefan eine PM gerschickt

Edit 2
hatte für die Tests mal den alten Burscheider Uplink-router abgeschaltet. Nun, nachdem ich ihn weder an habe, erscheinen die alten Burscheider zwar wieder im Graphen, aber ich bekomme mit keinem Client eine IP / DHCP. Also Internetverbindung nun auch für die alten Nodes gekappt.

Edit 3
hab gerade von Stefan das OK bekommen und alles auf „Freifunk“ ohne Ortsangabe (Troisdorfer Firmware) geändert. Klappt. Also nun ist die relevante Karte nur noch http://map.wupper.freifunk-rheinland.net/geomap.html

CHRlS · 11. März 2015 um 08:36

Aber was genau ist denn da in Wupper los? Wo stecken den Dustin und Philipp?

steneu · 11. März 2015 um 08:58

Könnte das vielleicht an der fastd freichaltung liegen? Eigentlich sollten in der Domäne Wupper alle fastd Schlüssel angenommen werden. Aber vielleicht ist diese Einstellung auf wupper0 und wupper1 für euch jetzt irgendwie abhanden gekommen.

@Pinky: Gehen alte Router ab dem Zeitpunkt nicht mehr, wenn du beim Flashen den Harken bei „Einstellungen erhalten“ raus machst bzw. mit sysupgrade -n flashst?