|
|
|
|
|
|
|
|
|
|
|
|
|
War bestimmt der hier: 
*GIMP schnell beend und renn*
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Cheaterhossie
Deine Routing Tabelle ist in dem Moment einfach futsch bzw. nicht logisch.
| |
Natürlich ist sie das.
Spielen wir das ganze doch mal durch:
| Interface | Mac | IP | Maske | | eth0 | 00:E0:81:28:7E:2F | 192.168.0.1 | 255.255.255.0 | | eth1 | 00:E0:81:1A:C1:02 | 192.168.0.2 | 255.255.255.0 |
Die Routingtabelle enthält damit zwei Einträge:
| Netzadresse | Router | Maske | Interface | Metrik | | 192.168.0.0 | * | 255.255.255.0 | eth0 | 0 | | 192.168.0.0 | * | 255.255.255.0 | eth1 | 0 |
Wenn der Rechner jetzt ein Paket ins Netz 192.168.0.0 verschicken möchte, klappert er die Routingtabelle von oben nach unten ab und wählt den ersten Eintrag der passt, hört dort auf und sendet das Paket (in diesem Fall über eth0). Alles was danach kommt ist schlicht egal und wird garnicht betrachtet.
Wenn die Routingtabelle nun aber unterschiedliche Metriken enthält, also so aussieht:
| Netzadresse | Router | Maske | Interface | Metrik | | 192.168.0.0 | * | 255.255.255.0 | eth0 | 100 | | 192.168.0.0 | * | 255.255.255.0 | eth1 | 0 |
Hier würde das Paket über eth1 rausgehen, da die Route mit niedrigerer Metrik bevorzugt wird.
Aus Sicht des senden Computers ist es also absolut kein Problem. Aus Sicht des Empfangenden Rechner (als des Routers) ergibt sich ebenfalls kein Problem. Da der Rechner zwei verschiedene IPs hat, hat der Router ohnehin zwei unterschiedliche Ziele.
Nehmen wir an ein Paket kommt von aussen wieder rein. Dann schaut der Router in seine NAT-Tabelle und stellt fest "Aha, dieses Paket müsste an IP 192.168.0.2". Dann wirft er einen blick in die ARP-Tabelle, ordnet dem Paket eine MAC-Adresse zu und sucht sich daran das entsprechende Interace heraus, über das das Paket versendet wird.
Es gibt aus Netzwerktechnischer Sicht absolut keinen Grund warum mehrere Interfaces im selben Netz nicht gehen sollten.
|
|
|
|
|
|
|
|
|
|
|
|
hm heute mal schauen ob ich den dvi Ausgang an meinem Macbook zum laufen krieg. Und ob ich damit auf nen Fernseher komme.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Cheaterhossie
Ein PC ist kein Router.
| |
Entschudlige mal...was faselst du eigentlich?
Mal abgesehen davon das die Aussage falsch ist, denn ein PC mit mindestens zwei Interface und einem geeigneten Betriebssystem ist ein Router, hat mein Post rein garnichts mit Router oder nicht Router zu tun. Das ganze ist ein Konzept an das sich Netzwerkfähige Geräte, sofern sie einen halbwegs vollständigen TCP/IP Stack implementieren halten müssen.
|
|
|
|
|
|
|
|
|
|
|
Dann probiers halt einfach aus. 
¤: Und nein, es ist kein Router, weil ein Router zwei Füße in unterschiedlichen Netzen braucht, um als solcher zu gelten. Wenn wir hier schon so genau sind.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Cheaterhossie am 23.07.2008 15:12]
|
|
|
|
|
|
|
|
|
|
sogar mein blödes Win2008 zuhause ist (auf Wunsch) ein Router, sobald die Kiste im Internet eingewählt ist.
|
|
|
|
|
|
|
|
|
|
|
Windoof kann routen? Wieviel Lizenzupgrades brauchts denn dafür? 
|
|
|
|
|
|
|
|
|
|
|
|
die blöde Internetverbindungsfreigabe ist doch nix anderes als ein NAT-Router. Saublöd gemacht und zu doof, auch nur kleinere Portweiterleitungen vernünftig hinzubekommen, aber Router ist Router. Und Server 2008 kann auch richtig routen.
|
|
|
|
|
|
|
|
|
|
|
|
Boaah. Erhelle uns doch bitte einfach jemand mit der Weissheit, wie man zwei NICs unter Linux "Up" bekommt und zwar mit der selben IP im Netzwerk, die dann auch entsprechende funktionieren.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von ./hoschi am 23.07.2008 18:01]
|
|
|
|
|
|
|
|
|
| | Zitat von Achsel-des-Bösen
| | Zitat von Cheaterhossie
Ein PC ist kein Router.
| |
Entschudlige mal...was faselst du eigentlich?
(...)
| |
Gewoehn dich dran.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von ./hoschi
Boaah. Erhelle uns doch bitte einfach jemand mit der Weissheit, wie man zwei NICs unter Linux "Up" bekommt und zwar mit der selben IP im Netzwerk, die dann auch entsprechende funktionieren.
| |
So, jetzt rufst du deine Grundschullehrerin an und bittest sie den ersten Post zu diesem Thema laut vorzulesen.
Acid
|
|
|
|
|
|
|
|
|
|
|
args. xorg.conf gefotzelt und gleichzeitig aus Dummheit die backupdatei geschlissen.
|
|
|
|
|
|
|
|
|
|
| | Zitat von dino the pizzaman
args. xorg.conf gefotzelt und gleichzeitig aus Dummheit die backupdatei geschlissen.
| |
|
|
|
|
|
|
|
|
|
|
|
ich machs ja nur ungern, aber:
| | Zitat von Traxer
wie genau setzte ich eigentlich die priorität eines threads?
ich hab hier pthreads auf nem kernel > 2.6.12
scheduler wird SCHED_OTHER genutzt
pthread_setschedparam gibt nen EINVAL aus, da sched_priority in der struct sched_param bei SCHED_OTHER nur 0 sein darf.
via setpriority gehts nicht, da ich die pid von dem thread nicht kenne und ich momentan wohl irgendwie zu doof bin die zu ermitteln. getpid gibt mir nur die vom master prozess aus, gettid ist nicht verfügbar.
ich will doch eigentlich nur ne simple variante von den Win32 funktionen SetThreadPriority und GetThreadPriority haben...
| |
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Nikro
| | Zitat von dino the pizzaman
args. xorg.conf gefotzelt und gleichzeitig aus Dummheit die backupdatei geschlissen.
| |
| |
jo definitiv. k.a. wo ich mich da vertippt habe. egal. läuft nun wieder.
trotzdem bin ich mit meinem externen Monitor auf hohe Auflösung-Problem noch nicht weiter.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Traxer
via setpriority gehts nicht, da ich die pid von dem thread nicht kenne und ich momentan wohl irgendwie zu doof bin die zu ermitteln. getpid gibt mir nur die vom master prozess aus, gettid ist nicht verfügbar.
| |
gettid() sollte schon die Funktion sein, die du suchst, allerdings musste du direkt den Syscall benutzen, so in etwa:
| |
| Code: |
#define _GNU_SOURCE
#include <unistd.h>
#include <sys/syscall.h>
...
pid_t tid = syscall(SYS_gettid);
|
|
E: Bullshit entfernt
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von [SFoR]-RedEagle am 24.07.2008 0:44]
|
|
|
|
|
|
|
|
|
hm Frage: ich hab den virtual screen nun genug gross (sogar minim zu gross), und mit xrandr krieg ich den Output in gewünschter Auflösung auf den DVI-Ausgang meines notebooks und somit via hdmi auf den TV.
nun verschwindet mir aber dabei die Menüleiste und ein Teil des Desktops... scheint sich wohl irgendwo zwischen Notebook-Bildschirm und TV zu befinden
woran kann das liegen? Scheint irgendwie generell Probleme zu geben wenn die beiden Auflösungen nicht überein stimmen.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von ./hoschi
...mit der selben IP im Netzwerk...
| |
...mit unterschiedlichen.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Pfff... die haben ne andere Seitenzählung!
|
|
|
|
|
|
|
|
|
|
Und ne ordentliche Boardsoftware (wie wir mittlerweile auch?)
Nerden gibts, die gibts gar nicht.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von teK am 24.07.2008 12:45]
|
|
|
|
|
|
|
|
|
| | Zitat von [SFoR]-RedEagle
| |
| Code: |
#define _GNU_SOURCE
|
|
| |
Was macht das?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Cheaterhossie
| | Zitat von [SFoR]-RedEagle
| |
| Code: |
#define _GNU_SOURCE
|
|
| |
Was macht das?
| |
aus "include/features.h"
| |
| Code: |
/* These are defined by the user (or the compiler)
to specify the desired environment:
__STRICT_ANSI__ ISO Standard C.
_ISOC99_SOURCE Extensions to ISO C89 from ISO C99.
_POSIX_SOURCE IEEE Std 1003.1.
_POSIX_C_SOURCE If ==1, like _POSIX_SOURCE; if >=2 add IEEE Std 1003.2;
if >=199309L, add IEEE Std 1003.1b-1993;
if >=199506L, add IEEE Std 1003.1c-1995;
if >=200112L, all of IEEE 1003.1-2004
_XOPEN_SOURCE Includes POSIX and XPG things. Set to 500 if
Single Unix conformance is wanted, to 600 for the
upcoming sixth revision.
_XOPEN_SOURCE_EXTENDED XPG things and X/Open Unix extensions.
_LARGEFILE_SOURCE Some more functions for correct standard I/O.
_LARGEFILE64_SOURCE Additional functionality from LFS for large files.
_FILE_OFFSET_BITS=N Select default filesystem interface.
_BSD_SOURCE ISO C, POSIX, and 4.3BSD things.
_SVID_SOURCE ISO C, POSIX, and SVID things.
_ATFILE_SOURCE Additional *at interfaces.
_GNU_SOURCE All of the above, plus GNU extensions.
|
|
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von klmann am 24.07.2008 15:48]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [SFoR]-RedEagle
| | Zitat von Traxer
via setpriority gehts nicht, da ich die pid von dem thread nicht kenne und ich momentan wohl irgendwie zu doof bin die zu ermitteln. getpid gibt mir nur die vom master prozess aus, gettid ist nicht verfügbar.
| |
gettid() sollte schon die Funktion sein, die du suchst, allerdings musste du direkt den Syscall benutzen, so in etwa:
| |
| Code: |
#define _GNU_SOURCE
#include <unistd.h>
#include <sys/syscall.h>
...
pid_t tid = syscall(SYS_gettid);
|
|
E: Bullshit entfernt
| |
nur um auf nummer sicher zu gehen, wenn ich die tid habe, dann kann ich die so ohne weiteres an setpriority geben und damit die priorität des threads erhöhen bzw. verringern?
das gute pthread_setschedparam funzt ja nicht im SCHED_OTHER modus, zumindest nicht unter linux. unter freebsd gehts und aufm macos muss ichs noch testen.
|
|
|
|
|
|
|
|
|
|
|
Meine drei vom ISP gelieferten DNS-Server liefern alle POOR. Juchu
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Nefkom:
"212.114.152.1 is GOOD: 26 queries in 4.4 seconds from 26 ports with std dev 17710.97"
\o/
Acid
|
|
|
|
|
|
|
|
| Thema: 100 Gute Gründe für Linux - Teil 18 ( sudo chmod 000 /dev/windows ) |
