Ich spiele momentan viel mit alternativen Betriebssystemen für die Pandora rum. Um da ein wenig mehr Bandbreite zu haben, war ich auf der Suche nach einem USB to Ethernet Adapter. Und ich habe auch einen schönen gefunden.

Das gute Stück wird bei Amazon als Kensington Mini Dock mit Ethernet (3x USB 2.0) schwarz beworben. Neben einem 100MBit RJ-45 Anschluss besitzt der Adapter noch drei USB 2.0 Ports. Somit hat man zwei Fliegen mit einer Klappe geschlagen.

Das "original" System der Pandora erkennt den Adapter sofort. Man muss nur im Network Manager auf die Verbindung tippen. Plug & Play also. 

In dem Arch Linux Package von wejp wird der Adapter zwar erkannt und in ifconfig aufgelistet, mit wicd versteht er sich allerdings nicht. Da muss man nacharbeiten. Das werde ich die Tage mal versuchen.

Auf jeden Fall kein Fehlkauf und ein super Teil für meine Pandora.

Anstatt Strg+Alt+Entf nutzt man ganz einfach

Strg+Alt+Ende

Schon taucht der entsprechende Dialog nicht mehr auf dem lokalen Desktop, sondern in der Remote Desktop Verbindung auf.

Der NetworkManager, welcher bei der Pandora eingesetzt wird, erlaubt es beim aktivieren eines Netzwerkgeräts Scripte auszuführen. So kann man beispielsweise die Powersafe Funktionen des WLAN Chips automatisch deaktivieren lassen.

Man legt ganz einfach als root ein Script im Ordner /etc/NetworkManager/dispatcher.d/ an:

sudo mousepad /etc/NetworkManager/dispatcher.d/20<meinscriptname>

Nun sollte sich ein Editorfenster mit root Rechten öffnen und man kann hier nun das Template eines dispatcher Scripts dort reinkopieren:

#!/bin/sh

case "$2" in
up)
   if [ "$1" == "wlan0" ]; then
      iwconfig wlan0 power off
   fi
;;

down)
   # ein anderer befehl
;;

*)
   # $2 ist weder up noch down
;;

esac

Das Script führt als beispiels jedes mal wenn WLAN (wlan0) aktiviert wird, den Befehl zum deaktivieren der Power Management Funktionen aus. Man kann an der stelle natürlich auch jeden anderen Befehl ausführen.

Nun muss das Script noch ausführbar gemacht werden:

sudo chown root:root /etc/NetworkManager/dispatcher.d/20<meinscriptname>
sudo chmod u=rwx,go=rx /etc/NetworkManager/dispatcher.d/20<meinscriptname>

Wenn man nun testweise WLAN aktiviert, sollte der Befehl eigentlich ausgeführt werden.
Probiert es mal aus.

Ich wollte schon länger mal wieder mit meinem Nintendo DSi online spielen. Problem ist hierbei noch immer, dass innerhalb von Spielen nur WLAN Verbindungen mit WEP Verschlüsselung benutzt werden können. Ist halt wieder so ein Halbherzig-Problem was bei Nintendo ja dazu gehört...

Meine zweite Dockstar steht via WLAN mit dem Netzwerk verbunden neben meinem PC. Die Idee war nun, eine alte Fritz!Box als WLAN Access Point an den LAN Port der Dockstar zu hängen. Dies hat nach einem bisschen Rumprobieren auch funktioniert. [...] Weiterlesen...

Ich habe hier noch eine alte Fritz!Box WLAN 3030 stehen, welche nun als WLAN Access Point für meinen Nintendo DSi dient.

Problem war nur, dass man in der Box keine erweiterten DNS Server eintragen kann. Sprich wenn die Box nicht als DSL-Modem dient, funktioniert DNS-Technisch garnichts, solange man an den Endgeräten keinen festen DNS Server angibt.

Um genau das zu vermeiden, gibt es einen relativ genialen Weg. Man exportiert die Konfiguration der Fritz!Box. Die daraus resultierende Textdatei kann man ganz einfach bearbeiten.

servercfg {
        hostname = "(none)";
        dns1 = 192.168.1.1;
        dns2 = 192.168.1.1;
}

Versucht man nun die Datei wieder zu importieren, wird die Box sagen, dass dies keine gültige Konfiguration ist. Dies kann mit dem Hinzufügen folgender Zeile an den Anfang der Konfigurationsdatei umgangen werden:

NoChecks=yes

Nach dem erfolgreichen Import der Konfiguration wird die Fritz!Box neu starten. War der Import erfolgreich, befindet sich nun folgender Hinweis auf der Startseite der WebGUI:

In Ihrer FRITZ!Box wurden vom Hersteller nicht unterstützte Änderungen durchgeführt.

Nun sollte das Anfragen von DNS Servern funktionieren.
Have fun.

Meine Dockstar hat gestern Debian Squeeze und einen WLAN Stick von AVM spendiert bekommen.

Die Treiber für den Fritz!WLAN USB Stick N 2.4 gibt es in den non-free Repos von Debian.

aptitude update
aptitude install firmware-atheros wireless-tools wpasupplicant
modprobe -r ar9170usb ; modprobe ar9170usb

Eine genau Anleitung gibt es im Wiki von Debian. Wenn der WLAN Stick richtig erkannt wurde, kann nun das Interface in /etc/network/interfaces konfiguriert werden.

auto  wlan0
allow-hotplug wlan0
iface wlan0 inet static
  address   192.168.1.3
  broadcast 192.168.1.255
  netmask   255.255.255.0
  gateway   192.168.1.1
  hostname wirelessstar
  wpa-ssid MyWlanHotSpot
  wpa-psk xxxxxxxxxxxxxxxxxxxxxxxx

Nachdem man mit ifdown und ifup das Netzwerkinterface neu gestartet hat, sollte man das LAN Kabel abziehen können.

http://wiki.debian.org/WiFi/HowToUse
http://wiki.debian.org/ar9170usb#Squeeze

Die Freeagent Dockstar von Seagate scheint auf dem ersten Blick eine 0815 Dockingstation für 2,5" Platten zu sein. Allerdings kann das Teil wesentlich mehr. Mit ein paar Handgriffen kann man aus der Dockstar einen Mini-Server mit Debian als Betriebssystem machen.

Nach Hause telefonieren

Im Auslieferungszustand hat die Dockstar mehr Nach- als Vorteile. Das System kann nur über den Onlinedienst von Pogoplug konfiguriert werden. Es wird also zwingend eine Internetverbindung voraus gesetzt. Alle Services die Zugang zu den Daten ermöglichen sind zu Anfang deaktiviert. Es gibt zwar einen Service der auf Port 80 lauscht, aber der gibt keine Antwort.

Allerdings läuft auf der Dockstar auch ein SSH Server bei dem es einige Hacker geschafft haben das Root Passwort herauszufinden. Man kann sich also als root mit dem Passwort stxadmin einloggen.

Ein weiteres Problem: Das Teil telefoniert natürlich nach Hause, damit der Pogoplug Dienst funktionieren kann. Verbindet sich die Dockstar das erste mal mit dem Internet wird ein Firmwareupdate durchgeführt und das root Passwort geändert. Als alternatives Root Passwort könnte dann noch ceadmin funktionieren.

Um die Call-Home Funktion zu deaktivieren, [...] Weiterlesen...

 Als Entwicklungsumgebung dient mir für PHP, MySQL usw ein Debian Squeeze als VirtualBox VM. Um nicht für jedes Projekt einen Eintrag in die /etc/hosts der "echten" Maschine machen zu müssen, ist auf der VM auch ein bind9 als Nameserver installiert. Der wird als Primary DNS in der "echten" Maschine eingetragen.

Nun habe ich meine "echte" Maschine auf Ubuntu 10.04 umgestellt. Danach ging auf einmal die Auflösung meiner Domain dev.local nicht mehr. Abfragen mit nslookup, host und dig verliefen korrekt. Das echte Nutzen der Domain funktionierte jedoch nicht.

Problem war hierbei der Zeroconf Daemon Avahi, der bei Ubuntu mitgeliefert wird. Nutzt man Avahi, ist es nicht möglich eine local-TLD für den normalen Netzwerkbetrieb zu verwenden. Auf meinem Arch Linux war kein Avahi installiert. Also gab es hier auch keine Probleme.

Habe nun einfach dev.local in dev.lokal umbenannt. Schon geht es wieder.

Vielen Dank an das Unixboard, die hier mal wieder erfolgreich geholfen haben.

Nmap kann auch Serverdienste Identifizieren, wenn diese nicht auf Standard Ports laufen. Sogar Versionsnummern und das genaue Betriebssystem kommt dabei zum Vorschein.

Beispiel eines Windows Server 2003 Systems:

nmap windows.local -PN -A -T4

Starting Nmap 5.21 ( http://nmap.org ) at 2010-04-28 10:19 CEST
Nmap scan report for windows.local (172.16.1.92)
Host is up (0.0045s latency).
Not shown: 991 closed ports
PORT     STATE SERVICE       VERSION
80/tcp   open  http          Microsoft IIS webserver 6.0
|_html-title: Sie haben nicht die erforderliche Berechtigung, um die Seite a...
| http-auth: HTTP Service requires authentication
|   Auth type: Negotiate
|_  Auth type: NTLM
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds  Microsoft Windows 2003 or 2008 microsoft-ds
1025/tcp open  msrpc         Microsoft Windows RPC
1311/tcp open  ssl/rxmon?
3306/tcp open  mysql         MySQL 5.1.40-community
| mysql-info: Protocol: 10
| Version: 5.1.40-community
| Thread ID: 3
| Some Capabilities: Long Passwords, Connect with DB, Compress, ODBC,
| Transactions, Secure Connection
| Status: Autocommit
|_Salt: CRR$YubihM,1R(q!L=-f
3389/tcp open  microsoft-rdp Microsoft Terminal Service
8000/tcp open  http-alt?
Service Info: OS: Windows

Host script results:
|_nbstat: NetBIOS name: WINDOWS, NetBIOS user: <unknown>, 
| NetBIOS MAC: 00:0f:1f:fa:4d:b7
|_smbv2-enabled: Server doesn't support SMBv2 protocol
| smb-os-discovery:  
|   OS: Windows Server 2003 R2 3790 Service Pack 2 (Windows Server 2003 R2 5.2)
|   Name: DOMAIN\WINDOWS
|_  System time: 2010-04-28 10:19:54 UTC+2

Service detection performed. Please report any incorrect 
results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 56.29 seconds

Beispiel eines Linux Systems:

nmap localhost -A -T4

Starting Nmap 5.21 ( http://nmap.org ) at 2010-04-28 10:33 CEST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00092s latency).
Hostname localhost resolves to 2 IPs. Only scanned 127.0.0.1
rDNS record for 127.0.0.1: localhost.localdomain
Not shown: 995 closed ports
PORT      STATE SERVICE     VERSION
22/tcp    open  ssh         OpenSSH 5.4 (protocol 2.0)
| ssh-hostkey: 1024 ae:34:4c:ad:00:95:ee:8c:fb:c8:00:44:bc:af:f5:9e (DSA)
|_2048 dc:59:ac:b1:c6:87:28:2b:b5:83:dc:e5:0d:94:b4:9f (RSA)
111/tcp   open  rpcbind
| rpcinfo:  
| 100000  2,3,4    111/udp  rpcbind  
| 100000  2,3,4    111/tcp  rpcbind  
|_391002  2        704/tcp  sgi_fam  
139/tcp   open  netbios-ssn Samba smbd 3.X (workgroup: BLECHNET)
445/tcp   open  netbios-ssn Samba smbd 3.X (workgroup: BLECHNET)
55555/tcp open  http-proxy  Squid webproxy 2.7.STABLE3
| http-open-proxy: Potentially OPEN proxy.
|_Methods supported:  GET HEAD

Host script results:
|_nbstat: NetBIOS name: LINUX, NetBIOS user: <unknown>, NetBIOS MAC: <unknown>
|_smbv2-enabled: Server doesn't support SMBv2 protocol
| smb-os-discovery:  
|   OS: Unix (Samba 3.5.2)
|   Name: Unknown\Unknown
|_  System time: 2010-04-28 10:33:29 UTC+2

Service detection performed. Please report any incorrect 
results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 21.46 seconds

Schon krass was man da so alles über Server heraus finden kann.

Hatten wir glaube ich schon einmal hier in einem User Kommentar, aber ich poste das noch mal als kleines Memo für mich und vielleicht für den einen oder anderen Besucher.

Einfacher Verbindungsaufbau:

ssh sim4000@example.com -L 55555:192.168.1.1:3306 -N

Verbindungsaufbau mit Key und anderem SSH Port:

ssh sim4000@example.com -p 1234 -i .ssh/key -L 55555:192.168.1.1:3306 -N

Das Beispiel zeigt, wie man via SSH einen Tunnel zu einem anderen Server aufbaut. Über diesen Tunnel kann man eine Verbindung zu einem Dienst aufbauen, der sonst nur in einem anderen Netz erreichbar ist.

In dem Beispiel oben würde ein Verbindungsaufbau mit einem MySQL Client zu localhost:55555 im Netz von example.com auf dem Rechner 192.168.1.1 rauskommen. Man hat also Verbindung zu einem Serverdienst, der sonst nur im lokalen Netz von example.com erreichbar wäre.

Nebeneffekt dabei ist, dass die Verbindung vom eigenen Rechner bis ins fremde Netzwerk komplett verschlüsselt ist. Hat zum Beispiel in öffentlichen WLAN Netzen enorme Vorteile.

Was die einzelnen Parameter bedeuten, kann man in »man ssh« nachlesen.