Andryan’s Random Notes

I have 6 Buffalo-Tech’s WHR-HP-G54 (with the latest firmware — WHR-HP-G54 Ver.1.40 (1.0.37-1.00.0.03-1.04)) installed at a shopping center to provide wireless Internet hotspot. Since these access points (AP) have to be accessible from my office LAN, I set their default gateway via the web interface. Apparently this didn’t do the trick, I couldn’t access nor ping any of the APs from my LAN.

I used their Ping Test page to test connectivity from the APs to the router which is set as its default gateway, they received replies from the router and are now accessible from my office LAN.

After a few hours I wanted to change something via the web interface of the APs, but they were no longer accessible! Ping from my LAN to the APs ceased to work again, then I tried to ping the APs from the router, which is in the same network as the APs, and I got replies.

Knowing that the APs are actually still accessible from the router, I installed tinyproxy on the router to get to the APs’ web interface. I found a trick that triggers the firmware not to ’sleep’: set NTP server with 1 hour interval. Why 1 hour? Because when I used 2 hours or more, the firmware still went to ’sleep’ until the next NTP synchronization. Since I wanted the APs to be accessible at any time, I set them to 1 hour and voila, no more ’sleep’ing problem!

Update (Nov 23, 2007):

I got this one wrong, sorry.
The firmware is fine, there is nothing wrong with Buffalo-Tech’s WHR-HP-G54 latest firmware. I found out that the tunnel interface on my Linux server created by ChilliSpot caused this behavior. If devices behind this tunnel-bound network interface do not initiate any connection then they will not be reachable from outside (despite having correct routes on the server). The only way to reach these devices from outside network is by getting them to initiate something. In my case, the hourly NTP synchronization schedule that I set on my WHR-HP-G54s triggers something which initiates a connection every hour allowing these APs to be ‘registered’ and reachable from outside network.

Since I have always used ClamAV’s clamd as the virus filter of my email servers along with qmail-scanner, I noticed that crash-hat’s clamav RPM packages use logrotate to rotate the logs files. qmail-scanner runs as its own user (qscand), so clamd has to run under the same user. When the RPM package was first installed, it created these directories: /var/run/clamav/ and /var/log/clamav/. Chown these 2 directories to qscand (this assumes that User directives in freshclam.conf and clamd.conf have been changed to qscand), otherwise clamd and freshclam wouldn’t be able to write any logs and pid file and neither service would start.

As for the logrotate configuration, edit clamd and freshclam in /etc/logrotate.d/ to change the log files’ ownership to qscand instead of clamav. Modify line 8 where it says:

create 640 clamav clamav

to

create 640 qscand clamav

That should do the trick.

Since Fedora Core 5, pppoe-server that comes with rp-pppoe RPM package has always been broken. Someone actually filed a bug report, but unfortunately there was no response. Apparently the problem is caused by ppp conflicting with syslogd. If you stop syslogd and klogd, then pppoe-server will run properly. Fedora Core 4 does not have this problem though. I’m not sure if the newly released Fedora 7 has got this issue sorted out. I’m guessing that they haven’t.

If you have installed Fedora 7 and found out that the issue has been fixed, please let me know ASAP. Thanks!

Update (Jul 03, 2007): Problem confirmed in Fedora 7.

Update (Mar 14, 2008): Problem fixed as stated on bugzilla ticket.

I was just compiling an updated version of HTB-tools a few minutes ago then I noticed that either I forgot to make a note about removing a line from q_show.c or the addition of bitops.h is new in the latest version of HTB-tools (0.3.0a). If you don’t remove the following line in q_show.c:

#include <asm/bitops.h>

the compilation process will fail with the following error:

sys/q_show.c:40:24: error: asm/bitops.h: No such file or directory

I found this on Google to explain why bitops.h is missing in Fedora Core 6.