.titleBar { margin-bottom: 5px!important; }

In der Telnet Console: packetsock_doread

Dieses Thema im Forum "FRITZ!Box Fon: Modifikationen" wurde erstellt von realriot, 30 Jan. 2005.

Status des Themas:
Es sind keine weiteren Antworten möglich.
  1. realriot

    realriot Neuer User

    Registriert seit:
    23 Nov. 2004
    Beiträge:
    156
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Ort:
    Bremen
    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
     
  2. realriot

    realriot Neuer User

    Registriert seit:
    23 Nov. 2004
    Beiträge:
    156
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Ort:
    Bremen
    ... 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.
     
  3. pfeffer

    pfeffer Mitglied

    Registriert seit:
    26 Okt. 2004
    Beiträge:
    755
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    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.
     
  4. khigh

    khigh Neuer User

    Registriert seit:
    4 Jan. 2005
    Beiträge:
    21
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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...
     
  5. realriot

    realriot Neuer User

    Registriert seit:
    23 Nov. 2004
    Beiträge:
    156
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Ort:
    Bremen
    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...
     
  6. nemesis001

    nemesis001 Mitglied

    Registriert seit:
    14 Jan. 2005
    Beiträge:
    200
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Ort:
    Dresden
    Das Problem hatte ich auch. Ich habe dann einfach nochmal die x.29 drauf gespielt und seitdem ist es nicht mehr aufgetaucht.
     
  7. olistudent

    olistudent IPPF-Urgestein

    Registriert seit:
    19 Okt. 2004
    Beiträge:
    14,756
    Zustimmungen:
    2
    Punkte für Erfolge:
    0
    Beruf:
    Softwareentwickler
    Ort:
    Kaiserslautern
  8. khigh

    khigh Neuer User

    Registriert seit:
    4 Jan. 2005
    Beiträge:
    21
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    ach du kacke, dann ist das auch die gleiche Ursache hier :p
    danke für den Hinweis olistudent
     
  9. realriot

    realriot Neuer User

    Registriert seit:
    23 Nov. 2004
    Beiträge:
    156
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Ort:
    Bremen
    tjo. ich hoffe avm bekommt das feature im nexten firmware release gefixt...
     
  10. realriot

    realriot Neuer User

    Registriert seit:
    23 Nov. 2004
    Beiträge:
    156
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Ort:
    Bremen
    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...
     
  11. khigh

    khigh Neuer User

    Registriert seit:
    4 Jan. 2005
    Beiträge:
    21
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    ö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.
     
  12. iwan

    iwan Neuer User

    Registriert seit:
    3 Okt. 2004
    Beiträge:
    9
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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
     
  13. realriot

    realriot Neuer User

    Registriert seit:
    23 Nov. 2004
    Beiträge:
    156
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Ort:
    Bremen
    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;)
     
  14. iwan

    iwan Neuer User

    Registriert seit:
    3 Okt. 2004
    Beiträge:
    9
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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?
     
  15. realriot

    realriot Neuer User

    Registriert seit:
    23 Nov. 2004
    Beiträge:
    156
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Ort:
    Bremen
    kam gerade als antwort auf mein support-ticket...
     
  16. khigh

    khigh Neuer User

    Registriert seit:
    4 Jan. 2005
    Beiträge:
    21
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    hab auch grad ne mail geschickt mit Anleitung zum reproduzieren ohne dbox, naja scheinbar haben die doch eine :p

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

    Anhänge:

  17. olistudent

    olistudent IPPF-Urgestein

    Registriert seit:
    19 Okt. 2004
    Beiträge:
    14,756
    Zustimmungen:
    2
    Punkte für Erfolge:
    0
    Beruf:
    Softwareentwickler
    Ort:
    Kaiserslautern
    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
     
Status des Themas:
Es sind keine weiteren Antworten möglich.