When I tried Fritzing for the first time today, I unfortunately had to notice that two parts are missing. A NodeMCU has already created and released squix78, thanks for that. But unfortunately I could not find a RS232-TTL converter (MAX3232). No problem, then I just create an own part. With this manual this is relatively easy. Unfortunately the part editor did not accept the SVG’s I created with Adobe Illustrator. After a long time of trying I found out that the following export settings are necessary. Important is the number of decimal places:
The final part:
You could download my MAX3232 RS232-to-TTL-Converter Breakout Board here. To use it, drag and drop it into you sketch.
I just wanted to test Fritzing today, but it is not so easy to download the program. On the website it is only possible to download it after a PayPal donation. Unfortunately the binaries are not available on github. Please don’t get me wrong, I don’t have anything against donating for free software, but I don’t like to force this on everyone. At the end, I found something after all:
TL;DR: Sign up for an acccount (or use bugmenot.com) and then you can select “I already paid” and download the binary for you platform. If you like Fritzing, please donate.
The task was simple: two computers (notebooks). One – we call it A – with a working operating system (Xubuntu) and a new one – we call it B – without operating system. This is how I proceeded:
- Create bootable flash drive with in my case Arch-Linux
- In the Arch-Linux boot loader, press [TAB] and add “copytoram” to the boot command to load the squashfs image into ram. I needed this because in this case I only had a flash drive at hand. If you have two, you don’t need this.
- List network devices:
- Assign a IP adress to computer A with:
ip address add <machine A ip adress> dev <ethernet device>
- To identify source disk, list all block devices with:
- Prepare the copy operation (do not execute yet!) with
dd if=/dev/<source block device> bs=32M status=progress | nc <machine B ip adress> <random port number>
- Boot machine B from the same or different flash drive
- Assign different IP adress
- Identify target device
- Prepare the receiving copy operation with
nc -l -p <same port number as A> | if of=/dev/<destination block device> bs=32M status=progress
- Execute the command on Machine B
- Then execute the command on Machine A
- Wait until the copying process is completed.
- Use at least the Sync command to synchronize corresponding file data in volatile storage and permanent storage
- Restart the machine, you are done
How it works/remarks
dd reads the source drive bit by bit into the normal output stream. The output stream is piped to netcat, which sends it over the network to a receiving netcat process (server with -l). Therefore the server must be started first. The server receives the bits and piped them back to dd, which writes them to the target on machine B.
Maybe this is not the best and/or most efficient way, but transfer speed in my case of 75MB/s (poor performance on screenshots is from a setup with two vm’s) is in IHMO very good for this simple setup.
Thanks to pmenke for his support.
Use the following settings to configure a Fritz!Box – also a LTE version – to connect to a Sophos UTM (v9.7)
- Sophos UTM Settings
- Fritz!Box VPN VPN-Configfile
enabled = yes;
conn_type = conntype_lan;
name = "Sophos IPsec";
always_renew = yes;
reject_not_encrypted = no;
dont_filter_netbios = yes;
localip = 0.0.0.0;
local_virtualip = 0.0.0.0;
remoteip = AAA.BBB.CCC.DDD; // Change to Sophos External IP
remote_virtualip = 0.0.0.0;
fqdn = "my.fqdn.net"; // No change needed. Is ignored from the UTN
ipaddr = "AAA.BBB.CCC.DDD"; // Change
mode = phase1_mode_idp; // Main Mode
phase1ss = "dh14/aes/sha";
keytype = connkeytype_pre_shared;
key = "MySecr3tPassw0rd!"; // has to be changed
cert_do_server_auth = no;
use_nat_t = yes;
use_xauth = no;
use_cfgmode = no;
ipaddr = 192.168.0.1; // change to local network
mask = 255.255.255.0; // change to local subnet
ipaddr = 172.16.0.0; // change to remote network
mask = 255.255.255.0; // change to remote subnet
phase2ss = "esp-aes256-3des-sha/ah-no/comp-lzs-no/pfs";
accesslist = "permit ip any 172.16.0.0 255.255.255.0"; // to remote network
ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",
"udp 0.0.0.0:4500 0.0.0.0:4500";
I got this error when I tried to add a SNMP HP ProLiant Physical Disk Sensor for HP Proliant DL 380 G7 with Windows 2012 R2 in our monitoring solution from Paessler (PRTG). The SNMP HP ProLiant System Health, Network and Storage Controller Sensor works fine.
HPE Insight Management Agents and HPE Insight Management WBEM Providers for Windows are installed.
An SNMP walk against OID 22.214.171.124.126.96.36.199.2.5 (used by Paessler for this sensor) works without errors but also without result.
I found some guys with the same probleme and a solution: The problem was the disk (controller) driver. Installed was v188.8.131.52, which seems to be a standard Microsoft driver. With the original HPE controller driver (for us 184.108.40.206) it works.
Today I switched from a Synology DS215play to a DS918+. Perfect time to change the file system – the DS215play didn’t support Btrfs. The migration also works with only one device. So I wrote down both ways.
Steps if you haven’t changed your DiskStation:
- Backup your data! If you switch to a device with new drives like me, you still have a copy of your data, but if you migrate without new drives, you don’t have a copy! In germany we say: No backup – no pity.
- Shut down the DS, remove drive 2. Format drive 2 with your computer.
- Turn the DS back on and DO NOT repair the fault volume.
- Create a new volume (SHA and Btrfs) in the Storage Manager on drive 2.
- For each shared folder, change the location to the new volume. You can only do this for one shared folder at a time and the move may need several hours depending on the size of your shared folders.
- When you have moved all the shared folders, shut down your DS and remove drive 1.
- Format drive 1 with your computer.
- Turn on your DS and go to the Package Center. Repair all apps.
- Expand your new volume to drive 1 and wait until RAID Resync is complete. You’re done.
Steps if you are switching to a new DiskStation with new drives (my situation):
- Turn off your old DS, remove drive 2.
- In the new DS, place the new drives in slot 1 and 2. Place the (old) drive 2 in slot 3.
- Turn on the new DS. Open your browser and navigate to the new DiskStation. In my case, the DS got a new IP address. I looked them up in my router DHCP table.
- Follow the Migration Wizard and wait until the DS restarts.
- Create a new volume (SHA and Btrfs) in the Storage Manager on drive 1 and 2. It is now recommended to change the RAID Resync speed to Fast and wait until RAID synchronization is complete.
- Now for each shared folder, change the location to the new volume. You can only do this for one shared folder at a time and may need several hours depending on the size of your shared folders.
- When you have moved all shared folders, shut down your DS and remove drive 3.
- Turn on your DS and go to the Package Center. Repair all apps. You’re Done.
Last week I noticed that the Single Sign-On (SSO) for the vSphere Client (Flex and HTML5) no longer works in my Firefox. Normally, the VMware Enhanced Authentication Plugin toolbar disappears at the bottom and you can enable the “Using Windows Session Authentication” option, but the checkbox remains unchecked. Reinstalling the VMware Enhanced Authentication plugin, updating the vCenter Server and reinstalling the plugin does not work.
Then I open a ticket at Vmware Support. Hours and some technology later, we had no idea what was going on. But, we find out that the local web server at https://vmware-plugin:8094/ (used by the SSO) displays the following error message in Firefox:
It looks like a problem with the Enhanced Authentication Plugin certificate. This is provided by the plugin. It creates a local web server to communicate with the web page. The VMware support team then created the certificate manually, but the error still occurred – even with IE and Edge.
Then I tried it with a fresh portable Firefox and it worked. In my installed Firefox I removed certificate exceptions for the normal host from the vCenter and vmware-plugin. I also – and most importantly – remove the certificate from the vCenter host and the vmware plugin from the certification authorities in Firefox. Reload the page and it’s working again.
After updating an iMac Late 2010 to Windows 10 1903 I got a blue screen “WDF_VIOLATION”. After checking the minidump, I could see that the MacHALDriver.sys (Macintosh Hardware Application Layer Driver) is involved. After renaming the file (c:\windows\system32\drivers\MacHALDriver.sys) over the network (works because the system crashes after user login) or in safe mode and rebooting, I was able to log back in. Since I don’t use an Apple keyboard I can do without the driver.
While researching I found out that other users also have problems with a similar keyboard driver for HP. In this case it is called HpqKbFiltr.sys. Is also responsible for the hotkeys (screen brightness and co.).