feed-image -=Kernel-Error=- BlogFeed

LG G2 (d802) LinageOS und TWRP

Auf meinem Smartphone werkelt inzwischen LinageOS. Funktioniert auch ganz prima :-) Heute am Morgen kommt die Meldung hoch: "Es gibt ein Update". Ich drück natürlich auf: "Gib ihm!"

Das Gerät macht irgendwas und startet dann im TWRP neu. An der Stelle hätte ich nun damit gerechnet, dass es beginnt das Update zu installieren. Tut er aber leider nicht :-/ Ich starte also neu, wieder kommt er im TWRP hoch. Egal was ich mache, bleibt so.

Nicht falsch verstehen, ich beschwere mich nicht darüber. Ich habe mich ja dafür entschieden ein solch instabiles System zu nutzen. :-D

Wie auch immer. Folgendes hat mir geholfen.

Im TWRP den Terminal Emulator starten und folgende Befehl absetzten:

dd if=/dev/zero of=/dev/block/platform/msm_sdcc.1/by-name/fota
dd if=/dev/zero of=/dev/block/platform/msm_sdcc.1/by-name/misc


Reboot und gut!

Anruf bei der G-Data Hotline

Ich: tuuuuut...... tuuuuuut
Hotline: Bla gdata Hotline bla
Ich: Pffffhhhh
Hotline: *laala* (mucke)
Ich: Pffffhhhh
Hotline: Willkommen an der Hotline, mein Name ist Mann, was kann ich für sie tun?
Ich: Sie brauchen sicher meinen Benutzernamen, oder?

Das scheint da so etwas wie die Kundennummer in anderen Unternehmen zu sein....

Hotline: Oh ja, den nehme ich gerne.
Ich: Konrad-5-Julius-Heinrich-97- [Hotlinemann unterbricht mich]
Hotline: Konrad ausgeschrieben?
Ich: Öhm ähh ne also öh der Buchstabe?!?
Hotline: OK
Ich: Kundenummer...
Hotline: und was kann ich nun für sie tun?
Ich: Wir testen gerade die Amavis Integration eurer G DATA Business Lösung und das läuft nicht ganz rund.
Hotline: uhhaaa ohh
Ich: Warum uhaaa ohh?
Hotline: Öhm (hehe) also ähh, da bekommen wir eher weniger Anfragen. Wird nicht so oft benutzt.
Ich: Na aber ihr verkauft das ja.
Hotline: Ja aber ähh gut.


Dann wurden Version und OS abgefragt und ein Ticket angelegt. Ich sollte mal Auszüge aus dem Maillog senden O_o irgendwie habe ich das Gefühl als wenn das gerade nix wird :-D

Für Spaß auch mal die Logfiles:

Feb  7 08:27:54 mx amavis[27217]: (21323-04-4) (!)run_command: child process [27217]: Insecure dependency in exec while running with -T switch at /usr/sbin/amavisd-new line 4743.
Feb  7 08:27:54 mx amavis[21323]: (21323-04-4) (!!)collect_results from [27217] (/usr/bin/gdmailscannerc): exit 3 Feb  7 08:27:54 mx amavis[21323]: (21323-04-4) (!)checking with spam scanner GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158.
Feb  7 08:27:54 mx amavis[21323]: (21323-04-4) (!!)TROUBLE in check_mail: spam_scan FAILED: GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158. at (eval 98) line 159.
Feb  7 08:27:54 mx amavis[21323]: (21323-04-4) (!)PRESERVING EVIDENCE in /var/lib/amavis/tmp/amavis-20170207T082744-21323-gFK_Ofar
Feb  7 08:27:54 mx postfix/smtp[27003]: EFA15C0A13: to=<type@domain.de>, relay=127.0.0.1[127.0.0.1]:10024, conn_use=4, delay=85234, delays=85181/42/0/10, dsn=4.5.0, status=deferred (host 127.0.0.1[127.0.0.1] said: 451 4.5.0 Error in processing, id=21323-04-4, spam_scan FAILED: GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158. at (eval 98) line 159. (in reply to end of DATA command)) Feb  7 08:27:54 mx amavis[27219]: (21323-04-5) (!)run_command: child process [27219]: Insecure dependency in exec while running with -T switch at /usr/sbin/amavisd-new line 4743.
Feb  7 08:27:54 mx amavis[21323]: (21323-04-5) (!)run_av (GDAVCLIENTC SCANNER.) FAILED - unexpected , output=""
Feb  7 08:27:54 mx amavis[21323]: (21323-04-5) (!)GDAVCLIENTC SCANNER. av-scanner FAILED: CODE(0x2cc4260) unexpected , output="" at (eval 97) line 905.
Feb  7 08:27:54 mx amavis[21323]: (21323-04-5) (!)WARN: all primary virus scanners failed, considering backups Feb  7 08:27:54 mx amavis[27221]: (20783-09-4) (!)run_command: child process [27221]: Insecure dependency in exec while running with -T switch at /usr/sbin/amavisd-new line 4743.
Feb  7 08:27:54 mx amavis[20783]: (20783-09-4) (!!)collect_results from [27221] (/usr/bin/gdmailscannerc): exit 3 Feb  7 08:27:54 mx amavis[20783]: (20783-09-4) (!)checking with spam scanner GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158.
Feb  7 08:27:54 mx amavis[20783]: (20783-09-4) (!!)TROUBLE in check_mail: spam_scan FAILED: GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158. at (eval 98) line 159.
Feb  7 08:27:54 mx amavis[20783]: (20783-09-4) (!)PRESERVING EVIDENCE in /var/lib/amavis/tmp/amavis-20170207T082744-20783-75UHo67I
Feb  7 08:27:54 mx postfix/smtp[27159]: D74F7C00F4: to=<type@domain.de>, relay=127.0.0.1[127.0.0.1]:10024, conn_use=4, delay=342238, delays=342185/42/0/10, dsn=4.5.0, status=deferred (host 127.0.0.1[127.0.0.1] said: 451 4.5.0 Error in processing, id=20783-09-4, spam_scan FAILED: GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158. at (eval 98) line 159. (in reply to end of DATA command)) Feb  7 08:27:55 mx amavis[20783]: (20783-09-5) Passed CLEAN {RelayedInbound}, SPAM_DISC [1.2.3.4]:44419 [1.2.3.4] <type@domain.de> -> <type@domain.de>, Queue-ID: 6D65CC0A33, Message-ID: <62734015.3835.1486452455492.JavaMail@domain.de>, mail_id: lsOZOYNAIa3o, Hits: 0, size: 44774, queued_as: 57B04C0A40, 471 ms

Feb  7 09:55:25 mx amavis[22893]: (22893-07) Passed CLEAN {RelayedInbound}, SPAM_DISC [1.2.32.4]:36945 [1.5.7.98] <type@domain.de> -> <type@domain.de>, Queue-ID: E7592C0071, Message-ID: <20170207085513.B8A52340881@domain.de>, mail_id: 3lhpfBFnyuAI, Hits: 0, size: 4172, queued_as: 1F499C00F7, 10166 ms Feb  7 09:55:25 mx amavis[20843]: (20843-14) (!)run_av (GDAVCLIENTC SCANNER.) FAILED - unexpected , output="SKIP"
Feb  7 09:55:25 mx amavis[20843]: (20843-14) (!)GDAVCLIENTC SCANNER. av-scanner FAILED: CODE(0x2cc4260) unexpected , output="SKIP" at (eval 97) line 905.
Feb  7 09:55:25 mx amavis[20843]: (20843-14) (!)WARN: all primary virus scanners failed, considering backups

 

DNSSEC IPv6 DENIC und ein DNS in Japan

Ich brauche mal eure Hilfe...

Zum Spaß habe ich mir einen VPS Server in Japan geklickt. Was nun damit tun? Einfach mal ein weiteren DNS Server nutzen \o/ Gute Idee? Nein... Warum nicht? Weil der Server in Japan steht, höhere Antwortzeiten hat und der meist zufällig entscheidet, welcher DNS Server nun gefragt wird. Ich habe somit also sporadisch DEUTLICH langsamere DNS Antworten. Für meinen Spieltrieb aber gerade OK .-P

Ist also nun ein FreeBSD 10 mit einem Bind9.11 als slave für drei Spielzonen (kernel-error.org, kernel-error.com, kernel-error.de). FreeBSD ans Ende gepatcht, aktuellen Bind drauf, getestet ob die Kiste sauber signierte Zonen abfragen und prüfen kann (TCP/UDP und größer 512) alles gut. Dann als slave eingebunden wieder getestet und dann in die Zone darüber eintragen lassen. Die Zonen org. sowie com. haben den DNS-Server einfach gefressen. die Zone de. meckert aber! DNS timeout bei IPv6 O_o Öhm, ok... dig und drill sagen das geht aber. Bind ist auch fest ein und ausgehend an die IPv6 Adresse gebunden. Als "Firewall" rennt PF, das mal deaktiviert ändert aber nichts. Vielleicht filter der Provider? Nope nur switch, iptables und ebtables öhm, das klingt sehr spartanisch.

Hat das Problem nur denic? Nö, DNSViz scheint es auch nicht zu können: http://dnsviz.net/d/kernel-error.com/dnssec/

Wie gesagt NUR bei IPv6! Jetzt habe ich mir alle Mühe gegeben diesen Timeout selbst mal zu produzieren, klappt aber nicht. Bei mir geht es einfach IMMER egal was für Optionen ich dig mitgebe.

# dig @2001:310:6000:f::1fc7:1 +edns +multi +norec +bufsize=4096 kernel-error.com IN MX +short
10 smtp.kernel-error.de.
# dig @2001:310:6000:f::1fc7:1 +tcp +edns +multi +norec +bufsize=4096 kernel-error.com IN MX +short
10 smtp.kernel-error.de.

Ich verstehe das nicht! Ich mache am bind keine Unterscheidung zwischen IPv4 und IPv6, für mich geht alles. Alle Antworten und Fragen in alle Richtungen laufen ohne jedes Problem. Nur DNSViz und denic scheinen ein "Problem" zu haben. Mal sehen ob jemand von der denic mit einen sinnvollen Tipp geben kann. Mir würde ja schon der dig Aufruf reichen der zu einem timeout führt :-/ Dann hätte ich etwas zum Testen.

Oh ja, ich habe natürlich auch ganz brav mal tcpdump laufen lassen. Leider sieht es hier ebenfalls einfach funktionstüchtig aus :(

https://www.kernel-error.de/download/dns.tar.gz

Hat von euch irgendjemand eine Idee?


*U-P-D-A-T-E*


Die interne Fehlermeldung der API DENIC:

ERROR: 223 Timeout after switching from UDP to TCP - switch to TCP due to timeout (target) (ns3.kernel-error.com./2001:310:6000:f:0:0:1fc7:1:53)


*U-P-D-A-T-E*

Mal querry log eingeschaltet:

30-Jan-2017 18:30:04.669 client @0x802e62600 2a02:568:201:214::1:15#38145 (ns3.kernel-error.com): query: ns3.kernel-error.com IN A -E(0)DC (2001:310:6000:f::1fc7:1)
30-Jan-2017 18:30:04.670 client @0x802e62600 2a02:568:201:214::1:15#41589 (ns3.kernel-error.com): query: ns3.kernel-error.com IN AAAA -E(0)DC (2001:310:6000:f::1fc7:1)
30-Jan-2017 18:30:04.938 client @0x802e62600 2a02:568:201:214::1:15#20703 (kernel-error.de): query: kernel-error.de IN SOA - (2001:310:6000:f::1fc7:1)
30-Jan-2017 18:30:05.510 client @0x802e6f800 2a02:568:201:214::1:15#58465 (kernel-error.de): query: kernel-error.de IN NS -T (2001:310:6000:f::1fc7:1)
30-Jan-2017 18:30:05.889 client @0x802e62600 2a02:568:201:214::1:15#47548 (kernel-error.de): query: kernel-error.de IN SOA -E(0)D (2001:310:6000:f::1fc7:1)
30-Jan-2017 18:30:05.896 client @0x802e62600 2a02:568:201:214::1:15#55493 (kernel-error.de): query: kernel-error.de IN DNSKEY -E(0)D (2001:310:6000:f::1fc7:1)
30-Jan-2017 18:30:06.416 client @0x802e70c00 2a02:568:201:214::1:15#37170 (kernel-error.de): query: kernel-error.de IN DNSKEY -E(0)TD (2001:310:6000:f::1fc7:1)

*U-P-D-A-T-E*

Ich glaube es nicht... Ich teste hier gerade rum, will einem Kollegen zeigen das es nicht geht und das Update läuft bei DENIC einfach durch und OK Ö_ö ich verstehe das nicht, wirklich nicht. Absolut 0,0 warum geht das jetzt und warum meint DNSViz das es dennoch nicht geht? Was passiert hier?


*U-P-D-A-T-E*

Bleibt nur noch meine Vermutung, dass es wirklich um die Antwortzeit des Servers geht... Die liegt so zwischen 200 und 300ms. Das ist echt lange aber auch nicht SOOOOOOO lange :-/ Mal sehen ob von denic irgendwas kommt?!?!


*U-P-D-A-T-E*

Da fliegt mir doch gerade folgende Info rein:

die DENIC meinte dazu:

    unsere Kollegen können derzeit nicht genau sagen woran es hängt. Jedoch sind unsere Verbindungen nach Korea zeitweise leicht beeinträchtigt, evtl. wurde dir Nast Prüfung genau in dem Moment durchgeführt.


Es scheint als bekommen wir das nicht geklärt. Aber schön, wenn das
Update nun durch ist.

PS: Ein leicht ungutes Gefühl bleibt ...

 

Mein DNSRBL RHSBL RBL für Postfix

Hallo zusammen,

ich habe meine DNSRBL RHSBL RBL für Postfix angefasst. Wer sie also zum Test abfragen möchte (/etc/postfix/main.cf)):

# RECIPIENT restrictions:
smtpd_recipient_restrictions =
   permit_mynetworks,
   permit_sasl_authenticated,
   check_recipient_access hash:/etc/postfix/recipient-access,
   check_sender_access hash:/etc/postfix/sender-access,
   reject_unverified_recipient,
   reject_unauth_pipelining,
   reject_non_fqdn_recipient,
   reject_unknown_recipient_domain,
   reject_unauth_destination,
   reject_rbl_client imap.bl.blocklist.de,
   reject_rbl_client mail.bl.blocklist.de,
   reject_rbl_client b.barracudacentral.org,
   reject_rbl_client zen.spamhaus.org,
   reject_rbl_client bl.spamcop.net,
   reject_rbl_client cbl.abuseat.org,
   reject_rbl_client ix.dnsbl.manitu.net,
   reject_rbl_client virbl.dnsbl.bit.nl,
   reject_rbl_client abuse.rhsbl.kernel-error.de,
   reject_rbl_client postmaster.rhsbl.kernel-error.de,
   reject_rbl_client spam.rhsbl.kernel-error.de,
   reject_rbl_client spam.rbl.kernel-error.de,
   reject_unknown_recipient_domain,
   permit

B.t.w.: Ihr solltet das natürlich niemals produktiv einsetzten und macht es vollständig auf eure Verantwortung, denn ich würfle das nach meine ganz privaten Meinung :-)

Ich fülle die Liste zum Teil von Hand, wenn ich irgendwas von einem System bekomme was ich nicht haben wollte landet es dort. Ebenfalls füllt es sich automatisch durch ein Postfach das "Werbung" sammelt. Ich lasse Adressen/Systeme dort in der Regel für min. 6 Monate liegen. Es sei denn da ist was schief gelaufen, ich habe doch das Bedürfnis mit diesem System E-Mails zu tauschen oder sonst was.

Es bleibt aber dabei, es ist meine ganz private Liste damit nicht jedes meiner Mailsysteme einzeln lernen muss welche E-Mails ich nicht haben will. Wenn ihr es produktiv einsetzt wird es Probleme geben :D

So long..

Neue IPv6 Adresse für ns2.kernel-error.org

Wenn wir schon dabei sind hier Dinge umzustellen, ns2.kernel-error.org hat eine neue IPv6 Adresse bekommen (IPv4 bleibt).

Alt: 2001:41d0:2:c3b4::66
Neu: 2001:41d0:302:2100::6401

In den Zonen passt schon alles, fehlt nur noch der Glue-Record. Der sollte aber auch bald da sein :-D