In der Telnet Console: packetsock_doread

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.

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...

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

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

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

ö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.

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

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?

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.

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