Toon posts:

[BC3] KERNEL SOURCE AANPASSING

Pagina: 1
Acties:

  • imdos
  • Registratie: Maart 2000
  • Laatst online: 05-08 12:09

imdos

I use FreeNAS and Ubuntu

die printk regel weghalen. Dit is datgene wat gepost wordt.

pvoutput. Waarom makkelijk doen, als het ook moeilijk kan! Every solution has a new problem


Verwijderd

Topicstarter
Dat klopt maar als ik alleen die print regel weg haal dan krijg ik dus die 0 devision regel fout

Verwijderd

Topicstarter
Ja klopt ik gebruik iptables waar zit dan precies de oorzaak en wat is de oplossing. Alvast heel erg bedankt ik zit er al eepaar weken mee en ik probeer het op te losssen zonder succes

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

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

  • wouzer
  • Registratie: Maart 2000
  • Niet online
Ja, je moet natuurlijk ook dat if statement 1 regel erboven weghalen, duh!

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

Topicstarter
Allemaal bedankt voor jullie antwoord ik heb er veel aangehad bedankt :) :)

Verwijderd

/me is nu nieuwsgierig geworden:)

Hoe heb je het nu eigenlijk, uiteindelijk opgelost?

(ik ben niet nieuwsgierig hoor>:))

Verwijderd

Topicstarter
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
Pagina: 1