In der Telnet Console: packetsock_doread

[realriot]

wenn die box einige zeit online ist fängt die box auf einmal an diese seltsame meldung in der telnet console loszulassen... das ist ein richtiger flood und die meldung wiederholt sich dauernd und SEHR SCHNELL:

Jan 30 19:09:21 multid[312]: 8(lan:udp:67) (fd 8): packetsock_doread: packet alloc failed
Jan 30 19:09:21 multid[312]: 7(arpping) (fd 7): packetsock_doread: packet alloc failed


jemand ne ahnung?

grüße

Sascha

 

[realriot]

... Durch diese Meldung / dieses Verhalten bedingt sind zu der Zeit (wenn das auftritt) VOIP Gespräche nicht möglich da diese total abgehackt sind. ein reboot behebt das problem dann.

 

[pfeffer]

ich habe keine Ahnung, was das genau bedeutet, könnte aber heißen, dass die Box nicht mehr genügen RAM frei hat, um Pakete (Daten) von der Netzwerkkarte zu lesen? - Evtl. zu viel in /var/tmp gespeichert (RAM-Laufwerk) oder zu viele Prozesse am laufen?

Gruß,
Pfeffer.

 

[khigh]

hi,
ich logge auf einen Server, der Eintrag in debug.cfg:
/sbin/syslogd -R 192.168.178.XXX

Mir sind eben zufällig die flatternde Traffic-Leds (fb <-> logserver) am Switch aufgefallen.
tcpdump zeigte das die fb auf den logserver schreiben will:
16:22:50.838691 IP fritz.box.1026 > XXX.XXX.syslog: UDP, length: 74
mit ca 550 Paketen pro Sekunde.

tail -f /var/log/messages zeigte aber nix Neues, hab dann mit ethereal nachgesehn:
[...]
User Datagram Protocol, Src Port: 1026 (1026), Dst Port: syslog (514)
Syslog message: USER.ERR: multid[300]: 7(arpping) (fd ...
0000 1... = Facility: USER - random user-level messages (1)
.... .011 = Level: ERR - error conditions (3)
Message: multid[300]: 7(arpping) (fd 7): packetsock_doread: packet alloc failed

Rebooten übers Webinterface dann gehts (nur was?) wieder.

Was mir mehr Sorgen macht: ich bekomme Anrufe aber das Telefon klingelt nicht!
Das jemand Anruft weis ich nur durch meinen Server der auch an ISDN hängt und die Anrufe anzeigt.
In der Anrufliste der FB erscheinen die Anrufe ach nicht!
Ein Kaltstart der Box (strom raus) behob das Problem, welches seit dem Update auf .29 auftretet, jetzt ist es aber wieder.
Gerade wollte wieder jemand anrufen, der packetsock_doread Fehler war zu der Zeit nicht und auch nicht danach.

Ich schick das an AVM und geh dann wiedermal den Stecker ziehn...

 

[realriot]

sobald auf der box der "multid" restarted wird (multid -s und dann multid) is das problem behoben. irgendwie scheint das problem am multid bzw. einem seiner komponenten zu liegen...

 

[nemesis001]

Das Problem hatte ich auch. Ich habe dann einfach nochmal die x.29 drauf gespielt und seitdem ist es nicht mehr aufgetaucht.

 

[olistudent]

Das Problem bei realriot ist eine dbox im internen Netzwerk, die beim starten ein bootp-Request an Broadcast macht. Und daraufhin stürtzt der multid auf der Fritz ab...

siehe hier: http://www.ip-phone-forum.de/forum/viewtopic.php?t=10638

MfG Oliver

 

[khigh]

ach du kacke, dann ist das auch die gleiche Ursache hier
danke für den Hinweis olistudent

 

[realriot]

tjo. ich hoffe avm bekommt das feature im nexten firmware release gefixt...

 

[realriot]

dabei fällt mir ein...
kann man da nicht eine "notlösung" bauen? evtl. die bootp requests firewallen? oder ist das auf der osi-level ebene zu tief? habe in der ar7.cfg ja einige "rejects" entdeckt...

 

[khigh]

öh joa das könnte gehn, man kann auf der fb mac-adressen im wlan filtern, kommt drauf an wie das implementiert worden ist. Unter Linux mit iptables geht das.
Die wlan-MAC meines freigeschalteten Laptops steht aber nicht in der ar7.cfg sondern in wlan.cfg.
Achso man möchte ja nur den dhcp request filtern, nicht komplett sprerren was mit der mac kommt, das kann die fritzbox dann eher doch nicht.

Eine Möglichkeit wär evtl. einen fake Eintrag für die dbox in /var/flash/multid.leases zu machen, das glaub ich zwar eigentlich auch nicht aber man weis ja noch nicht worans genau liegt.

 

[iwan]

Hallo,
Ich habe genau das gleiche Problem, weiss jetzt dank dieses Threads, dass meine DBoxen "schuld" sind. Ich habe bei mir festgestellt, dass die multid Fehlermeldungen genau dann "starten" wenn die DBOX beim booten auf den Ping antwortet - das wäre ja ein wenig nach dem BOOTP-request.
Als Workaround hätte ich eine Idee - weiß aber nicht ob das realisierbar ist:
Man könnte ja im Start-Script der DBox (/etc/init.d/rc1) das multid auf der FBF stoppen und wieder starten. Die DBox, falls Neutrino drauf hat ja auch ein Linux, vielleicht kann man ja dann per Skript auf die Fritz um das multid zu stoppen und zu starten. Meine Frage: geht so was? - und wenn ja: wie?

mfG
Iwan

 

[realriot]

joa das geht. ich glaube oli hatte da eine lösung realisiert. er hat sich ein cgi-script gebaut was bei einem aufruf den multid restartet... ist aber denke ich eher nur ein workaround.

mein workaround ist der, daß ich mein box einfach anlasse bzw. nur in den standby gehe. voller sehnsucht warte ich nun auf eine lösung von avm

 

[iwan]

Die DBox anlassen geht zwar auch, kostet aber auch Strom!
Eine Korrektur von AVM wäre mir auch lieber - kann aber bekanntlich dauern.
Das mit dem cgi-Script hört sich gut an, nur wo finde ich das bzw. wie mache ich das?

 

[realriot]

danke für das Feedback, wir sind dabei diese Sache genauer zu Untersuchen.
Soweit scheint es tatsächlich auszureichen die Dbox erst zu starten und
dann
ans Netz zu bringen.


Mit freundlichen Grüßen

Dirk Hartel (AVM Support)

kam gerade als antwort auf mein support-ticket...

 

[khigh]

hab auch grad ne mail geschickt mit Anleitung zum reproduzieren ohne dbox, naja scheinbar haben die doch eine

hab das bootp-paket mit packetyzer geloggt und im anhang mitgeschickt.
Mit http://packetyzer.sf.net/ kann man das dann auch wieder senden.

 

[olistudent]

Hi.
Ich habe das mal mit iptables auf der Fritz probiert.
Er zeigt mir vom iptables auch an, dass er auf Port 67 was geblockt hat, aber der multid stürtzt trotzdem ab??

MfG Oliver