[Freifunk-Bonn] Config-Mode nach Update (war: Re: gluon 2017.1.3 für kbu - WAS: Remote-Code-Execution in dnsmasq)

Fr Okt 6 01:08:54 CEST 2017

Nabend Ede,

Hmmm... der scheint nach einem update per ssh wie hier beschrieben
https://kbu.freifunk.net/wiki/index.php?title=Pimp_my_Node#Sysupgrade_unter_beibehaltung_der_Einstellungen
in den config-mode zu booten statt in den normalen Betriebs-Modus...

Gut, das ich das erstmal auf einem probierte habe, auf den ich nicht nur
ssh-Zugriff habe sondern ein LAN-Kabel anstecken konnte. Einmal
192.168.1.1 luci aufrufen, speichern und er läuft wieder :)

Den Node-Namen musste ich erneut angeben, das ssh-pw habe ich zur
sicherheit auch nochmal neu gesetzt in luci.

Kann man irgendwas dagegen tun, dass er erstmal im Config-Mode bootet?

Ich hatte jetzt nur die 5 Zeilen wie im Wiki beschrieben von der Config
behalten (/etc/dropbear/* und gluon-node-info und system aus
/etc/config). Kann man da zb noch irgendeine weitere Zeile behalten,
damit er beim ersten booten nach dem upgrade nicht in den Config-Mode
bootet?

Am 06.10.2017 um 00:03 schrieb edgar.soldin at web.de:
> On 10/5/2017 23:51, Guido Pannenbecker wrote:
>> Moin Ede
>>
>> Lede-bassiert? Das heißt, auch die ganze hardware, die lede kann aber
>> wrt nicht funktioniert jetzt auch? :-) Das würde neu-anschaffungen
>> deutlich vereinfachen! :)
> 
> wahrscheinlich schon, hängt davon ab worauf neoraider das release jeweils basiert
>  
>> ich habe viele wr841 (v9, v10, v11), ein paar wr1043 v4, einen wdr3600
>> v1 und einen cpe210 v1.0. 
> 
> hab ich alle mitgebaut,
> 
>> Alles Hood Köln. 
> 
> für deine meine hood köln
> 
>> Für die allermeisten habe ich
>> ein Passwort um sie remote upzudaten. Der wdr3600 und cpe210 machen
>> "mesh on WAN". Mindestens den cpe müsste man also mit "keep settings"
>> flashen weil der sonst seine connection verliert... ausgerechnet der ist
>> natürlich auch auf nem dach verbaut wo es schwer ist ran zu kommen.
>> vielleicht lassen wir den erstmal aussen vor ;)
> 
> ja vorsicht ist angebracht. es gibt nen extra hinweis
>   http://gluon.readthedocs.io/en/v2017.1.x/releases/v2017.1.html
> das x86 versionen ihre konfiguration unter umständen verlieren können. aber klar generell würd ich mit so eperimentellem kram kein dachgepäck aktualisieren, ausser Du hast Leiter, Zeit und Montagematerial zur Hand.
> 
> 
>> ansonsten kann ich gerne die neue fw testen! Auch selber kompilieren
>> kann ich testen!
> 
> tob Dich aus ;)
>   http://jamoke.net/kbu/gluon-2017.1.3.beta/koeln/
> 
> ..ede
> 
>>
>>
>> Am 05.10.2017 um 20:58 schrieb edgar.soldin at web.de:
>>> hello peoples, we are here,
>>> in the one hand nen micro, in the other hand nen neuet gluon 2017.1.3 ..
>>>
>>> hände hoch wer interesse am aktuellen LEDE basierten gluon hat. natürlich komplett auf eigene gefahr und ohne gewähr, dafür mit aktuellerem kernel 4.4.x und abgesichertem dnsmasq ;). bitte hood und gerät ansagen. 
>>> soweit habe ich kbuk (köln) auf zwei wr841(v9,11) ein paar stunden am laufen und es scheint zu zucken.
>>>
>>> falls jemand selber bauen möchte, kann ich die site config auf github schieben, würd ich eh, kann ich aber auch früher falls bedarf besteht.
>>>
>>> far out.. ede
>>>
>>> On 10/4/2017 11:54, Ramon Waldherr wrote:
>>>> Hiho,
>>>>
>>>> super, hoffe ich schaffe es zum nela am Donnerstag, und falls fix nötig und
>>>> fertig innerhalb gluons dann auch mal ein neues release machen.
>>>>
>>>> Greetz,
>>>>
>>>> rampone
>>>>
>>>> Am 04.10.2017 11:52 schrieb <edgar.soldin at web.de>:
>>>>
>>>>> On 03.10.2017 00:09, Ramon Waldherr wrote:
>>>>>> bei
>>>>>>> gluon nicht sicher, sollte aber nur ein radvd sein, der da läuft.
>>>>>
>>>>> hmm.. hab grad mal auf einen gluon-v2016.2.5 geschaut und da läuft ein
>>>>> dnsmasq drauf. wofür der gebraucht wird im "nicht-recovery-modus" ist mir
>>>>> nicht ganz klar.
>>>>>
>>>>> eigtl. sollte ja sämtlicher traffic direkt in die batman wolke geschoben
>>>>> werden, in der dann per dhcp adressen verteilt und ein dns namen auflöst.
>>>>>
>>>>> ok, aber ich seh grad,
>>>>>
>>>>> # cat /etc/resolv.conf
>>>>> search lan
>>>>> nameserver 127.0.0.1
>>>>>
>>>>> was allerdings kein sicherheitsproblem sein sollte, solange der knoten der
>>>>> einzige client der dnsmasq instanz ist.
>>>>>
>>>>> ich frag mal auf gluon at luebeck.freifunk.net nach inwieweit das standard
>>>>> openwrt/lede gluon knoten betrifft.
>>>>>
>>>>> soweit.. ede
>>>>> --
>>>>> _______________________________________________
>>>>> Freifunk-Bonn mailing list
>>>>> Freifunk-Bonn at lists.kbu.freifunk.net
>>>>> https://lists.kbu.freifunk.net/cgi-bin/mailman/listinfo/freifunk-bonn
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
> 
> 

-- 
Mit freundlichen Grüßen
Guido Pannenbecker

.  . Software Dienstleistungen
.  . Guido Pannenbecker

Zülpicher Str. 8, 50674 Köln
http://www.sd-gp.de/