Hier soll es darum gehen einen Raspberry Pi aufzusetzen. Ich nutze hier einen Mac, für Windows oder Linux hilft sicherlich Google weiter.
Je nachdem was auf der MicroSD Karte drauf ist, wird die vom macOS automatisch gemounted. In diesem Fall ist es „disk2“, dies kann bei euch aber etwas anderes ein.
Achtung! Wer hier jetzt versehentlich seine eigene SSD/HDD des Mac auswählt, baut echt Bockmist! Bitte vorsichtig!
BennyE$ diskutil list
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.3 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_CoreStorage 499.4 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: Apple_HFS Macintosh HD *499.1 GB disk1
Logical Volume on disk0s2
Unlocked Encrypted
/dev/disk2
#: TYPE NAME SIZE IDENTIFIER
0: FDisk_partition_scheme *15.5 GB disk2
1: Windows_FAT_32 boot 66.1 MB disk2s1
2: Linux 15.5 GB disk2s2
Damit wir mit der Karte arbeiten können, müssen wir sie erstmal unmounten.
BennyE$ diskutil unmountdisk /dev/disk2 Unmount of all volumes on disk2 was successful
Nun sind wir bereit die MicroSD Karte mit dem Image (das ZIP müsst ihr natürlich entpacken) zu beschreiben. Hier ist es wichtig auf dem Mac (BSD-like) /dev/rdisk2 zu verwenden, da die Übertragung sonst ewig dauert. (Dies hängt damit zusammen dass rdisk ein „character device“ ist und disk ein „block device“.)
BennyE$ sudo dd if=2016-05-10-raspbian-jessie-lite.img of=/dev/rdisk2 bs=1024k 1322+0 records in 1322+0 records out 1386217472 bytes transferred in 126.697464 secs (10941162 bytes/sec)
Wer Lust hat kann den Vorgang parallel mit iostat überwachen
BennyE$ iostat disk2 10
disk2 cpu load average
KB/t tps MB/s us sy id 1m 5m 15m
676.90 0 0.00 7 4 89 1.95 1.99 2.03
1024.00 10 10.20 3 3 94 2.19 2.04 2.05
1024.00 14 13.79 4 3 93 2.08 2.02 2.04
1024.00 14 13.70 4 3 93 2.23 2.05 2.05
1024.00 14 13.90 5 3 92 1.96 2.00 2.03
1024.00 13 12.90 8 4 88 2.05 2.01 2.04
1024.00 14 13.80 4 3 93 1.96 2.00 2.03
1024.00 14 13.79 4 3 93 1.97 2.00 2.03
1024.00 14 13.70 2 3 95 1.82 1.96 2.02
1024.00 14 13.90 2 3 95 1.76 1.95 2.01
769.03 12 9.31 6 3 91 1.87 1.97 2.01
8.00 0 0.00 2 3 95 2.12 2.02 2.03
0.00 0 0.00 2 2 95 2.10 2.01 2.03
0.00 0 0.00 5 3 93 2.15 2.03 2.03
Nach dem Boot ist der Raspberry Pi automatisch im Netzwerk (LAN) erreichbar (wenn man DHCP nutzt, wovon ich mal ausgehe).
Die IP-Adresse entnimmt man entweder seinem DHCP-Server oder dem Boot-Screen des Pi.
Benutzer/Passwort für die erste Anmeldung:
Wer direkt mit der Tastatur am Pi angeschlossen ist, sollte beachten dass standardmäßig ein QWERTY-Tastaturlayout hinterlegt ist. Man sollte also „raspberrz“ eintippen. Bei SSH gilt euer eigenes Tastaturlayout.
BennyE$ ssh pi@192.168.5.156 The authenticity of host '192.168.5.156 (192.168.5.156)' can't be established. RSA key fingerprint is c8:c2:66:d9:74:ca:0a:ed:4a:0c:80:b3:c5:e9:27:d5. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.5.156' (RSA) to the list of known hosts. pi@192.168.5.156's password: raspberry The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. pi@raspberrypi:~ $
Im nächsten Schritt wollen wir dem Raspberry Pi das korrekte Tastaturlayout verpassen, die Zeitzone auf Berlin einstellen, den Hostname setzen und optional (wenn vorhanden) die Wi-Fi/Wireless Schnittstelle auf Deutschland einrichten.
pi@raspberrypi:~ $ sudo raspi-config
Für deutsches Tastaturlayout wählt nacheinander:
„Internationalisation Options“ →
„Keyboard Layout“→
z.B. „Generic 105-key (Intl) PC“ →
„Other“ →
„German“ →
„German“ →
„The default for the keyboard layout“ →
„No compose key“
Für deutsche Zeitzone wählt nacheinander:
„Internationalisation Options“ →
„Change Timezone“ →
„Europe“ →
„Berlin“
Den Hostname des Raspberry Pi festlegen:
„Advanced Options“ →
„Hostname“ →
„OK“ →
„pi1“ (wahlweise was ihr wollt)
Für deutsche regulatorische Domäne Wi-Fi/Wireless:
„Internationalisation Options“ →
„Change Wi-fi Country“ →
„DE Germany“
Nach diesen Änderungen ist ein Neustart notwendig, wählt „Finish“ und ihr werdet nach dem Reboot gefragt den ihr mit „Yes“ bestätigt.
Nach dem Neustart aus dem vorherigen Schritt, steht erst einmal eine Aktualisierung des Betriebssystems an (Korrekturen und Behebung von poteniellen Sicherheitsproblemen). Dieses Thema solltet ihr ernst nehmen!
pi@raspberrypi:~ $ sudo apt-get update && sudo apt-get dist-upgrade
Der Raspberry aktualisiert daraufhin erst einmal die Informationsbasis welche Pakete aktuell sind und bietet euch danach zahlreiche Pakete zur Aktualisierung an:
Do you want to continue? [Y/n]
Dies mit „Enter“ bestätigen und warten …
Um ungebetene Gäste vom System fernzuhalten, sollte nun das Passwort geändert werden:
pi@raspberrypi:~ $ sudo raspi-config
Um das Passwort zu ändern, wählt:
„Change User Password“ →
„OK“ →
Enter new UNIX password:
Retype new UNIX password:
pi@raspberrypi:~ $ sudo apt-get install -y vim tcpdump iperf3
Optional (smcroute)
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6
bzw. in der sysctl.conf
net.ipv6.conf.all.disable_ipv6 = 1
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE sudo iptables -A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT sudo iptables -A FORWARD -i wlan0 -o eth0 -j ACCEPT sudo sh -c "iptables-save > /etc/iptables.ipv4.nat" # In /etc/network/interfaces o.ae. irgendwo unten up iptables-restore < /etc/iptables.ipv4.nat
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:Ethernet HWaddr b8:27:eb:82:26:a8
inet addr:192.168.5.155 Bcast:192.168.5.255 Mask:255.255.255.0
inet6 addr: fe80::e72a:7f1b:ac2c:ca62/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:123 errors:0 dropped:0 overruns:0 frame:0
TX packets:126 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:12051 (11.7 KiB) TX bytes:16815 (16.4 KiB)
pi@pi1:~ $ ip maddr show dev eth0
2: eth0
link 33:33:00:00:00:01
link 33:33:ff:2c:ca:62
link 01:00:5e:00:00:01
link 33:33:00:00:00:fb
link 01:00:5e:00:00:fb
inet 224.0.0.251
inet 224.0.0.1
inet6 ff02::fb
inet6 ff02::1:ff2c:ca62
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, 0 received, 100% packet loss, time 5004ms
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:43:11.536867 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.5.155 > 239.0.10.1: ICMP echo request, id 828, seq 1, length 64
20:43:12.544589 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.5.155 > 239.0.10.1: ICMP echo request, id 828, seq 2, length 64
20:43:13.544467 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.5.155 > 239.0.10.1: ICMP echo request, id 828, seq 3, length 64
20:43:14.544464 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.5.155 > 239.0.10.1: ICMP echo request, id 828, seq 4, length 64
20:43:15.544456 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
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 = disabled, Querying = disabled, Proxying = disabled, Spoofing = disabled, Zapping = disabled, Querier Forwarding = disabled, Flood Unknown = disabled, Dynamic control drop-all status = disabled, Version = 2, Robustness = 2, Query Interval (seconds) = 125, Query Response Interval (tenths of seconds) = 100, Last Member Query Interval (tenths of seconds) = 10, Unsolicited Report Interval (seconds) = 1, Router Timeout (seconds) = 90, Source Timeout (seconds) = 30, Max-group = 0, Max-group action = none -> ip multicast status enable -> show ip multicast Status = enabled, Querying = disabled, Proxying = disabled, Spoofing = disabled, Zapping = disabled, Querier Forwarding = disabled, Flood Unknown = disabled, Dynamic control drop-all status = disabled, Version = 2, Robustness = 2, Query Interval (seconds) = 125, Query Response Interval (tenths of seconds) = 100, Last Member Query Interval (tenths of seconds) = 10, Unsolicited Report Interval (seconds) = 1, Router Timeout (seconds) = 90, Source Timeout (seconds) = 30, Max-group = 0, Max-group action = none
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, 0 received, 100% packet loss, time 4004ms
-> show ip multicast source Total 1 Sources Group Address Host Address Tunnel Address VLAN Port ---------------+---------------+---------------+-----+----- 239.0.10.1 192.168.5.155 0.0.0.0 1 1/7
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, man kann aber keine neuen Gruppen manuell registrieren.
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 -dSendet einen „IGMP-Join“ über die angegebene Schnittstelle und registriert dies lokal auch im Kernel
sudo smcroute -j eth0 239.0.10.1Sendet einen IGMP-Leave„ über die angegebene Schnittstele
sudo smcroute -l eth0 239.0.10.1Beendet den Prozess
sudo smcroute -k
Alternativ kann man das Paket „socat“ verwenden (mir gefällt smcroute derzeit besser):
Registriert die Adresse 239.0.10.1 auf der Schnittstelle eth0pi@pi2:~ $ socat STDIO UDP4-RECV:1234,ip-add-membership=239.0.10.1:eth0
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:25:04.000098 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))
192.168.5.156 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 239.0.10.1 to_ex { }]
21:25:04.750039 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))
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, 0 received, 100% packet loss, time 9003ms
Der OmniSwitch 6450 sieht die Pakete und vermittelt sie auch weiter
-> show ip multicast source Total 1 Sources Group Address Host Address Tunnel Address VLAN Port ---------------+---------------+---------------+-----+----- 239.0.10.1 192.168.5.155 0.0.0.0 1 1/7 -> show ip multicast group Total 1 Groups Group Address Source Address VLAN Port Mode Static Count Life RVLAN ---------------+---------------+-----+-----+--------+-------+------+-----+------ 239.0.10.1 0.0.0.0 1 1/3 exclude no 2 133 -
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:25:25.919115 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.5.155 > 239.0.10.1: ICMP echo request, id 873, seq 2, length 64
21:25:26.919035 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.5.155 > 239.0.10.1: ICMP echo request, id 873, seq 3, length 64
21:25:27.919029 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.5.155 > 239.0.10.1: ICMP echo request, id 873, seq 4, length 64
21:27:06.528880 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.5.155 > 239.0.10.1: ICMP echo request, id 874, seq 2, length 64
21:27:07.528765 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.5.155 > 239.0.10.1: ICMP echo request, id 874, seq 3, length 64
21:27:08.528766 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.5.155 > 239.0.10.1: ICMP echo request, id 874, seq 4, length 64
21:27:09.528757 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.5.155 > 239.0.10.1: ICMP echo request, id 874, seq 5, length 64
21:27:10.528758 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.5.155 > 239.0.10.1: ICMP echo request, id 874, seq 6, length 64
21:27:11.528757 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.5.155 > 239.0.10.1: ICMP echo request, id 874, seq 7, length 64
21:27:12.528759 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.5.155 > 239.0.10.1: ICMP echo request, id 874, seq 8, length 64
21:27:13.528761 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.5.155 > 239.0.10.1: ICMP echo request, id 874, seq 9, length 64
21:27:14.528757 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
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 „vergessen“ wird vom Switch. Dies liegt daran dass der smcroute Daemon nicht selbstständig die Registrierung aktiv hält, sondern darum gebeten werden muss.
Wir aktivieren dafür „ip multicast querying“ auf dem OmniSwitch 6450
-> show ip multicast Status = enabled, Querying = disabled, Proxying = disabled, Spoofing = disabled, Zapping = disabled, Querier Forwarding = disabled, Flood Unknown = disabled, Dynamic control drop-all status = disabled, Version = 2, Robustness = 2, Query Interval (seconds) = 125, Query Response Interval (tenths of seconds) = 100, Last Member Query Interval (tenths of seconds) = 10, Unsolicited Report Interval (seconds) = 1, Router Timeout (seconds) = 90, Source Timeout (seconds) = 30, Max-group = 0, Max-group action = none -> ip multicast querying enable -> show ip multicast Status = enabled, Querying = enabled, Proxying = disabled, Spoofing = disabled, Zapping = disabled, Querier Forwarding = disabled, Flood Unknown = disabled, Dynamic control drop-all status = disabled, Version = 2, Robustness = 2, Query Interval (seconds) = 125, Query Response Interval (tenths of seconds) = 100, Last Member Query Interval (tenths of seconds) = 10, Unsolicited Report Interval (seconds) = 1, Router Timeout (seconds) = 90, Source Timeout (seconds) = 30, Max-group = 0, Max-group action = none -> show ip multicast querier Total 1 Queriers Host Address VLAN Port Static Count Life ---------------+-----+-----+-------+------+----- 192.168.5.104 1 CPU no 0 24
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 Source Address VLAN Port Mode Static Count Life RVLAN ---------------+---------------+-----+-----+--------+-------+------+-----+------ 239.0.10.1 0.0.0.0 1 1/3 exclude no 5 257 - -> show ip multicast group Total 1 Groups Group Address Source Address VLAN Port Mode Static Count Life RVLAN ---------------+---------------+-----+-----+--------+-------+------+-----+------ 239.0.10.1 0.0.0.0 1 1/3 exclude no 7 173 - -> show ip multicast group Total 1 Groups Group Address Source Address VLAN Port Mode Static Count Life RVLAN ---------------+---------------+-----+-----+--------+-------+------+-----+------ 239.0.10.1 0.0.0.0 1 1/3 exclude no 5 259 - -> ->
So sieht dies auf Seite des Pi2 aus
pi@pi2:~ $ sudo tshark -i eth0 -Y igmp tshark: Lua: Error during loading: [string "/usr/share/wireshark/init.lua"]:46: dofile has been disabled due to running Wireshark as superuser. See http://wiki.wireshark.org/CaptureSetup/CapturePrivileges for help in running Wireshark as an unprivileged user. Running as user "root" and group "root". This could be dangerous. Capturing on 'eth0' 46 16.914403 192.168.5.156 -> 239.0.10.1 IGMPv2 46 Membership Report group 239.0.10.1 57 24.554366 192.168.5.156 -> 239.0.10.1 IGMPv2 46 Membership Report group 239.0.10.1 64 30.954357 192.168.5.156 -> 239.0.10.1 IGMPv2 46 Membership Report group 239.0.10.1 73 41.338705 192.168.5.104 -> 224.0.0.1 IGMPv2 60 Membership Query, general <--------- 84 48.614361 192.168.5.156 -> 224.0.0.251 IGMPv2 46 Membership Report group 224.0.0.251 90 50.834353 192.168.5.156 -> 239.0.10.1 IGMPv2 46 Membership Report group 239.0.10.1 <- !!!! ^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 /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts 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: [string "/usr/share/wireshark/init.lua"]:46: dofile has been disabled due to running Wireshark as superuser. See http://wiki.wireshark.org/CaptureSetup/CapturePrivileges for help in running Wireshark as an unprivileged user. Running as user "root" and group "root". This could be dangerous. Capturing on 'eth0' 10 4.793110 192.168.5.155 -> 239.0.10.1 ICMP 98 Echo (ping) request id=0x0699, seq=2/512, ttl=1 11 4.793220 192.168.5.156 -> 192.168.5.155 ICMP 98 Echo (ping) reply id=0x0699, seq=2/512, ttl=64 19 5.793032 192.168.5.155 -> 239.0.10.1 ICMP 98 Echo (ping) request id=0x0699, seq=3/768, ttl=1 20 5.793124 192.168.5.156 -> 192.168.5.155 ICMP 98 Echo (ping) reply id=0x0699, seq=3/768, ttl=64 28 6.793028 192.168.5.155 -> 239.0.10.1 ICMP 98 Echo (ping) request id=0x0699, seq=4/1024, ttl=1 29 6.793128 192.168.5.156 -> 192.168.5.155 ICMP 98 Echo (ping) reply id=0x0699, seq=4/1024, ttl=64 35 7.793004 192.168.5.155 -> 239.0.10.1 ICMP 98 Echo (ping) request id=0x0699, seq=5/1280, ttl=1 36 7.793078 192.168.5.156 -> 192.168.5.155 ICMP 98 Echo (ping) reply id=0x0699, seq=5/1280, ttl=64 44 8.793011 192.168.5.155 -> 239.0.10.1 ICMP 98 Echo (ping) request id=0x0699, seq=6/1536, ttl=1 45 8.793096 192.168.5.156 -> 192.168.5.155 ICMP 98 Echo (ping) reply id=0x0699, seq=6/1536, ttl=64 51 9.793004 192.168.5.155 -> 239.0.10.1 ICMP 98 Echo (ping) request id=0x0699, seq=7/1792, ttl=1 52 9.793076 192.168.5.156 -> 192.168.5.155 ICMP 98 Echo (ping) reply id=0x0699, seq=7/1792, ttl=64 60 10.793052 192.168.5.155 -> 239.0.10.1 ICMP 98 Echo (ping) request id=0x0699, seq=8/2048, ttl=1 61 10.793149 192.168.5.156 -> 192.168.5.155 ICMP 98 Echo (ping) reply id=0x0699, seq=8/2048, ttl=64 67 11.793021 192.168.5.155 -> 239.0.10.1 ICMP 98 Echo (ping) request id=0x0699, seq=9/2304, ttl=1 68 11.793093 192.168.5.156 -> 192.168.5.155 ICMP 98 Echo (ping) reply id=0x0699, seq=9/2304, ttl=64 74 12.793017 192.168.5.155 -> 239.0.10.1 ICMP 98 Echo (ping) request id=0x0699, seq=10/2560, ttl=1 75 12.793100 192.168.5.156 -> 192.168.5.155 ICMP 98 Echo (ping) reply id=0x0699, seq=10/2560, ttl=64 76 13.149535 192.168.5.104 -> 224.0.0.1 IGMPv2 60 Membership Query, general 84 13.793005 192.168.5.155 -> 239.0.10.1 ICMP 98 Echo (ping) request id=0x0699, seq=11/2816, ttl=1 85 13.793076 192.168.5.156 -> 192.168.5.155 ICMP 98 Echo (ping) reply id=0x0699, seq=11/2816, ttl=64 91 14.793031 192.168.5.155 -> 239.0.10.1 ICMP 98 Echo (ping) request id=0x0699, seq=12/3072, ttl=1 92 14.793119 192.168.5.156 -> 192.168.5.155 ICMP 98 Echo (ping) reply id=0x0699, seq=12/3072, ttl=64 100 15.793022 192.168.5.155 -> 239.0.10.1 ICMP 98 Echo (ping) request id=0x0699, seq=13/3328, ttl=1 101 15.793091 192.168.5.156 -> 192.168.5.155 ICMP 98 Echo (ping) reply id=0x0699, seq=13/3328, ttl=64 107 16.793035 192.168.5.155 -> 239.0.10.1 ICMP 98 Echo (ping) request id=0x0699, seq=14/3584, ttl=1 108 16.793121 192.168.5.156 -> 192.168.5.155 ICMP 98 Echo (ping) reply id=0x0699, seq=14/3584, ttl=64 110 17.135066 192.168.5.156 -> 239.0.10.1 IGMPv2 46 Membership Report group 239.0.10.1 118 17.793027 192.168.5.155 -> 239.0.10.1 ICMP 98 Echo (ping) request id=0x0699, seq=15/3840, ttl=1 119 17.793098 192.168.5.156 -> 192.168.5.155 ICMP 98 Echo (ping) reply id=0x0699, seq=15/3840, ttl=64 125 18.793047 192.168.5.155 -> 239.0.10.1 ICMP 98 Echo (ping) request id=0x0699, seq=16/4096, ttl=1 126 18.793144 192.168.5.156 -> 192.168.5.155 ICMP 98 Echo (ping) reply id=0x0699, seq=16/4096, ttl=64 134 19.793026 192.168.5.155 -> 239.0.10.1 ICMP 98 Echo (ping) request id=0x0699, seq=17/4352, ttl=1 135 19.793099 192.168.5.156 -> 192.168.5.155 ICMP 98 Echo (ping) reply id=0x0699, seq=17/4352, ttl=64 141 20.793037 192.168.5.155 -> 239.0.10.1 ICMP 98 Echo (ping) request id=0x0699, seq=18/4608, ttl=1 142 20.793124 192.168.5.156 -> 192.168.5.155 ICMP 98 Echo (ping) reply id=0x0699, seq=18/4608, ttl=64 148 21.793024 192.168.5.155 -> 239.0.10.1 ICMP 98 Echo (ping) request id=0x0699, seq=19/4864, ttl=1 149 21.793100 192.168.5.156 -> 192.168.5.155 ICMP 98 Echo (ping) reply id=0x0699, seq=19/4864, ttl=64 155 22.765096 192.168.5.156 -> 224.0.0.251 IGMPv2 46 Membership Report group 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 „User-Network-Profile“ (UNP) angebunden und per non-supplicant Authentifizierung ist. (Dann sollte kein Eintrag in der Ausgabe von „ip multicast group“ auftauchen)
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 <192.168.5.1/rad01> 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 "non-supplicant" -> 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 Classification Vlan Port Address Status Policy Learned -----+-----------------+----------------+-------------------+-------- 01/03 b8:27:eb:61:78:ec Authenticated Basic-Dft VLAN 1 -> ! Aber es ging ja um das UNP, daher .. -> aaa user-network-profile name "mcasttest" vlan 1 -> show 802.1x non-supplicant Slot MAC MAC Authent Classification Vlan Port Address Status Policy Learned -----+-----------------+----------------+-------------------+-------- 01/03 b8:27:eb:61:78:ec Authenticated Basic-UNP-Auth Svr 1 -> show 802.1x non-supplicant unp Slot MAC Vlan HIC Dynamic Port Address Status UNP -----+-----------------+-----+---------------+----------------- 01/03 b8:27:eb:61:78:ec 1 Not Started mcasttest -> show ip multicast group Total 1 Groups Group Address Source Address VLAN Port Mode Static Count Life RVLAN ---------------+---------------+-----+-----+--------+-------+------+-----+------ 239.0.10.1 0.0.0.0 1 1/3 exclude no 2 155 -
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 = "B827EB6178EC"
User-Password = "B827EB6178EC"
NAS-IP-Address = 192.168.5.104
NAS-Port = 77
NAS-Port-Type = Ethernet
Calling-Station-Id = "b827eb6178ec"
Service-Type = Call-Check
# Executing section authorize from file /etc/freeradius/sites-enabled/default
+group authorize {
++[preprocess] = ok
++[chap] = noop
++[mschap] = noop
++[digest] = noop
[suffix] No '@' in User-Name = "B827EB6178EC", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] = noop
[eap] No EAP-Message, not doing EAP
++[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 /etc/freeradius/sites-enabled/default
+group PAP {
[pap] login attempt with password "B827EB6178EC"
[pap] Using clear text password "B827EB6178EC"
[pap] User authenticated successfully
++[pap] = ok
+} # group PAP = ok
# Executing section post-auth from file /etc/freeradius/sites-enabled/default
+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 = "mcasttest"
Finished request 0.
Going to the next request
Waking up in 4.9 seconds.
Cleaning up request 0 ID 4 with timestamp +23