This procedure is entirely based on the information obtained from this You-Tube video. I simply needed to refer to the procedure multiple times when experimenting with DD-WRT, OpenWRT, and the stock firmware and it is more efficient for me to follow the written form. The procedure works perfectly for my TL-WR841N V11.x. Please follow Richard Lloyd’s YouTube page for this and other useful information in video format. I didn’t do it; nobody saw me do it; there’s no way you can prove anything!
- Download the version-specific firmware for your TL-WR841N from TP-LINK’s website. My TL-WR841N V11 works well with Firmware Version: 3.16.9 Build 150616 Rel.52099n.
- Unzip the downloaded firmware.
- Rename the extracted file to wr841nv11_tp_recovery.bin (v11 is used because the hardware (and firmware) is for a Version 11 router).
- Download and install the 32-Bit version of Tftpd32 found here.
- Disable your wireless card(s).
- Connect your PC directly to the router’s port #1 using a network cable.
- Assign the following static IP information to your PC’s NIC:
- IP address: 192.168.0.66
- Subnet mask: 255.255.255.0
- Leave all other network settings “as is.”
- Launch Tftpd32 and set:
- Server interfaces: 192.168.0.66 (via the drop-down selection)
- Current Directory: The directory where your renamed firmware from step 3 resides. You can click the “Show Dir” button to confirm that the firmware is visible in the chosen directory.
- Hold and continue holding the “WPS/RESET” button for three seconds after using the ON/OFF button to power-cycle the router.
- You should see the router grab the firmware update from the TPTP Server status window. The router’s peer address during this process is 192.168.0.86:xxxx.
- Close Tftpd32 and wait a minute or two for the router to “settle.”
- Change your PC’s NIC from static back to “Obtain an IP address automatically.”
- Open 192.168.0.1 in a browser and confirm that the TP-LINK firmware loaded correctly.
This applies to a Samsung Micro SDXC xGB EVO Memory Card that I recently purchased (and probably a wider range of similar Samsung cards). Despite a long search, I couldn’t find any information (even on Samsung.com) about which of the tiny sets of numbers and letters on the back of the card constituted the serial number.
I’ve finally figured it all out. On the back of the card, there are 4 lines of information. From top to bottom as it relates to the sample image:
Line 1 is the Model Number > MB-MP32D
Line 2 is the Lot ID > MBMPBGVEQBFW-B
Line 3 is the Serial Number > DHTA410GG407
Line 4 is the Country of Manufacture > MADE IN KOREA
The first task is to verify if you have a WNDR3400 V1, 2, or 3. I used this site to determine I have a V1 device. As the hardware for each version is significantly different, this procedure ONLY applies to V1.
According to what I found here (Sat Jun 11, 2016 4:06 post by mrjcd), the latest known good version of dd-wrt for this router is v24-27858_NEWD-2_K2.6. When going from stock firmware (as I am), use dd-wrt.v24-27858_NEWD-2_K2.6_mini-WNDR3400.chk.
- Reset the router
- Connect via Ethernet cable to the router’s #1 port
- Access the firmware update page at http://192.168.1.1 using the default admin/password login
- Upload the dd-wrt firmware
- Wait for the firmware to upload and for the router to restart
- Access the default dd-wrt Router Management page at http://192.168.1.1
Additional Reference: The infamous “Peacock Thread”
Perhaps the single biggest hamartia of the Barracuda Spam Firewall’s Attachment Filtering is that it omits filtering any whitelisted messages. Based on this comment in the user forum, this has apparently been an issue for at least 9 years.
To review your Attachment Filename Filters (only visible when managing the overall system): BLOCK/ACCEPT > Attachment Filters
If you are interested in changing this behavior, you should add your name to Feature Request ID BNSF-8261.
When using the Print button embedded in a ticket, I receive the following error:
The website encountered an error while retrieving https://<my server’s path>/tickets.php?id=274&a=print¬es=1. It may be down for maintenance or configured incorrectly.
The root cause was evident when reviewing /var/log/httpd/user-error_log:
FastCGI: server “/php-fpm-handler” stderr: PHP message: PHP Fatal error: Unsupported operand types in /volume1/web/osticket/upload/include/mpdf/config_fonts.php on line 307, referer: https://<my server’s path>/tickets.php?id=274
The resolution is to enable PHAR
Go to Control Panel > Web Services > PHP Settings > Select PHP extension
Then select “phar” and click ok.
Beginning with IBM Traveler 22.214.171.124, the NTS_DEFRAG_INTERVAL_DAYS= ini setting is no longer valid.
If the setting is still present in the Traveler server’s ini, you will see the following warning on the server console (and/or in the log) when Traveler starts:
Traveler: WARNING *system Unrecognized IBM Traveler parameter in notes.ini: NTS_DEFRAG_INTERVAL_DAYS
If the server was upgraded with the NTS_DEFRAG_INTERVAL_DAYS= in place, the upgrade process appears to transfer the previously set interval. The same result can be achieved by issuing: tell traveler dbmaint set interval 30
You can then verify the set interval using: tell traveler dbmaint show
Don’t forget to remove the NTS_DEFRAG_INTERVAL_DAYS= setting from your post-126.96.36.199 server’s ini.
In a standalone DB situation where you want to trigger Traveler database maintenance, you can issue the following command at the console: tell traveler DBMaint run
This will set the ini parameter NTS_DEFRAG_ONCE=1 which will trigger defrag at the next Traveler restart. The server will automatically remove the NTS_DEFRAG_ONCE=1 setting after the triggered defrag completes.
Again, in a standalone DB situation, you could automate regularly scheduled defrags to run by:
- Using the “tell traveler DBMaint set” commands to set the desired interval, time, day
- Creating a Program document that issues the server command, restart task traveler, just after the time set in the command above
Those that are already using or considering enabling secure SMTP sessions using STARTTLS for Domino should either disable it / wait for now (until SPR# MKENA4SQ7R is resolved in an IF or 9.0.1 FP6), obtain hotfix(es) directly from IBM, or risk the inability to deliver/receive TLS with (at least) some @outlook.com addresses.
For those using (or planning to use) TLS, you should also look at adding the SSL_SESSION_SIZE notes.ini setting. When the setting is not used, the value defaults to 5000 and this is too low to prevent errors like:
02/25/2016 12:23:52 PM New SSL session data length of 5121 bytes is larger than the current size of 5000 bytes.
02/25/2016 12:23:52 PM You may want to set the Notes.ini variable SSL_SESSION_SIZE to at least 5121 bytes.
Note that the server suggested the 5121 value in this example (presumably based upon the handshake with the external server) and I’ve been unable, as yet, to find any other scientific method for determining what other value might be better.