HP Procurve MSM422 / MAP-625 clients flow the dhcp server [solved]

A client was using the HP Procurve MSM422 / MAP-625 MultiService Access Point (wifi). It was being used in a rather crowded wifi environment and the problem was the wifi clients keept reconnecting and renegotioating so often that the DHCP server was overflowed, sometimes with DHCP requests every few seconds. They had been struggling with the problem for a couple of months and the focus was aimed at the DHCP requests.

It turned out that the problem was not in the DHCP negotiation at all, but was caused by the wireless clients that keept losing connection and each time when they reconnected a DHCP request was sent.

The client was misinformed, that 5 GHz band was prohibited in the country where it was set up (which is acutally not). So both radios (radio 1 and 2) where set to 2,4 GHz where radio 1 was set to 802.11n/b/g and radio 2 with 802.11b/g.

Furthermore, for radio 2 the value of the Antenna gain was set to the maximum which is 29 dBi in an attempt to boost the maximum power out of the system. However, this field works the opposite. In order to be regulatory compliant and not emit more than the allowed power, this field informs the system that it is connected to an antenna with 29 dBi gain, so to not emit illegal levels of power (output power + antenna gain), the system will reduce the actual output power (i.e. the power input to the antenna) by 29 dBi. But the system was using the internal antennas which, I guess, has more or less no antenna gain. This caused the system to actually emit -29 dBi, i.e. a very weak wifi signal.

The low power output made it hard for the wifi clients to “hear” the access point, which caused them constantly to lose connection and when reconnecting, they were sending a DHCP request, hogging down the DHCP server.

Solution:

  • Radio 1 was configured to use the 5 GHz band. This band is much less crowded than the 2,4 GHz band and the bandwidth is better, so when a client has the possibility, it is preferred if it can use the 5 GHz band.
  • Radio 2 was configured to use Internal Antenna with 0 dBi antenna gain.

Settings used when the problem was solved like this (click on the image to enhance it):

HP Procurve MSM422 MAP-625

HP Procurve MSM422 MAP-625

“Not a valid image” when trying to upload images in Joomla! 3.7

Error message “Not a valid image” displayed when trying to upload an image in Joomla! 3.7. The error message is displayed even though the file type being uploded (jpg or png for example) is existing as valid type in both valid file types and mime types fields.

Solution: Go to System -> Global configuration -> Media and select Check MIME types = No

PrestaShop 1.6 – unable to remove product from cart [solution]

If it’s not possible to remove an item from the cart in PrestaShop 1.6, try this solution:

Advanced settings -> Performance -> Move JavaScript to the end = NO

The problem seems to occur in Chrome and Microsoft Internet Explorer but not in other browsers like Firefox for example.

PrestaShop and PayPal payment error after checkout – 699 kr was paid instead of 699 kr [solved]

A client running PrestaShop 1.6.1.13 with PayPal payment module version 3.11.4 had problems after checkout of orders with an error message saying “699 kr was paid instead of 699 kr”. It turned out it was a rounding error where PrestaShop and PayPal use different methods of calculating the rounding.

The solution suggested was:

  • Go to preferences -> General
  • Rounding rule: Round to infinity when the value is halfway (recommended)
  • Rounding Type: Rounding for each element

This solved part of the problem. However, the client applied a store wide discount of 30%, causing a product (for example) costing 999 kr to checkout at 699 kr. To be precise, 999 kr minus 30% discount is 699,30 kr, but the 0,30 was rounded off. The same problem as mentioned above occured even when putting one piece of this item in the cart and checking it out.

It turned out that the theme used (jms_homewares version 1.0) only display prices in full kronor, without any decimals, independent of the settings regarding decimals in the Preferences -> General tab. In this case the settings was set to display 2 decimals. Setting it to 0 decimals solved the problem. I should mention that I am not sure if this is standard behavoiur of jms_homewares or if it has been modfied by the website developer. However, in this case setting it to display 0 decimals made everyting work without errors.

Joomla 3.7.0 error “Warning. Empty solution not allowed” when trying to save article in frontend [solution]

After upgrade to Joomla 3.7.0 an error was displayed when saving an article in the frontend. The error message was “Warning. Empty solution not allowed”.

The error message is a bit confusing, not giving any real hint what it is about. It turns out it has to do with Captcha. A new feature in Joomla 3.7.0 is the possibility to use Captcha on article editing.

To solve the problem, go to Options -> Articles and select the Editing Layout tab. Make sure “None Selected” is set in the Captcha field and click Save. Do click Save if it is already selected because it seems the setting is missing after the upgrade. By saving, the setting will be added and the problem is solved.

Joomla 3.7.0 "Warning. Empty solution not allowed"

Joomla 3.7.0 “Warning. Empty solution not allowed”

Disable Joomla! two-factor authentication

The Joomla! two-factor authentication is a great security improvement. But if you got locked out, maybe because your smartphone with the Google Authenticator installed broke down, was factory reset or the app was uninstalled – what to do?

  1. First of all, reinstall the Google Authenticator app back into your smartphone or tablet
  2. Use FTP software or similar to access the Joomla! installation directory
  3. Go to the plugins folder
  4. Rename the folder twofactorauth to something else
  5. Access the backend login page (i.e. /administrator) of your site
  6. Now the secret key field is gone, so proceed and login with just username and password
  7. Once logged in, you can rename the plugin folder back to twofactorauth
  8. Go to Users in the Joomla! backend and find your user account and click on it
  9. Click the Two factor authentication tab and scan the QR code with Google Authenticator on your smartphone/tablet
  10. Done! Now you can login using two factor authentication again

SiteOrigin Pagebuilder and widgets not working after site move / migration [solution]

Normally when moving, mirating or deploying a WordPress site, I use the Akeeba Backup plugin for WordPress. This works excellent, also for sites built using SiteOrigin Pagebuilder and SiteOrigin widgets bundle.

If, for some reason, it is not possible to use Akeeba Backup and a more traditional approach is used, like transferring the files using FTP, dumping the database to a SQL file, replacing the urls in the SQL file from the old url to the new, you will run into trouble if the old and new urls have different lengths (number of characters) because Pagebuilder uses something called serialization.

However, there is a solution:

  1. Transfer all the site files using FTP to the new server
  2. Edit wp-config.php on the new server regarding database host, database name, database username and database password
  3. On the old server, use for example phpmyadmin to export the database to a SQL file
  4. On the new server, import the SQL file using for example phpmyadmin
  5. In phpmyadmin on the new server, go to the PREFIX_options table and find the key siteurl and update it to the new url (do not change anything else)
  6. Log in to wp-admin on the new server and install the Better Search and Replace plugin (this one handles serialization)
  7. Go to Tools -> Better Search & Replace
  8. Enter your old url in the “Search for field” and the new url in the “Replace with” field
  9. Click the “Run Search/Replace” button (this will simulate the search and replace process)
  10. If everything looks normal and it reports there are a number of replacement possible, deselect “Run as dry run” and click the button again

SIP-client behind NAT disconnects incoming external call after 8-10 seconds

Scenario: a SIP server running Elastix (Asterisk and FreePBX) with SIP-clients behind NAT. Outgoing calls from the clients (which where CounterPath Xten and Siemens Gigaset C530ip, i.e. completely different brands) works well, but incoming calls are disconnected after 8-10 seconds.

Googleing the problem suggests the problem is caused by a SIP REINVITE on the client side, which can’t happen because of NAT. During testing, I discovered that calls between SIP-phones connected to the same SIP PBX worked fine, even between different locations. Only calls that originated externally would be interrupted.

This made me focus on the trunks instead and I found out that the problem indeed was a REINVITE but it occured on the trunk side.

The solution was to add the following lines to the PEER DETAILS and USER DETAILS on the trunk configuration in the SIP server:

directmedia=no
canreinvite=no

Footer widgets not displaying when using Cherry Framework 4 for WordPress

To make the footer widgets visible when using the Cherry Framework 4 template for WordPress:

  • Under Cherry in the backend menu, select Static Area Builder
  • In the Footer Top section, click on the Footer Sidebars
  • In the .col-xs-*, .col-sm-*, .col-md-* and .col-lg-* select the desired widget size for each screen size (i.e. select anyting else than “none” to make the footer widgets visible)
  • Click Save statics (bottom right of the screen)

Ispconfig3 php5-fpm Error 500 Internal server error

When trying to change a client website on a Ispconfig3 host from Fast-CGI to PHP-FPM the page just gave Error 500 Internal server error. Investigating the site error log showed lines like:

[Sat Oct 22 10:39:56 2016] [error] [client xx.xx.xx.xx] (2)No such file or directory: FastCGI: failed to connect to server "/var/www/clients/client6/web447/cgi-bin/php5-fcgi-*-80-domain.xx": connect() failed
[Sat Oct 22 10:39:56 2016] [error] [client xx.xx.xx.xx] FastCGI: incomplete headers (0 bytes) received from server "/var/www/clients/client6/web447/cgi-bin/php5-fcgi-*-80-domain.xx"

Checking the status of PHP-FPM by the command:

service php5-fpm status

gave the result “not running”.

Investigating the PHP-log file, /var/log/php5-fpm.log, displayed lines like:

[22-Oct-2016 10:34:53] ERROR: [pool web405] cannot get uid for user 'web405'
[22-Oct-2016 10:34:53] ERROR: FPM initialization failed

However, the site widh id 405 and user web405 did no longer exist on the server and has been left there by Ispconfig3 for unknown reasons.

The solution was to manually remove the file /etc/php5/fpm/pool.d/web405.conf file and then:

service php5-fpm restart
service apache2 restart