raspberry-pi-aufsetzen
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende Überarbeitung | ||
raspberry-pi-aufsetzen [2016/08/19 16:43] – benny | raspberry-pi-aufsetzen [2024/06/09 10:29] (aktuell) – Externe Bearbeitung 127.0.0.1 | ||
---|---|---|---|
Zeile 105: | Zeile 105: | ||
</ | </ | ||
- | Im nächsten Schritt wollen wir dem Raspberry Pi das korrekte Tastaturlayout verpassen, die Zeitzone auf Berlin einstellen und optional (wenn vorhanden) die Wi-Fi/ | + | Im nächsten Schritt wollen wir dem Raspberry Pi das korrekte Tastaturlayout verpassen, die Zeitzone auf Berlin einstellen, den Hostname setzen |
< | < | ||
Zeile 138: | Zeile 138: | ||
>>>> | >>>> | ||
+ | |||
+ | **Den Hostname des Raspberry Pi festlegen: | ||
+ | |||
+ | > " | ||
+ | |||
+ | >> " | ||
+ | |||
+ | >>> | ||
+ | |||
+ | >>>> | ||
**Für deutsche regulatorische Domäne Wi-Fi/ | **Für deutsche regulatorische Domäne Wi-Fi/ | ||
Zeile 154: | Zeile 164: | ||
< | < | ||
- | sudo apt-get update && sudo apt-get dist-upgrade | + | pi@raspberrypi: |
</ | </ | ||
Zeile 185: | Zeile 195: | ||
* VIM | * VIM | ||
+ | * tcpdump | ||
+ | * iperf3 | ||
+ | * tshark | ||
+ | * smcroute | ||
< | < | ||
- | sudo apt-get install -y vim | + | pi@raspberrypi: |
</ | </ | ||
+ | Optional | ||
+ | (smcroute) | ||
+ | |||
+ | ===== IPv6 deaktivieren (wahlweise) ===== | ||
+ | |||
+ | <code bash> | ||
+ | echo 1 > / | ||
+ | </ | ||
+ | |||
+ | bzw. in der sysctl.conf | ||
+ | <code bash> | ||
+ | net.ipv6.conf.all.disable_ipv6 = 1 | ||
+ | </ | ||
+ | |||
+ | ===== iptables für NAT zwischen wlan0 und eth0 ===== | ||
+ | |||
+ | <code bash> | ||
+ | sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE | ||
+ | sudo iptables -A FORWARD -i eth0 -o wlan0 -m state --state RELATED, | ||
+ | sudo iptables -A FORWARD -i wlan0 -o eth0 -j ACCEPT | ||
+ | sudo sh -c " | ||
+ | # In / | ||
+ | up iptables-restore < / | ||
+ | </ | ||
+ | |||
+ | ===== Multicast am OmniSwitch 6450 (6.7.1.86.R03) + Raspberry Pi ===== | ||
+ | |||
+ | Der Linux Kernel des Raspberry Pi macht von Haus aus Multicast, daher muss man hier nicht groß rumsuchen: | ||
+ | |||
+ | < | ||
+ | pi@pi1:~ $ ifconfig eth0 | ||
+ | eth0 Link encap: | ||
+ | inet addr: | ||
+ | inet6 addr: fe80:: | ||
+ | UP BROADCAST RUNNING MULTICAST | ||
+ | RX packets:123 errors:0 dropped:0 overruns:0 frame:0 | ||
+ | TX packets:126 errors:0 dropped:0 overruns:0 carrier:0 | ||
+ | collisions: | ||
+ | RX bytes:12051 (11.7 KiB) TX bytes:16815 (16.4 KiB) | ||
+ | |||
+ | pi@pi1:~ $ ip maddr show dev eth0 | ||
+ | 2: eth0 | ||
+ | link 33: | ||
+ | link 33: | ||
+ | link 01: | ||
+ | link 33: | ||
+ | link 01: | ||
+ | inet 224.0.0.251 | ||
+ | inet 224.0.0.1 | ||
+ | inet6 ff02::fb | ||
+ | inet6 ff02:: | ||
+ | inet6 ff02::1 | ||
+ | inet6 ff01::1 | ||
+ | pi@pi1:~ $ ping 239.0.10.1 | ||
+ | PING 239.0.10.1 (239.0.10.1) 56(84) bytes of data. | ||
+ | ^C | ||
+ | --- 239.0.10.1 ping statistics --- | ||
+ | 6 packets transmitted, | ||
+ | </ | ||
+ | |||
+ | Am Pi2 kann man diese Pakete auch sehen (aber es wird nicht darauf geantwortet) | ||
+ | |||
+ | < | ||
+ | pi@pi2:~ $ sudo tcpdump -lvvvni eth0 host 239.0.10.1 | ||
+ | tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes | ||
+ | 20: | ||
+ | 192.168.5.155 > 239.0.10.1: ICMP echo request, id 828, seq 1, length 64 | ||
+ | 20: | ||
+ | 192.168.5.155 > 239.0.10.1: ICMP echo request, id 828, seq 2, length 64 | ||
+ | 20: | ||
+ | 192.168.5.155 > 239.0.10.1: ICMP echo request, id 828, seq 3, length 64 | ||
+ | 20: | ||
+ | 192.168.5.155 > 239.0.10.1: ICMP echo request, id 828, seq 4, length 64 | ||
+ | 20: | ||
+ | 192.168.5.155 > 239.0.10.1: ICMP echo request, id 828, seq 5, length 64 | ||
+ | </ | ||
+ | |||
+ | Soweit so gut, nur wollen wir die Pakete erst erhalten nachdem wir diese Gruppe per IGMP gejoined haben. | ||
+ | |||
+ | Dafür müssen wir erstmal dem OmniSwitch etwas mehr Intelligenz einhauchen, damit der nicht alles einfach vervielfältigt. | ||
+ | |||
+ | < | ||
+ | -> show ip multicast | ||
+ | |||
+ | Status | ||
+ | Querying | ||
+ | Proxying | ||
+ | Spoofing | ||
+ | Zapping | ||
+ | Querier Forwarding | ||
+ | Flood Unknown | ||
+ | Dynamic control drop-all status | ||
+ | Version | ||
+ | Robustness | ||
+ | Query Interval (seconds) | ||
+ | Query Response Interval (tenths of seconds) | ||
+ | Last Member Query Interval (tenths of seconds) | ||
+ | Unsolicited Report Interval (seconds) | ||
+ | Router Timeout (seconds) | ||
+ | Source Timeout (seconds) | ||
+ | Max-group | ||
+ | Max-group action | ||
+ | |||
+ | -> ip multicast status enable | ||
+ | -> show ip multicast | ||
+ | |||
+ | Status | ||
+ | Querying | ||
+ | Proxying | ||
+ | Spoofing | ||
+ | Zapping | ||
+ | Querier Forwarding | ||
+ | Flood Unknown | ||
+ | Dynamic control drop-all status | ||
+ | Version | ||
+ | Robustness | ||
+ | Query Interval (seconds) | ||
+ | Query Response Interval (tenths of seconds) | ||
+ | Last Member Query Interval (tenths of seconds) | ||
+ | Unsolicited Report Interval (seconds) | ||
+ | Router Timeout (seconds) | ||
+ | Source Timeout (seconds) | ||
+ | Max-group | ||
+ | Max-group action | ||
+ | </ | ||
+ | |||
+ | Wiederholt man nun den ping auf dem Pi1, empfängt man auf Pi2 nichts mehr - dafür sieht der Switch den Pi1 als Source | ||
+ | |||
+ | < | ||
+ | pi@pi1:~ $ ping 239.0.10.1 | ||
+ | PING 239.0.10.1 (239.0.10.1) 56(84) bytes of data. | ||
+ | ^C | ||
+ | --- 239.0.10.1 ping statistics --- | ||
+ | 5 packets transmitted, | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | -> show ip multicast source | ||
+ | |||
+ | Total 1 Sources | ||
+ | |||
+ | Group Address | ||
+ | ---------------+---------------+---------------+-----+----- | ||
+ | 239.0.10.1 | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | pi@pi2:~ $ sudo tcpdump -lvvvni eth0 host 239.0.10.1 | ||
+ | tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes | ||
+ | ^C | ||
+ | 0 packets captured | ||
+ | 0 packets received by filter | ||
+ | 0 packets dropped by kernel | ||
+ | </ | ||
+ | |||
+ | Zum Zeitpunkt zu dem dieser Artikel geschrieben wurde, beherrschen die iproute2 Werkzeuge zwar die Anzeige von Multicast-Einstellungen, | ||
+ | |||
+ | **Pi2 SSH Session 1** | ||
+ | < | ||
+ | pi@pi2:~ $ sudo smcroute -d | ||
+ | pi@pi2:~ $ sudo smcroute -j eth0 239.0.10.1 | ||
+ | </ | ||
+ | |||
+ | > Startet den Prozess als Daemon (Superuser Rechte sind Muss!) | ||
+ | >> sudo smcroute -d | ||
+ | > Sendet einen " | ||
+ | >> sudo smcroute -j eth0 239.0.10.1 | ||
+ | > Sendet einen IGMP-Leave" | ||
+ | >> sudo smcroute -l eth0 239.0.10.1 | ||
+ | > Beendet den Prozess | ||
+ | >> sudo smcroute -k | ||
+ | |||
+ | Alternativ kann man das Paket " | ||
+ | > Registriert die Adresse 239.0.10.1 auf der Schnittstelle eth0 | ||
+ | >> pi@pi2:~ $ socat STDIO UDP4-RECV: | ||
+ | |||
+ | **Pi2 SSH Session 2** | ||
+ | < | ||
+ | pi@pi2:~ $ sudo tcpdump -lvvvnni eth0 igmp or host 239.0.10.1 | ||
+ | tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes | ||
+ | 21: | ||
+ | 192.168.5.156 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 239.0.10.1 to_ex { }] | ||
+ | 21: | ||
+ | 192.168.5.156 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 239.0.10.1 to_ex { }] | ||
+ | </ | ||
+ | |||
+ | **Pi1, mal lospingen** | ||
+ | < | ||
+ | pi@pi1:~ $ ping 239.0.10.1 | ||
+ | PING 239.0.10.1 (239.0.10.1) 56(84) bytes of data. | ||
+ | ^C | ||
+ | --- 239.0.10.1 ping statistics --- | ||
+ | 10 packets transmitted, | ||
+ | </ | ||
+ | |||
+ | **Der OmniSwitch 6450 sieht die Pakete und vermittelt sie auch weiter** | ||
+ | < | ||
+ | |||
+ | -> show ip multicast source | ||
+ | |||
+ | Total 1 Sources | ||
+ | |||
+ | Group Address | ||
+ | ---------------+---------------+---------------+-----+----- | ||
+ | 239.0.10.1 | ||
+ | |||
+ | -> show ip multicast group | ||
+ | |||
+ | Total 1 Groups | ||
+ | |||
+ | Group Address | ||
+ | ---------------+---------------+-----+-----+--------+-------+------+-----+------ | ||
+ | 239.0.10.1 | ||
+ | |||
+ | </ | ||
+ | |||
+ | **Pi2 SSH Session 2** | ||
+ | < | ||
+ | pi@pi2:~ $ sudo tcpdump -lvvvnni eth0 igmp or host 239.0.10.1 | ||
+ | tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes | ||
+ | 21: | ||
+ | 192.168.5.155 > 239.0.10.1: ICMP echo request, id 873, seq 2, length 64 | ||
+ | 21: | ||
+ | 192.168.5.155 > 239.0.10.1: ICMP echo request, id 873, seq 3, length 64 | ||
+ | 21: | ||
+ | 192.168.5.155 > 239.0.10.1: ICMP echo request, id 873, seq 4, length 64 | ||
+ | 21: | ||
+ | 192.168.5.155 > 239.0.10.1: ICMP echo request, id 874, seq 2, length 64 | ||
+ | 21: | ||
+ | 192.168.5.155 > 239.0.10.1: ICMP echo request, id 874, seq 3, length 64 | ||
+ | 21: | ||
+ | 192.168.5.155 > 239.0.10.1: ICMP echo request, id 874, seq 4, length 64 | ||
+ | 21: | ||
+ | 192.168.5.155 > 239.0.10.1: ICMP echo request, id 874, seq 5, length 64 | ||
+ | 21: | ||
+ | 192.168.5.155 > 239.0.10.1: ICMP echo request, id 874, seq 6, length 64 | ||
+ | 21: | ||
+ | 192.168.5.155 > 239.0.10.1: ICMP echo request, id 874, seq 7, length 64 | ||
+ | 21: | ||
+ | 192.168.5.155 > 239.0.10.1: ICMP echo request, id 874, seq 8, length 64 | ||
+ | 21: | ||
+ | 192.168.5.155 > 239.0.10.1: ICMP echo request, id 874, seq 9, length 64 | ||
+ | 21: | ||
+ | 192.168.5.155 > 239.0.10.1: ICMP echo request, id 874, seq 10, length 64 | ||
+ | </ | ||
+ | |||
+ | Es fällt auf dass der Eintrag der 239er Multicast Gruppe immer wieder " | ||
+ | |||
+ | **Wir aktivieren dafür "ip multicast querying" | ||
+ | |||
+ | < | ||
+ | -> show ip multicast | ||
+ | |||
+ | Status | ||
+ | Querying | ||
+ | Proxying | ||
+ | Spoofing | ||
+ | Zapping | ||
+ | Querier Forwarding | ||
+ | Flood Unknown | ||
+ | Dynamic control drop-all status | ||
+ | Version | ||
+ | Robustness | ||
+ | Query Interval (seconds) | ||
+ | Query Response Interval (tenths of seconds) | ||
+ | Last Member Query Interval (tenths of seconds) | ||
+ | Unsolicited Report Interval (seconds) | ||
+ | Router Timeout (seconds) | ||
+ | Source Timeout (seconds) | ||
+ | Max-group | ||
+ | Max-group action | ||
+ | |||
+ | -> ip multicast querying enable | ||
+ | |||
+ | -> show ip multicast | ||
+ | |||
+ | Status | ||
+ | Querying | ||
+ | Proxying | ||
+ | Spoofing | ||
+ | Zapping | ||
+ | Querier Forwarding | ||
+ | Flood Unknown | ||
+ | Dynamic control drop-all status | ||
+ | Version | ||
+ | Robustness | ||
+ | Query Interval (seconds) | ||
+ | Query Response Interval (tenths of seconds) | ||
+ | Last Member Query Interval (tenths of seconds) | ||
+ | Unsolicited Report Interval (seconds) | ||
+ | Router Timeout (seconds) | ||
+ | Source Timeout (seconds) | ||
+ | Max-group | ||
+ | Max-group action | ||
+ | |||
+ | -> show ip multicast querier | ||
+ | |||
+ | Total 1 Queriers | ||
+ | |||
+ | Host Address | ||
+ | ---------------+-----+-----+-------+------+----- | ||
+ | 192.168.5.104 | ||
+ | </ | ||
+ | |||
+ | Diese Konfiguration sorgt dafür dass der Switch regelmäßig fragt wer für welche Gruppen registriert ist und darauf reagiert der smcroute Daemon dann auch und der Eintrag wird aktiv gehalten. | ||
+ | |||
+ | < | ||
+ | -> show ip multicast group | ||
+ | |||
+ | Total 1 Groups | ||
+ | |||
+ | Group Address | ||
+ | ---------------+---------------+-----+-----+--------+-------+------+-----+------ | ||
+ | 239.0.10.1 | ||
+ | |||
+ | -> show ip multicast group | ||
+ | |||
+ | Total 1 Groups | ||
+ | |||
+ | Group Address | ||
+ | ---------------+---------------+-----+-----+--------+-------+------+-----+------ | ||
+ | 239.0.10.1 | ||
+ | |||
+ | -> show ip multicast group | ||
+ | |||
+ | Total 1 Groups | ||
+ | |||
+ | Group Address | ||
+ | ---------------+---------------+-----+-----+--------+-------+------+-----+------ | ||
+ | 239.0.10.1 | ||
+ | |||
+ | -> | ||
+ | -> | ||
+ | </ | ||
+ | |||
+ | **So sieht dies auf Seite des Pi2 aus** | ||
+ | < | ||
+ | pi@pi2:~ $ sudo tshark -i eth0 -Y igmp | ||
+ | tshark: Lua: Error during loading: | ||
+ | | ||
+ | Running as user " | ||
+ | Capturing on ' | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | ^C6 packets captured | ||
+ | </ | ||
+ | |||
+ | Nun fällt auf dass der Pi2 nicht auf den ICMP Echo Request antwortet, obwohl er ihn erhält (geht ja an eine Multicast Adresse). | ||
+ | |||
+ | **Dies aktivieren wir für diesen Test wie folgt:** | ||
+ | < | ||
+ | pi@pi2:~ $ cat / | ||
+ | 1 | ||
+ | pi@pi2:~ $ sudo sysctl net.ipv4.icmp_echo_ignore_broadcasts=0 | ||
+ | net.ipv4.icmp_echo_ignore_broadcasts = 0 | ||
+ | </ | ||
+ | |||
+ | **Hier nun das finale Ergebnis (Multicast Echo Request, Unicast Echo Response)** | ||
+ | < | ||
+ | pi@pi2:~ $ sudo tshark -i eth0 -Y "igmp or ip.dst==239.0.10.1 or ip.dst == 192.168.5.155" | ||
+ | tshark: Lua: Error during loading: | ||
+ | | ||
+ | Running as user " | ||
+ | Capturing on ' | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | 100 15.793022 192.168.5.155 -> 239.0.10.1 | ||
+ | 101 15.793091 192.168.5.156 -> 192.168.5.155 ICMP 98 Echo (ping) reply id=0x0699, seq=13/ | ||
+ | 107 16.793035 192.168.5.155 -> 239.0.10.1 | ||
+ | 108 16.793121 192.168.5.156 -> 192.168.5.155 ICMP 98 Echo (ping) reply id=0x0699, seq=14/ | ||
+ | 110 17.135066 192.168.5.156 -> 239.0.10.1 | ||
+ | 118 17.793027 192.168.5.155 -> 239.0.10.1 | ||
+ | 119 17.793098 192.168.5.156 -> 192.168.5.155 ICMP 98 Echo (ping) reply id=0x0699, seq=15/ | ||
+ | 125 18.793047 192.168.5.155 -> 239.0.10.1 | ||
+ | 126 18.793144 192.168.5.156 -> 192.168.5.155 ICMP 98 Echo (ping) reply id=0x0699, seq=16/ | ||
+ | 134 19.793026 192.168.5.155 -> 239.0.10.1 | ||
+ | 135 19.793099 192.168.5.156 -> 192.168.5.155 ICMP 98 Echo (ping) reply id=0x0699, seq=17/ | ||
+ | 141 20.793037 192.168.5.155 -> 239.0.10.1 | ||
+ | 142 20.793124 192.168.5.156 -> 192.168.5.155 ICMP 98 Echo (ping) reply id=0x0699, seq=18/ | ||
+ | 148 21.793024 192.168.5.155 -> 239.0.10.1 | ||
+ | 149 21.793100 192.168.5.156 -> 192.168.5.155 ICMP 98 Echo (ping) reply id=0x0699, seq=19/ | ||
+ | 155 22.765096 192.168.5.156 -> 224.0.0.251 | ||
+ | ^C39 packets captured | ||
+ | </ | ||
+ | |||
+ | Nun wurde mir seitens eines geschätzten Business Partners berichtet dass es eine Herausforderung gibt, wenn der Client der den Multicast erhalten soll per " | ||
+ | |||
+ | **Authentifizierung auf dem OmniSwitch einrichten** | ||
+ | < | ||
+ | -> aaa radius-server rad01 host 192.168.5.1 key verysecret | ||
+ | -> | ||
+ | -> aaa test-radius-server rad01 type authentication user alcatel password alcatel method pap | ||
+ | Testing Radius Server < | ||
+ | Access-Accept from 192.168.5.1 Port 1812 Time: 2 ms | ||
+ | Returned Attributes | ||
+ | |||
+ | -> vlan port mobile 1/3 | ||
+ | -> vlan port 1/3 802.1x enable | ||
+ | -> ! Durch folgendes Kommando halten wir uns nicht mit 802.1x auf sondern machen direkt " | ||
+ | -> 802.1x 1/3 supp-polling retry 0 | ||
+ | -> | ||
+ | -> 802.1x 1/3 non-supplicant policy authentication pass default-vlan fail block | ||
+ | -> | ||
+ | -> aaa authentication mac rad01 | ||
+ | -> | ||
+ | -> ! Der häufigste Fehler ist die folgende Zeile nicht zu haben, also daher los! | ||
+ | -> aaa authentication 802.1x rad01 | ||
+ | -> | ||
+ | -> ! Gleich mal probieren, Pi2 abgezogen und aufgesteckt ... | ||
+ | -> show 802.1x non-supplicant | ||
+ | |||
+ | Slot MAC MAC Authent | ||
+ | Port Address | ||
+ | -----+-----------------+----------------+-------------------+-------- | ||
+ | 01/03 b8: | ||
+ | |||
+ | -> ! Aber es ging ja um das UNP, daher .. | ||
+ | |||
+ | -> aaa user-network-profile name " | ||
+ | |||
+ | -> show 802.1x non-supplicant | ||
+ | |||
+ | Slot MAC MAC Authent | ||
+ | Port Address | ||
+ | -----+-----------------+----------------+-------------------+-------- | ||
+ | 01/03 b8: | ||
+ | |||
+ | -> show 802.1x non-supplicant unp | ||
+ | |||
+ | Slot MAC | ||
+ | Port Address | ||
+ | -----+-----------------+-----+---------------+----------------- | ||
+ | 01/03 b8: | ||
+ | |||
+ | -> show ip multicast group | ||
+ | |||
+ | Total 1 Groups | ||
+ | |||
+ | Group Address | ||
+ | ---------------+---------------+-----+-----+--------+-------+------+-----+------ | ||
+ | 239.0.10.1 | ||
+ | |||
+ | </ | ||
+ | |||
+ | Der Ping läuft auch wie zuvor. Da scheint der Aufbau beim Partner doch irgendwie anders zu sein. :( | ||
+ | |||
+ | **Das sagt der Freeradius (v2)** | ||
+ | < | ||
+ | rad_recv: Access-Request packet from host 192.168.5.104 port 1030, id=4, length=98 | ||
+ | User-Name = " | ||
+ | User-Password = " | ||
+ | NAS-IP-Address = 192.168.5.104 | ||
+ | NAS-Port = 77 | ||
+ | NAS-Port-Type = Ethernet | ||
+ | Calling-Station-Id = " | ||
+ | Service-Type = Call-Check | ||
+ | # Executing section authorize from file / | ||
+ | +group authorize { | ||
+ | ++[preprocess] = ok | ||
+ | ++[chap] = noop | ||
+ | ++[mschap] = noop | ||
+ | ++[digest] = noop | ||
+ | [suffix] No ' | ||
+ | [suffix] No such realm " | ||
+ | ++[suffix] = noop | ||
+ | [eap] No EAP-Message, | ||
+ | ++[eap] = noop | ||
+ | [files] users: Matched entry B827EB6178EC at line 98 | ||
+ | ++[files] = ok | ||
+ | ++[expiration] = noop | ||
+ | ++[logintime] = noop | ||
+ | ++[pap] = updated | ||
+ | +} # group authorize = updated | ||
+ | Found Auth-Type = PAP | ||
+ | # Executing group from file / | ||
+ | +group PAP { | ||
+ | [pap] login attempt with password " | ||
+ | [pap] Using clear text password " | ||
+ | [pap] User authenticated successfully | ||
+ | ++[pap] = ok | ||
+ | +} # group PAP = ok | ||
+ | # Executing section post-auth from file / | ||
+ | +group post-auth { | ||
+ | ++[exec] = noop | ||
+ | +} # group post-auth = noop | ||
+ | Sending Access-Accept of id 4 to 192.168.5.104 port 1030 | ||
+ | Framed-Filter-Id = " | ||
+ | Finished request 0. | ||
+ | Going to the next request | ||
+ | Waking up in 4.9 seconds. | ||
+ | Cleaning up request 0 ID 4 with timestamp +23 | ||
+ | </ |
raspberry-pi-aufsetzen.1471625030.txt.gz · Zuletzt geändert: 2024/06/09 10:29 (Externe Bearbeitung)