Hack Netgear WG602 access point to run dd-wrt
We have two Access Points, both Netgear WG602EE v4. According a review about the devide, it has a limitation of 20 simultaneous sessions, so I started to look some kind of limit breaking. (Yes, we did have problems like this.)
Fortunately, these devices are on the list of the ones able to run dd-wrt. But how to hack?
The steps:
- download the version for netgear from the dd-wrt page
- install tftp
( I use ubuntu, so apt-get install tftp) - add an IP address from 192.168.0.1/24 to your existing addresses, and one from 192.168.1.1/24
The first is because the access point’s default is 192.168.0.227, the second is because dd-wrt default is 192.168.1.1.
This is always the default. - Login with the tftp session and enter the following.
(the best is to enter these at the location, where you downloaded the dd-wrt binary)
Do not press enter at the end of the last line, just put is there!
tftp 192.168.0.227
verbose
trace
put dd-wrt.v24_micro_generic.bin image.idts334
The tftp only send/recieve data when put or get is entered, so you can log in without the other IP even exists. - On the device, press the reset button and hold for at least 10 seconds, than pull the power cord. Insert the power cord back while still holding the reset button and hold it for 5 seconds more.
- 1 second after press enter at the tftp session. Attention! At this point, there’s no return, because no original firmware is available from Netgear.
- You sould see a lot of send/recieve messages.
- If the transmission was correct, you should be able to login to dd-wrt at the address 192.168.1.1
Nikon 70-210/f4
Nikon 70-210 / f4
Bevezetés
avagy hogyan került hozzám
Miután imádott Fuji S5500 gépemet – némi külső segítséggel – lecseréltem egy Nikon D80-ra, az első “nagytele”, amihez hozzá tudtam jutni, egy 70-300 Sigma volt. Az obi botrányos képminőséggel párosult, ráadásul képtelenség volt megtartani (értsd: könnyű és nagyon hosszú), így keresni kezdtem valamit, amivel kiválthatnám.
Viszonylag gyorsan rájöttem, hogy a pénztárcám a Nikon 70-200/2.8-at soha, a Nikon 80-200/2.8-a, a Sigma/Tamron 70-200/2.8-at pedig belátható időn belül nem fogja elbírni. Megnéztem, hogy a Canonnál vajon lenne-e elérhető árú, nekem megfelelő. Puszta kíváncsiságból. Arra jutottam, hogy a 70-200/4 használtan talán elmenne, és felvetődött a kérdés, hogy vajon a Nikonnál ilyen miért nem kapható.
Rövid kutatás után kiderült, hogy létezett, ámde nagyon kevés ideig, méregdrágán, és meglehetősen régen. ’86 és ’87 között gyártották, a Series E lencséit örökölte (AZ a series E? Igen, AZ.), nincs benne D (distance chip), és anyagból készült, elnézve a súlyát. Nem is olyan hosszú vadászás után találtam egy apróhirdetést: ha jól emlékszem, 65.000 Ft.
Ezt kicsit sokalltam, inkább kerestem tovább, végül belebotlottam egy apronetes hirdetésbe, benne egy 50.000 Ft-os ajánlattal. Mivel kellően jól hangzott, bár féltem az állapotától, találkoztam az illetővel, és a Nikon történelem egy elfeledett, de zseniális darabjával lettem gazdagabb.
Technikai adatok
- lencseméret: 62 mm
- élességállításnál forgó első lencse: igen
- zoomnál forgó első lencse: nem
- súly: 760 g
- átmérő: 76 mm
- hossz: 156 mm
- legszűkebb rekesz: 32
Próbaképek
| 70 mm | 135 mm | 200mm | |
|---|---|---|---|
| f4 | ![]() |
![]() |
![]() |
| f5.6 | ![]() |
![]() |
![]() |
| f11 | ![]() |
![]() |
![]() |
Vélemény
Tapasztalat alapján
- egy kicsit erős tud lenni a kék-magenta kromatikus aberráció
- kékesnek hat a színe, mert alapvetően hidegebb egy kicsit a megszokottnál
- lassú, de pontos az autófókusz
- egészen meglepően közelre tud fókuszálni
- a D chip hiánya még sosem okozott gondot
- nagyon-nagyon jó fogni és a zoomot használni
- igen kényelmetlen a manuális fókusz, túl elől van, és túl keskeny a gyűrű
Összegezve
Ez egy kiváló szerkezet. Nagyon jó képeket képes készíteni, stabil, éles, egyszerűen jó használni. Számomra rejtély, hogy a Nikon miért fejezte be a sorozatot, és ma, amikor komoly igény lenne rá, miért nem eleveníti fel.
Megvannak a maga korlátai és hátrányai, de mindezek ellenére sosem bántam meg a vételt, bátran ajánlom mindenkinek, akit ezzel a korántsem fiatal lencsével összehozna a sors.
VMWare ESXi and promiscuous mode
The problem: I had a XenServer guest, serving as our gateway, and I needed to convert it to VmWare. The only error was, that no bridged network work: the gateway saw both, but the networks could not communicate.
After searching for a while, I’d found the keyword: promiscuous mode. But where can I enable it in VMWare ESXi 4.1?
The solution: select the server (the host server) from the list on the left, goto “configuration” tab, search for Virtual Switch: (), and click on Properties of the Virtual Switch.
The you’ll see the networks configured with the virtual switch. Selecting on network, click on Edit down, and select security tab. You’ll find promiscuous mode there.
SSL status check problems with Pound and apache
We have a high-available system, with the following architecture:
- the main gate: HAProxy on port 80 on the public interface
- all webservers: nginx on port 80, if the content is not static (regex list)
- proxied to localhost, port 81, to apache2
But this architecture cannot be used for ssl connections, therefore on port 443, pound is listening on the HA cluster, and forwards every connection to the HA proxy without SSL.
The problem, is that when a request arrives to one of the apache servers, I cannot force SSL connection, because it will slip into an endless loop.
The solution is:
- add a special HTTP header with pound
- insted of HTTPS check in apache, check this
pound.conf:
######################################################################
## global options:
User "www-data"
Group "www-data"
LogLevel 0
Alive 2
Control "/var/run/poundctl.socket"
######################################################################
ListenHTTPS
Address [IP]
Port 443
Cert "/etc/pound/[cert].pem"
AddHeader "XHTTPS: on"
Service
Backend
Address [IP]
Port 80
End
End
End
The check in apache (inside virtualhost):
RewriteCond %{HTTP:XHTTPS} !on
RewriteRule ^(.*) https://[domain]/$1 [R,L]
Leaving the beloved GD and moving towards Imagick
PHP has a mostly undocumented part, php5-imagick. It is available in Ubuntu from Hardy, so I thought, I could woth to take a look into. The introduction says, that “Imagick is a native php extension to create and modify images using the ImageMagick API”.
I started working with PHP a long time ago, so I started image manipulation with GD because this was the easiest native way. But as the times changed, I needed to use a lot of additional scripts like unsharp_mask for better resizing, PEL to keep exif data, and so on. This was sloooooow.
Imagick extension is a lot different. First, it works on the opened image – no need for a second copy, for example on resizing. Second, it always keeps meta information by default.
I looked into some comparison and some tutorial, and I found that even imagick is a littlebit slower, for image manupilation this tool is a lot more useful, than GD.
Installing PHP 5.3 on Ubuntu 9.10 Karmic Koala
In production, we use Ubuntu 9.10, because of the need of the newer kernel. Now we also need 5.3 PHP, because of Symfony, so I started searching.
I’ve found a post on JMOZ blog, about installing 5.3 PHP from dotdeb packages, but when I tried, I recieved some more errors over the one libicu38 mentioned in the post, so I decided to write them down.
The needed additional apt sources:
# for PHP 5.3 deb http://php53.dotdeb.org stable all deb-src http://php53.dotdeb.org stable all # for libicu38 deb http://security.ubuntu.com/ubuntu jaunty-security main deb-src http://security.ubuntu.com/ubuntu jaunty-security main # for libltdl3 deb http://archive.ubuntu.com/ubuntu hardy main deb-src http://archive.ubuntu.com/ubuntu hardy main deb http://archive.ubuntu.com/ubuntu hardy-updates main deb-src http://archive.ubuntu.com/ubuntu hardy-updates main
A usable theme for Ubuntu Desktop: Shiki
I never liked Ubuntu’s Humanity theme, New Wave theme in 9.10 crashes some applications, like F-Spot, and both are brown. Now Lucid is about to make purple (sic!) it’s default colour, so that’s not for me as well.
When I used to work with Windows XP, I used a theme named NeogenX, from a deviantart publisher, dobee, and I simply loved it. So I wanted to find something similar to that for Ubuntu.
I’ve searched throught deviantart’s customization part for this, and I’ve found nothing. Fortunatelly, I came across with Ubuntu Tweak, some kind of system management software for Ubuntu. It has a third party repository list from ppa, and there was a theme repository, named gnome-colors. Inside of it, there’s a pack, shiki-colors.
This is exactly what I was looking for.
Changing postfix’s incoming smtp port
This is one of the most simple tasks, yet I had to Google around for hours: change the incoming port of postfix’s SMTP, without iptables prerouting.
Open /etc/postfix/master.cf, and search for the following line (usually the first uncommented line):
smtp inet n - - - - smtpd
To change the port, simply write the number instead of smtp in the begining.
For example:
2525 inet n - - - - smtpd
Restart postfix
/etc/init.d/postfix restart
and the system can not accept messages on the port you added. Don’t forget to enable the port on your firewall, if you have one!
Changing to policyd-weight from postfix’s built-in reject_rbl_client
Last week my own server – hosting some sites from old and relatively close client – had been hijacked, and got listed on some RBL lists.
Using apache2-mpm-itk it was quite easy to trace it back, because the spamsender process was running with a user’s id, not with simple www-data. Someone managed to log in with an FTP account, placed some scripts in the www directory, and started it from a web request. The real beauty was that the script removed itself after loading. It also sent the mails from the domain’s default name, so, unfortunately it wasn’t forged, and a lot of lists added my IP.
Using the help of mxtoolbox.com, a site for monitoring mailservers, a lot of hours and at least 10 apologizing mails I managed to remove myself. This reminded me, that I use the same method: RBL blockings right inside postfix’s main.conf.
So if anyone got listed on one the lists I use, I reject their mail just like it happened to me. I clearly feel now, that this is not the good approach. So I looked for some kind of weighted possibility, like spamassassin for spam, and I met policyd-weight. It is the perfect tool I was looking for, and the best, Ubuntu has it as package.
# apt-get install policyd-weight
The only thing: it doest not provide a default conf file, you need to create it with a build-in feature:
# policyd-weight defaults > /etc/policyd-weight.conf
You also need to add it to postfix’s main.conf, right into smtp_recipient_restrictions
# check_policy_service inet:127.0.0.1:12525,
You can also remove every RBL entry from here after this is enabled.
Reload postfix
# /etc/init.d/postfix reload
and your system is ready to use policyd-weight, a lot more sophisticated solution for RBL listings, than built-in version of postfix.
To see more, visit Ubuntu manpage of policyd-weight, or the poject’s website.
Quick installing eBox 1.2 with managesieve and custom spam filtering under Ubuntu 8.04
eBox platform is a Perl-based web administration console for a linux small business server. When you own one or not too many servers, and not only redneck linux sysadmins for the tasks, eBox is a free choice over Microsoft solution.
You can read a lot more about it in forum, on it’s site or Wikipedia.
Although eBox has it’s own distribution, I wanted to get it work on Ubuntu 8.04 – but the version in the repo is only 1.0, and I really needed 1.2. Fortunatelly, eBox has a PPA site, so it can be inserted into Hardy. Open /etc/apt/sources.list with your favourite editor (mcedit, vim, emacs, etc.) and add the following lines:
deb http://ppa.launchpad.net/ebox/1.2/ubuntu hardy main
deb-src http://ppa.launchpad.net/ebox/1.2/ubuntu hardy main
You’ll also need an apt-key for this to get it work:
# apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 342D17AC
There’s another PPA, published by Molnár Károly, a fellow Hungarian. It’s very important to put it in the begining of the file, before the ubuntu standards! That is because the installed version by apt is the first possibility on the list.
deb http://ppa.launchpad.net/karoly-molnar/dovecot-managesieve/ubuntu hardy main
deb-src http://ppa.launchpad.net/karoly-molnar/dovecot-managesieve/ubuntu hardy main
and the key:
# apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 3B498A2C
We’re going to need this for Dovecot with Sieve, read on.
Updates repos,
apt-get update
and eBox is ready for install.
I didn’t need everything, so I just gave the following command:
# apt-get install ebox-antivirus ebox-firewall ebox-mail ebox-network ebox-objects ebox-services ebox-usersandgroups
This is going to install a lot of software, so be patient, and prepare with enough bandwidth. After all, you can access your eBox platform on https://[your ip].
I didn’t install ebox-mailfilter for reason. First of all, I don’t really like amavisd, and second, it is going to fail, and the whole mail system will going to stop because of an error in the eBox stub naming related to amavisd: amavisd does not read /etc/amavisd/amavisd.conf as it’s conf file. If you rename it, it’ll work, but eBox keeps naming it back.
So I looked for something else as a solution. I needed to:
- install spamassassin
- add clamav plugin to it
- get a version of dovecot with sieve patch for local delivery
- change ebox settings about to use all of this.
We already added Károly Molnár’s dovecot with sieve and a security patch, so Dovecot with Managsieve is installed. The next thing is spamassassin and it’s clamav plugin.
# apt-get install spamassassin spamc
# cpan
CPAN will ask some questions at first run, just hit Enter, usually that’s enough. When the promt is ready, install
cpan> install File::Scan::ClamAV
cpan> exit
When it is complete, save the two files (clamav.cf, clamav.pm) from http://wiki.apache.org/spamassassin/ClamAVPlugin into /etc/mail/spamassassin
Now, nearly everything is complete, the last step is to modify the stubs of eBox. This is not the best solution; an update could overwrite all changes, the perfect solution would be to place regex patterned scripts into /etc/ebox/, but that was too much for my taste.
So I opened the configuration templates from /usr/share/ebox/stubs/mail/and modified what I needed.
# mcedit /usr/share/ebox/stubs/mail/dovecot.conf.mas
Find the line started with protocols = and add managesieve after %>
Managesieve listens on port 2000, you’ll have to open this in eBox firewall.
After protocol POP3, add the following:
##
## MANAGESIEVE specific settings
##
protocol managesieve {
# Login executable location.
login_executable = /usr/lib/dovecot/managesieve-login
# MANAGESIEVE executable location. See IMAP's mail_executable above for
# examples how this could be changed.
mail_executable = /usr/lib/dovecot/managesieve
# Maximum MANAGESIEVE command line length in bytes. This setting is
# directly borrowed from IMAP. But, since long command lines are very
# unlikely with MANAGESIEVE, changing this will not be very useful.
#managesieve_max_line_length = 65536
# Specifies the location of the symlink pointing to the active script in
# the sieve storage directory. This must match the SIEVE setting used by
# deliver (refer to http://wiki.dovecot.org/LDA/Sieve#location for more
# info). Variable substitution with % is recognized.
sieve=~/.dovecot.sieve
# This specifies the path to the directory where the uploaded scripts must
# be stored. In terms of '%' variable substitution it is identical to
# dovecot's mail_location setting used by the mail protocol daemons.
sieve_storage=~/sieve
# If, for some inobvious reason, the sieve_storage remains unset, the
# managesieve daemon uses the specification of the mail_location to find out
# where to store the sieve files (see explaination in README.managesieve).
# The example below, when uncommented, overrides any global mail_location
# specification and stores all the scripts in '~/mail/sieve' if sieve_storage
# is unset. However, you should always use the sieve_storage setting.
# mail_location = mbox:~/mail
# To fool managesieve clients that are focused on timesieved you can
# specify the IMPLEMENTATION capability that the dovecot reports to clients
# (default: dovecot).
#managesieve_implementation_string = Cyrus timsieved v2.2.13
}
##
## LDA specific settings
##
protocol lda {
# Address to use when sending rejection mails.
# postmaster_address = mail@domain
log_path = /var/log/dovecot.log
info_log_path = /var/log/dovecot.log
# Hostname to use in various parts of sent mails, eg. in Message-Id.
# Default is the system's real hostname.
#hostname =
# Support for dynamically loadable plugins. mail_plugins is a space separated
# list of plugins to load.
#mail_plugins =
#mail_plugin_dir = /usr/lib/dovecot/modules/lda
# Binary to use for sending mails.
#sendmail_path = /usr/lib/sendmail
# UNIX socket path to master authentication server to find users.
#auth_socket_path = /var/run/dovecot/auth-master
# Enabling Sieve plugin for server-side mail filtering
mail_plugins = cmusieve
}
And in plugin {} part insert
# sieve sieve_global_path = [your path]
The given path should be writeable by dovecot.
Save the file, and open the next one:
# mcedit /usr/share/ebox/stubs/mail/main.cf.mas
Find the lines
virtual_transport = virtual mailbox_transport = virtual
and replace virtual with dovecot so it would look like this:
mailbox_transport = dovecot virtual_transport = dovecot
Save the file, and open the next:
# mcedit /usr/share/ebox/stubs/mail/master.cf.mas
Search for the line:
dovecot unix - n n - - pipe
and add this after:
flags=DRhu user=ebox:ebox argv=/usr/bin/spamc -e /usr/lib/dovecot/deliver -d ${recipient} -f {sendder}
If there’s something similar, replace it with this.
The system is now ready to use.
What we’ve done now: the mail is recieved by Postfix, than given to spamassassin (and clamav, with the plugin), which adds the X-Spam and X-Spam-Virus headers, and then Dovecot’s Local Delivery Agent delivers it to the users maildir.
The only thing left is to create a default sieve filter, so create a file named sieve.default, save it to the [path] you’ve given in the dovecot.conf.mas as global sieve path, and add the following content to it:
require "fileinto";
if header :contains "X-Spam-Virus" "Yes" {
fileinto "Virus";
stop;
}
if header :contains "X-Spam-Flag" "YES" {
fileinto "Junk";
stop;
}
Enjoy.
Roundcube has a perfect plugin to configure sieve filters per user.
UPDATE:
According to Dovecot Prebuild binaries page, all Ubuntu releases are built with managesieve, so the additional apt source can be skipped.
I tested it; I seems to be true.










