Posts by ABPSoft

    Quote

    Originally posted by murray73
    3* DVB-C will ich auch haben


    Ich will 4* DVB-C haben, das Gerät kann also nicht beschafft werden, bevor es nicht einen DVB-C-Doppeltuner für diesen Steckplatz gibt. Genau wie bei der 8000 sind festverbaute Sat-Tuner und abweichende Tuner-Specs für jeden Zwangsverkabelten völlig indiskutabel. Wir sind schon genug gestraft, wir müssen nicht auch noch verarscht werden.


    An"wird Zeit für full SAT>IP"dre.

    Quote

    Originally posted by white_raffaelo
    Was ist eigentlich am sinnigsten bzgl. meiner eigebauten 1 TB HDD in meiner 8k ? Aufnahmen sicher, formatieren und in neuer 7080 einbauen oder mitverticken und jungfräuliche HDD in 7080 einbauen?


    1TB ist doch Magerquark. Die Gelegenheit, eine angemessen große Platte mit besseren Parametern einzubauen, würde ich mir nicht entgehen lassen. Die 6TB WD Red ist allerdings ganz schön gefräßig (impliziert warm) und laut, wenn man sie mit der 3TB vergleicht. Preis-Leistungs-Optimum ist momentan wohl die 4TB. XFS drauf, die alten Aufnahmen rüber-rsyncen und fertig.


    HTH,
    Andre.

    Quote

    Originally posted by BartHD
    So sehe ich es auch, dann war es dass wohl vorerst mit DM.


    Wieso nicht "dann war es das wohl vorerst mit Sky"?


    Aber statt den Serviceanbieter, der gerade dabei ist die Daumenschrauben kräftig nachzujustieren, in die Wüste zu jagen wird gegenüber völlig unabhängigen Hardwareanbietern rumgeheult, warum sie nicht endlich einen automatischen Eiswasserspender für besagte Daumen einbauen. Und das, obwohl jeder weiß, dass genau das von besagtem Serviceanbieter als sträfliche Interferenz mit seinem Geschäftsmodell vermittels teurer Anwälte verfolgt und das sofortige Aus für den Hardwareanbieter bedeuten würde.


    Manchmal fragt man sich schon, was da draußen eigentlich abgeht. Wenn Sky (oder welche PayTV-Spacken auch immer, ich schließe speziell HD+ in diesen Kreis ein) sich das nicht leisten könnte, würden sie es nicht tun. Hint, Hint, Hint.


    An"Stell Dir vor es ist Sky und keiner geht hin"dre.

    Quote

    Originally posted by Charly2mal2
    1W = 1VA


    Nicht wirklich. Hint: Wechselstrom. Womit sich die Frage ergibt: Was ist der cos(Phi)? Klingt so, als hätte skywatcher das gemessen und der cos(Phi) ist ca. 0,5...


    Gespannt,
    Andre.

    Quote

    Originally posted by Micha_123
    mal so neben bei gefragt, kommt das oe 2.2 auch auf die anderen boxen ?? oder nur die 7080hd ???


    Die Frage stellt man sich unweigerlich, wenn man das README liest - da klingt es so als wären alle (noch supporteten) Boxen dabei, nur die Images u.U. zu fett für deren Flash. Es gab aber hier schon negative Bescheide dazu von dhwz. Konkret passiert das hier:

    Code
    ERROR: Nothing RPROVIDES 'enigma2' (but meta-opendreambox/recipes-dreambox/packagegroups/packagegroup-opendreambox-enigma2.bb RDEPENDS on or otherwise requires it)
    ERROR: enigma2 was skipped: incompatible with machine dm7020hd (not in COMPATIBLE_MACHINE)


    Hintergrund ist:

    Code
    (wheezy-amd64)me@hopper:.../dreambox/2.2/opendreambox$ grep COMPATIBLE_MACHINE meta-opendreambox/recipes-dreambox/enigma2/enigma2_4.2.0r3-dm7080.bb
    COMPATIBLE_MACHINE = "^(dm7080)$"


    Mit anderen Worten, enigma2 4.2 ist z.Z. nur für die 7080 verfügbar, damit scheitert der Build auf allen anderen Plattformen. Vorläufig keine weiteren Versuche nötig ;)


    HTH,
    Andre.

    Na Hallelujah!


    Die Änderungen im OE2.2 sind ja auch heftiger als man das erwartet hätte. Da bleibt im Plumbing-Layer ja kaum ein Stein auf dem anderen. Dagegen war der Sprung von OE1.6 zu OE2.0 ja bescheiden, da kam im Wesentlichen nur ein neuer Kernel. Es wird spannend, wie schnell man das stabil bekommt, denn einiges ist verflucht frisch vom Feuer (systemd in da house, Wayland statt fb, viel Doku zu entsorgen)...


    Interessante Zeiten,
    An"The DM800HD is dead, Jim."dre.

    Quote

    Originally posted by krusta
    Da die Daten für mich sowieso schon verloren waren habe ich halt einfach wild rumgespielt ohne zu verstehen, was ich denn da mache. ;)


    Das wilde Rumspielen ist an sich keine schlechte Idee, nur sollte man das mit einem Image der Platte machen. Beim Erstellen des besagten Image kriegt man auch sehr schnell mit, ob überhaupt noch was zu erwarten ist: Hier ist ja recht offensichtlich (bereits Dein erster dmesg zeigt das) der Anfang der Platte nicht mehr zu lesen. Da in Block 0 die klassische DOS Partition Table steht, war die weg und damit auch die Partitionierung unbekannt. Alle weiteren Beobachtungen resultieren daraus. Das kann nun bedeuten, dass auch kein anderer Block der Platte mehr zu lesen ist (wahrscheinlich), könnte aber auch nur auf einen Schaden im Außenbereich der Platte zurückgehen (unwahrscheinlich).


    Generelle Vorgehensweise:
    [list=1]
    [*]Image
    Hier besorgt man sich am besten erstmal eine neue (und damit leere) Platte mit mehr als der doppelten Kapazität des Opfers. Braucht man ja am Ende wahrscheinlich sowieso. Nun an einem Linux-Host mit GNU ddrescue und passenden Error Retry Parametern eine Kopie in ein File oder ggf. ein Logical Volume anstarten und am besten erstmal in den Urlaub fahren. Nach Stunden bis Tagen kristallisiert sich heraus, ob überhaupt noch Blöcke zu lesen sind und ob man das irgendwann gnädig beendet oder abwartet. Falls man am Ende mehr als 80% der Blöcke doch noch gelesen kriegt (ich hatte Fälle, wo es nur wenige MB erwischt hat, die aber ewig an ein paar anderen schwachen Blöcken kauten), dann lohnt es sich weiter rumzuspielen. Die nächste Aktion ist, die originale Platte weit weg zu legen, das Image noch mal zur Sicherheit wegzukopieren und dann alle weiteren Schritte nur an dem Image vorzunehmen.
    [*]PTBL Recover
    Da nicht mehr damit zu rechnen ist, die PTBL bei (1) noch gelesen zu kriegen, muss man die als nächstes versuchen selbst wieder herzuzaubern. Oft hilft dabei gpart (Guess Partition Table), aber im vorliegenden trivialen Fall (Sektor 0 tot und auch folgende Blöcke nicht lesbar) kann es passieren, dass das nicht mehr klappt. Also rauskriegen, wie die aussah (andere DB-Besitzer mit ähnlicher Box und Platte fragen) und dann manuell anlegen. Auf dem Image kann man ja schreiben.
    [*]Filesystem recover
    Du bist schon auf dem korrekten Weg, wenn die PTBL wieder steht und in deren ersten Blöcken schon ein Superblock steht, Gratulation. Sonst mit der Suche nach Superblock Backups anfangen. Wie gesagt, wenn >80% der Blöcke noch da sind, stehen die Chancen gut, einen zu finden. Danach das entsprechende fsck (am besten erstmal mit -n zum antesten, dann irgendwann mit -y um das Unvermeidliche hinzunehmen - was weg ist ist weg, die Metadaten müssen wieder begradigt werden). Und dann gucken, was überlebt hat.
    [/list=1]
    Falls man nach Schritt 3 den Eindruck hat, da wäre mehr gegangen, einfach das verhunzte Image wegwerfen, eine neue Arbeitskopie von der bei (1) gezogenen Sicherheitskopie machen und auf ein Neues.


    BTW, wenn man nicht den Eindruck hat, die Platte zerlegt sich zunehmend mechanisch und jeder Leseversuch zehrt an ihr, kann man erstmal ddrescue nach /dev/null fahren, um die Erfolgsaussichten abzuschätzen. Es ist ja nicht unwahrscheinlich, dass das Fehlerbild (Read Errors) sich über die ganze Platte zieht. Wurde ja bisher kaum versucht, da ohne PTBL kein Grund vorlag, mal weiter hinten zu lesen.


    HTH,
    Andre.

    Quote

    Originally posted by Bschaar
    keymapparser.KeymapError: keymap /usr/share/enigma2/keymap.xml not well-formed.
    aber wer weiss welche dateien noch korrupt sind, flashe neu, da bist du sicher


    Gewöhnlich ist das der einzige Fehler und sonst nix korrupt - die keymap.xml wird halt von gewissen Plugins bei jedem Bootvorgang überschrieben und E2 crashed, sobald sie kaputt geht - das macht sie ein speziell empfindliches Instrument zum ertappen von Power-Offs vor einem korrekten FS-Sync.


    Wenn es nicht grade das UBIFS gehimmelt hat (und das passiert ja auf 8000ern soweit bekannt nicht), dann sollte kein Flashen nötig sein, ein schlichtes

    Code
    opkg update && opkg install --force-reinstall enigma2

    sollte es richten. Wenn man das einmal erlebt hat, hat man ein Notfall-Backup der keymap.xml auf dem USB-Stick (enigma2 ist ein großes Paket, das reinstall zieht sich), dann ist der Fix ein schlichtes cp ;)


    HTH,
    Andre.

    Quote

    Originally posted by dreamboxco
    klar das verstehe ich aber ein Image welches im August veröffentlicht wird
    hierzu die Info enigma2 20140616 -> 20140624 passt nicht.


    DMM backt nicht wegen jedem one line bugfix ein neues E2-Release, sondern publiziert die meist erstmal nur im OE2.0 als Patches (wenn es eh im Python glue code oder einer externen Dependancy ist, sonst gänge das nicht). Es lohnt sich daher, alle drei GIT Repos im Blick zu behalten:
    [list=1]
    [*]Enigma2
    Gelegentliche Updates für komplett neue E2-Releases
    [*]OpenDreambox (OE2.0)
    Alle Änderungen am OE2.0 Build, incl. Post-Release-Patches an E2 glue code oder anderen externen Deps. Speziell solche Patches führen dann auch zu Image Rebuilds, weil sie meist ernsthafte Probleme mit dem Release fixen.
    [*]Schwerkraft
    Alle Änderungen an den offiziellen Plugins auf Schwerkraft. Führen selten zu Image Rebuilds, aber es wurde schon gesehen, speziell wenn schwerwiegende Bugs in Plugins durch DMM selbst gefixt wurden. Aber auch da nicht immer.
    [/list=1]
    Diesmal ging es sicher um den mp4 parser bug fix im GStreamer.


    HTH,
    Andre.

    Quote

    Originally posted by mfgeg
    und irgendwas ist bei dir Kaputt oder am Image oder am Feed,
    frag bitte mal Oozoon...


    libevent liegt auf dem Feed, wie man sich mit dem Browser leicht überzeugen kann. Allerdings ist das experimental und Currald referenziert release. Und tatsächlich, hier fehlt sie. Ich glaube, die gründlichste Lösung für das Problem wäre, sich von dem Gedanken zu trennen, mit Release hätte man irgendwelche Stabilitätsvorteile ;)


    Ansonsten halt die aus experimental manuell reinhämmern und den Feed-Bug bei OoZooN reporten, damit er gefixt wird.


    HTH,
    Andre.

    Quote

    Originally posted by kopernikus2005
    Wenn du nur eine Schnellformatierung durchgeführt hast, dann ist in der Regel nur die Baumstruktur bzw. das Inhaltsverzeichnis gelöscht worden und die Filmdateien noch erhalten sind und mit Datenrettung wieder hergestellt werden können.


    Schnellformatierung? Das ist doch dieses Unwort aus der Windows-Ecke, was nix weiter bedeutet, als dass man genau das gleiche macht wie immer (ein neues Filesystem aufbringen), wobei man sich nur den völlig antiquierten kompletten Lesetest spart, den DOS mal in den frühen 80ern einführen zu müssen glaubte (die Qualität der damals in PCs verbauten Platten schien sowas wohl angeraten erscheinen). Der destruktive Impact ist damit identisch.


    Und bei "nur die Baumstruktur bzw. das Inhaltsverzeichnis" musste ich mal kurz innehalten und in den Teppich beißen, bis der Blick langsam wieder tränenfrei wurde. Ein mkfs mit exakt den selben Parametern wie das bereits existierende Filesystem hat die unangenehme Eigenschaft, dass es exakt alle Blöcke überschreibt, in denen die Metadaten des alten Filesystems standen. Jeglicher künstlich etablierter Zusammenhang aller der Milliarden Blöcke, der mal die Files repräsentierte, wurde perfekt weggeputzt. Es ist ungefähr das selbe, wie alle Buchstaben des Herrn der Ringe in die Luft zu werfen, einen großen Haufen zu hinterlassen und sich dann hinzustellen und zu sagen: "Das hier ist der HdR - es sind nur die Metadaten verloren gegangen, aber da ist noch was zu retten". Und wir reden hier von ein paar Größenordnungen mehr an Blöcken, als der HdR Buchstaben hat...


    In einigen speziellen Sonderfällen ist tatsächlich noch was zu retten. Genau dann, wenn das Filesystems ursprünglich nur Files enthielt, die ein inneres Metadatengerüst aufweisen, anhand dessen man sie zweifelsfrei wieder zusammensetzen kann. Bei MPEG2 Transport Streams und den darin multiplexten Elementary Streams stünden diese Chancen besser als bei vielen anderen Formaten - diverse Timestamps zur A-V-Sync etwa, Teletext-Streams mit auswertbaren Metadaten etc könnten Anhaltspunkte sein. Aber wenn in 10GB ex-HD-Aufnahme auch nur ein paar Blöcke nicht automatisch rekonstruierbar sind, dann ist die Aufnahme trotzdem hinüber - im Idealfall hat sie nur Lücken und klötzelt, aber selbst das hat AFAIK noch niemand, dem das beschriebene Malheur wirklich passiert ist, mit irgendeinem Tool erreicht. Für kaputte Speicherkarten mit Fotos hört man gelegentlich Reports zu Teilerfolgen. Aber das hier ist noch mal eine handvoll Größenordnungen mehr an Aufwand.


    Also bitte, ein lakonisches "sind nur die Metadaten weg" hilft niemandem.


    Yapapa: Mit welchem Tool exakt, für welche Filetypen exakt und mit was für konkreten Verlusten hast Du was genau von einer wodurch genau beschädigten Dream-HDD gerettet? Ich bin skeptisch, aber empirisch zu überzeugen. Praktisch jeder Schreib-Schrotschuss auf eine HDD aktuell gängiger Größe ist eigentlich weitgehend harmlos, weil man so fast nie die Metadaten und ihre Schutzmechanismen ausreichend beschädigt bekommt - man trifft üblicherweise ein paar fette Files oder gar den Free Space und bekommt kaum mit, dass was zerlegt wurde. Ein Backup Superblock hilft, wenn der Write mal etwas gezielter auf den Anfang der Platte ging. Aber "Überformatieren" ist anders, weil es fieserweise genau "weiß", wo es hinschreiben muss, um mit wenigen Writes maximales Unheil anzurichten. Ich glaube da nur an Rettungserfolge, die ich selbst gesehen habe - oder zumindest glaubhaft und mit Details belegt dokumentiert wurden.


    HTH anyway,
    Andre.

    Quote

    Originally posted by sin
    Wills ja nicht sagen. :D
    Aber... streamen geht mit abstand am besten mit dem VU+ Player.


    Wobei ich mit VLC auch keine Probleme habe. HD (ÖR, also 720p) stabil auf'm S4 mini. Der Schlüssel zum Erfolg war weniger der Player (MX ging ja wie beschrieben gar nicht mehr, so what, ist runtergeflogen) sondern die Erkenntnis, warum das eigentlich wie blöde stockt und hängt und klötzelt. Es ist das in urbaner Umgebung hoffnungslos zugeschissene^Wkaputtinterferierte 2.4GHz ISM-Band. Den Weg auf 5GHz festgebrummt und plötzlich war alles in Butter (Test lief ca. 4m und eine Wand vom AP entfernt). Ich will es nur erwähnen, weil das u.U. nicht jeder auf dem Plan hat und meistens ja nur kolportiert wird, dass die CPU der mobilen Geräte nicht reicht. Wenn das Netz Dreck ist, gilt halt das alte Mantra: Garbage in --> Garbage out.


    HTH,
    Andre.

    Quote

    Originally posted by rascal1
    Fehlerbeschreibung : Ich habe in der Anzeige der Dreambox beim Start die 192.....21, die ich bei flashen auch anwähle. In der Anzeige des Routers taucht die Dreambox allerdings mit der Endnummer 192......29 auf.


    Könnte sein, dass die das mal als Lease bekommen hat und sich jetzt immer diese Lease wieder holt. Wobei mir neu wäre, dass irgendein Image für die Dream das täte.

    Quote

    Ich habe auch schon eine feste IP eingegeben, leider bleibt es auch dann unverändert.


    Wo?

    Quote

    Hat jemand einen Tipp, was ich tun kann, um wieder eine IP in der Box zu haben?


    Static Lease durch die Fritz vergeben lassen. Also bei der Dream bleibt alles (BIOS und Image) auf DHCP und die Fritz weist der Dream anhand der MAC-Adresse immer die gewünschte IP zu. Einfacher geht's nicht, und eine persistente Wunsch-Lease sollte das auch überschreiben.


    Wenn nicht, dann ändert sich u.U. die MAC Deiner Dream zwischen 2nd stage loader und Image. Das wurde schon beobachtet, ist Anzeichen für einen Defekt und sollte erst verfolgt werden, wenn es nachweislich passiert.


    HTH,
    Andre.

    Quote

    Originally posted by mani0007
    Ich hätt ene frage zu den ntpd Daemon ist der mir rawdcf compiliert???


    Nö. Ich habe keinen großen Sinn darin gesehen, auf der Dream eine Refclock zu betreiben[1], Ziel war eher ein wirklich guter NTP-Sync gegen Server im Heimnetz oder Internet. Der Build erfolgte im Interesse eines kompakten Executables daher mit (die local clock ist da schon ein Zugeständnis an die Tradition, eigentlich bringt die nix):

    Code
    --enable-all-clocks=no --enable-parse-clocks=no --enable-LOCAL-CLOCK


    Quote

    Würde gerne meine Expert mouse clock 2 USB am Receiver betreiben.


    Das ist ein RAWDCF parse driver, also in diesem Paket hier nicht drin. Das BB-Rezept hängt aber an ;)


    Quote

    Bloß der Versuch scheitert kläglich wenn ich den ntpd Daemon installiere und dann die VU+ neustarte startet sie nicht mehr. Ich muss dann das Image komplett neu aufspielen damit es wieder läuft.


    Das Paket ist im DMM OE2.0 gebaut, keine Ahnung was das auf einer VU+ anrichtet, ich kenne da weder das Build Environment noch die letztlich auf der Box landenden Strukturen. Ich hänge mich z.Z. in rcS.d als S42ntpd ein (das ist nach meinem letzten Kenntnisstand etwas straffer als nötig, frühes rc3.d würde auch langen, schaden sollte es aber auch nicht). Das Script könnte den Bootvorgang lange verzögern, falls keiner der Server im ntp.conf erreichbar ist, aber eigentlich sollte es nicht freezen. Um das zu testen, könntest Du direkt nach der Installation des Pakets den S42ntpd in rcS.d entschärfen, so dass es erstmal nicht beim Booten gestartet würde (z.B. umbenennen in _S42ntpd). Dann kann man interaktiv gucken, was das Teil treibt. Ist aber wie gesagt müßig, wenn es um refclocks geht - die sind alle amputiert.


    [1] Argumente: Keine seriellen Schnittstellen, die meisten Refclock-Treiber sind eh nicht an einer STB zu betreiben, die ntpd Exe ist schon ohne Refclocks 371KiB und damit verflucht fett, langsame CPU mit anderen Aufgaben, keine Ahnung wie sehr diverse Modelle driften, die STB ist nicht 24/7 an also taugt sie eh nicht als Refclock, E2 dreht gern selbst mal an der Uhr, etc.


    HTH anyway,
    Andre.

    Quote

    Originally posted by d.e.s.m.o
    Kenn ich irgendwelche Möglichkeiten noch nicht, oder ist das wirklich so umständlich. Gibts Alerantiven?


    Weiß nicht, was Du schon kennst, aber:
    [list=1]
    [*]Ich vermute, niemand benutzt die Standard-Filmliste. Ich hab EMC selbst länger nicht mehr gesehen, die AdvancedMovieSelection (AMS) hat diverse Tagging-Funktionen. Ich nutz aber da auch nur die Filter. Will jedenfalls sagen, mal eine der Komfort-MovieLists ausprobieren.
    [*]Es gibt AutoTimer. Das spart einem nicht nur 90% der repetitiven Tätigkeiten bei Serien, es tagged die auch gleich richtig so dass man die wiederfindet. Ich setz alle Jubeljahre mal 'nen expliziten Aufnahmetimer, den Rest macht hier AutoTimer. Auch mal ausprobieren.
    [/list=1]


    HTH,
    Andre.

    Quote

    Originally posted by Polymorph
    Ein moderner Fernseher zeigt natürlich keine Halbbilder an sondern errechnet sich aus 2 Bildern ein Bild.


    Er berechnet aus zwei Halbbildern (Fields) zwei Bilder (Frames)[1]. Schließlich wollen wir den einzigen Vorteil von 1080i50, die verbesserte temporale Auflösung, nicht gleich wieder wegwerfen. Sonst könnte man ja gleich 1080p25 senden. Was für Spielfilme auch reichen würde, aber das ist halt nicht das einzige im TV.


    [1]Evtl. auch mehr, speziell mit einem dem Display-"Blanking" angepassten Zeitraster. Da gibt's ganz coole Technik, nur leider macht es ein Pawlow-Reflex komplett zunichte (Soap Effekt - es ist nicht Hollywood wenn's nicht ruckelt).


    HTH,
    Andre.

    Hi,


    was eher Kosmetisches: Beim automatischen Abgleich der Picons über FTP werden alle Files sauber übertragen, die auf der Dream als reguläre Files vorliegen. Ich habe allerdings in letzter Zeit diverse neue Picons unter IMO passenderen Namen angelegt und dann nur mittels Symlink auf die nötigen Kanalreferenz-Namen verwiesen. Das verwirrt leider den FTP-Abgleich, konkret bleibt der vor dem Ziel stehen und die Symlinks kommen nicht mit. Ich hätte kein Problem damit, wenn die Files dann einfach doppelt regulär runterfallen würden, keine Ahnung ob Android einer App überhaupt gestattet, mit Symlinks rumzuopern. Ein kleiner Test hat gezeigt, dass der vsftpd auf der Dream bei einem RETR auf einen der Symlinks erwartungsgemäß den Inhalt des verlinkten regulären Files ausliefert, die Serverseite kann daher eigentlich nicht das Problem sein. Mir ist auch klar, dass man eigentlich so wenig wie möglich an einem Output von ls -l rumparsen möchte. Der übrigens im gegebenen Fall so aussieht, womöglich führt da ja schon die ungewohnte RHS ins Verderben:

    Code
    lrwxrwxrwx 1 0 0 27 Jan 19 2014 1_0_1_C3B5_2714_F001_FFFF0000_0_0_0.png -> disney-channel-100060-2.png


    Wenn ich mit einem gewöhnlichen FTP-Client ein mget *.png absetze, klappt dass und alle Files kommen an (regulär halt). Der benutzt offenbar NLST *.png als FTP-Kommando, um an die Liste zu kommen.


    Falls sich das ohne großen Aufwand irgendwann fixen ließe, wäre es toll - bisher kopiere ich die paar Picons halt manuell ;)


    TIA,
    Andre.

    Quote

    Originally posted by skywatcher
    Weil es eigentlich in den Windows Netzwerkeinstellungen die Möglichkeit gibt eine virtuelle Brücke zu erstellen


    Nur kann eine Bridge allein an dieser Stelle nichts ausrichten. Eine STA ist auf L2 mit einer einzigen MAC am AP assoziiert, die Association ist keine self-learning bridge im Sinne von 802.1D und daher kann das nicht funktionieren (weitere MACs hinter der Radio-MAC der STA werden vom AP einfach nicht gelernt, Frames an diese MACs also auch nie über diese Assoc verschickt). Umgehen kann man es entweder auf L3 (dann wird der PC praktisch zum NAT-Router, bei Windows mit ICS wie cmikula hier gebetsmühlenartig empfiehlt) oder durch ein paar kranke Hacks, die eine Art L2-NAT (mit IP-Adressen als Verbindungsdiskriminatoren) implementieren. Sowas nennt sich gern "Client Bridge" und kommt auf diversen Geräten aus der AP-Ecke als Feature mit (oder als explizites Gerät nur zu diesem Zweck, hier im Forum sind ja eine dieser Teile sehr beliebt). Was man nie vergessen darf, ist: Diese Teile sind ein Hack. Selbst wenn sie funktionieren, tun sie das nur rein zufällig für den Großteil von IP (genauer, von IPv4). Kein anderes Protokoll funktioniert, auch nicht IPv6. Viel Spaß damit in der mittelfristigen Zukunft ;)


    HTH,
    Andre.

    Hi,


    die anstehenden Standard-Sprünge dürften am Markt einiges wieder ins Kippeln bringen, was sich die letzten Jahre immer mehr betoniert hatte: Der TV hat alle Tuner eingebaut, externe Boxen sind passe. Jetzt sitzen alle da mit ihren tollen Triple-Tunern, die keinen der neuen Standards beherrschen. Welcome back, STB...


    Nichtproprietäre vorgeschriebene Trennung von Display und Steuerelektronik jetzt ;)


    Andre.