pvoutput. Waarom makkelijk doen, als het ook moeilijk kan! Every solution has a new problem
Verwijderd
Okee die module is dus een andere dan die ik in gedachte had.
De module die jouw meldingen veroorzaakt heet "ip_conntrack" (zoals ook al wel uit de eerste source regel was op te maken).
Tja deze module is onmisbaar wil NAT functionaliteit gebruiken.
Ik heb nog even nagezocht wat de reden was van een dergelijke foutmelding:
Verder kan je dus inderdaad die printk regel uit de source code slopen.
Je zou ook een volgende regel kunnen gebruiken:
Wat doet dit?
Dit dropt al het multicast verkeer dat naar ip 224.0.0.2 verstuurt wordt en dat niet getraceerd kan worden. Het verschijnt nu dus ook niet meer in je logfiles.
Overigens is dit dus symptoom bestrijding en niet oorzaak bestrijding
De module die jouw meldingen veroorzaakt heet "ip_conntrack" (zoals ook al wel uit de eerste source regel was op te maken).
Tja deze module is onmisbaar wil NAT functionaliteit gebruiken.
Ik heb nog even nagezocht wat de reden was van een dergelijke foutmelding:
Probleem zit hem dus in het multicast gedeeltje nadat ik je vorige post nu ook gelezen heb. Ik zou dus eerst onderzoeken waar al dat multicast verkeer vandaan komt!NAT: X dropping unteracked paket Y Z aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb
This message is printed by the NAT code. It drops packets, because in order to do NAT it has to have valid connection tracking information. For all packets, for which connection tracking was unable to determine conntrack information AND for which the user has a NAT rule, this message is printed.
Possible reasons are:
maximum limit of entries in the conntrack database reached
-->> couldn''t determine inverted tuple (multicast, broadcast) <<--
kmem_cache_alloc fails (out of memory)
reply on unconfirmed connection
icmp packet too short
icmp is fragmented
icmp checksum wrong
If you want to have a more detailed logging of these packets (i.e. if you suspect it are remote probe / scanning packets), use the following rule:
iptables -t mangle -A PREROUTING -j LOG -m state --state INVALID
And yes, you have to put the rule in the mangle table, because the packets get dropped by the NAT code before they reach the filter table.
Verder kan je dus inderdaad die printk regel uit de source code slopen.
Je zou ook een volgende regel kunnen gebruiken:
code:
1
| iptables -t mangle -A PREROUTING -d 224.0.0.2/32 -j DROP -m state --state INVALID |
Wat doet dit?
Dit dropt al het multicast verkeer dat naar ip 224.0.0.2 verstuurt wordt en dat niet getraceerd kan worden. Het verschijnt nu dus ook niet meer in je logfiles.
Overigens is dit dus symptoom bestrijding en niet oorzaak bestrijding
Verwijderd
Op woensdag 04 april 2001 09:51 schreef wouzer het volgende:
Ja, je moet natuurlijk ook dat if statement 1 regel erboven weghalen, duh!
Verwijderd
/me is nu nieuwsgierig geworden
Hoe heb je het nu eigenlijk, uiteindelijk opgelost?
(ik ben niet nieuwsgierig hoor>:))
Hoe heb je het nu eigenlijk, uiteindelijk opgelost?
(ik ben niet nieuwsgierig hoor>:))
Gewoon dat regeltje toegevoegd ik weet dat het niet de oorzaak is maar het is wel een oplossing. Hier in de buurt hebben veel meer mensen er last van. Het lijkt wel of het aan een van de routers van @home light maar ik weet er te weinig van om dat te zeggen..
Verwijderd
Hmm ik zie nou inderdaad dat er geen accolades omheen staan!
Tja en dat studeert dan technische informatica:P
Tja en dat studeert dan technische informatica:P
Pagina: 1