Range extender confusion with two MAC but same ID

Running through the hostapd and dhcpd logs recently gave me an interesting puzzle to have fun with – amongst various MAC addresses in my syslog I noticed a pattern that was repeating: an ID of an Android device (a Samsung phone) had been registering itself with two different IDs. A phone would offer the ID in a DHCPREQUEST, but the strange thing to me – at the moment I saw it – was that the dhcp server would give different IPs to different MACs, but both of those using the same ID of the device.

I started looking for the MACs of the devices I use, trying to eliminate various MACs from the log, and at first it made no sense at all – it was either a break into my WLAN, or my phone indeed had more than one MAC. To confuse me even more, turning on the bluetooth of the phone would spawn one more MAC in “Settings >> About device >> Status >> Wi-Fi MAC address”, and I couldn’t figure out what it had to do with the above-described situation found in logs, nor find any proofs. Could there be more MACs, activated and/or assigned under similar conditions, like using HDSPA, 4G?

Then I made an educated guess that it had to do something with my WiFi range extender, TP-Link’s TL-WA850RE, that I use to cover some of the less accessible parts of the apartment. I made an experiment, and proved to myself that the guess was a good one – walking away of the main WiFi AP and approaching the extender would have the phone quickly disassociate and then associate again, borrowing a MAC from the extender, but keeping the ID!

There, if you notice the same in the logs – strangely leased IPs to a same ID of a device that suddenly appears to have a ghost MAC – there is a slim chance that you have not been hacked. Yet… 😛

New Confluence available at Simulakrum

New Confluence 5.9.7 is now available to the members of the appropriate groups in LDAP. There was an issue with Confluence-in-Docker in the installation phase where Confluence would reach the “Insert license key” step, and then simply spin in a vicious circle.

Found a workaround for that – simply do not attempt to add SSL keys to Confluence during the installation, but reach it through an openssh tunnel (make sure you reach it as “127.0.0.1”) finish the installation, and then add SLL, LDAP and other necessities.

The steps are: Continue reading

Jenkins in a container

The jenkins.simulakrum.org server is now running from within a Docker container. Migration was flawless and done from scratch in less than 30 minutes. The reason was that Ubuntu would fail to restart a native jenkins service if another Docker container would use a port, albeit on a different IP. After being fed up with constant joggling between solutions for that, I decided it would be faster to simply “dockerise” Jenkins, too, and have it confined in a container for good.
Continue reading

Kyocera FS 1040 printer not working

A Kyocera FS 1040 printer not working with the drivers and rastertokpsl from https://www.kyoceradocumentsolutions.eu/index/service/dlc.false._.FS1040._.EN.html site? Just fetch them from here: http://www.kyoceradocumentsolutions.com.cn/support/mfp/download/ecosys6.html

 

Edit: if the alternate driver does not help either, a third way might be useful – instead of the printing, choose saving as a PDF somewhere on the disk, and then open with the default viewer and try to print – this worked for me on a few occasions.

Simulakrum moves to SSDs

Simulakrum will soon be moved onto SSDs, a significant decrease of latency is expected for all of the services.

new_server

Also, routing should be improved through a new switch, and brand new cables connected to a new patch panel.

new_small_rack

Finally, some of the new services are now moved to Docker. Evil would say that move actually degrades the speed, but I need some Docker practice, so it should be a double benefit.

CoD – Code of the Day – 1447441471

#include <stdio.h>

enum {WARNING, ERROR, INFO, SUCCESS};

char const *msg(int type);

int main (int argc, char **argv)
{

puts(msg(INFO));

puts(msg(0));
return 0;
}

char const *msg(int type)
{

switch (type)
{
case WARNING:
return “Warning message!”;
case ERROR:
return “Error message!”;
case INFO:
return “Info message!”;
case SUCCESS:
return “Success message!”;

}

return NULL;
}

slapi_attr_is_last_mod

Had to move 389-ds from a docker container running under a CentOS 7 to docker container running under Ubuntu 14.04 LTS. An exotic message appeared once I tried to run the dirsrv from within the new container:

/usr/sbin/ns-slapd: undefined symbol: slapi_attr_is_last_mod

Apparently, the user that last used the dirsrv left some inconsistencies (though I used “-rltzuv” for rsync).

The thing that helped was to erase and re-install. Have you tried to turn it off and on again?

Joomla’s rewrite rules break server-status

I’ve noticed that we’d lost all of the munin monitoring for Joomla-based sites after switching on Joomla‘s internal URL rewriting. The default rules in the recommended .htaccess file block the access to the Apache’s server-status page. A simple:

# allow status
RewriteCond %{REQUEST_URI} !=/server-status

just above the last rule there fixes this problem.

SSL not working: certificate verify failed (18)

If your ssmtp persistently returns a “SSL not working: certificate verify failed (18)” in logs, and you do have “TLS_CA_File=/etc/pki/tls/certs/ca-bundle.crt” in your conf, and you do use a self-signed certificate, try adding the certificate in “/usr/share/pki/ca-trust-source/anchors/” (Fedora 22 directory, may vary for other distros) and then re-try the mailer agian.