X220, noch recht jungfraeulich:
Nett.
X220, noch recht jungfraeulich:
Nett.
Ein Geheimtipp bei den BSDs sind immer die Manpages, die sind Welten besser als das was Linux-Distributionen so im Angebot haben. Manchmal etwas Low-Level, aber geben einen guten Überblick: http://www.openbsd.org/cgi-bin/man.cg…query=apm&sec=8Nicht verwirrt sein, dass das bei OpenBSD "apm" heisst, im Hintergrund wird ACPI verwendet, und es gibt einen ThinkPad-spezifischen ACPI-Treiber: http://www.openbsd.org/cgi-bin/man.cg…uery=acpi&sec=4
Das ist schon mal n Anfang. Danke ![]()
Eine Frage quält mich aber noch. Wie siehts mit m (Synaptics) Touchpad aus? Das was ich bisher gefunden habe, meinte, dass es keinen Treiber für OpenBSD 5.7 gebe. Gibts da irgendein Pauschalrezept?
Hallo Leute,
ich habe mal wieder ne Frage. Ich habe schon ein wenig Erfahrung mit der Einrichtung von OpenBSD gesammelt. Generell gefällt mir das System sehr gut. Jetzt habe ich hier noch ein Thinkpad T61 als Zweitnotebook rum stehen (Hauptnotebook ist n Thinkpad X220), dessen Akku defekt ist. Dort läuft aktuell Debian 8 drauf.
Was brauch ich auf dem Notebook?
- Firefox
- Thunderbird
- Pidgin (mcabber)
- irssi
- TeXstuido (mit TeXlive)
- i3-wm
- irgendeinen grafischen Dateimanager
- Bildbetrachter und PDF-Reader
- Clients für smb, nfs und später eventuell rsync und git.
- Treiber fürs Synaptics-Touchpad (Wobei ich mir hier nicht sicher bin, ob es überhaupt nen Synaptics-Treiber für OpenBSD gibt.
Wie ich Software unter OpenBSD installiere weiß ich, kein Ding. Nur fehlt mir grade zum Thema Stromsparen einfach komplett die Materie ich hab nix in die Richtung gefunden. Ebenfalls würde ich gerne wissen, was ich beim T61 oder Thinkpads allgemein bei OpenBSD beachten muss.
Ich brauche keine Schritt für Schritt Anleitung, sondern nur ein paar Hinweise oder Anmerkungen.
Vielen Dank schon mal.
tk1908
Hier mal n Ausschnitt vom tcpdump Trace:
localhost.43008 > localhost.nfs: Flags [.], cksum 0xd2c1 (correct), ack 1, win 227, options [nop,nop,TS val 129934 ecr 24019006], length 0
21:51:41.540702 IP (tos 0x0, ttl 63, id 45154, offset 0, flags [DF], proto TCP (6), length 288)
localhost.3611421560 > localhost.nfs: 232 getattr fh 0,2/42
21:51:41.540706 IP (tos 0x0, ttl 64, id 58200, offset 0, flags [DF], proto TCP (6), length 52)
localhost.nfs > localhost.43008: Flags [.], cksum 0xd1cd (correct), ack 237, win 235, options [nop,nop,TS val 24019006 ecr 129934], length 0
21:51:41.540739 IP (tos 0x0, ttl 64, id 58201, offset 0, flags [DF], proto TCP (6), length 76)
localhost.nfs > localhost.3611421560: reply ERR 20: Auth Bogus Credentials (seal broken)
21:51:41.541964 IP (tos 0x0, ttl 63, id 45155, offset 0, flags [DF], proto TCP (6), length 52)
localhost.43008 > localhost.nfs: Flags [.], cksum 0xd1bc (correct), ack 25, win 227, options [nop,nop,TS val 129935 ecr 24019006], length 0
21:51:41.541968 IP (tos 0x0, ttl 63, id 45156, offset 0, flags [DF], proto TCP (6), length 52)
localhost.43008 > localhost.nfs: Flags [F.], cksum 0xd1bb (correct), seq 237, ack 25, win 227, options [nop,nop,TS val 129935 ecr 24019006], length 0
21:51:41.541987 IP (tos 0x0, ttl 64, id 58202, offset 0, flags [DF], proto TCP (6), length 52)
localhost.nfs > localhost.43008: Flags [F.], cksum 0xd1b1 (correct), seq 25, ack 238, win 235, options [nop,nop,TS val 24019007 ecr 129935], length 0
21:51:41.545286 IP (tos 0x0, ttl 63, id 45157, offset 0, flags [DF], proto TCP (6), length 52)
localhost.43008 > localhost.nfs: Flags [.], cksum 0xd1b8 (correct), ack 26, win 227, options [nop,nop,TS val 129936 ecr 24019007], length 0
21:51:41.545499 IP (tos 0x0, ttl 63, id 46925, offset 0, flags [DF], proto TCP (6), length 60)
localhost.13274 > localhost.nfs: Flags [S], cksum 0x8714 (correct), seq 902909149, win 28960, options [mss 1460,sackOK,TS val 129936 ecr 24019007,nop,wscale 7], length 0
21:51:41.545522 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
localhost.nfs > localhost.13274: Flags [S.], cksum 0x6fe9 (correct), seq 53023728, ack 902909150, win 28960, options [mss 1460,sackOK,TS val 24019008 ecr 129936,nop,wscale 7], length 0
21:51:41.546752 IP (tos 0x0, ttl 63, id 46926, offset 0, flags [DF], proto TCP (6), length 52)
localhost.13274 > localhost.nfs: Flags [.], cksum 0x0ef3 (correct), ack 1, win 227, options [nop,nop,TS val 129936 ecr 24019008], length 0
21:51:41.546966 IP (tos 0x0, ttl 63, id 46927, offset 0, flags [DF], proto TCP (6), length 288)
localhost.3611421560 > localhost.nfs: 232 getattr fh 0,2/42
21:51:41.546974 IP (tos 0x0, ttl 64, id 37809, offset 0, flags [DF], proto TCP (6), length 52)
localhost.nfs > localhost.13274: Flags [.], cksum 0x0dff (correct), ack 237, win 235, options [nop,nop,TS val 24019008 ecr 129936], length 0
21:51:41.546998 IP (tos 0x0, ttl 64, id 37810, offset 0, flags [DF], proto TCP (6), length 76)
localhost.nfs > localhost.3611421560: reply ERR 20: Auth Bogus Credentials (seal broken)
21:51:41.547961 IP (tos 0x0, ttl 63, id 46928, offset 0, flags [DF], proto TCP (6), length 52)
localhost.13274 > localhost.nfs: Flags [.], cksum 0x0dee (correct), ack 25, win 227, options [nop,nop,TS val 129937 ecr 24019008], length 0
21:51:41.551386 IP (tos 0x0, ttl 63, id 46929, offset 0, flags [DF], proto TCP (6), length 52)
localhost.13274 > localhost.nfs: Flags [F.], cksum 0x0dec (correct), seq 237, ack 25, win 227, options [nop,nop,TS val 129938 ecr 24019008], length 0
21:51:41.551423 IP (tos 0x0, ttl 64, id 37811, offset 0, flags [DF], proto TCP (6), length 52)
localhost.nfs > localhost.13274: Flags [F.], cksum 0x0de2 (correct), seq 25, ack 238, win 235, options [nop,nop,TS val 24019009 ecr 129938], length 0
21:51:41.552402 IP (tos 0x0, ttl 63, id 46930, offset 0, flags [DF], proto TCP (6), length 52)
localhost.13274 > localhost.nfs: Flags [.], cksum 0x0dea (correct), ack 26, win 227, options [nop,nop,TS val 129938 ecr 24019009], length 0
Alles anzeigen
War ursprünglich drin, allerdings als
Ich probiere es aber gerne heute Abend nochmal mit deinem Eintrag ![]()
Welche IP-Adresse kommt denn am NFS Server an? Ich würde fast vermuten, dass irgendwie 10.0.0.1 aufschlägt.
Rein von der Logik müsste 10.0.0.2 ankommen. Ich sniffe heute Abend mal den Traffic mit tcpdump.
Alles anzeigen
Hier hat soch jetzt noch ein Problem ergeben. Die Konstellation ist die selbe wie oben beschrieben. Allerdings kann ich jetzt keine NFS-Shares mehr von 10.0.0.1 mounten. (Zumindest wenn die Anfrage aus 10.24.0.0/16 oder 172.16.1.0/24 kommt.)Routen auf 10.0.0.1 sehen so aus:
Coderoot@beer:/home/tkoehler# ip route default via 192.168.178.1 dev wlan0 10.0.0.0/30 dev eth0 proto kernel scope link src 10.0.0.1 10.24.0.0/16 via 10.0.0.2 dev eth0 172.16.1.0/24 via 10.0.0.2 dev eth0 192.168.178.0/24 dev wlan0 proto kernel scope link src 192.168.178.22 root@beer:/home/tkoehler#iptables:
Code Alles anzeigenroot@beer:/home/tkoehler# iptables -L Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT icmp -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere root@beer:/home/tkoehler# echo Firewall wird gestartet. # Erstmal die alten Regeln rauswerfen iptables -F iptables -X # ...und Forwarding aktivieren echo 1 > /proc/sys/net/ipv4/ip_forward # Routing/NAT iptables -t nat -A POSTROUTING -o $TARGET -d 0.0.0.0/0 -j MASQUERADE # Antworten Auf Paketanfragen erlauben (Kann man prima am State nachschauen) iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT # Eingehende Pings erlauben iptables -A INPUT -p icmp -j ACCEPT # Eingehendes ssh erlauben iptables -A INPUT -p tcp -m --dport 22 -j ACCEPT # Eingehendes nfs erlauben iptables -A INPUT -p tcp -m --dport 2049 -j ACCEPT # Eingehendes dns erlauben iptables -A INPUT -p udp -m --dport 53 -j ACCEPT # Auf Loopback darf alles rein und raus iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT # Auf dem Quellinterface ist alles erlaubt iptables -A INPUT -i $SOURCE -j ACCEPT iptables -A OUTPUT -o $SOURCE -j ACCEPT # Auf dem Zielinterface ist auch alles erlaubt iptables -A INPUT -i $TARGET -j ACCEPT iptables -A OUTPUT -o $TARGET -j ACCEPT # Policies setzen iptables -P INPUT DROPNFS-Exports:
Code/data/save 10.24.0.0/16(rw,no_subtree_check) /data/save 172.16.1.0/24(rw,no_subtree_check) /data/save 192.168.178.31(rw,all_squash,anonuid=1000,anongid=1000) #NFS-Share für N900 /data/nfs/grml32 10.18.1.1/16(ro) /data/nfs/grml64 10.18.1.1/16(ro)Vielen Dank schon mal.
Kleiner EDIT:
Als Fehlermeldung bekomme ich:
"mount.nfs: access denied by server while mounting beer:/data/save"
Keiner ne Idee?
Hier hat soch jetzt noch ein Problem ergeben. Die Konstellation ist die selbe wie oben beschrieben. Allerdings kann ich jetzt keine NFS-Shares mehr von 10.0.0.1 mounten. (Zumindest wenn die Anfrage aus 10.24.0.0/16 oder 172.16.1.0/24 kommt.)
Routen auf 10.0.0.1 sehen so aus:
root@beer:/home/tkoehler# ip route
default via 192.168.178.1 dev wlan0
10.0.0.0/30 dev eth0 proto kernel scope link src 10.0.0.1
10.24.0.0/16 via 10.0.0.2 dev eth0
172.16.1.0/24 via 10.0.0.2 dev eth0
192.168.178.0/24 dev wlan0 proto kernel scope link src 192.168.178.22
root@beer:/home/tkoehler#
iptables:
root@beer:/home/tkoehler# iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
root@beer:/home/tkoehler#
echo Firewall wird gestartet.
# Erstmal die alten Regeln rauswerfen
iptables -F
iptables -X
# ...und Forwarding aktivieren
echo 1 > /proc/sys/net/ipv4/ip_forward
# Routing/NAT
iptables -t nat -A POSTROUTING -o $TARGET -d 0.0.0.0/0 -j MASQUERADE
# Antworten Auf Paketanfragen erlauben (Kann man prima am State nachschauen)
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# Eingehende Pings erlauben
iptables -A INPUT -p icmp -j ACCEPT
# Eingehendes ssh erlauben
iptables -A INPUT -p tcp -m --dport 22 -j ACCEPT
# Eingehendes nfs erlauben
iptables -A INPUT -p tcp -m --dport 2049 -j ACCEPT
# Eingehendes dns erlauben
iptables -A INPUT -p udp -m --dport 53 -j ACCEPT
# Auf Loopback darf alles rein und raus
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Auf dem Quellinterface ist alles erlaubt
iptables -A INPUT -i $SOURCE -j ACCEPT
iptables -A OUTPUT -o $SOURCE -j ACCEPT
# Auf dem Zielinterface ist auch alles erlaubt
iptables -A INPUT -i $TARGET -j ACCEPT
iptables -A OUTPUT -o $TARGET -j ACCEPT
# Policies setzen
iptables -P INPUT DROP
Alles anzeigen
NFS-Exports:
/data/save 10.24.0.0/16(rw,no_subtree_check)
/data/save 172.16.1.0/24(rw,no_subtree_check)
/data/save 192.168.178.31(rw,all_squash,anonuid=1000,anongid=1000) #NFS-Share für N900
/data/nfs/grml32 10.18.1.1/16(ro)
/data/nfs/grml64 10.18.1.1/16(ro)
Vielen Dank schon mal.
Hier hat soch jetzt noch ein Problem ergeben. Die Konstellation ist die selbe wie oben beschrieben. Allerdings kann ich jetzt keine NFS-Shares mehr von 10.0.0.1 mounten. (Zumindest wenn die Anfrage aus 10.24.0.0/16 oder 172.16.1.0/24 kommt.)Routen auf 10.0.0.1 sehen so aus:
Coderoot@beer:/home/tkoehler# ip route default via 192.168.178.1 dev wlan0 10.0.0.0/30 dev eth0 proto kernel scope link src 10.0.0.1 10.24.0.0/16 via 10.0.0.2 dev eth0 172.16.1.0/24 via 10.0.0.2 dev eth0 192.168.178.0/24 dev wlan0 proto kernel scope link src 192.168.178.22 root@beer:/home/tkoehler#iptables:
Code Alles anzeigenroot@beer:/home/tkoehler# iptables -L Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT icmp -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere root@beer:/home/tkoehler# echo Firewall wird gestartet. # Erstmal die alten Regeln rauswerfen iptables -F iptables -X # ...und Forwarding aktivieren echo 1 > /proc/sys/net/ipv4/ip_forward # Routing/NAT iptables -t nat -A POSTROUTING -o $TARGET -d 0.0.0.0/0 -j MASQUERADE # Antworten Auf Paketanfragen erlauben (Kann man prima am State nachschauen) iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT # Eingehende Pings erlauben iptables -A INPUT -p icmp -j ACCEPT # Eingehendes ssh erlauben iptables -A INPUT -p tcp -m --dport 22 -j ACCEPT # Eingehendes nfs erlauben iptables -A INPUT -p tcp -m --dport 2049 -j ACCEPT # Eingehendes dns erlauben iptables -A INPUT -p udp -m --dport 53 -j ACCEPT # Auf Loopback darf alles rein und raus iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT # Auf dem Quellinterface ist alles erlaubt iptables -A INPUT -i $SOURCE -j ACCEPT iptables -A OUTPUT -o $SOURCE -j ACCEPT # Auf dem Zielinterface ist auch alles erlaubt iptables -A INPUT -i $TARGET -j ACCEPT iptables -A OUTPUT -o $TARGET -j ACCEPT # Policies setzen iptables -P INPUT DROPNFS-Exports:
Code/data/save 10.24.0.0/16(rw,no_subtree_check) /data/save 172.16.1.0/24(rw,no_subtree_check) /data/save 192.168.178.31(rw,all_squash,anonuid=1000,anongid=1000) #NFS-Share für N900 /data/nfs/grml32 10.18.1.1/16(ro) /data/nfs/grml64 10.18.1.1/16(ro)Vielen Dank schon mal.
Kleiner EDIT:
Als Fehlermeldung bekomme ich:
"mount.nfs: access denied by server while mounting beer:/data/save"
Metal Only
pfSense nutzt pf statt netfilter. Dem entsprechend gibt es kein iptables dort. Auch ip wird es dort nicht geben, ifconfig und route wären dort von Nöten, da FreeBSD.Aber am besten ist, du zeigst einfach mal alle gesetzten Regeln und wir schauen weiter.
Ich hab jetz erstmal nen Workaround geschaffen. Homeserver stellt per DHCP das 10.0.0.0/30er Netz bereit. Mit ner statischen IP muss ichs die Tage nochmal ausprobieren.
Du musst Antworen anhand des States erkennen und rein lassen. Denn mit deiner "alles droppen" Regel droppst du auch die.In iptables wäre die Lösung:
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPTSchau mal, dass du bei pfSense Pakete dieser beiden States reinläßt, das sind die Antworten.
Drop ist übrigens unsauber, da es Timeouts verursacht. Hier solltest du zu Rejects wechseln. Ich weiß allerdings nicht, wo genau das bei pfSense ist.
Sollte er das nicht automatisch machen?
Nabend,
ich versuche mich aktuell an ner Änderung meines Routing-Setups.
Aktuell:
DSL -> Fritzbox -> Homeserver -> Embedded Kiste mit pfsense -> Switch -> Rechner.
Dabei hängt der Homeserver mit dem /30er Netz an der pfsense an em0 (WAN-Port).
Netze:
Transportnetz (DMZ): 10.0.0.0/30
LAN: 10.24.0.0/16 (em1 an pfsense)
WLAN: 172.16.1.0/24 (ath0 an pfsense)
In der DMZ hängen nur die Router (Homeserer und pfsense).
Der Homeserver kommt ins Inet. Die pfsense Box kann den Homeserver pingen, kommt aber nicht raus. Regeln stehen INPUT auf DROP, aber Output sollte alles auf ACCEPT stehen.
DHCP auf Homeserver ist aus, Adressen sind statisch hinterlegt.
Jemand ne Idee?
Viele Grüße
tk
Wie siehts jetzt eigentlich aus xCtrl? Schon was in der Richtung realisiert?
Was für Access Points du einsetzen willst, also Hersteller/Modell.
Oh. Werde vorerst die Alix APU1D4 als Access Point nutzen. Wenn die Geschwindigkeiten zu schlecht sind, werde ich mir wohl nen dedizierten Access Point besorgen.
Was für APs sind drin? Schöne Unifis?
Wen meinste jetzt?
Steht mir heute Abend auch noch bevor. Freu mich drauf.
Ich muss mich korrigieren. Das Paket wird erst morgen ankommen. Danke DHL -.-
Das will ich als FiSi schwer hoffen.
Steht mir heute Abend auch noch bevor. Freu mich drauf. ![]()
Eventuell bin ich da als Linux-User anders. Ich verurteile niemand weil er kein Linux-User ist. Ich missioniere auch niemanden, wenn man es selbst ausprobiert es einem zusagt bleibt man freiwillig dabei. Ich erwarte von einem Betriebssystem für meine Bedürfnisse eine maximale Anpassbarkeit und Kontrolle über dem was auf meinem System geschieht - ich kann überall den Deckel aufmachen und schrauben bis es so ist wie ich mir das vorstelle. Deswegen ist es das System meiner Wahl - und darum wohl auch nicht jedermanns Sache. Dazu kommen die üblichen hausgemachten Probleme wie die starke Fragmentierung.
Kann dir hier zustimmen Pain. Ich würde sogar behaupten, dass es dem Großteil der Linux User relativ egal ist, ob die Leute jetzt Windows oder Linux nutzen.
@Doc
Ich weiß nicht, was ihr mit euren Linux-Kisten macht. Ich hab hier jetzt seit ner ganzen Weile mein Arch laufen und es tut genau das: laufen.