Thin Client Siemens Futro S550 im Einsatz als günstiger Offloader


#245

pcie geht ned…


#246

Du benötigst eine 32Bit PCI Karte mit 5V.


#247

Was ist eigentlich aus den Versuchen (siehe oben im Thread) geworden, es mit PCI-X zu probieren?


#248

Was soll das bringen?


#249

Durch die Nachrüstung eines zweiten Laninterfaces beseitigt man das Problem GBit-Switches/Router zu Trennen der VLANs zu beschaffen.


#250

Schon klar. Ich hab die FAQ geschrieben schon vergessen :wink:

Ich meine was soll eine große PCI-X Karte in einem System bringen, das für 32Bit LP PCI Karten ausgelegt ist? Hat ds irgendeinen Vorteil gegenüber einer klassischen 0815 NIC?


#251

Deine ausgewählte Riser Card sieht recht kurz aus. Nimm lieber ebay Artikel 311038228927 . Ich betreibe die zusammen mit einer Broadcom Dual-Port 1-Gigabit PCI-X 31P6409 und es passt perfekt. Du könntest auch diese Karte probieren, sieht genauso aus wie meine. EBay 131632051722. Gruß Christian


#252

Den Preis. Teilweise für 3,5€ plus Versand. Und wenn man dann 10 Stück nimmt und es Kombiversand gibt.


#253

Das kam jetzt 10min zu spät, Bestellung ist gerade raus. Aber die von mir verlinkten und jetzt gekauften betreibt @Pelle schon erfolgreich mit dem Futro:


#254

Naja, vielleicht konnte ich Dir wenigstens mit der günstigen Dualport Gigabit Karte helfen, wenn sie Dir jetzt kein anderer wegschnappt… @Andi


#255

Hab mich schon für diese hier entschieden - das ist aktuell die günstigste Gigabit-Single-Port-Karte auf ebay. Aber danke trotzdem für deine Hilfe :slight_smile:


#256

hm… das vlan theater kann man sich doch imho sparen indem man einfach MoW macht und bei den Knoten dann mesh-vpn deaktiviert?


#257

Bitte mal detailliert beschreiben!

Bisher fallen mir dazu ohne VLAN keine Lösungen ein, bei denen nicht das private LAN mit FF Paketen überschwemmt wird.


#258

Naja zB einfach nen separaten Switch an den Gästeport eines Routers, und da dann den Offloader + Meshnodes ran…


#259

Du musst dann einen Openwrt-Router als Nat-Kaskade davorhängen, der den Batman-Brpadcaststurm zuverlässig abhält.
Also mal eine Natfirewall mit umgekehrter Hauptkampfrichtung: WAN vor LAN schützen.


#260

Hast du das mal getestet oder ist das nur eine “normalerweile sollte das gehen …” Vermutung?

Ja sowas hatte ich auch im Sin, aber @mephisto’s Antwort klang eher nach … ein par Klicks und dann gehts…

@mephisto
Nicht falsch verstehen, ich bin für alles offen, was Dinge einfacher macht und vor allem kostengünstiger ist. … Wobei Switch vs. Raiser+PCI NIC … das tut sich auch nicht viel. Wobei man natürlich auch die LAN Ports eine FF Routers zum Switch ummogeln könnte.


#261

Jo, da funktioniert so. Man könnte es auch direkt an nem normalen LAN Port machen, dann sehen die ports, die nichts mit mesh zu tun haben halt auch die batmanpakete, funktionieren tut das auch. Um das die LAN Ports nicht damit zu fluten halt über den Gästeport. Ist halt ganz normales mesh-on-wan…


#262

Tut, also, zumindest werden beide Ports der PCI-X-Karte erkannt:

[quote=“wusel, post:236, topic:7711”]
immerhin, beide zusätzlichen Ethernetports werden erkannt, wenngleich IIRC PCI schon mit 1x GBit/sec an die Leistungsgrenzen kommt?[/quote]

Lasttests o. ä. habe ich damit noch nicht gefahren, das Kistchen soll den Dockstar im Keller ersetzen, der bei ~20 MBit/sec OpenVPN-Traffic deckelt – das reichte für VDSL 25/2,5, das saugt dann für VDSL 100/40 :wink:

Was die Risers & LP-Karten angeht: das ist mehr so im Bereich »paßt, wackelt nicht, ist aber auf Zug«:

Im Millimeterbereich könnte es noch nach oben gehen, das wäre fein. Aber die LP-Karten laufen (RTL-8139/8139C/8139C+), und mehr als 100 MBit/sec machen bei ~80 MBit/sec fastd-Performance ja auch nicht sonderlich viel Sinn :wink:

Die verlinkte HP 395863-001 wäre natürlich auch schick (und zudem Faktor 4 billiger bei Faktor 10 mehr Bandbreite), aber sie hat kein LP-Slotblech und während ich eine Karte ohne in meinem Keller verbauen kann (s. o.), finde ich das für Geräte “draußen” nicht akzeptabel.

Letzlich scheint mir das alles mit L2TP statt fastd aber eh’ obsolet?


#263

Nur dort, wo man der Community den Verzicht auf Verschlüsselung auf dem VPN-tunnel zumuten kann.
(Geht bei vielen kommunalen Projekten nicht, da dort andere Zusicherungen gemacht wurden und niemand das Fass wieder aufmachen möchte, wenn die Zustimmung zu Freifunk einmal gegeben wurde. Aber das gehört woanders hin)


#264

Die Kernel config änderungen sind jetzt upstream.

https://dev.openwrt.org/changeset/47304/trunk

Spricht aus meiner Sicht also nichts dagegen das jetzt in Gluon auch so zu handhaben.