FreeBSD 5.3: Sammlung der Änderungen bezgl. Netzwerk

asg

asg

push it, don´t hype
Andre Oppermann hat für die Sucon 04 eine Präsentation ausgearbeitet die die Änderungen unter FreeBSD 5.3 bezüglich Netzwerk kurz beschreibt:
http://people.freebsd.org/~andre/FreeBSD-5.3-Networking.pdf
Interessant ist sicher die volle Integration von "PF" (CARP wird noch folgen) und das ein Netzwerkdevice nun einen frei bestimmbaren Namen bekommen kann (statt "xl0" kann man diesem dann "OFFICE" oder anderes geben).

Hier noch der Post auf der FreeBSD Mailingliste mit folgendem Auszug:
Code: 
PS: Linux guys where pretty much floored that FreeBSD 5.3 can route 1Mpps and
they can't do much more than 100kpps. ;-)  Yes, way to go!
Nachzulesen unter:
http://lists.freebsd.org/pipermail/freebsd-net/2004-September/004840.html

Andre Oppermanns Seite unter freebsd.org:
http://people.freebsd.org/~andre/
 
"... I think there have been some good developments in both dfly and fbsd, but the lack of a tride and true maintainer for ULE and various IPI and ACPI issues have really made 5.3 and -current a pain in the butt. Also - re@ is apparently discussing the future of ULE as a default (IOW, maybe switching back to 4BSD as the default). We'll see!"

Stand als Kommentar unter der Meldung bei OSNEWS.COM. Lassen sich die Aussagen über ULE in der Mailingliste nachvollziehen oder ist die Problemschilderung frei erfunden?
 
Ehhh.... installier dir doch einfach mal -CURRENT.

Achja, Viel Glueck! :)

Aber Spass beiseite, -CURRENT ist im Moment ein Scherbenhaufen. RELENG_5 haette erst in einem Monat abgezweigt werden duerfen. Mich wundert auch, das HEAD nicht fuer min. zwei Wochen eingefroren wurde, bevor der Branch gemacht wurde.

Schoene Scheisse.
 
Z.B. geht das mit dem NDIS-Wrapper so wie darin beschrieben bei mir mal gar nicht. Er kennt die Option "NDIS" nicht mal... allerdings auch seit ein paar Tagen kein cvsup mehr laufen lassen.

Und wieso sind Optionen wie random ip und fastforward nicht per default aktiviert? Die erstere ist doch zumindest schon lange im Betrieb und sollte daher gut getestet sein... komisch.

Gruß, I.MC
 
snoopy schrieb:
Lassen sich die Aussagen über ULE in der Mailingliste nachvollziehen oder ist die Problemschilderung frei erfunden?
Zum Vergrößern anklicken....
Sie lassen sich insofern nachvollziehen, als das der ursprüngliche Committer von ULE anscheinend nicht auf der mailingliste ist und auf Anfragen zu ULE nicht antwortet.
 
I.MC schrieb:
Z.B. geht das mit dem NDIS-Wrapper so wie darin beschrieben bei mir mal gar nicht. Er kennt die Option "NDIS" nicht mal... allerdings auch seit ein paar Tagen kein cvsup mehr laufen lassen.
Zum Vergrößern anklicken....

Fuer 5.2.1 musst du manuell die ndis-Sourcen ziehen. In HEAD ist NDIS schon seit Monaten. Der Fehler liegt also mal wieder vorm Monitor (Ich weiss auch nicht, was du mit "Option NDIS" meinst...)
Und wieso sind Optionen wie random ip und fastforward nicht per default aktiviert? Die erstere ist doch zumindest schon lange im Betrieb und sollte daher gut getestet sein... komisch.
Zum Vergrößern anklicken....

RADNOM_IP_ID war noch nie im GENERIC aktviert und deshalb nicht Standard. Denn zum einen benoetigt sie einiges an zusaetzlicher Rechenkapazitaet und zum anderen ist der Nutzen eh zweifelhaft.

Und ueberhaupt, du kennst POLA?
 
MrFixit schrieb:
Fuer 5.2.1 musst du manuell die ndis-Sourcen ziehen. In HEAD ist NDIS schon seit Monaten. Der Fehler liegt also mal wieder vorm Monitor (Ich weiss auch nicht, was du mit "Option NDIS" meinst...)
Zum Vergrößern anklicken....
Schon klar, aber ich habe 5.3 und bin einfach mal so vorgegangen wie es in dem Pdf beschrieben wird. Dort ist die Rede von "options NDIS". Die kennt mein System aber nicht.
RADNOM_IP_ID war noch nie im GENERIC aktviert und deshalb nicht Standard.
Zum Vergrößern anklicken....
Na das ist wohl keine Begründung :-)
Denn zum einen benoetigt sie einiges an zusaetzlicher Rechenkapazitaet und zum anderen ist der Nutzen eh zweifelhaft.
Zum Vergrößern anklicken....
Also ich finde das nicht so zweifelhaft, wenn es damit möglich ist besser zu verbergen wieviele Rechner hinter dem NAT sind, dann ist das doch eine feine Sache. Wenn das deutlich mehr CPU braucht, ok, das ist ein Argument. Ich frage mich aber um wieviel Last sicht das unterscheidet...

Und ueberhaupt, du kennst POLA?
Zum Vergrößern anklicken....
Nein, klär mich auf.

Gruß, I.MC
 
current schrieb:
Sie lassen sich insofern nachvollziehen, als das der ursprüngliche Committer von ULE anscheinend nicht auf der mailingliste ist und auf Anfragen zu ULE nicht antwortet.
Zum Vergrößern anklicken....

Also gibt es doch einen Maintainer für ULE? Ich fand die Zeilen spannend, wo doch ULE nunmehr die Standardeinstellung in 5.3 wird (ist).
 
snoopy schrieb:
Also gibt es doch einen Maintainer für ULE? Ich fand die Zeilen spannend, wo doch ULE nunmehr die Standardeinstellung in 5.3 wird (ist).
Zum Vergrößern anklicken....
Jetzt hast du mich verwirrt - mit welchem Bestandteil des obigen Satzes habe ich dich auf die Idee gebracht, dass es einen Maintainer von ULE gibt?
 
current schrieb:
Jetzt hast du mich verwirrt - mit welchem Bestandteil des obigen Satzes habe ich dich auf die Idee gebracht, dass es einen Maintainer von ULE gibt?
Zum Vergrößern anklicken....

Du hast mich nicht auf die Idee gebracht. Mein erster Satz war eine Frage.

Du sagtest dass der commiter für ULE nicht auf der Mailingliste auftaucht. In meinem Zitat steht, dass ULE keinen echten Maintainer hat. Daraufhin meine Frage, ob es nun einen Maintainer für ULE gibt bzw. ob die Aussage aus dem Zitat so stimmt.

Habe ich zur Enwirrung beigetragen? ;)
 
I.MC schrieb:
Also ich finde das nicht so zweifelhaft, wenn es damit möglich ist besser zu verbergen wieviele Rechner hinter dem NAT sind, dann ist das doch eine feine Sache.
Zum Vergrößern anklicken....

Was genau soll das bringen? Mehr Sicherheit? Lol
Verwenden denn _alle_ Hosts hinterm NAT zufallsgenerierte IPIDs? Selbst wenn, kann man sehr wohl herausfinden, ob es da mehrere Rechner hinter der IP gibt, oder nur einen.

Zumal scheint mir fuer dein Vorhaben pf mit scrubbing, reassembling und normalization um einiges besser geeignet. Aber selbst dann ist das nichts weiter als security through obscurity.
 
MrFixit schrieb:
Was genau soll das bringen? Mehr Sicherheit? Lol
Verwenden denn _alle_ Hosts hinterm NAT zufallsgenerierte IPIDs?
Zum Vergrößern anklicken....
Gegenfrage, verschlechtert es die Sicherheit wenn alle Rechner zufällige IPDSs nutzen? Es spricht nichts dagegen, nur dafür.

Selbst wenn, kann man sehr wohl herausfinden, ob es da mehrere Rechner hinter der IP gibt, oder nur einen.
Zum Vergrößern anklicken....
Sag mal wie, interessiert mich (jetzt ernsthaft)!

Zumal scheint mir fuer dein Vorhaben pf mit scrubbing, reassembling und normalization um einiges besser geeignet. Aber selbst dann ist das nichts weiter als security through obscurity.
Zum Vergrößern anklicken....
Das habe ich auch nicht bestritten. Ob das jetzt "Sicherheit" durch ungewöhnliches Vorgehen ist, kann man sich jetzt drüber streiten. Sicher, das hindert keinen am evtl. Einbrechen. Es verhindert nur dieses Art des Aushängeschildes.

Gruß, I.MC
 
Ach Kinners, ist das denn so schwer? Kennt ihr Passive OS Fingerprinting?

Was ist, wenn von einer IP drei Verbindungen zu login.icq.com bestehen? An den User-Agents der http-request kann man das auch recht einfach ablesen, etc. pp.
 
Hmm, so hab ich mir das nicht vorgestellt. z.B. gehen von meinem einen Rechner immer mindestens zwei Verbindungen zu login.icq.com (bzw. dahin wo manhin weitergeleitet wird). Ist ja schliesslich ein Multiuser OS. Es ging hier aber um mehrere Rechner!
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben