Blog
UDP and Ubuntu 14/Windows incompatibility
14/9/2017
For the last few weeks I've been mucking around in the background with an application I've called "ClipShare" that basically sits on the network and allows you to copy and paste between different machines. It supports text, images and files at the moment. I'm sure such a thing already exists but I like how it auto-detects all the machines running it on the network via UDP broadcast and supports Windows, Mac and Linux. It's far from production ready, it still crashes a bit and hangs up during file transfers sometimes. But over time I'm sure I'll iron that out.

Things like Samba, VNC and VM's (Vmware/Virtualbox) tend to have support for things like clipboard and file sharing. But in my experience they break very easily and it's 50/50 if they'll work or not. Hence having an alternative for getting the data across.

In testing I had a Ubuntu 14 VM running on a Windows host and for the life of me couldn't get the UDP packets to go from Ubuntu to Windows. I could see the packets arriving in Windows land via Wireshark but the recvfrom wouldn't get the packet. The packet wasn't large, just 40 bytes or so. In researching the issue I found that IP packets have a checksum, so I figured out how to get Wireshark to test the checksum. It confirmed the checksum was good. I could see using 'netstat -s' that there was an increasing count of 'Received Packets Discarded'. So Windows for reasons unknown was discarding the UDP traffic from Ubuntu. I tried turning off the Windows Firewall. No difference.

So then I decided to spin up my Ubuntu 16 VM and test the exact same code there. And sure enough it's working fine. So in conclusion I believe that at the OS level, Ubuntu 14 has some busted networking code. I can't tell what's wrong. Maybe it's a Windows thing. But it's basically meant I'm moving to Ubuntu 16 for all my Linux dev stuff. The main reason I had a Ubuntu 14 environment was that I had a working Raspberry Pi cross compiler install and I hate messing with a working env just for the sake of upgrading. However that broke recently anyway so it seems that the last reason for keeping 14 just disappeared.

Fun times.

Tags: linux ubuntu networking | (1) Comment | Add Comment

sem_post funkiness on Linux
9/8/2017
I moved the Linux implementation of the GThreadEvent class (.h, .cpp) over to the sem_open, sem_post, sem_wait calls a little while back.

Initially I used named semaphores and that seemed to work ok. But after a few weeks I noticed that sometimes the call to sem_post would just quietly NOT increment the semaphore count, while still returning 0 (Success). Which causes the listening thread blocking in sem_wait to never wake up. Crucially this would break the destructor / exit loop of GEventTargetThread.

Googling this didn't turn up anything useful. I believe I was using the API correctly and the documentation is very sparse. Anyway I implemented the semaphores using the sem_init/sem_destroy (anonymous) and it seems to be robust. Still, I'd like to know what the deal is with the named ones. The general pattern of behaviour I would see is:
Fun times. I checked it under valgrind and no weird memory accesses. Sometimes it would work ok and exit gracefully. But most of the time it would hang.

Tags: linux | (0) Comments | Add Comment

Merry Christmas
24/12/2015
I think for the first time ever? There is a simultaneous release of Scribe on 3 different platforms: Windows, Mac AND Linux. The new v2.1.3 build is tri-platform. The Linux (x64) build is a GTK2 app and runs ok on Ubuntu and Arch. Well that's all I've tested at this point.

It also runs on a Raspberry Pi 2 although it's a little slow. I know because I got bored and tried building it while working on some MC2 stuff.

Links to the i.Scribe builds:

Tags: scribe linux | (0) Comments | Add Comment

Portable OpenSSL for Linux
21/12/2015
A year ago I worked out how to make a portable build of OpenSSL for Mac. And now with the imminent release of the Linux build of Scribe I need to do the same with the Linux build of OpenSSL.

After downloading and unpacking OpenSSL I configured it with:
./config shared -DPURIFY
The reason for adding the -DPURIFY #define is to suppress valgrind errors related to uninitialized memory usage.

Once that is built I had a look at the shared object paths with ldd:
matthew@ubuntu:~/Downloads/openssl$ ldd ./libssl.so.1.0.0 
	linux-vdso.so.1 =>  (0x00007ffc0e197000)
	libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f5c5ab6c000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5c5a7a7000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5c5a5a3000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f5c5b1c1000)
So it's not portable yet. I initially tried using the chrpath command but it can only modify existing RPATH records. My binary doesn't have any RPATH yet. So that didn't work. The next thing I tried was the patchelf command from here:
http://nixos.org/releases/patchelf/patchelf-0.8/
After building and installing I issued this command in the OpenSSL folder:
patchelf --set-rpath '$ORIGIN' ./libssl.so.1.0.0
Now to check if libssl pulls in the local libcrypto:
matthew@ubuntu:~/Downloads/openssl$ ldd ./libssl.so.1.0.0 
	linux-vdso.so.1 =>  (0x00007ffcdce86000)
	libcrypto.so.1.0.0 => /home/matthew/Code/Scribe/trunk/./libcrypto.so.1.0.0 (0x00007f39b99d8000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f39b9613000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f39b940f000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f39ba0a5000)
Yes! Now this build can be installed in the same folder as the Scribe binary and Scribe will use it without interfering with the system OpenSSL which is often out of date, or not built with -DPURIFY or missing.

Tags: shared-object linux openssl scribe | (0) Comments | Add Comment