Using Google Chromecasts with Aruba Instant APs

Von | | , ,
Einen Kommentar hinterlassen

I bought two Aruba IAP-205 Instant access points a while back. I was stoked about deploying them in my home environment as I knew that this enterprise grade hardware is used frequently by big organisations and on events with thousand of visitors which fluenty roam from AP to AP while walking around the premises.
Soon after the deployment I discovered that my Google Chromecasts could no longer be discovered by Chromecast enabled applications. Bummer. Some testing, a couple hours of research and a lot of swearing later the IAPs got replaced by some shiny new Ubiquiti APs and everything was working right out of the box.

Fast forward a couple years. I revisited the IAPs after the friend I bought them from told me about some firmware changes that might be the solution to my connection problems. Quickly set them up and upgraded to the latest available firmware (6.5.4.14) and tried to reach my Chromecast. Again no luck. In fact it got even worse: my multi room system based on Yamaha MusicCast was also unable to discover or control the connected speakers.
This can’t be right. These devices get used on campuses where students have devices like AppleTVs or Chromecasts in their dorm rooms and they don’t seem to have any troubles using them. What was I doing wrong? Again I spent some hours researching and found numerous threads in the Airheads community board which all told me to limit broadcast filtering to ARP requests, enable multicast optimization and to activate the Chromecast and DLNA AirGroups in the Services menue.

SSID Multicast settings

Of course I already did that but even though I was able to discover the Chromecasts, I still was unable to connect to them. Only in one thread someone mentioned, that enabling the AirGroups alone wasn’t enough. You additionally have to disable the pre-defined DLNA and Bonjour options!

AirGroup settings

After doing this everything was working flawless. Discovering and using the Chromecasts and MusicCast speakers withouth any trouble at all. I searched the documentation for these options to understand what happens under the hood but interestingly enough there is no mention of these switches in the newer revisions. In older revision of the documentation you can find mentions of the DLNA option but without any explanation what it does and especially why it interferes with the AirGroups. As of now I cannot explain what is happening if you enable these. I checked the status of the standalone AirGroups before and after disabling the pre-defined ones but they always say „Enabled“ even though they obviously do not work when the pre-defined options are enabled. Let me know if you know more about this.

Update: Setting the Broadcast filtering option to ARP, prevents clients to receive SLAAC or DHCPv6 messages thus effectivly blocking the automatic assignment of IPv6 addresses to your clients! If you want a dual-stack WiFi setup you must set the Broadcast filtering option to Disabled.

Hetzner Cloud: LUKS remote unlock on Debian

Von | | , ,
Einen Kommentar hinterlassen

I recently decided to migrate my mailserver away from the (old) Uberspace 6 to a new, self administrated machine. Uberspace has been great but over time I demanded more features than they offer.
Due to the fact that I want to keep the mailserver for my primary mail address separated from my main server, I once again compared multiple virtual server/cloud server hosters. I decided to give Hetzners new Cloud Server a go as you can use custom images to build the OS (Debian is the distribution of my choice) as you like. That was particularly important to me because as this will be the place where all my existing private mails will be stored it has to be fully encrypted. Because of that I needed some kind of remote unlock mechanism to be able to unlock the machine after a reboot without the need to log into the Hetzner web interface and use the console.
There are plenty of how-to’s on how to achive this with Beardrop as SSH server in initramfs and Busybox as shell but none of these seemed to work as Beardrop never got available on the configured port. What I did notice was this error message during boot up:

SIOCSIFNETMASK: Cannot assign requested address

This correlates with an article in the Hetzner wiki about the default gateway for custom installations on cloud servers as their GW is outside of the used subnet. Even when using DHCP to retrieve the IP and default GW, the setup fails as NetworkManager refuses to use the given GW. The same for static IP configuration in /etc/initramfs-tools/initramfs.conf or /etc/default/grub. So probably Dropbear does not start because the network fails.
I found only one report on this exact problem after hours of trial and error and searching the web for help.

tl;dr

To fix this you need to hook in before the network is set up and add the default route yourself. To do that you can either add a hook in /usr/share/initramfs-tools/hooks or (like the Serverfault thread suggests) add two statements to /usr/share/initramfs-tools/scripts/functions:

ip route add ${IPV4GATEWAY}/${IPV4NETMASK} dev ${DEVICE}
ip route add default via ${IPV4GATEWAY} dev ${DEVICE}

To ensure that this methods works you have to remove the static IP configureation in grub and/or initramfs.conifig and enable DHCP again!

Spacewalk: Failed channel syncs because of duplicate packages

Von | | , ,
5 Kommentare

A brief summary:
I’m working with Spacewalk for three years now, from version 2.4 on. We manage about 350 systems, 30+ channels, 50+ repositories and 105.000+ packages. We import new packages and errata on a daily basis, roll out critical patches to stage systems automatically and do weekly/monthly patchdays on productive systems exclusively via Spacewalk.

Lately the periodic syncs of our CentOS 6 x86_64 channel failed on every run. New packages stayed in the queue and could not be rolled out to our systems. The Taskomatic daemon sent out error notification emails to the configured administrator mailbox in which it basically tells you that the repo-sync-bunch failed and in which logfile you can read more about this issue.

The error:13:37:56 ERROR: (23, 'ERROR: duplicate key value violates unique constraint "rhn_cnp_cid_nid_uq"', 'Could not update database entry.')
13:37:56 Repo URL: http://mirror.centos.org/centos/6/extras/x86_64/
Traceback (most recent call last):
File "/usr/bin/spacewalk-repo-sync", line 257, in <module>
[...]
spacewalk.server.rhnSQL.sql_base.SQLSchemaError: (99999, 'ERROR: current transaction is aborted, commands ignored until end of transaction block', '', InternalError('current transaction is aborted, commands ignored until end of transaction block\n',))
2018-07-12 11:30:47,557 [DefaultQuartzScheduler_Worker-10] ERROR com.redhat.rhn.taskomatic.task.RepoSyncTask - Executing a task threw an exception: org.quartz.JobExecutionException
2018-07-12 11:30:47,557 [DefaultQuartzScheduler_Worker-10] ERROR com.redhat.rhn.taskomatic.task.RepoSyncTask - Message: Command '[/usr/bin/spacewalk-repo-sync, --channel, centos6_x86_64, --type, yum]' exited with error code 1
2018-07-12 11:30:47,558 [DefaultQuartzScheduler_Worker-10] ERROR com.redhat.rhn.taskomatic.task.RepoSyncTask - Cause: null
2018-07-12 11:30:47,558 [DefaultQuartzScheduler_Worker-10] ERROR com.redhat.rhn.taskomatic.task.RepoSyncTask - Stack trace:org.quartz.JobExecutionException: Command '[/usr/bin/spacewalk-repo-sync, --channel, centos6_x86_64, --type, yum]' exited with error code 1
[...]

Okay so what do we have here? Obviously it’s something about the database and a duplicate primary key. We also have the repository that caused the error to happen. No hint which entry is the duplicate whatsoever. But we do have the failed command so let’s try that on our own and strace the process and it’s forks:[...]
23319 sendto(5, "Q\0\0\0?select LOOKUP_PACKAGE_NEVRA"..., 64, MSG_NOSIGNAL, NULL, 0) = 64
23319 poll([{fd=5, events=POLLIN|POLLERR}], 1, -1) = 1 ([{fd=5, revents=POLLIN}])
23319 recvfrom(5, "T\0\0\0\33\0\1id\0\0\0\0\0\0\0\0\0\6\244\377\377\377\377\377\377\0\0D\0\0\0"..., 16384, 0, NULL, NULL) = 65
23319 sendto(5, "Q\0\0\0\210select * from rhnPackage wh"..., 137, MSG_NOSIGNAL, NULL, 0) = 137
23319 poll([{fd=5, events=POLLIN|POLLERR}], 1, -1) = 1 ([{fd=5, revents=POLLIN}])
23319 recvfrom(5, "T\0\0\3#\0\34id\0\0\0\240\4\0\1\0\0\6\244\377\377\377\377\377\377\0\0org_"..., 16384, 0, NULL, NULL) = 1346
23319 sendto(5, "Q\0\0\0\210select * from rhnPackage wh"..., 137, MSG_NOSIGNAL, NULL, 0) = 137
23319 poll([{fd=5, events=POLLIN|POLLERR}], 1, -1) = 1 ([{fd=5, revents=POLLIN}])
23319 recvfrom(5, "T\0\0\3#\0\34id\0\0\0\240\4\0\1\0\0\6\244\377\377\377\377\377\377\0\0org_"..., 16384, 0, NULL, NULL) = 1682
23319 sendto(5, "Q\0\0\0\211select * from rhnPackage wh"..., 138, MSG_NOSIGNAL, NULL, 0) = 138
23319 poll([{fd=5, events=POLLIN|POLLERR}], 1, -1) = 1 ([{fd=5, revents=POLLIN}])
23319 recvfrom(5, "T\0\0\3#\0\34id\0\0\0\240\4\0\1\0\0\6\244\377\377\377\377\377\377\0\0org_"..., 16384, 0, NULL, NULL) = 1478
23319 sendto(5, "Q\0\0\0l\n select channel"..., 109, MSG_NOSIGNAL, NULL, 0) = 109
23319 poll([{fd=5, events=POLLIN|POLLERR}], 1, -1) = 1 ([{fd=5, revents=POLLIN}])
23319 recvfrom(5, "T\0\0\0#\0\1channel_id\0\0\0\242\255\0\1\0\0\6\244\377\377\377\377"..., 16384, 0, NULL, NULL) = 56
23319 sendto(5, "Q\0\0\0l\n select channel"..., 109, MSG_NOSIGNAL, NULL, 0) = 109
23319 poll([{fd=5, events=POLLIN|POLLERR}], 1, -1) = 1 ([{fd=5, revents=POLLIN}])
23319 recvfrom(5, "T\0\0\0#\0\1channel_id\0\0\0\242\255\0\1\0\0\6\244\377\377\377\377"..., 16384, 0, NULL, NULL) = 56
23319 sendto(5, "Q\0\0\0l\n select channel"..., 109, MSG_NOSIGNAL, NULL, 0) = 109
23319 poll([{fd=5, events=POLLIN|POLLERR}], 1, -1) = 1 ([{fd=5, revents=POLLIN}])
23319 recvfrom(5, "T\0\0\0#\0\1channel_id\0\0\0\242\255\0\1\0\0\6\244\377\377\377\377"..., 16384, 0, NULL, NULL) = 56
23319 sendto(5, "Q\0\0\1W\n select pac"..., 344, MSG_NOSIGNAL, NULL, 0) = 344
23319 poll([{fd=5, events=POLLIN|POLLERR}], 1, -1) = 1 ([{fd=5, revents=POLLIN}])
23319 recvfrom(5, "T\0\0\0#\0\1package_id\0\0\0\242\255\0\2\0\0\6\244\377\377\377\377"..., 16384, 0, NULL, NULL) = 56

Not very helpful in my opinion as there is no clue on what the package_id is that caused the error. It only confirms what we already know. But when it’s something in correlation to the database we should be able to get more information by logging all the queries done during the sync process, right? After enabling log_destination = 'stderr' and log_directory = 'pg_log' in postgresql.conf (assuming your Spacewalk installation uses a pgSQL DB), I restarted the sync and watched the PostgreSQL log closely:
2018-07-12 13:11:09.736 CEST LOG: statement: select LOOKUP_PACKAGE_NAME('centos-release') id from dual
2018-07-12 13:11:09.737 CEST LOG: statement: select LOOKUP_PACKAGE_NAME('python-setuptools') id from dual
2018-07-12 13:11:09.737 CEST LOG: statement: select LOOKUP_PACKAGE_NAME('sysstat') id from dual
2018-07-12 13:11:09.738 CEST LOG: statement: select LOOKUP_EVR(NULL, '9.0.4', '33.el6_9.1') id from dual
2018-07-12 13:11:09.753 CEST LOG: statement: select LOOKUP_EVR(NULL, '6', '10.el6.centos.12.3') id from dual
2018-07-12 13:11:09.767 CEST LOG: statement: select LOOKUP_EVR(NULL, '0.6.10', '4.el6_9') id from dual
2018-07-12 13:11:09.794 CEST LOG: statement: BEGIN
2018-07-12 13:11:09.795 CEST LOG: statement: lock table rhnChecksum in exclusive mode
2018-07-12 13:11:09.797 CEST LOG: statement: select lookup_checksum_fast('sha256', '3cdb75f0d06fe1d39cee6f010a2a487d1b2ba595fa3197bbfac9e9050b2c233f') id from dual
2018-07-12 13:11:09.894 CEST LOG: statement: select lookup_checksum_fast('sha256', '65fa114e7d947143580f98a5feeb652ceb7ebdd8b27fba65ba0b383b250c63d3') id from dual
2018-07-12 13:11:09.922 CEST LOG: statement: select lookup_checksum_fast('sha256', 'e0c9c45557bc787d85417b1daa3799ae61bab899e6475b793cf3488309f94304') id from dual
2018-07-12 13:11:09.954 CEST LOG: statement: COMMIT
2018-07-12 13:11:09.955 CEST LOG: statement: select LOOKUP_PACKAGE_NEVRA(603, 28320, 120) id from dual
2018-07-12 13:11:09.959 CEST LOG: statement: select LOOKUP_PACKAGE_NEVRA(5339, 28321, 100) id from dual
2018-07-12 13:11:09.973 CEST LOG: statement: select LOOKUP_PACKAGE_NEVRA(5913, 28322, 120) id from dual
2018-07-12 13:11:09.974 CEST LOG: statement: select * from rhnPackage where org_id = 1 and name_id = 603 and evr_id = 28320 and package_arch_id = 120 and checksum_id = 10000270
2018-07-12 13:11:09.987 CEST LOG: statement: select * from rhnPackage where org_id = 1 and name_id = 5339 and evr_id = 28321 and package_arch_id = 100 and checksum_id = 9998526
2018-07-12 13:11:09.989 CEST LOG: statement: select * from rhnPackage where org_id = 1 and name_id = 5913 and evr_id = 28322 and package_arch_id = 120 and checksum_id = 10000274
2018-07-12 13:11:09.990 CEST LOG: statement:
select channel_id
from rhnChannelPackage
where package_id = 121940
2018-07-12 13:11:09.991 CEST LOG: statement:
select channel_id
from rhnChannelPackage
where package_id = 121941
2018-07-12 13:11:09.992 CEST LOG: statement:
select channel_id
from rhnChannelPackage
where package_id = 121942
2018-07-12 13:11:09.992 CEST LOG: statement:
select package_id
from rhnChannelPackage cp
join rhnPackage p
on p.id = cp.package_id
join rhnChannel c
on c.id = cp.channel_id
where cp.channel_id = 105
and c.org_id != p.org_id
2018-07-12 13:11:10.206 CEST LOG: statement: insert into rhnChannelPackage (channel_id, package_id) values (105, 121940)
2018-07-12 13:11:10.230 CEST LOG: statement: insert into rhnChannelPackage (channel_id, package_id) values (105, 121941)
2018-07-12 13:11:10.230 CEST LOG: statement: insert into rhnChannelPackage (channel_id, package_id) values (105, 121942)
2018-07-12 13:11:10.231 CEST LOG: statement: SELECT rhn_channel.refresh_newest_package(105, 'server.app.yumreposync', 603)
2018-07-12 13:11:10.406 CEST LOG: statement: SELECT rhn_channel.refresh_newest_package(105, 'server.app.yumreposync', 5339)
2018-07-12 13:11:10.459 CEST ERROR: duplicate key value violates unique constraint "rhn_cnp_cid_nid_uq"
2018-07-12 13:11:10.459 CEST DETAIL: Key (channel_id, name_id, package_arch_id)=(105, 5339, 100) already exists.
2018-07-12 13:11:10.459 CEST CONTEXT: SQL statement "insert into rhnChannelNewestPackage
(channel_id, name_id, evr_id, package_id, package_arch_id)
(select channel_id,
name_id, evr_id,
package_id, package_arch_id
from rhnChannelNewestPackageView
where channel_id = channel_id_in
and (package_name_id_in is null
or name_id = package_name_id_in)
)"
PL/pgSQL function rhn_channel.refresh_newest_package(numeric,character varying,numeric) line 9 at SQL statement
2018-07-12 13:11:10.459 CEST STATEMENT: SELECT rhn_channel.refresh_newest_package(105, 'server.app.yumreposync', 5339)
2018-07-12 13:11:10.462 CEST LOG: statement:
select k1.description as ca_cert_name, k1.key as ca_cert, k1.org_id as ca_cert_org,
k2.description as client_cert_name, k2.key as client_cert, k2.org_id as client_cert_org,
k3.description as client_key_name, k3.key as client_key, k3.org_id as client_key_org
from rhncontentsource cs inner join
rhncontentsourcessl csssl on cs.id = csssl.content_source_id inner join
rhncryptokey k1 on csssl.ssl_ca_cert_id = k1.id left outer join
rhncryptokey k2 on csssl.ssl_client_cert_id = k2.id left outer join
rhncryptokey k3 on csssl.ssl_client_key_id = k3.id
where cs.id = 507
2018-07-12 13:11:10.462 CEST ERROR: current transaction is aborted, commands ignored until end of transaction block
2018-07-12 13:11:10.462 CEST STATEMENT:
select k1.description as ca_cert_name, k1.key as ca_cert, k1.org_id as ca_cert_org,
k2.description as client_cert_name, k2.key as client_cert, k2.org_id as client_cert_org,
k3.description as client_key_name, k3.key as client_key, k3.org_id as client_key_org
from rhncontentsource cs inner join
rhncontentsourcessl csssl on cs.id = csssl.content_source_id inner join
rhncryptokey k1 on csssl.ssl_ca_cert_id = k1.id left outer join
rhncryptokey k2 on csssl.ssl_client_cert_id = k2.id left outer join
rhncryptokey k3 on csssl.ssl_client_key_id = k3.id
where cs.id = 507

Marked in red we have the package_ids that have to be in any way responsible for the failed sync. Let’s do a quick search via the GUI to find out more about them. After looking them up one by one I discovered that all three of them where still in the package queue and not associated with a channel yet. You can check that in the software package manager.

Orphaned packages

So whats next? I know that these packages remain in the queue because the import fails but the real cause of the error seems to be something that’s already in the database which has some attribute with the exact same value as one of these three packages. Let’s google that error message and see if someone had the same issue in the past.
Seems like this happend once in 2016 because of a duplicate package published by Red Hat. Let’s see if one of these packages already exists in the database… Bingo! The sysstat and python-setuptools package have already been published some month prior but with a faulty naming schema. Like in 2016 the package names didn’t contain a dot between the package version and the OS release version. In theory simply deleting the faulty package should solve the problem but let’s see…

Delete the duplicate package

Okay and now let’s try to rerun the channel synchronisation and see if it runs without errors.
13:51:02 Sync of channel completed in 0:04:30.
13:51:02 Total time: 0:04:30

Perfect :)

I2P with the Tor browser bundle

Von | | ,
Einen Kommentar hinterlassen

Based on the The Tin Hat Turotial on how to use the Tor browser with I2P, I tried to import the FoxyProxy configuration file to my FoxyProxy. Unfortunately the format FoxyProxy uses to export and import settings seems to has changed so that the import failed. Because of that I set up the needed proxies and filters manually and exported my ruleset. Everybody who wants to use the Tor browser for both Tor and I2P can download my exported config and import it or set up the rules manually based on the config file.

I2P mit dem Tor Browser

Von | | ,
Einen Kommentar hinterlassen

Basieren auf dem The Tin Hat Artikel habe ich versucht meinen Tor Browser mit I2P anzufreunden. Mit der dort verfügbaren Konfiguration wollte der Import in FoxyProxy nicht funktionieren, da sich die Formatierung von FoxyProxy zwischenzeitlich geändert zu haben scheint. Ich habe daraufhin die Konfiguration manuell vorgenommen und anschließend exportiert. Wer ebenfalls den Tor Browser für I2P und Tor gleichzeitig nutzen will, kann sich gern meine Konfigurationsdatei herunterladen und importieren oder ebenfalls selbst die nötigen Einstellungen daraus ziehen.

Yaesu FT-2DE: C4FM Duobander

Von | | , ,
4 Kommentare

An dieser Stelle möchte ich meine Erfahrungen mit dem FT-2DE aus dem Hause Yaesu festhalten, speziell weil es zu diesem Transceiver bisher nicht allzu viele Beiträge gibt. Vorab sei gesagt, dass dies mein erstes AFu Handfunkgerät ist! Ich habe keinen Vergleich mit Geräten anderer Hersteller und bin daher nicht in der Lage einzuschätzen, ob Yaesu im Vergleich komplett grauenhaft abschneiden würde. Ebenfalls habe ich bisher keine Erfahrung mit DMR, kann also auch hier C4FM nicht damit vergleichen.

Ich habe das Gerät gebraucht von einem OM erworben, welcher es aufgrund der fehlenden C4FM Abdeckung nicht gebrauchen kann. Das Problem der Abdeckung ist in meinen Breitengraden (in und um Berlin) tatsächlich noch ein Problem, wie ein Blick auf die Relaiskarte von DB0HWR zeigt. Glücklicherweise erreiche ich DB0BLO von meinem QTH aus noch ausreichend um QSOs zu führen.

Nun zum Gerät:

Äußerer Eindruck

Mein erste Eindruck war das es ein sehr hochwertiges Gerät ist, bei dem Look und Feel gut aufeinander abgestimmt sind. Ich persönlich mag Gerätschaften bei denen man das Gefühl hat wirklich etwas in der Hand zu halten und nicht eine „slim“ Version o.Ä. zu nutzen. Das Touchdisplay ist zwar resistiv aber dennoch keines bei welchem bei Druck auf die Oberfläche das komplette Display eine Art Mulde bildet. Die Tasten an der linken Seite haben alle einen hör- und spürbaren Druckpunkt und sind zumindest von mir gut erfühlbar. Soll heißen das ich immer genau welche Taste ich jetzt drücke. Der doppelt belegte Drehregler sitzt ein wenig locker, was aber wenn man nicht explizit darauf achtet, nicht weiter auffällt oder stört. Beim unteren Regler fehlt mir ein wenig die Härte die der obere Regler hat, allerdings soll dies ja auch der Lautstärkeregler sein.

Das Display

Ich denke hier ist definitiv der Punkt an dem sich die Geister scheiden. Schaut man sich im Web ein wenig um findet man dutzende Meinungen zum Display, von denen die eine Hälfte es als absolute Fehlkonstruktion und die andere Hälfte es als absolut in Ordnung bezeichnet. Ich gehöre zur letzteren Fraktion wenn auch mit Abstrichen. Gleich vorweg: Ich kann absolut nicht bestätigen, dass das Display im Kontrast nicht ausreichend sei! Auf den Produktbildern von Yaesu mag das Display zwar geschönt sein aber trotzdem konnte ich bisher zu jeder Zeit problemlos alles ablesen und habe meinen Kontrast trotzdem nicht auf der höchsten Stufe, eher im Gegenteil. Wo ich zweifellos zustimme ist aber die Tatsache, dass das verbaute Display einfach nicht mehr zeitgemäß ist. Wer eine Betriebsart vertreibt die in der Lage ist Bilder (wenn auch in peinlicher Auflösung) zu übertragen, der sollte dann auch ein Farbdisplay mit ausreichend Auflösung verbauen, so ist das ziemlich witzlos. Ich jedenfalls habe mir empfangene Bilder lieber auf dem Computer angeguckt um überhaupt etwas zu erkennen.
Die Beleuchtung ist bei Tageslicht nicht vonnöten, kommt bei dunklerer Umgebung aber gut zum Einsatz. Leider gibt es keine Möglichkeit sie schnell zu aktivieren ohne eine Taste mit Funktion drücken zu müssen. Selbst auf dem Display sind überwiegend Buttons, so dass man nicht einfach ziellos drauf tippen sollte nur um das Licht zu aktivieren. Eine Art Minimalbeleuchtung gibt es auch nicht, heißt sobald das Licht aus ist, ist es aus.
Die Reaktion des Displays auf Berührungen funktioniert im Schnitt ganz gut, es gibt aber auch Momente in denen ich zwei oder drei mal auf einen Button drücke weil mein ersten mal nichts passiert. Yaesu weist darauf hin, dass bei geringer Außentemperatur so ein Verhalten schnell auftreten kann aber ich hatte dieses Problem auch bei mir in den heimischen vier Wänden bei 22°C. Es passiert glücklicherweise eher selten, zumindest selten genug um micht nicht zu stören.

Die Bedienung

Hier lässt sich schwer um den heißen Brei herumreden: Die Bedienung ist Murks. Endlose Menüs mit endlosen Unterpunkten und das Meiste davon in der kürzest möglichen Form um es auf das Display zu bekommen. Das mag vielleicht nur mir so gehen weil ich als noch recht frischer Funkamateur bei etlichen Abkürzungen die Bedeutung einfach noch nicht kenne aber ich vermute das es auch den ein oder anderen erfahrenen Funker gibt der hier mit der Bedienungsanleitung vorlieb genommen hat (dazu später mehr!). Einen Vorteil hat das Ganze aber: Durch die vielen Abkürzungen ist mehr nutzbare Fläche vorhanden, sodass es eigentlich an keiner Option fehlt. Die Informationsdichte ist hoch und das ist gut so, zumindest finde ich das.
Die zu passender Zeit eingeblendete Tastatur funktioniert nach dem bekannten T9 System und ist einfach nur nervig. Mit dem mehrfachen drücken einer Taste um zum gewünschten Buchstaben zu kommen kann ich ja noch leben aber die vorhandene Umschalttaste funktioniert nicht, sodass für die Eingabe eines großen Buchstabens erst die komplette Palette kleiner Buchstaben und dann noch zum passenden, großen Buchstaben durchgetippt werden muss. Leider gibt es zwischen den ganzen Buttons für jede erdenkliche Funktion keine um mal fix den GPS Empfänger ein- oder auszuschalten. Das ist doof weil der doch ziemlich auf den Akku geht und ich ihn immer abschalte wenn ich beispielsweise im Shack oder im OV angekommen bin.

Lautsprecher und Mikrofon

Der verbaute Lautsprecher ist ziemlich schwach auf der Brust, um neben einer befahrenen Straße etwas zu hören muss man schon 3/4 aufdrehen. Das ist kein Vergleich zum UV-5R wo einem die Ohren schmerzen wenn man es auch nur halb aufdreht. Der Klang ist ziemlich flach, Radio hören macht damit keinen großen Spaß, für AFu reicht es aber aus. Bei der Wiedergabe von empfangenen Signalen ist leider ein hochfrequentes Pfeifen zu hören. Im Einstellungsmenü findet sich eine Option namens CLOCK TYPE welche laut Anleitung dafür verantwortlich sein kann aber keine der zwei einstellbaren Modi behebt das Problem. Durch einen bloßen Zufall habe ich herausgefunden, dass solange man als Empfangsmodus ASM (automatische Erkennung der Signalart) aktiv ist, das Pfeifen zu hören ist. Schaltet mal manuell auf FM, DM oder VM ist das Pfeifen verschwunden.
Das Mikro scheint okay zu sein, jedenfalls hat sich bisher keiner beschwert und ich selbst habe beim gegenhören auch keine Mängel festgestellt. Ihr solltet allerdings den MIC GAIN auf mindestens 7 stellen, mit den ausgelieferten 5 kam ich zu leise durch. Vorab hatte sich ein OM über den MIC GAIN seines FT-2DE beschwert, da er für C4FM oder analog FM immer umstellen musste. Ich kann das nicht bestätigen und verstelle auch nicht jedes mal den GAIN wenn ich die Betriebsart wechsle, vielleicht wurde das also in einem Firmwareupate gefixt.
Das externe Handmikro MH-34B4B ist lauter als der verbaute Lautsprecher, dafür aber ebenfalls sehr flach. Das Mikro scheint das Selbe wie im Gerät selbst zu sein, ich habe keinen Unterschied hören können. Am Kabel des Handmikros befindet sich ein Ring der um den Fuß der Antenne gehört. Das ist eigentlich eine ziemlich pfiffige Idee da so das versehentliche rausziehen des Steckers aus dem Gerät verhindert wird. Leider ist der Anschluss dafür aber auf der rechten und die Antenne auf der linken Seite und somit das Ganze enorm unter Spannung. Der Ring lässt sich zwar öffnen und in der Position am Kabel verschieben, stößt aber schnell an die Grenze wo dann der Spiralteil des Kabels beginnt. Praktisch also leider nicht wirklich nutzbar.

Zubehör

Der mitgelieferte Akku ist mit seinen 2.200mAh zu klein. Damit lassen sich zwar schon etliche Stunden Betrieb machen aber alle zwei Tage laden ist leider normal. Gerade wenn man den GPS Empfänger aktiv hat kann man dem Ladestand beim schrumpfen zusehen. Ich plane mir bei Gelegenheit noch das Leergeäuse FBA-39 für drei AA Akkus/Batterien zu kaufen und dort meine Eneloops drin unter zubringen, das sollte die Laufzeit erheblichen anheben. Der Steckerlader ist leider extrem Lahm (0,5 Ampere Ladestrom) sodass ich das HFG meist die komplette Nacht über am Strom lasse. Der Schnelllader CD-41 soll wohl abhilfe schaffen.
Ein Programmierkabel wie beim FT-1(X)DE liegt nicht bei (bei dem Preis schon wirklich frech!), lediglich ein USB-Anschlusskabel für Firmware Updates ist dabei. Zu denen lässt sich übrigends fast nur Positives sagen: Schnell und unkompliziert. Zwar muss an der USB Buchse je nachdem welchen Part der Firmware man updated ein kleiner Schalter umgelegt werden aber sonst lief das bei mir Fehlerfrei und fix durch. Changelogs gibt’s nicht, keiner weiß so recht was in den Updates enthalten ist. Optisch lassen sich jedenfalls keine Änderungen feststellen. Ein recht schwerwiegender Bug ist auch mit der aktuellsten Firmware nicht gefixt: Steckt das HFG am Ladekabel und man betätigt die WIRES-X Taste, so friert das Gerät ein und sendet dauerhaft.
Die Gummiantenne ist okay. Viel mehr kann man dazu nicht sagen.
Im Karton findet man noch die Bedienungsanleitung für die meisten Funktionen, nicht jedoch für APRS, WIRES-X und den Group Monitor (merkt das mal!). Mir ist das nach ungefähr einer Stunde erst richtig klar geworden und ich habe mir die fehlenden Teile von der Yaesu Seite heruntergeladen.

C4FM

Mir persönlich gefällt diese Betriebsart eigentlich ziemlich gut, von der Verständlichkeit nimmt sich das nicht viel mit dem, was ich von anderen OMs auf deren DMR Geräten gehört habe. Die Datenübermittlung ist nett umgesetzt und das Empfangen von Sprachnachrichten/Bildern/Textnachrichten geht in der Regel auch bei einer eher schlechten Verbindung ziemlich schnell. Leider gibt es zumindest in Deutschland noch nicht allzu viele Nutzer, geschweigedenn eine regelmäßige Runde. Primär sehe ich da die Relaisbetreiber in der Pflicht sich nicht nur den DR-1X inklusive Cashback zu holen, sondern dann auch zu nutzen. Viele haben ihn in FM only laufen oder lassen ihn nach dem Einkauf etliche Monate stehen.

Update:

Ich habe C4FM während meines Urlaubs und auch in Berlin inzwischen recht häufig benutzt und finde es einen ziemlich gelungenen Digi-Mode. Neben Test QSOs mit OMs aus meinem OV, habe ich über DB0BLO auch einige QSOs mit leuten im Harz über DB0BRO geführt, welches zusammen mit BLO im Wires-X Raum DL-NORDOST ist. Beide Standorte haben eine wirklich gute Anbindung ans Internet, weshalb C4FM über Wires-X problemlos funktionierte.
Bei einem QSO über BLO zu DB0FS, war die Verbindung eines der beiden Relais immer mal wieder unterbrochen. Optisch wurde mir dies auf dem Display meines Gerätes durch ein Blinken des Wires-X Symbols mitgeteilt. Das allein ist noch nicht bahnbrechend, interessant wurde es aber, nachdem die Internetverbindung des Relais wiederhergestellt und beide Relais erneut verbunden waren: Der Durchgang meines Gegenübers wurde erneut ausgesendet! Offenbar puffert die Software dahinter – ob gewollt oder ungewollt – die einkommenden Daten und sendet sie erneut im Falle eines Verbindungsabbruchs. Da dies sowohl auf dem sendenden als auch dem empfangenden Relais geschieht, sorgt es beim erstmaligen Auftreten doch für einige Verwirrung, ist aber be instabilen Verbindungen durchaus praktisch.

Group Monitor

Tja was soll ich dazu groß sagen. Eine Funktion deren Nutzen aus meiner Sicht eher gering ist. Ist eine einmalig nette Sache um die einem selbst bekannten YLs/OMs schnell in eine Art Kontaktliste aufzunehmen um fix eine Nachricht an sie übermitteln zu können. Macht praktisch nur keiner. Bilder aufgrund der vorhin genannten Auflösung nicht und Sprachnachrichten sind bei einem Relais auch eher witzlos weil man die Person auch einfach direkt rufen kann. Die Textnachrichten werden leider kaum genutzt, dabei finde ich die von den drei Medien noch die praktischste (Stichwort Relais-News, OV-News, …). Liegt vermutlich auch daran, dass die Ausgabe auf dem FT-1(X)DE aufgrund des Displays eher nervig und die Eingabe auf dem FT-2DE wegen des T9 Systems umständlich ist.

Fazit

Im Alltag gefällt mir das Gerät aber sehr gut und ich bereue im Gegenteil zu vielen Anderen den Kauf keineswegs. Es funktioniert und tut seinen Job gut, ich mag die eingebaute APRS Funktion die nachdem man dem GPS Empfänger Zeit für die Fix gelassen hat super funktioniert und als meine erste, digitale Betriebsart ist auch C4FM sehr nutzerfreundlich. So wie ich das über DMR gehört habe, ist es dort ein wenig komplizierter bzw. die Lernkurve steiler. Als FM Gerät ist es ebenfalls sehr zufriedenstellend und eine mehr als deutliche Verbesserung zum UV-5R (wen wunderts).

Natürlich gibt es wie bei jedem Gerät dinge die einen stören und um diese Punkte kurz und bündig darzustellen, folgt eine Liste wie sie DK3ML bereits für das FT-1XDE führt:

1. Der Lautsprecher ist zu leise! Auf der Straße ist die Lautstärke bei mir in der Regel auf 3/4 eingestellt.
2. Es gibt keine Mute-Funktion! Zwar steht in der Anleitung, dass ein längerer Druck auf SQL genau das tun soll aber fehlanzeige.
3. Der GPS Empfänger braucht (wie viele GPS Empfänger auch) wirklich sehr lange wenn man den Standort seit dem letzten Betrieb gewechselt hat und er braucht sogar noch länger wenn man sich dabei schnell fortbewegt (Auto, Bahn, Fahrrad, …). Zusätzlich dazu verliert er auch extrem schnell den Empfang, teilweise reicht es das HFG in der Jackentasche zu haben und schon weiß das Gerät nicht mehr wo es ist.
4. Speichert man eine QRG ab dann schließt das den Empfangsmodus nicht mit ein. Wechselt man von einem C4FM Relais auf ein FM Relais muss händisch der Empfänger auf FM/AMS gestellt werden, andernfalls bleibt er auf dem Datamodus und gibt nichts aus.
5. Das hochfrequente Pfeifen welches bei der Wiedergabe zu hören ist nervt! Solange AMS als Empfangsmodus gewählt ist, ist es hörbar.
6. Der Akku ist für den Verbrauch unterdimensioniert und das Ladegerät zu langsam (0.5A Ladestrom!).
7.  Die eigene APRS Bake ist trotz APRS Filter und Lautstärke auf 0 immer zu hören.
8. Das SmartBeaconing ist gut gedacht, funktioniert aber nicht wirklich gut. Liegt primär daran das zwischen den Baken das GPS Signal mal wieder verloren gegangen ist.
9. Die zu den Frequenzen eingespeicherten Namen werden nur im Single VFO Mode angezeigt.
10. Im Single VFO Modus werden auf VFO B keine APRS Baken mehr ausgesendet oder empfangen.

Diesen Artikel habe ich jetzt in einem Rutsch geschrieben, ich bin mir sicher da kommen später noch Punkte dazu die mir aktuell nur nicht in den Sinn kommen. Es kann jedenfalls nicht schaden als Interessent hier noch das ein oder andere mal vorbei zuschauen.

73 de Robert

Update 02.03.2018:

Ich habe aktuell einen FT-1XDE zum Testen auf dem Schreibtisch liegen und werde nach einigen Wochen „Einarbeitung“ einen Vergleich zwischen dem 2DE und dem 1XDE ziehen. Selbstverständlich werde ich meine Eindrücke hier mit euch teilen.

Nachteile Vorteile
1. Updates der Firmware sind im Gegensatz zum FT-2DE nur mit dem Programmierkabel möglich 1. Kein Pfeifen im AMS Modus wie beim FT-2DE
2. Das Display ist zu klein, dementsprechend fehlen Informationen 2. Der GPS Empfänger hat extrem schnell einen Fix
3. Im Single VFO Modus werden auf VFO B keine APRS Baken mehr ausgesendet oder empfangen  3. Bessere Akkulaufzeit gegenüber dem FT-2DE
4. Nur ein Drehregler für Auswahl und Lautstärke  4. Subjektiv ist der Empfänger besser und hat ein deutlich geringeres Grundrauschen
5. Einstellungen ändern ist verhältnismäßig umständlich

Quick Info: VMware Workstation Netzwerk funktioniert nicht

Von | | , ,
Einen Kommentar hinterlassen

Ich habe kürzlich meine VMware Workstation auf eine neue Hostmaschine umgezogen und seitdem funktionierten weder die vmnet Interfaces noch sonst irgendein Netzwerk Service von VMware. Mittels vmware-network –status lässt sich der aktuelle Zustand der virtuellen NICs und der Netservices überprüfen. Bei mir kam

Bridge networking on vmnet0 is not running
DHCP service on vmnet1 is not running
Hostonly virtual adapter on vmnet1 is disabled
DHCP service on vmnet8 is not running
NAT service on vmnet8 is not running
Hostonly virtual adapter on vmnet8 is disabled
Some/All of the configured services are not running

was ich versuchte mit vmware-network –start zu beheben. Leider bekam ich Failed to start some/all services als Antwort und musste auf Fehlersuche gehen. Des Rätsels Lösung war ein nicht aktivierter Kernelmod namens vmnet. Ein schnelles modprobe vmnet und erneutes starten des Services löste das Problem.