Maximale Größe von tables mit pf

ieee

ieee
Weiß jemand zufällig, ob es für pf unter Open-/FreeBSD eine maximale Tabellengröße gibt? Eine meiner spammers-Tables beinhaltet mehrere tausend IP-Adressen und ist ca. 700 KByte groß - ist das eventuell zu viel? Die Internetverbindung wird nach ca. 1 Stunde einfach unterbrochen, vielleicht hängt's ja mit der Table zusammen.
 
ieee said:
Weiß jemand zufällig, ob es für pf unter Open-/FreeBSD eine maximale Tabellengröße gibt? Eine meiner spammers-Tables beinhaltet mehrere tausend IP-Adressen und ist ca. 700 KByte groß - ist das eventuell zu viel? Die Internetverbindung wird nach ca. 1 Stunde einfach unterbrochen, vielleicht hängt's ja mit der Table zusammen.

Die maximale Größe der States kannst du ja selbst bestimmen. Schaue dir mal die Manpage zu pf.conf an.

Da hast du die jeweiligen Optionen für die Umgebungswerte.

Die Tabellen selbst können tausende von IPs/Netzen/sonstwas beinhalten, ohne dass die Maschine deswegen aus der Puste kommt.

Du hast, nehme ich an, die aktuell laufenden States gemeint, denn es gibt an sich keine Grenze für die Menge der Einträge in der Tabelle. Bis auf die physikalische, versteht sich (sprich: deine RAM-Größe).

Hier ein Beispiel für das Setzen der jeweiligen Werte:

set limit { states 20000, frags 20000, src-nodes 2000 }
 
CW said:
Hier ein Beispiel für das Setzen der jeweiligen Werte:

set limit { states 20000, frags 20000, src-nodes 2000 }

Hm, die src-nodes kann ich in meiner pf.conf nicht setzen, ich bekomme die Fehlermeldung pfctl: DIOCSETLIMIT: Invalid Argument beim Laden der Regeln mit dem Befehl pfctl -f /etc/pf/pf.conf. Muss wohl am Quelltext von pfctl.c liegen:
Code:
pfctl_set_limit(struct pfctl *pf, const char *opt, unsigned int limit)
{
	struct pfioc_limit pl;
	int i;

	if ((loadopt & (PFCTL_FLAG_OPTION | PFCTL_FLAG_ALL)) == 0)
		return (0);

	memset(&pl, 0, sizeof(pl));
	for (i = 0; pf_limits[i].name; i++) {
		if (strcasecmp(opt, pf_limits[i].name) == 0) {
			pl.index = i;
			pl.limit = limit;
			if ((pf->opts & PF_OPT_NOACTION) == 0) {
				if (ioctl(pf->dev, DIOCSETLIMIT, &pl)) {
					if (errno == EBUSY) {
						warnx("Current pool "
						    "size exceeds requested "
						    "hard limit");
						return (1);
					} else
						err(1, "DIOCSETLIMIT");
				}
			}
			break;
		}
	}
Aber was hat das konkret zu bedeuten? Habe auch kein manpages zu pool, fehlt auf meinem Rechner irgendein Programm?

Noch was: Nach einer gewissen Zeit (30 - 60 Minuten) geht der Rechner einfach offline, wie bereits beschrieben, er kann dann auf einen ping hin keine Namen mehr auflösen, pinge ich eine numerische IP-Adresse an, kommt die Fehlermeldung ping: sendto: No buffer space available. Wenn ich dann einfach so ca. 15 Minuten warte und nichts tue, funktioniert es wieder normal, bis dann nach einer gewissen Zeit wieder die Internetverbindung unterbrochen wird.

Shit, ich kriege hier noch die Krise!
 
Last edited:
Ich fahre ein FreeBSD-5.3-RELEASE/i386. Habe hier im OpenBSD-Unterforum gepostet, weil ich dachte, es liegt primär an pf - na ja, war vielleicht ein Fehler (eventuell sollte man den Thread verschieben), liegt möglicherweise gar nicht an pf, sondern an irgendetwas anderem. Jetzt habe ich schon die ganze Nacht herumgewurschtelt und sogar die Netzwerkkarten umgesteckt, es hilft alles nichts!

Was bedeutet bloß die Fehlermeldung mit dem No buffer space available? Läuft da irgendein Speicher voll? Ich hab keine Ahnung von den theoretischen Hintergründen mit ppp und dergleichen.

:huth:

EDIT:
Außerdem kommen während des Bootvorgangs zwei merkwürdige Fehlermeldungen (die Kiste hat eine AVM-Fritz-Karte):
Code:
Copyright (c) 1992-2004 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD 5.3-RELEASE #0: Sun Nov 14 23:15:05 CET 2004
    root@beatnix.lan:/usr/obj/usr/src/sys/BEATNIX
.
.
.
[b]WARNING: debug.mpsafenet forced to 0 as i4b_ipr requires Giant
WARNING: MPSAFE network stack disabled, expect reduced performance.[/b]
.
.
.
i4b: ISDN call control device attached
i4btel: 2 ISDN telephony interface device(s) attached
i4btrc: 4 ISDN trace device(s) attached
i4bipr: 4 IP over raw HDLC ISDN device(s) attached (VJ header compression)
i4bctl: ISDN system control port attached
i4brbch: 4 raw B channel access device(s) attached
i4bisppp: 4 ISDN SyncPPP device(s) attached
pflog0: promiscuous mode enabled
[b]i4b-L3 T303_timeout: SETUP not answered, cr = 79
i4b-L3 next_l3state: FSM illegal state, state = ST_U0 - Null, event = EV_T303EXP - T303 timeout![/b]
Was besagt dieser MPSAFE network stack und warum gibt es jedesmal beim Hochfahren einen i4b-L3 T303_timeout?
 
Last edited:
Aua, au, au, au. ieee: Das war ein klasisches Eigentor, bitte für Dich und alle anderen: Niemals, niemals wieder so etwas machen!

ieee, so leid es mir für Dich tut, die Regeln des Ordens verlangen es: :huth: :huth: :huth:

@CW: bitte tief durchatmen, ruhig bleiben, erstmal 2 Valium einwerfen und bitte thread sofort nach FreeBSD verschieben.

//ich denke ob und wann cw den thread verschiebt entscheidet er selbst ;) -kith

Ich hab schon viel in diesem Forum erlebt, aber das ist wirklich hart ;'( ;'( ;'(
 
Last edited by a moderator:
Ist mir schon klar, drei Hüte sind noch viel zu wenige für mich! Damned, ich bin hart genug bestraft, ISDN scheint kaputt zu sein unter v5.3, das bedeutet, wieder zurück zu v4.10. Ich dachte wirklich, es liegt an pf, an zu restriktiven Regeln, hab' mich halt heftig verhauen. Kloppt meinen Thread in die Mülltonne oder, wenn ihr Erbarmen habt, an die richtige Stelle unter FreeBSD.
 
Mann, Mann ... und ich dache, es gäbe da Probleme im Source-Code.

Hm, aber den _/\_ kriegst du nicht ... das war nicht miserabel genug. ;)

Und bedanken kannst du dich bei Daniel, denn ich war gerade dabei, meine Zähne auszufahren. :D

Grüße
 
Meinen Dank an CW! :)

Nun, warum ISDN in v5.3 kaputt ist? Hunderprozentig wissen tue ich es nicht, aber die Fehlermeldungen lassen diese Schlussfolgerung vermuten. Auf den diversen Mailinglisten habe ich derweil ähnliche Fehlermeldungen zur Kenntnis genommen und es scheint z. Zt. keine Abhilfe in Sicht zu sein. Das Problem ist offensichtlich seit den jüngsten Veränderung im SMP-Code entstanden. Unter massiver Last bricht ISDN einfach zusammen. So ist es z. B. nicht möglich, über längere Zeit mehrere Downloads gleichzeitig zu tätigen, vielleicht ist es aber auch ein Problem mit ppp. Diese Fehlermeldung mit dem MPSAFENET gibt mir Rätsel auf, eine Anpassung der /boot/loader.conf brachte keine Besserung. Ich mache die Kiste platt und bügle wieder 4.10 drauf - nur Schade ist's um pf - hatte mich gerade daran gewöhnt! ;'(
 
Hab die Kiste doch noch nicht plattgemacht und einige Stunden lang in diversen Mailinglisten herumgestöbert und einen Workaround gefunden: options INET6 raus und options VFS_AIO rein in den Kernel, dazu debug.mpsafenet="0" rein in die /boot/loader.conf. Fragt mich nicht nach den Hintergründen dafür, habe zu wenig Sachverstand über ppp und die Kernel-Interna, ich wende diesen Tip ganz einfach nur als Kochrezept an, ohne zu wissen, weswegen es funktioniert. Gegenwärtig scheinen sehr viele Netzwerkinterfaces (eben auch meine ifpi0) ohne GIANT LOCK nicht zu funktionieren, deshalb dieser Workaround. Für v5.4-RELEASE ist u. a. folgendes angekündigt:


"Currently, some network interface drivers are not safe without the Giant lock due to missing synchronization. These drivers are protected by running non-INTR_MPSAFE and with the IFF_NEEDSGIANT flag set, which cause interrupt threads to acquire the Giant lock before executing the driver's interrupt handler, and to perform if_start (interface transmit start) asynchronously once the Giant lock can be acquired. This results in these drivers performing less well due to increased lock contention, decreased ability to preempt, and latency associated with asynchronous launching of latency-critical events. For 5.4, all network drivers should be able to operate without the Giant lock."



Jedenfalls läufts jetzt, die Verbindung steht jetzt ununterbrochen seit etwa 14 Stunden.
 
Back
Top