|
|
|
|
|
|
|
gemeinnützige Forschungseinrichtung - bis das Schiff untergeht ist mein Vertrag eh ausgelaufen 
(Der Server ist quasi das VPN. Die Fileserver sind da eingebunden - auf dem lokalen Rechner darf man die nicht direkt einbinden, wenn man local root haben will und nicht das Uralt Suse der IT verwendet oder Windows)
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von RichterSkala am 13.10.2017 21:39]
|
|
|
|
|
|
|
|
|
| | Zitat von [KdM]MrDeath
wieso kündigste nicht bei der klitsche bevor das schiff unter geht?
| |
Das muss das Boot abkönnen Herr Kaleun!
|
|
|
|
|
|
|
|
|
|
|
Moin.
| |
| Code: |
#include <stdio.h>
#include <stdlib.h>
int funktion(char *text);
int main(void) {
char text[20] = {0};
funktion(text);
printf("funktion returned %s\n", text);
return 0;
}
int funktion(char *text) {
FILE* filepointer = popen("/home/pi/programm_das_string_auf_stdout_ausgibt", "r");
fgets(text, sizeof(text), filepointer);
printf("fgets returned %s\n", text);
pclose(filepointer);
return 0;
}
|
|
liefert "Str", ich erwarte aber "String".
Ich vermute dass der Fehler offensichtlich ist, wenn das schonmal gemacht hat, aber ich versuche zum ersten Mal aus C heraus eine andere Funktion aufzurufen und die Ausgabe auf stdout abzufangen.
Kleiner Tipp?
|
|
|
|
|
|
|
|
|
|
|
|
sizeof gibt dir nur die grösse des datentyps zurück, hier in dem fall die grösse deines char pointers.
|
|
|
|
|
|
|
|
|
|
|
Aus der man-page:
char *fgets(char *s, int size, FILE *stream);
fgets() reads in at most one less than size characters
size ist bei dir sizeof(text), text ist aber ein pointer. Auf dem Pi ist der 4 bytes lang. -> Länge vorher ermitteln und als extra parameter übergeben.
|
|
|
|
|
|
|
|
|
|
Läuft, danke! 
/e: ach, das passt vielleicht doch besser in den RPi Thread
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von Rootsquash am 14.10.2017 19:00]
|
|
|
|
|
|
|
|
|
|
Pulseaudio liefert jetzt manchmal spontan stark verzerrten Ton, wieder ohne erkennbaren Trigger (tendenziell scheint es mit Muten/Unmuten oder Beginn/Ende von Audiowiedergabe in mpv/FF zu tun zu haben). Ich geh mir jetzt apulse holen.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 15.10.2017 23:56]
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Pulseaudio liefert jetzt manchmal spontan stark verzerrten Ton, wieder ohne erkennbaren Trigger (tendenziell scheint es mit Muten/Unmuten oder Beginn/Ende von Audiowiedergabe in mpv/FF zu tun zu haben). Ich geh mir jetzt apulse holen.
| |
Haste meinen Post zum X11 Bell Sound gesehen?
|
|
|
|
|
|
|
|
|
|
|
Nein 
Ich Desktop-Sounds komplett aus (mache ich immer und überall so, mich nerven die Dinger nur). Hmmm... am Ende ignoriert da noch was meine Einstellungen nur weil es unter PA läuft?
| | Zitat von RichterSkala
| | Zitat von RichterSkala
| | Zitat von csde_rats
Zischeln (wie immer, wenn PA startet), gleiches Problem. Habe inzwischen neugestartet. "module-suspend-on-idle" ist schon raus.
| |
Merkwürdig. Ich hab auf einem Rechner auch ein Problem mit Pulseaudio. Manchmal unter load fängt er an eine Verzögerte Kopie des Signals an die Ausgänge zu senden. Es ist aber kein reines Echo, sondern beide Signale klingen downgesampelt oder hart übersteuert. Mit ALSA nie Probleme gehabt 
(Achso, bleibt bei mir bis zum neustart von pulseaudio)
| |
Update: Festgestellt, dass das Problem bei mir nur (noch?) auftritt, wenn irgendwas versucht, die Bell klingeln zu lassen - ein Bug der mich jetzt irgendwie fast schon erheitert.
| |
|
|
|
|
|
|
|
|
|
|
|
Präparieren Sie Ihre respektiven Orifizien, WPA2 bröckelt. Und mit bröckelt meine ich Core Protocol-level flaw in WPA2. Ob es wohl Firmware-Updates von Koryphäen wie TP-Link geben wird? ( )
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 16.10.2017 2:23]
|
|
|
|
|
|
|
|
|
Nichts genaues weiß man? Alle brauchen WPA2 und die meisten werden keinen Fix bekommen?
Und es ist Montag
// edit
| | | Das klappt Informationen von The Register zufolge aber nur, wenn ein Angreifer sich Reichweite eines Clients und Access Points befindet. | |
Offenbar kann man aber dagegen anpatchen.
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von hoschi am 16.10.2017 11:39]
|
|
|
|
|
|
|
|
|
Package : wpa
CVE ID : CVE-2017-13077 CVE-2017-13078 CVE-2017-13079 CVE-2017-13080
CVE-2017-13081 CVE-2017-13082 CVE-2017-13086 CVE-2017-13087
CVE-2017-13088
CVE-2017-13077: reinstallation of the pairwise key in the Four-way handshake
CVE-2017-13078: reinstallation of the group key in the Four-way handshake
CVE-2017-13079: reinstallation of the integrity group key in the Four-way
handshake
CVE-2017-13080: reinstallation of the group key in the Group Key handshake
CVE-2017-13081: reinstallation of the integrity group key in the Group Key
handshake
CVE-2017-13082: accepting a retransmitted Fast BSS Transition Reassociation
Request and reinstalling the pairwise key while processing it
CVE-2017-13086: reinstallation of the Tunneled Direct-Link Setup (TDLS) PeerKey
(TPK) key in the TDLS handshake
CVE-2017-13087: reinstallation of the group key (GTK) when processing a
Wireless Network Management (WNM) Sleep Mode Response frame
CVE-2017-13088: reinstallation of the integrity group key (IGTK) when
processing a Wireless Network Management (WNM) Sleep Mode
Response frame
Ein Update der Clients scheint fürs erste hinreichenden Schutz zu bieten.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von csde_rats am 16.10.2017 12:15]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | Our attack is especially catastrophic against version 2.4 and above of wpa_supplicant, a Wi-Fi client commonly used on Linux. Here, the client will install an all-zero encryption key instead of reinstalling the real key. This vulnerability appears to be caused by a remark in the Wi-Fi standard that suggests to clear the encryption key from memory once it has been installed for the first time. When the client now receives a retransmitted message 3 of the 4-way handshake, it will reinstall the now-cleared encryption key, effectively installing an all-zero key. Because Android uses wpa_supplicant, Android 6.0 and above also contains this vulnerability. This makes it trivial to intercept and manipulate traffic sent by these Linux and Android devices. Note that currently 41% of Android devices are vulnerable to this exceptionally devastating variant of our attack. | |
Da hat wohl jemand eine Empfehlung falsch verstanden 
| |
To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo. | |
Als Entwickler bist du da immer der Arsch. Du brauchst Zeit, am besten viel Zeit um das Problem zu verstehen, einen guten Patch zu schreiben und zu testen. Und dann darfst du den Patch nicht freigeben, weil du schneller bist als andere oder kommst und Zeitdruck, weil du langsamer bist als andere.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 16.10.2017 13:52]
|
|
|
|
|
|
|
|
|
| | Should I temporarily use WEP until my devices are patched?
NO! Keep using WPA2. | |
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Danzelot am 16.10.2017 13:50]
|
|
|
|
|
|
|
|
|
|
Client zu patchen reicht ja wohl gegen vuln AP, aber reicht AP patchen auch gegen vuln Clients? So ein oller smart TV kostet ja mehr als nen neuer billo router
|
|
|
|
|
|
|
|
|
|
|
Ich habe eine Dump-Beamer. Aber wozu war gestern Abend das FireTV-Update da? Archlinux hat die Patches von wpa_supplicant gestern Abend erhalten.
// edit
Ich bin da immer hin- und hergerissen bei diesen Geheimhaltungsgeschichten, in diesem Fall halt besonders kritisch weil gleich mehrere unabhängige Systeme betroffen sind. Angeblich hat Microsoft einen auf OpenBSD gemacht und den Patch vorher rausgeschoben, ebenso ohne Releasenotes und zusätzlich ohne Quellcode 
Wenigstens muss ich jetzt nicht mehr jedem erklären, warum mir in gewissen Fällen Kabel lieber sind. Habe mir vor einiger Zeit extra ein LAN-Kabel durch die Wand ins Büro gelegt, schon allein wegen der besseren Verbindung.
|
|
[Dieser Beitrag wurde 6 mal editiert; zum letzten Mal von hoschi am 17.10.2017 11:31]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
hey, ganz ruhig, ist avm, die sind unbedeutend und machen nie fehler.
|
|
|
|
|
|
|
|
|
|
|
So. Jetzt mehr als 13 Stunden in der Arbeit. Wer Informatiker - haben Sie gesagt. Da musst du nicht körperlich arbeiten - haben sie gesagt.
Einen Scheiß 
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 17.10.2017 22:43]
|
|
|
|
|
|
|
|
|
Ich gehe nicht davon aus, dass du leitender Angestellter bist und somit steht dein Chefchen mit einem Bein im Gefägnis.
|
|
|
|
|
|
|
|
|
|
|
Leitender...Senior im Team?
Meine Motivation ist sowieso am Boden, ist halt Pflichtgefühl. Ich hätte erstmal mich an unserem alten Berater orientieren sollen.
| | | Erstmal machen, hinterher kann man sich immer noch entschuldigen! | |
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 17.10.2017 23:13]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Doppelte Verneinung du bist.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
Doppelte Verneinung du bist.
| |
Schon spät. Heute waren es 9:45h Anwesenheit für mich.
|
|
|
|
|
|
|
|
|
|
|
Spät trifft es. Feierabend warum 06:00 Uhr
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
wieso lässt eigentlich jemand auf nem unvertrauenswürdigen stück hardware sich private keys generieren?
da vertrau ich openpgp um längen mehr (ka, selbst dem debian packet ) als so embedded entwicklern...
|
|
|
|
|
|
|
|
|
|
|
Du nutzt also auch keine Intelhardware, weil die üblicherweise AMT kann?
We are doomed.
|
|
|
|
|
|
|
|
|
|
|
ich hab letztens festellen müssen, dass das AMT/ME zeugs auf meinem asrock C226 WS nicht so wirklich funktionsfähig ist. keine der intel treiber, noch irgendwelche tools von denen erkennen das teil.
die lustigen tools sagen sogar sehr deutlich, dass das system keine intel ME unit hat.
könnte natürlich daran liegen, dass die da sachen etwas eigenartig drauf verdrahtet haben, um ein wenig mehr aus dem chipsatz zu kitzeln, als das, was intel da so für vorgesehen hatte.
|
|
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 // 0x23 ( const int MAX_POST = 30 * 100; // 0x23 ) |
