Ich schließe mich hier eigentlich an, fehlende GBit-LAN-Schnittstelle schliesst eine vernünftige NAS-Nutzung normalerweise schon aus, vom der fehlenden SATA-Port ganz zu schweigen. Macht Deine SynNAS definitiv besser (habe ich auch im Einsatz, macht sogar für den RPI iSCSI-Target, aber 100Mbit/s LAN...naja geht so lala). Und die SynNAS hat ja auch ssh-Zugang und man könnte durchaus mit entsprechenden Developer-Tools das eine oder andere auf die SynNAS "hinkompilieren"...hab ich auch schon drüber nachgedacht. Aber den RPI "vergewaltige" ich dafür sicher nicht... 
Gibts den RPI vielleicht mal mit USB3 oder USB-C könnte man das schon neu bewerten...aber das ist derzeit wohl Zukunftsmusik und der sprichwörtliche "Blick in die Glaskugel" ...
Posts by dg2dra
-
-
Das lag aber eher daran, dass der Raspberry Pi Model B Rev.1 und 2 ein arges Problem mit einer etwas unterdimensionalen Spannungsregelung und einem heißen USB/LAN-Chip hatte. Durch die Kühlung des Spannungsreglers konnte man tatsächlich einiges gutmachen.ja, Spannungsregler sind so ne Sache...wenn ich mir das so auf einigen PC-Mainboards ansehe, was dort so getrieben wird oder besser nicht getrieben wird, kann man nur mit dem Kopf schütteln. Aber der Hersteller hat eben ein paar Cent bei den Materialkosten eingespart. Wobei ich aber den RPI (2) schon ganz solide konstruiert einschätzen würde und in der aktuellen Revision 2 wohl thermisch kaum mit Problemen zu rechnen sein dürfte, auch ohne (passive oder gar aktive) Kühlung.
-
nach meinen technischen Verständnis der Materie sollte eine Temperatur bis 70°C keine nennenswerten Probleme entstehen lassen (soo empfindlich sind Chips nicht wie man vielleicht meinen mag), ab 85°C regelt er den Takt automatisch runter wenn ich mich recht erinnere.
Also um die paar Grad zu diskutieren, die ein Kühlkörper zur Absenkung ggf. bringt, ist eigentlich keinen Gedanken wert, da schliesse ich mich einigen Vorrednern zu 100% an, das sich das nicht lohnt, wenn nicht sogar sinnfrei ist, von aktiver Kühlung mit Lüfter ganz zu schweigen (bei der Idee musste ich wirklich lauthals lachen, am besten noch ne Heatpipe um ja die ganze Hitze sauber aus dem Gehäuse rauszubekommen ). Aber jedem Tierchen sein Pläsierchen...;) -
Ich habe das Update auf Kernel v4 gemacht und kann bis jetzt keine Probleme auf meinem System feststellen. Händisch in den Kernel implementierte Treiber/Kernelmodule müssen ggf. auf den 4er angepasst werden und/oder mittels Sourcen dann ein eigener Kernel gebaut werden. Wie gesagt, bei mir (2x RPI 2) läuft soweit auch alles auf dem v4 und die Logs zeigen auch derzeit nichts auffälliges was auf den Kernel zurückzuführen wäre. Die Entscheidung muss wohl jeder selbst treffen, allerdings sollte man schon ein gewisses Maß an Kenntnissen um Linux herum mitbringen, um ggf. sich selbst zu helfen wissen, falls etwas nicht so geht wie man es erwartet hat (und es möglicherweise auf den Kernel v4 zurückzuführen wäre). Wie andere schon sagten, ein gewisses Risiko ist bei unstable immer mit bei.
-
Display More
Hallo zusammen,ich habe das jetzt mal so gemacht
Codenene, nicht deinstallieren. Ich meinte so: update-rc.d dhcpcd removefalls ichs wieder brauche dann wieder aktivieren.
Wenn ich den Dienst nun wieder aktiviere, bekomme ich folgende Meldung
Codesudo update-rc.d dhcpcd enable update-rc.d: using dependency based boot sequencing update-rc.d: error: no runlevel symlinks to modify, aborting!und nach einem Neustart wird dhcpd auch nicht mehr gestartet. Wie kann man das wieder fixen?
Danke und Gruss
sorry, war ein paar Tage anderweitig beschäftigt...
mach mal:
sudo update-rc.d dhcpcd defaults
sollte den funktionsfähigen Zustand erst mal grundsätzlich wieder herstellen.
Letztlich sind es alles nur Symb-Links nach /etc/init.d , wobei SXX die Reihenfolge steuert beim Boot wann welcher daemon/service gestartet wird und KXX macht das gleiche beim shutdown.
Definiert wird das runlevel in /etc/inittab , schau mal dort. Die Kommentare erklären das ganz gut.ansonsten guck mal hier http://www.debuntu.org/how-to-managin…th-update-rc-d/ falls Du die run-level anpassen musst.
Ich habe keinen Bedarf am dhcpcd, da ich nur statische IPs nutze, deswegen ist der bei mir rausgeflogen. Und das die Netzwerkkonfig im X11 nicht geht, kann ich mit leben. Das war schon bei Ubuntu mit dem network-manager ein Käse...ich nutze Linux genau nicht um wie bei WIN klicki-klicki machen zu können
Deswegen werde ich wohl über kurz oder lang den ganzen X11-Kram vollständig entfernen, the console-shell is the one and only .Gruss Heiko
-
Ich würde mich erst mal damit beschäftigen, ob _Google_ solche Automatismen überhaupt gestattet. Wenn nicht, was ich denke, wird wohl jeder die Finger davon lassen, sowas umzusetzen. Schule, Google...und das alles automatisch...dafür würde ich als Elternteil den Info-Lehrer ordentlich "rund" machen, da kannste sicher sein.
-
ohne es mit Sicherheit sagen zu können: ich hatte ähnliche Probleme mit einer 32 GB SD von Trancend. Dann habe ich ne SANDISK genommen und Problem war erledigt.
Fakt ist aber, dass die Transcend in meinem iMac 100% korrekt arbeitet, nur am RPI2 nicht, hingegeben die SANDISK schon.
Klingt alles nicht logisch, ich weiß, aber teste mal ne andere SD.
Gruß Heiko
-
Hier mal ne kurze Anleitung zum Einsatz des hostapd als Accesspoint. Gedacht ist diese Anleitung NICHT als Router, sondern als einfache WLAN-Brücke ins vorhandene Netzwerk, eben als reiner Accesspoint. Grundlegende Netzwerkdienste wie Router oder DHCP-Server werden also als bereits vorhanden vorausgesetzt, auch wird ein Mindestmaß an Basiswissen im Umgang mit Linux vorausgesetzt.
Wer sich auf Shell-Ebene etwas Komfort verschaffen will, installiert sich am besten den Midnight Commander mittels "sudo apt-get install mc", der auch mit "mc" gestartet wird. Die ältere Generation mit DOS-Kenntnissen wird eine gewisse Ähnlichkeit mit dem damaligen legendären Norton Commander erkennen können
Wem das ständige "sudo" etwas nervt, kann sich mit "sudo -s" eine Root-Shell verschaffen, normalerweise erkennbar am "#" am Eingabeprompt.
Zuerst wird eine sog. Bridge erzeugt aus dem Ethernet-Interface eth0 und dem WLAN, hier wlan0.
Mein Beispiel basiert auf einem lokalen Netzwerk, Raspberry Pi 2 mit statischer IP, Router ist Fritzbox.
Als WLAN-Stick habe ich einen Logilink WL0084B v.2.0 verwendet, gibts z.B. bei CONRAD für aktuell 6,99 Ocken.
Die IP-Adressen sind logischerweise an Euer vorhandenes Netzwerk entsprechend anzupassen !1. Dazu ist die /etc/network/interfaces wie folgt anzupassen:
---SCHNIPP---
auto lo
iface lo inet loopbackauto eth0
allow-hotplug eth0
iface eth0 inet manualauto wlan0
allow-hotplug wlan0
iface wlan0 inet manualauto br0
iface br0 inet static
# statische IPv4-Adresse außerhalb DHCP-Bereich
address 192.168.253.222
netmask 255.255.255.0
# Gateway ist IP der Fritzbox
gateway 192.168.253.1
# wir brücken eth0 und wlan0, also zum durchreichen des Netzwerkverkehrs aufs Ethernet
bridge_ports eth0 wlan0
# set bridge forward delay to time seconds
bridge_fd 0
# turn spanning tree protocol on/off
bridge_stp no
# IPv6 hätten wir auch noch gern, hier aber ohne statische IP
iface br0 inet6 autodns-nameservers 192.168.253.1
dns-search fritz.box
---SCHNAPP---sollte br0 nicht erzeugt werden können, bitte mit "sudo apt-get install bridge-utils" das notwendige Paket nachinstallieren.
2. hostapd sollte bereits vorhanden/installiert sein. Ich habe den allerdings aus den Sourcen selbst kompiliert (aktuell Version 2.4, siehe hier https://w1.fi/hostapd/ ).
Jetzt muss die /etc/hostapd/hostapd.conf angepasst werden:---SCHNIPP---
# Basic configuration 802.11b/g/n with WPA2-PSK and CCMP
interface=wlan0
# SSID ist das, was als WLAn-Netzwerk angezeigt werden soll
ssid=HotspotRPI
channel=7
ctrl_interface=/var/run/hostapd
bridge=br0
# WPA and/oder WPA2 configuration
# keine Limitierung auf MAC-Adressebene
macaddr_acl=0
# WPA only, WEP off
auth_algs=1
ignore_broadcast_ssid=0
# WPA2 only
wpa=2
wpa_passphrase=DeinWLANKeynachWahl
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP
rsn_pairwise=CCMP
wpa_group_rekey=600
wpa_ptk_rekey=600
wpa_gmk_rekey=86400
eapol_key_index_workaround=0
eap_server=0
# Hardware configuration, DOKU zum hostapd LESEN und auf eingesetzte Hardware anpassen !
driver=nl80211
ieee80211n=1
# <g> simply means 2.4GHz, <a> simply means 5 Ghz
hw_mode=g
# Definition Land, hier Deutschland Kanal 1-13 möglich
country_code=DE
# limit the frequencies used to those allowed in the country
ieee80211d=1
rts_threshold=2347
fragm_threshold=2346
dtim_period=2
beacon_int=100
---SCHNAPP---Jetzt noch starten mit "sudo service hostapd start" oder "sudo /etc/init.d/hostapd start" und fertig ist der WLAN-Accesspoint mit dem Raspberry PI.
Wer mal so testen will, wie schnell so das WLAN wirklich ist, den empfehle ich das Tool iperf3 ( https://github.com/esnet/iperf ) zu installieren, was es (allerdings kostenpflichtig) auch für iPhone/iPad gibt, und somit direkte Durchsatzmessungen auf TCP- und UDP-Ebene zwischen WLAN-Client und dem Raspberry ermöglicht. Nur Messen ist aussagekräftig, schwammiges wie "es geht langsam" kann nicht als Grundlage zur Fehlersuche dienen, denn evtl. ist es ja gar nicht das WLAN allein. Nicht vergessen: mehrere Clients am Accesspoint senken auch den Durchsatz, denn wir haben nur 1x WLAN-Bandbreite in Summe verfügbar !
Ich schaffe mit diesem low-cost-USB-WLAN-Stick durchschnittlich 27-30 Mbit/s effektiv, meine Fritzbox liefert auf 2,4 GHz etwa 37-41 Mbit/s, ist also ein wenig schneller, sie hat aber auch (ist ne 7490) MIMO, sollte also etwas mehr liefern. Aber was der Stick liefert, ist akzeptabel.
Mit diesem EDIMAX-Dingens habe ich übrigens nur 13-17 Mbit/s hinbekommen, trotz aller "Tuning-Versuche". Immer alles gemessen mit meinem iPhone 6 in ca. 2m Entfernung von den Geräten, um eine identische Vergleichsbasis zu haben.Hier noch was allgemeines zum WLAN. Angaben wie 150Mbit/s oder 300Mbit/s auf den Verpackungen der Sticks geben immer die sog. Nettodatenrate an und das noch unter idealen Bedingungen, die fast nirgends in der Realität existieren. Das ist nicht(!) das, was an Daten/per TCP/IP-Protokoll wirklich fliesst. Zieht von den Nettoraten mindestens 50% ab, denn das wird für die Übertragung selbst und Fehlerkorrektur zur sicheren und korrekten Übertragung des WLAN-Datenstroms benötigt und hängt leider von weiteren Bedingungen ab. Es bedeutet nicht, das man mit einem WLAN-N 150 Stick auch 150 MBit/s an Daten zwischen A und B übertragen bekommt. Ich will jetzt hier nicht alle Spezifika solch einer Funkübertragung darlegen, nur so als Faustformel zum Wissen. Meine Messungen sind natürlich Bruttodatenraten, also das was wirklich per TCP/IP übertragen wurde.
Das bedeutet aber auch, dass ich an z.B. einem VDSL2-Anschluß mit 50Mbit/s oder mehr auf 2,4GHz generell schon an Grenzen stosse, und hier eigentlich ac-WLAN auf 5 GHz fast zwingend ist, um die z.B. 50MBit/s brutto auch per WLAN transportieren zu können. "Langsam" könnte also einfach auch nur aufgrund technischer Grenzen sichtbar sein.
Wer auch speziell diesen USB-WLAN-Stick einsetzt, kann noch etwas "tunen", indem er in die /etc/hostapd/hostapd.conf folgende Zeilen hinten anfügt (entsprechende Infos gibts in der Doku zum hostapd):
---SCHNIPP---
# sonstiges
ht_capab=[GF][HT40+][HT40-][SHORT-GI-20][SHORT-GI-40][RX-STBC1][MAX-AMSDU-3839]
wmm_enabled=1
wmm_ac_be_aifs=3
wmm_ac_be_cwmin=4
wmm_ac_be_cwmax=10
wmm_ac_be_txop_limit=0
wmm_ac_be_acm=0
---SCHNAPP---Das wars dann auch schon, happy WiFi.
Gruss Heiko
-
Danke für deine Antwort.
Mir ging es einfach um das Prinzip
Trotzdem: Wieso nicht?weil Du a) für Frequenznutzung eine behördliche Zulassung benötigst und b) für die Nutzung nicht wenig Gebühren dafür hinlegen müsstest, denn Frequenzbereiche werden nicht "verschenkt"
wo und welche Frequenzen für was genutzt werden dürfen, steht im sog. nationalen Frequenznutzungsplan und regelt die Nutzungsfestlegungen von 9 khz bis 275 GHz, Infos dazu findest Du bei der Bundesnetzagentur, kurz BNetzA genannt. Siehe hier: https://de.wikipedia.org/wiki/Frequenznutzungsplan
Es ist wie mit dem Autofahren, es ist keine Frage ob Du Auto fahren KANNST, sondern ob Du es DARFST. Letzteres ist eben an einen Führersschein gebunden, also die quasi behördliche Genehmigung dazu. Und außerdem ist ein LTE-Sender etwas technisch aufwändiger als Dein Smartphone oder LTE-Stick, was LTE als Endgerät nutzt.
Und bei Deiner "Idee" ist es eben genauso. Das trifft im Normalfall auf ALLE Frequenzen zu, bis auf die welche von dem jeweiligen Staat zur Allgemeinnutzung freigegeben sind (wie z.B. die 2,4 und 5 GHz-WLAN-Bereiche). Das ist im übrigen weltweit so, wäre auch schlimm, wenn jeder senden könnte wo und was er wollte. Geht eben nicht.
-
Ich habe den Logilink hier http://www.conrad.de/ce/de/product/…L0084B?ref=list
von CONRAD, war quasi Plug'n'Play, Treiber sind schon dabei. Ist nicht viel größer wie der EDIMAX, macht aber kein Stress mit dem originalen hostapd (habe ich in der aktuellen Version 2.4 aus den Sourcen selbst kompiliert, da die vom Debian älter war, siehe hier: https://w1.fi/hostapd/ ).
Tut als AP was er soll, Speed ist auch soweit ok. Habe den hostapd als WLAN-Ethernet-Bridge laufen. -
Nachdem ich nun fast alles am laufen habe, hier mal so kurz meine Empfehlungen zu den Überlegungen, fertige Pakete oder selbst compilieren.
Proxy-Server squid 3.4.x: Habe ich aus den Sourcen selbst kompiliert, da das fertige Paket schon erheblich älter ist als die aktuellen Sourcen und manches nicht mitcompiliert wurde.
Also hier besser Sourcen holen und selbst machen, wie man's braucht. Squid brauche ich als noncaching-Proxy um den Nachwuchs mittels eigenen ACLs in Sachen Internetnutzung etwas auszubremsen, sonst rückt die Schule zu weit in den Hintergrund.HostAPd: auch älter, Probleme mit dem empfohlenen EDIMAX-WLAN-Stick (wieso der dann empfohlen wird erschliesst sich mir nicht ganz). Ich habe mich für den Logilink WL0084B Rev. 2.0 entschieden, der ist unwesentlich länger als der EDIMAX und geht auch nach dem Anstecken (basiert auf ralink-chipset). Gabs bei CONRAD für 6,99€ das ist ok. Vor allen Dingen konnte ich den hostapd in der aktuellen Version 2.4 aus den Sourcen compilieren, und der AP-Mode ging ohne Rumbastelei. Bei mir konfiguriert als Bridge ins LAN (also eth0 und wlan0 als Brücke br0). Funktioniert tadellos und stabil, muss nur die mobilen Devices versorgen, mein iMac und MacbookPro haben 5 GHz ac-WLAN only über einen Airport bzw. Fritzbox 7490, weil ich im LAN größere Datenvolumen bewegen muss.
Lighttpd: der Einfachheit halber aus den fertigen Paketen installiert, reicht aus und läuft. Noch eigene X509-Zertifikate mit meiner eignenen PKI/CA erstellt, SSL dann auch funktionsbereit.
webalizer: Nutze ich als "Kontrolle" vom squid um meinen Nachwuch etwas auf die Finger zu schauen, auch hier fertiges Paket genutzt.
Shairport: gibts nach meiner Kenntnis nur als Sourcen und macht bei mir AirPlay-Gateway Audio für die iPads und iPhones zur Soundanlage. Also selber erstellt.
Mein Einsatzzweck ist den PI als Netzwerk-Managment-Server mitlaufen zu lassen, es ist ein PI der Rev.B (also Quad-ARMv7, 1GB RAM und ich habe eine 32GB mSD von Sandisk drin). Zusätzlich noch einen SITECOM USB-LAN 10/100MBit-Adapter LN-030v2 als eth1 für Firewallzwecke. Das alles headless, also ohne Monitor, Maus, Tastatur, Zugriff per SSH reicht aus, keine grafische Umgebung, Textmode only, halt als low-energy-miniserver.
Was der kleine PI so leisten kann, ist schon beeindruckend, Gigabit-LAN und USB3 wären noch die optimale Ergänzung, aber vielleicht gibts das ja in der Zukunft mal...
Man sollte sich schon etwas fortgeschritten mit Linux auskennen, dann kann man den Kleinen schon gut trimmen, allerdings finde ich die Aktualität der Archive nicht ganz so optimal, hier machen andere bessere Pflege wie z.B. ubuntu (was ja mehr oder weniger auch auf debian basiert).
Alles in allem hat mich das etwa 3 Tage gekostet, dann lief alles was ich wollte.
Gruss Heiko
-
Das ist das Tool zur grafischen Einstellung des WLanJa, die Info hatte ich nun auch gefunden.
Trotzdem vielen Dank für die "Denkanstösse". Was jetzt so geht mit der Kiste seit Rev. B ...viele Ideen... z.B. Squid compilieren dauerte nur noch ca. 30min, das ist schon ein sehr guter Wert, da ziehen die 4 Kerne und 1 GB RAM bei 900 MHz schon ordentlich los. Fehlt nur noch Gigabit-Ethernet und USB3 und dann wäre das die perfekte Kiste, SATA muss nicht unbedingt sein.
Gruss Heiko
-
Das neue raspberrypi-net-mods benötigt das Paket. Du kennst Dich mit Linux ja aus, für alle anderen es ist manchmal besser, nicht alles in einem Schub zu deinstallieren, weil es zwischen verschiedenen Paketen auch mehrfache Abhängigkeiten geben kann. Also wenn, dann erst raspberrypi-net-mods rausnehmen und danach dhcpcd.Codeapt-get purge raspberrypi-net-mods apt-get purge dhcpcdBei der Nutzung von purge fliegen auch gleich alle Konfigurationsdateien mit raus.
nene, nicht deinstallieren. Ich meinte so:
update-rc.d dhcpcd removefalls ichs wieder brauche dann wieder aktivieren. Hab ich jetzt erst mal so gemacht. Btw, was machen die raspberrypi-net-mods eigentlich ?
Ah, ich sehe grade irgendwas mit der X11-WLAN-Konfig...DAS brauche ich gar nicht, denn mein PI ist Server (hostapd, squid, Airplay für iOS, httpd) also das alles "headless", wollte ich urspünglich mit meiner Synology machen, aber zu schlechte Umgebung. Und jetzt, mit dem PI Vers. B 4Kerner und 1GB RAM geht schon was los auf der kleinen Schachtel. Feine Hardware.Gruss Heiko
-
Dazu fällt mir spontan das hier ein
Frei übersetzt:Es existieren also die Einstellungen von dhcpcd und interfaces nebeneinander. dhcpcd nimmt, da nichts weiter eingetragen ist Standardwerte.
Ja, soweit alles klar, mir fehlte der Aufhänger (und das trotz 20 Jahren Linux-Erfahrung...es ist eben so mit dem Wald und den Bäumen...).
Aber kann ich den dhcpcd nicht ganz abschalten/lahmlegen ? Wofür brauche ich den überhaupt ?
Zumal ich ja statische IPs (kann ich auch bei IPv6 umstellen) benutze, und für den Rest ja eh mein DHCP-Server (v4 und v6) vom WIN2012er DomainController zuständig ist und der PI nix per DHCP beziehen muss.Es ist ja nicht so, dass ich keine Linux-Umgebung sonst noch so in Betrieb habe, aber bei den bisherigen Installationen (debian und ubuntu-server) hatte ich das Problem überhaupt nicht, deswegen war ich so verwundert.
Gruss Heiko
-
Ihr seid schon auf der richtigen Fährte, allerdings habe ich hier noch keinen Hinweis auf die dhcpcd.conf gesehen. Schaut euch mal die man pages dazu an, dann sollte Euch die Erleuchtung kommen, wo die 2. IP-Adresse herkommen könnte. http://roy.marples.name/man/html5/dhcpcd.conf.htmlEs ist die originale (unveränderte) dhcpcd.conf:
# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel# Inform the DHCP server of our hostname for DDNS.
hostname# Use the hardware address of the interface for the Client ID.
#clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
duid# Persist interface configuration when dhcpcd exits.
persistent# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Most distributions have NTP support.
option ntp_servers
# Respect the network MTU.
# Some interface drivers reset when changing the MTU so disabled by default.
#option interface_mtu# A ServerID is required by RFC2131.
require dhcp_server_identifier# Generate Stable Private IPv6 Addresses instead of hardware based ones
slaac private# A hook script is provided to lookup the hostname if not set by the DHCP
# server, but it should not be run by default.
nohook lookup-hostname -
Display More
Siehe z. B. die Ausgabe von:
Codehostname -I ip a ip neigh showroot@PI:/home/pi# hostname -I
169.254.180.17 169.254.207.139 192.168.254.5 192.168.254.47 2001:4dd0:ff00:9218:d236:79d:321d:2f5a 2001:4dd0:ff00:9218:a047:d2a2:57fc:34d2root@PI:/home/pi# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP qlen 1000
link/ether b8:27:eb:53:2d:df brd ff:ff:ff:ff:ff:ff
inet 169.254.180.17/16 brd 169.254.255.255 scope global eth0
valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP qlen 1000
link/ether 7c:dd:90:79:e1:67 brd ff:ff:ff:ff:ff:ff
inet 169.254.207.139/16 brd 169.254.255.255 scope global wlan0
valid_lft forever preferred_lft forever
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 7c:dd:90:79:e1:67 brd ff:ff:ff:ff:ff:ff
inet 192.168.254.5/24 brd 192.168.254.255 scope global br0
valid_lft forever preferred_lft forever
inet 192.168.254.47/24 brd 192.168.254.255 scope global secondary br0
valid_lft forever preferred_lft forever
inet6 2001:4dd0:ff00:9218:d236:79d:321d:2f5a/128 scope global dynamic
valid_lft 6581sec preferred_lft 2981sec
inet6 2001:4dd0:ff00:9218:a047:d2a2:57fc:34d2/64 scope global dynamic
valid_lft 6870sec preferred_lft 3270sec
inet6 fe80::ba27:ebff:fe53:2ddf/64 scope link
valid_lft forever preferred_lft foreverroot@PI:/home/pi# ip neigh show
2001:4dd0:ff00:9218:1cb3:90a8:2602:b725 dev br0 lladdr 5c:f5:da:1f:ad:a9 STALE
fe80::a96:d7ff:fee3:32c8 dev br0 lladdr 08:96:d7:e3:32:c8 router STALE
2001:4dd0:ff00:9218:cae0:ebff:fe3e:d645 dev br0 lladdr c8:e0:eb:3e:d6:45 STALE
192.168.254.36 dev br0 FAILED
192.168.254.1 dev br0 lladdr 08:96:d7:e3:32:c8 REACHABLE
192.168.254.32 dev br0 lladdr c8:e0:eb:3e:d6:45 STALEWie ist die Ausgabe von:
Codesudo netstat -tulpen sudo service dhcpcd statusroot@PI:/home/pi# service dhcpcd status
[ ok ] dhcpcd is running.root@PI:/home/pi# netstat -tulpen
Aktive Internetverbindungen (Nur Server)
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 0 5892 3034/lighttpd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 9475 2934/sshd
tcp 0 0 127.0.0.1:3350 0.0.0.0:* LISTEN 0 8473 2320/xrdp-sesman
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 0 9514 3020/exim4
tcp 0 0 0.0.0.0:3389 0.0.0.0:* LISTEN 108 9440 2297/xrdp
tcp6 0 0 :::80 :::* LISTEN 0 5893 3034/lighttpd
tcp6 0 0 :::21 :::* LISTEN 111 8859 3061/proftpd: (acce
tcp6 0 0 :::22 :::* LISTEN 0 9477 2934/sshd
tcp6 0 0 :::3128 :::* LISTEN 0 10601 2964/(squid-1)
tcp6 0 0 ::1:25 :::* LISTEN 0 9515 3020/exim4
udp 0 0 0.0.0.0:68 0.0.0.0:* 0 10490 3132/dhcpcd
udp 0 0 0.0.0.0:57442 0.0.0.0:* 103 15695 3680/avahi-daemon:
udp 0 0 192.168.254.47:123 0.0.0.0:* 104 5994 2490/ntpd
udp 0 0 169.254.207.139:123 0.0.0.0:* 104 5993 2490/ntpd
udp 0 0 169.254.180.17:123 0.0.0.0:* 104 5992 2490/ntpd
udp 0 0 192.168.254.5:123 0.0.0.0:* 0 5717 2490/ntpd
udp 0 0 127.0.0.1:123 0.0.0.0:* 0 5716 2490/ntpd
udp 0 0 0.0.0.0:123 0.0.0.0:* 0 5709 2490/ntpd
udp 0 0 0.0.0.0:40092 0.0.0.0:* 0 10541 2897/snmpd
udp 0 0 192.168.254.5:161 0.0.0.0:* 0 10546 2897/snmpd
udp 0 0 127.0.0.1:161 0.0.0.0:* 0 10544 2897/snmpd
udp 0 0 0.0.0.0:5353 0.0.0.0:* 103 15693 3680/avahi-daemon:
udp6 0 0 :::546 :::* 0 10401 3132/dhcpcd
udp6 0 0 2001:4dd0:ff00:9218:123 :::* 104 5912 2490/ntpd
udp6 0 0 2001:4dd0:ff00:9218:123 :::* 104 5911 2490/ntpd
udp6 0 0 fe80::ba27:ebff:fe5:123 :::* 0 5719 2490/ntpd
udp6 0 0 ::1:123 :::* 0 5718 2490/ntpd
udp6 0 0 :::123 :::* 0 5710 2490/ntpd
udp6 0 0 :::5353 :::* 103 15694 3680/avahi-daemon:
udp6 0 0 :::45349 :::* 103 15696 3680/avahi-daemon:?
Du könntest deinen Router z. B. so konfigurieren, dass dein PI, auch per dhcp vom Router eine statische (d. h. eine feste) IPv4-Adresse bekommt, dann könntest Du auf die Eintragungen zu eth0 in der interfaces-Datei, verzichten bzw. für eth0 die interfaces-Datei nicht nutzen.EDIT:
Poste mal auch die Ausgabe von:
Codeapt-cache policy raspberrypi-net-mods
root@PI:/home/pi# apt-cache policy raspberrypi-net-mods
raspberrypi-net-mods:
Installiert: 1.0-1
Installationskandidat: 1.0-1
Versionstabelle:
*** 1.0-1 0
500 http://archive.raspberrypi.org/debian/ wheezy/main armhf Packages
100 /var/lib/dpkg/statusInzwischen habe ich den hostapd (Bridge-Mode) noch installiert
hier /etc/network/interfacesroot@PI:/home/pi# cat /etc/network/interfaces
auto lo
iface lo inet loopbackauto eth0
allow-hotplug eth0
iface eth0 inet manual
# iface eth0 inet static
# address 192.168.254.5
# netmask 255.255.255.0
# gateway 192.168.254.1
# dns-nameservers 192.168.254.1
# iface eth0 inet6 autoauto wlan0
allow-hotplug wlan0
iface wlan0 inet manual
# wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
#iface wlan0 inet static
# address 192.168.0.1
# netmask 255.255.255.0auto br0
iface br0 inet static
address 192.168.254.5
netmask 255.255.255.0
gateway 192.168.254.1
dns-nameservers 192.168.254.1
bridge_ports eth0 wlan0
bridge_fd 0
bridge_stp no
iface br0 inet6 autoSiehe auch diese Threads:
Ich guck dort mal...oder es ist der ntpd ?!?
Gruss Heiko
-
Hallo RPI-Fans,
ich habe einen RPI2 und folgendes Problem:
Trotz in der /etc/network/interfaces eingetragenen statischen IPv4 (DHCP dort logischerweise aus) holt sich mein RPI2 _zusätzlich_ noch eine 2. IPv4 per DHCP vom Router.
Komisch ist, er zeigt das mit ifconfig nicht an, ABER diese IP ist pingbar und lt arp-Abfrage auch dem RPI2 zugewiesen (gleiche MAC wie eth0).Hat dieses Problem auch jemand oder ist das schon mal jemanden aufgefallen ??
Ich habe ja den avahi-daemon stark in Verdacht...
/etc/network/interfaces:
auto lo
iface lo inet loopback
auto eth0
allow-hotplug eth0
# iface eth0 inet manual
iface eth0 inet static
address 192.168.254.5
netmask 255.255.255.0
gateway 192.168.254.1
dns-nameservers 192.168.254.1
iface eth0 inet6 Auto
Auszug aus /var/log/daemon.log (DHCP IPv6 ist gewollt)Jun 9 17:05:16 PI dhcpcd[2043]: DUID 00:01:00:01:1c:dd:60:5f:b8:27:eb:53:2d:df
Jun 9 17:05:16 PI dhcpcd[2043]: eth0: IAID eb:53:2d:df
Jun 9 17:05:16 PI dhcpcd[2043]: eth0: soliciting an IPv6 router
Jun 9 17:05:16 PI dhcpcd[2043]: eth0: Router Advertisement from fe80::a96:d7ff:fee3:32c8
Jun 9 17:05:16 PI dhcpcd[2043]: eth0: adding address 2001:4dd0:ff00:9218:a047:d2a2:57fc:34d2/64
Jun 9 17:05:16 PI dhcpcd[2043]: eth0: adding route to 2001:4dd0:ff00:9218::/64
Jun 9 17:05:16 PI dhcpcd[2043]: eth0: adding default route via fe80::a96:d7ff:fee3:32c8
Jun 9 17:05:16 PI dhcpcd[2043]: eth0: confirming prior DHCPv6 lease
Jun 9 17:05:16 PI ntpd[2255]: ntpd 4.2.6p5@1.2349-o Sun Apr 12 22:37:22 UTC 2015 (1)
Jun 9 17:05:16 PI ntpd[2305]: proto: precision = 0.833 usec
Jun 9 17:05:16 PI ntpd[2305]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
Jun 9 17:05:16 PI ntpd[2305]: Listen and drop on 1 v6wildcard :: UDP 123
Jun 9 17:05:16 PI ntpd[2305]: Listen normally on 2 lo 127.0.0.1 UDP 123
Jun 9 17:05:16 PI ntpd[2305]: Listen normally on 3 eth0 192.168.254.5 UDP 123
Jun 9 17:05:16 PI ntpd[2305]: Listen normally on 4 lo ::1 UDP 123
Jun 9 17:05:16 PI ntpd[2305]: Listen normally on 5 eth0 fe80::ba27:ebff:fe53:2ddf UDP 123
Jun 9 17:05:16 PI ntpd[2305]: Listen normally on 6 eth0 2001:4dd0:ff00:9218:ba27:ebff:fe53:2ddf UDP 123
Jun 9 17:05:16 PI ntpd[2305]: peers refreshed
Jun 9 17:05:16 PI ntpd[2305]: Listening on routing socket on fd #23 for interface updates
Jun 9 17:05:17 PI dhcpcd[2043]: eth0: rebinding lease of 192.168.254.44 <-- WIESO ???!?
Jun 9 17:05:17 PI dhcpcd[2043]: eth0: REPLY6 received from fe80::a96:d7ff:fee3:32c8
Jun 9 17:05:17 PI dhcpcd[2043]: eth0: adding address 2001:4dd0:ff00:9218:13c4:baf8:7b48:b66a/128
Jun 9 17:05:17 PI dhcpcd[2043]: eth0: renew in 1800 seconds, rebind in 2880 seconds
Jun 9 17:05:17 PI avahi-daemon[2621]: Found user 'avahi' (UID 103) and group 'avahi' (GID 105).
Jun 9 17:05:17 PI avahi-daemon[2621]: Successfully dropped root privileges.
Jun 9 17:05:17 PI avahi-daemon[2621]: avahi-daemon 0.6.31 starting up.
Jun 9 17:05:17 PI avahi-daemon[2621]: Successfully called chroot().
Jun 9 17:05:17 PI avahi-daemon[2621]: Successfully dropped remaining capabilities.
Jun 9 17:05:17 PI avahi-daemon[2621]: Loading service file /services/udisks.service.
Jun 9 17:05:17 PI avahi-daemon[2621]: Joining mDNS multicast group on interface eth0.IPv6 with address 2001:4dd0:ff00:9218:ba27:ebff:fe53:2ddf.
Jun 9 17:05:17 PI avahi-daemon[2621]: New relevant interface eth0.IPv6 for mDNS.
Jun 9 17:05:17 PI avahi-daemon[2621]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.254.5.
Jun 9 17:05:17 PI avahi-daemon[2621]: New relevant interface eth0.IPv4 for mDNS.
Jun 9 17:05:17 PI avahi-daemon[2621]: Network interface enumeration completed.
Jun 9 17:05:17 PI avahi-daemon[2621]: Registering new address record for 2001:4dd0:ff00:9218:ba27:ebff:fe53:2ddf on eth0.*.
Jun 9 17:05:17 PI avahi-daemon[2621]: Registering new address record for 2001:4dd0:ff00:9218:a047:d2a2:57fc:34d2 on eth0.*.
Jun 9 17:05:17 PI avahi-daemon[2621]: Registering new address record for 2001:4dd0:ff00:9218:13c4:baf8:7b48:b66a on eth0.*.
Jun 9 17:05:17 PI avahi-daemon[2621]: Registering new address record for 192.168.254.5 on eth0.IPv4.
Jun 9 17:05:17 PI avahi-daemon[2621]: Registering HINFO record with values 'ARMV7L'/'LINUX'.Fakt ist, der RPI2 ist unter der DHCP-Adresse auch ansprechbar (SSH) und pingbar.
Hat jemand eine Idee ??!?
Gruss Heiko