HotSpot
wrt_configure.cgi автоматически настраивает chillispot на DD-WRT, FreeBSD, Linux.
Установка
Для того, чтобы точка доступа получила доступ к файлу wrt_configure.cgi необходимо дать такие права в Apache:
Важно: файл конфигурации работающий для apache24 доступен в abills-0.58 и выше (коммерческая версия abills-0.72 и выше).
При использовании программы автоматической настройки нужно:
DDWRT
ABillS Hotspot Solution
Сервер доступа (WiFi маршрутизатор) с фиксированным адресом.
Настройка WiFi маршрутизатора:
1. Берём точку доступа в случае тестового стенда была использована ASUS WL-500g
2. Прошиваем WRT прошивку. Более удобной в работе вышла DD-WRT (http://www.dd-wrt.com)
3. После успешной прошивки прописываем статический IP адрес
4. Настраиваем Chillispot
Primary Radius Server: 192.168.1.40 (Данный адрес является адресом сервера биллинга)
Shared Key: Пароль к радиус серверу
Radius NAS ID: идентификатор точки доступа для радиус сервера
UAM Secret: Пароль шифрования данных между биллинг сервером и точкой доступа
coaport 1700 — Для сбрасывания с линии при помощи Radius PoD
radiuslisten 192.168.1.45 – Для передачи параметра в параметре Radius NAS-IP- ADDRESS [].
5. Настройка биллинг сервера ABillS.
Для каждой точки доступа создаётся свой сервер доступа в биллинге.
(/ Сиcтема/ Сервера доступа/)
IP: IP адрес точки доступа
Тип: Тип нужно установить в chillispot
Alive (sec.): Время обновления статистики. По умолчанию 300 секунд
Управление IP:PORT: IP адрес и Порт сервера доступа для отключения абонента (порт
по умолчанию 3799)
Пароль: Пароль для отключения
6. Проверяем. Открываем браузер при первом наборе адреса должно показаться окно
Сервер доступа с динамическим IP адресом
Точка доступа соединяется с биллинг сервером по протоколу pptp и в этом туннеле
запрашивает в биллинг сервера данные об авторизации и передаёт аккаунтинг данные.
Сами же клиенты пользуются Интернетом на прямую без использования туннеля.
Настройка WiFi маршрутизатора:
1. Берём точку доступа в случае тестового стенда была использована ASUS WL-500g
2. Прошиваем WRT прошивку. Более удобной в работе вышла DD-WRT (http://www.dd- wrt.com/)
3. Настраиваем VPN соединение к серверу доступа
4. Настраиваем Chillispot на Wi-Fi маршрутизаторе.
5. Настройка AbillS
Создаём VPN сервер:
/ Настройка / Сервера доступу/
| IP: | IP адрес VPN сервера |
|---|---|
| Название: | Название |
| Описание: | Описание |
| Тип: | Выбираем тип в зависимости от Вашего VPN сервера. (Для Linux pppd) |
Для каждой точки доступа создаётся свой сервер доступа в биллинге.
/ Настройка/ Сервера доступу/
| IP: | IP адрес точки доступа |
|---|---|
| Название: | Название |
| Описание: | Описание |
| Тип: | Тип нужно установить в chillispot |
| Alive (sec.): | Время обновления статистики. По умолчанию 300 секунд |
| Управление IP:PORT: | |
| Пароль: | Пароль для отключения |
Автоматическая настройки chillispot:
wrt_configure.cgi автоматически настраивает chillispot на DD-WRT,FreeBSD,Linux
При использовании программы автоматической настройки нужно:
1. Зайти в биллинг / Настройка / Сервера доступа
2. Завести сервер доступа с типом “chillispot”
3. Повторно открыть его для проверки параметров и получения линка автоконфигурации.
а) в разделе “Hotspot Настройки” выбирать тип сервера доступа chillispot
б) скопируйте линк в буфер обмена
4. Открыть веб интерфейс точки доступа (или консоль в зависимости от типа сервер) и в
меню выполнение команд вставляете линк автоконфигурации
а) Если сервером Hotspot выступает Linux или FreeBSD, тогда линк автоконфигурации
Бесплатный Wi-Fi, с небольшой изюминкой
Данная статья повествует о небольшом проекте бесплатной Wi-Fi сети, об основных технических проблемах и решениях. Цель – просто рассказать о достаточно оригинальном проекте.
Чуть меньше года назад, моё руководство решило на территории организации развернуть сеть бесплатного Wi-Fi для посетителей. Все было бы просто и прозаично, если бы не одно интересное условие: прежде чем пользователь попадет в Интернет, он должен посмотреть информационную страницу, с нашей «рекламой».
После небольшого анализа пришли к выводу, что подобное можно реализовать только с помощью отдельного сервера- шлюза, скорее всего на Linux-е. Краткое ТЗ с общим описанием задачи разосланное по компаниям, занимающимся разработкой/внедрением решений хотя бы приближенных к подобному, показало, что при заказе внешнего решения стоимость проекта взлетит за облака.
После долгих раздумий и фантазий на тему: как же это реализовать (с погружением в глубины протоколов, и десятками эротических фантазий как же подменить пакеты, заголовки и т.д.) было найдено простое и логичное решение.
Гениальное – просто
- Пользователь подключаясь к сети получает ip-адрес с помощью обычного dhcp-сервера. В настройках указывается наш сервер в качестве шлюза по умолчанию.
- На сервере по умолчанию прописан такой набор правил iptables:
#!/bin/sh
LOG_FILE=/var/log/script_log
<
date | tr «\n» » »
echo -n ‘|IP:’
echo -n $1
echo -n ‘|MAC:’
/sbin/arp $1 -n | grep $1 | tr -s ‘ ‘ | cut -d ‘ ‘ -f 3 | tr «\n» » »
mac=`/sbin/arp $1 -n | grep $1 | tr -s ‘ ‘ | cut -d ‘ ‘ -f 3 | tr «\n» » «`
if ( sudo /sbin/iptables -n -L -t nat —line-numbers | grep $1 > /dev/null )
then
echo ‘|Rule exists!!’
else
echo -n ‘|Add rule ‘
sudo /sbin/iptables -t nat —insert PREROUTING -s $1 -j ACCEPT
echo -n ‘|Creat shedule:’
echo «sudo /sbin/iptables -t nat -D PREROUTING -s $1 -j ACCEPT » | at -m now + 45 minutes
sudo /usr/bin/python /usr/share/nginx/html/stat.py $
fi
> >> $LOG_FILE 2>&1
Который делает два основных действия: добавляет правило в iptables, и создает отложенную задачу в at.
sudo /sbin/iptables -t nat —insert PREROUTING -s $1 -j ACCEPT
Помещается в цепочке PREROUTING на первую позицию, тем самым располагаясь ДО правил редиректа. В результате пользователь с данным адресом получает полный доступ в Интернет.
Второе основное действие, создание правила в at:
echo «sudo /sbin/iptables -t nat -D PREROUTING -s $1 -j ACCEPT » | at -m now + 45
Схема была реализована, протестирована, и доказал свою жизнеспособность.
На этом стоило бы наверное закончить рассказ, но за «Чуть меньше года» было проделано работ по доводке проекта, устранению мелких косяков и добавлению достаточно оригинальных фич.
Менталитет
Первая возникшая проблема была в «злоупотребляющих». Было замечено, что некоторые особо жаждущие до халявы личности пользуются сетью чрезмерно долго. Для выявления подобных было решено вести статистику. Основная проблема в том что все биллинг- системы (или простенькие модули для ведения статистики) считают базовым элементом либо логин, либо ip-адрес. В нашем же случае первого просто нет, а ко второму привязываться нельзя, т.к. ip-адреса не статичны. Нужная была статистика опирающаяся на mac- адрес. После долгих изысканий пригодных решений найдено не было. Поэтому было решено изобрести очередной велосипед написать свое. Поскольку по сути необходимо, и достаточно, было считать кол-во сессий проведенных mac- адресом был написан простенький скрипт на python (к сожалению мои познания bash-а не смогли вытянуть данную задачу):
import sys
file = open(‘/var/log/stat.file’,’r’)
line = file.readlines()
line2 = »
i = 0
while len(line) > i :
line2 = str(line[i])
line2 = line2.rstrip()
line2 = line2.split()
if line2[0] == str(sys.argv[1]) :
line2[1] = str(int(line2[1])+1 )
del line[i]
line.insert(i,line2[0]+’ ‘+line2[1]+’\n’)
break
i = i + 1
else :
line.append(str(sys.argv[1])+’ ‘+’1’+’\n’)
###########
file.close()
file = open(‘/var/log/stat.file’,’w’)
file.writelines(line)
file.close()
Который вызывался из основного скрипта. В logrotate была добавлена секция для данного файла с периодом в неделю. И через две недели бы получен список «постоянных клиентов» mac-адреса которых были занесены в черные списки на коммутаторе установленном перед сервером.
Велосипеды не пройдут!
Следующая проблема была более оригинальна: при одновременном запуске нескольких скриптов один из них выдавал ошибку iptables (чтото из серии “ iptables: Unknown error 4294967295 ” ), не выполняясь. Если это был скрипт на создание правила, то ничего страшного не происходило – пользователь просто обновлял страницу и запустившийся заново скрипт отрабатывал без ошибок (конечно же если опять не попал на одновременный запуск, судя по логам однажды одному бедолаге сильно не везло, и он 5 раз попадал на одновременный запуск ).
Если же с такой ошибкой вылетала задача удаления правила, то ip-адрес оставался в списках, и пользователь мог бесконечно долго и безнаказанно сидеть в Интернете.
Первое временное решение пришло в виде простенького bash-скрипта сверяющего список адресов в iptables и пуле задач at:
#!/bin/bash
LOG_FILE=/var/log/script_log
<
echo -n «Checking rules: »
date | tr «\n» » »
ar_ip=(`sudo iptables -L -t nat -n | grep ACCEPT | grep -v policy | cut -d ‘ ‘ -f 10 | tr ‘\n’ ‘ ‘`)
ar_at=(`grep 168.143. /var/spool/at/* | cut -d ‘ ‘ -f 9 | tr ‘\n’ ‘ ‘`)
count=$<#ar_ip[@]>
for ((i=0; i <= count ; i++ ))
do
for h in «$
do
if [[ $
then
unset ar_ip[$i]
continue 2
fi
done
done
echo -n «|Delete rules: »
for i in $
do
sudo /sbin/iptables -t nat -D PREROUTING -s $
echo -n $
done
echo «|Checking done»
> >> $LOG_FILE 2>&1
Скрипт был помещен в /etc/cron.hourly, и исправно удалял последствия ошибок iptables.В принципе решение было достаточным, но «нет предела совершенству» и я начал бороздить бескрайние просторы в поисках лучшего решения. И оно было найдено. На одном из «уютненьких» linux- форумов, один из мастодонтов указал мне в сторону данного проекта
По сути, данный проект – это небольшая разработка для запуска bash-скриптов, помещающая их в пул и выполняющая в порядке строгой очередности, один за другим.
Строчка запуска скрипта на веб- странице была модифицирована до вида
И ошибки iptables исчезли.
Проблема третья, или как я помог open-source сообществу
Когда проект уже работал около полу года, и люди уже достаточно о нем узнали, появилась еще одна серьезная проблема: точки доступа (Lynksys wap54g) начали самопроизвольно отключатся/виснуть/перезагружаться. Естественно первое что пришло в голову это посмотреть логи. Как оказалось Lynksys не зря относят к «домашнему» сегменту, ведь домохозяйкам читать логи ни к чему. Единственное что содержалось в логах это когда какой mac- адрес подключился. К тому же формат логов был уникальный и обычный syslog- сервер его не понимал. Как всегда Lynksys предлагал какую- то подозрительную утилиту содержащее что- то волшебное в свое названии, якобы способную самостоятельно и мигом настроить вашу домашнюю сеть. После краткого изучения утилиты был сделан вывод о её непригодности, и опять началось долгое путешествие по бескрайним просторам. Где то в бескрайних степях На sf.net был найден маленький загнувшийся в 2009 проект (http://sourceforge.net/projects/wap54g-log/) который понимал формат логов точек и умел складывать их в файлик. «А большего нам и не надо!» ©
Оказалось, что рано радовались. Запись в логах имела вид:
May 20 12:04:42 /usr/local/bin/wap54g-log[17544] Wireless PC connected 00:26:C7:61:BB:26
И понять к какой же из точек подсоединился клиент, было невозможно. А следовательно и сделать вывод о нагрузке, как одной и самых возможных причин недостойного поведения точек.
И тут пришлось вспоминать С. Как оказалось не вспоминать, а изучать заново, т.к. то, что писалось на втором курсе в институте в Visual Studio, лишь отдаленно напоминало код этой небольшой утилиты
После вдумчивого чтения была обнаружена структура theiraddr, относящаяся к типу sockaddr _in (стандартный для unix тип сокета) который содержит в себе еще одну структуру in_addr которая содержит в себе единственную переменную s_addr типа in_addr_t. «Яйцо в утке, утка в зайце, заяц в шоке» ©. Самым веселым был комментарий «То, что используется такая структура, а не просто переменная типа in_addr_t, сложилось исторически».
Углубляясь все дальше и дальше, была обнаружена библиотека <arpa/inet.h>(О господи! Призрак арпы!) содержащая в себе функции для работы с данными структурами. Путем преобразования функцией inet_ntoa(strcu) и помещение всего это в вывод утилиты, получилось примерно так:
May 20 12:23:38 192.168.143.114 /usr/local/bin/wap54g-log[17544] Wireless PC connected 00:26:C7:61:BB:26
Ключевое отличие, в наличии адреса точки. Т.е. теперь можно судить о распределении нагрузки по точкам.
Как оказалось интуиция/логика/5-ая точка, меня не подвела. И после небольших наблюдений выяснилось, что Wap54g не выдерживает даже 30-ти одновременно подключенных пользователей.
Эту проблему еще предстоит решить. Пока вариантов кроме замены точек на что-то более «промышленное» я не вижу. Руководство решает что же делать, а разработчику утилиты было отправлено письмо с благодарностями, и предложениями под доработке.
Были и более мелкие проблемы: nginx выдавал 404 страницу, если адрес с которого происходил редирект, содержал название страницы и get-запрос в с троке адреса. Решилось одной строчкой в конфиге виртуального сервера «rewrite ^/(.*) /index.php last;». Но о подобных мелочах здесь не стоит рассказывать т.к. все они банальщина и повседневность.
Вместо заключения
Окончательное решение о написании данной стать утвердилось после прочтения пары статей «Как стать системным администратором — пособие для начинающих». Я не считаю себя каким- либо гуру, трезво понимаю что я – системный администратор linux- направленности средней руки. В это статье показана лишь малая часть того объема знаний что необходима для повседневной работы. Всего лишь html,bash,python, да небольшое знание С. Ну и как обязательная база: знание теории (всего ИТ, от сетей до программирования), и ОС (утилиты, системные приложения) с которой в основном приходится работать. Думаю, это будет неплохим дополнением.
Chillispot
NOTE: ChilliSpot was replaced in DD-WRT by CoovaChilli. The webUI naming schema was officially changed in builds after 43192. For posterity reasons, references to ChilliSpot shall remain in the wiki until a future edit.
CoovaChilli is an open-source software access controller, based on the popular, but now defunct, ChilliSpot project, and is actively maintained by an original ChilliSpot contributor. Released under the GNU General Public License (GPL). CoovaChilli is a feature rich software access controller that provides a captive portal / walled-garden environment and uses RADIUS or a HTTP protocol for access provisioning and accounting.
[edit] Important Note
There have been ongoing issues with ChilliSpot functionality throughout development history in DD-WRT. Firmware versions 44236 and newer should be fully functional.
(Old Note)It Seems that no firmware including ChilliSpot after DD-WRT V24 SP2 SVN 15506 works due to a compiler syntax bug. If you need to use ChilliSpot and if your device support it you should try a firmware release between SVN 14896 and SVN 15506
[edit] Brief introduction
[edit] Executive summary
ChilliSpot is a way to
- Easily make the wireless or LAN-connected computers display a «landing page» on users’ browsers.
- Redirection occurs on the first Web page, and until the user clicks through (I Agree/Login).
- Optionally earn revenue from your hotspot.
- Provide a Wi-Fi usage agreement, advertising or other neighbourhood or commercial activities.
- Proactive overuse prevention:
- Limit the bandwidth, up and down, hotspot-connected laptops or desktops can use.
- Limit the number of times within a given period hotspot users can log in.
- Other fine-grained limitations.
ChilliSpot can be used for single router, or extended with the use of external services to cover an entire metropolitan area.
[edit] Technical description
ChilliSpot is an open source Captive Portal wireless or local area network (LAN) access point controller. It is used for authenticating users. It supports Web-based login, which is today’s standard for public hotspots. Authentication, Authorization and Accounting (AAA) is handled by an on-line provider, or a local radius service you provide.
ChilliSpot cannot work alone and needs two (2) additional services, provided externally:
- A Web Portal to which users are redirected. This portal can provide any mean of access control service such as user login, on-line billing, etc.
- A Radius service for authentication and accounting. Most of the time, the Radius server and the Web server will be tightly integrated to offer advanced services.
- There are several on-line providers (ChilliSpot Service Provider, CSP) that have the additional services needed to make ChilliSpot work: See Captive Portal#Provider
- The advantage of a CSP is your ChilliSpot hotspot can operational within minutes.
Chillispot.info Web site redirects to chillispot.org Web site. ChilliSpot is now defunct and was replaced by CoovaChilli (see point 1 at the top of the wiki).
[edit] Terms and definitions
- DD-WRT device: Your DD-WRT-flashed device!
- ChilliSpot Account: Your [free] account on WorldSpot.net or [[Captive Portal|another online provider of ChilliSpot services[[.
- ChilliSpot Service Provider (CSP): An on-line (Internet-based) provider of the necessary back-end services for the DD-WRT device running ChilliSpot. The major contributor to this Wiki and other authors use Worldspot.net, but other CSP’s are available. If you have good success and are familiar with Wiki-editing and Chilli, please update this Wiki with your preferred provider. A list of CSP’s is at the bottom.
[edit] Prerequisites
- A DD-WRT-Compatible device programmed with a distribution of DD-WRT containing Chilli. Highly recommend build 13064 (10/10/09) or the latest BETA. See general flashing instructions elsewhere in the DD-WRT Wiki.
- For those using a CSP (ChilliSpot Service Provider, see above), the DD-WRT device must already have Internet access.
- Check that a wireless laptop is connected through the DD-WRT device and receiving Web pages.
- If you chain your hotspot off your existing LAN, so the ChilliSpot users are a separate, private subnet of your existing LAN, the DD-WRT WAN interface is facing the LAN. It is recommended that you open management interfaces on DD-WRT to the WAN-side so you can control the DD-WRT telnet/ssh/Web interface from your existing network.
- After signing up, the CSP should show you a convenient customized screen-image displaying the entries for the DD-WRT device.
- If you have Secondary Access Points specifically to increase the Wi-Fi coverage, and these SAP’s are physically wired into the LAN ports, then on the main ChilliSpot’ed DD-WRT device, you do not want to ‘Separate Wifi from the LAN Bridge’. Configurations A or B is recommended.
- If you have «public-access terminals» that are wired LAN computers, such as at a library, connected to the DD-WRT device, and you want these clients to now be directed to the ChilliSpot Authentication Splash Page, you also do not want to «Separate Wifi from the LAN Bridge». Configuration A is recommended.
- If you want to maintain a single, homogeneous network [all Internet-connected devices shares the same private subnet], of wireless and wired clients, and your wired clients have been made secure from wireless attacks [outside of the scope of this guide], then you do not want to «Separate Wifi from the LAN Bridge». Configuration B is recommended.
[edit] Additional prerequisites for older firmware
- Highly-recommended to have firmware build 14929 as the running firmware.
- Firmware V23xx: If you haven’t reset to factory settings after installation, do it, then reboot once more.
- Resetting to factory defaults is NOT needed for V24Final and later.
[edit] Configuration
After carefully following the above sections:
Three (3) options:
- New Hotspot Introduction: Hang a new DD-WRT device with Chilli, off an existing LAN. Existing LAN is left completely alone. If you have a DHCP server or some custom corporate setup and you don’t want to change or alter it, this is the best way.
- One (1) network: Put both the wireless local area network (WLAN) and LAN clients on the Chillspot. This is good for people who want to switch entirely over to ChilliSpot on their LAN and WLAN.
- Two (2) networks: Keep the existing LAN clients on normal services while splitting off the WLAN clients to chilli. This is okay if you already have a DD-WRT box managing services, and you only want the WLAN clients to go to the ChilliSpot portal page.
[edit] Configuration A: Add new Chilli-powered hotspot to existing non-DD-WRT subnet
Add chilli hotspot services to an existing network.
The existing network is not changed at all.
All existing clients operate as before.
A connection from the existing network is plugged into the WAN port on the DD-WRT device. Besides changing the DD-WRT device to allow WAN access to SSHd and the Web interface, the steps are nearly identical to «One Network Subnet». New library access terminals, for instance, can be connected to the LAN ports on the DD-WRT device.
[edit] Configuration B: One network subnet, move all clients to ChilliSpot
Keep your pre-Chilli setup throughout. Move all clients to Chilli. The LAN ports and Wi-Fi are bridged together and are seen as a single network managed by ChilliSpot.
Also known as, «Separate WLAN from LAN» — Disable.
It is strongly recommended that before doing this, you should access DD-WRT’s Web interface from the WAN port. If you have a configuration problem with ChilliSpot, you will still be able to access the configuration interface.
This setup is mandatory if you want to use the WDS feature (Wi-Fi repeaters to extend the Wi-Fi range)
ChilliSpot has its own DHCP Server. If «Separate Wi-Fi from LAN Bridge» is disabled, the DD-WRT device’s normal DHCP Server must be off.
Your existing LAN subnet was 192.168.1.x and your DD-WRT device LAN IP was 192.168.1.1. You have a conflict, as DD-WRT’s WAN will be your LAN. So you must change DD-WRT’s LAN IP to another subnet.
- From the DD-WRT Web Setup page, change the DD-WRT device LAN IP to another subnet, such as 192.168.2.1 & press Apply.
- Reconfigure your LAN client with 192.168.2.10, and reconnect to the Administration Web Site of the DD-WRT device on 192.168.2.1.
- From the Setup (Main page) of the Web Interface, turn off the DD-WRT DHCP Server.
-
- With build 13064/v24: Services, Hotspot — ChilliSpot section. or
- With v23xx: Administration, Hotspot — ChilliSpot section.
[edit] Configuration C: Existing DD-WRT router, ChilliSpot manages only Wi-Fi clients. The existing LAN, after some interruptions, operates as before (same IPs, DHCP services)
Two Networks, Wi-Fi separated from LAN. Existing DD-WRT device as a Router, adding ChilliSpot duties
- «Separate Wi-Fi from the LAN Bridge» — ENABLE
- Enable ChilliSpot
- For build 13064 (10/10/09), DHCP Interface — leave at LAN. Older builds may have to select WLAN.
[edit] Configuration D: Extend the network to regular neighbours and momentary roaming users (draft)
The actual instructions presented have not been polished in their formatting and presentation. And some additional testing is required (2011-12-06. having a bit of difficulty getting it working properly)
A DD-WRT box performs two functions — both an access point (AP), and a ChilliSpot in this example.
Like the other examples above and by the main author of this wiki, Configuration D is written and done with actual hardware and a successful, stable setup, running DD-WRT, in this case WHR-HP-G54 Buffalo-brand routers. For this case, there is a 50/10 backhaul (megabits) over VDSL2, a main wired LAN and a/n 5ghz separate wireless provided directly from the VDSL2 box (not DD-WRT). The particular model of DD-WRT-enabled box could not handle that level of traffic due to hardware limitations. A dedicated VDSL2 Fritzbox 7570 handles DSL conversion, connection to internal servers, and telephone devices. The DD-WRT box functions as a passthrough device to provide wide-coverage signal for regular neighbours who need more than what ChilliSpot provides, and casual users who only need to operate as clients, to check email for instance. Heavy wireless traffic goes directly through an 802.11a/n 5ghz signal provided directly from the Fritzbox 7570. This solution is an excellent way to provide secondary services to widespread users. A dedicated, modern DD-WRT box could potentially provide all network services and main routing functions, however, in this case a good quality router is rented directly from the telephone company and does the job.
All existing clients operate as before.
The desire is to have an added, encrypted WLAN signal, and add Chilli also as a second WLAN signal. Only some of the possible reasons for the configuration are:
- Allow casual roaming users 15 minutes of access AND
- Introduece the policy of the encrypted WLAN with the Chilli splash page WHILE
- Having local, non-roaming users, approach the hotspot operator physically and hand over donations to access the primary direct-to-backhaul, encrypted WLAN signal:
- Locals like cash and no specific logins.
- UPNP and port forwarding available: UPNP is blocked by Chilli (currently)
- Burst access: No limitation to bandwidth. Operator must trust each user to not hog bandwidth.
- Collect the emails of every user and all MAC addresses. If one is hogging bandwidth uncontrollably, email the other users and change the encrypted SSID password.
DDNS: opendns.com (restricts, e.g., pornosurfing through Chilli), provides dynamic DNS services more reliable than dyndns imho
DD-WRT Build: 14929The rest of this Configuration D text is a DRAFT format. There are some persistent issues yet. As more practical experience is gained and more time is possible to edit this, the text will be «dressed up». For now, it is raw text.
Latest tip: Hook the backhaul (local LAN) cable into a LAN port, and patch over to the WAN port. This has not been verified — and it seems the source is the need to be able to configure chilli to pull network from the LAN instead of the WAN interface.
These are the direct notes for setting up a chilli router with a private, encrypted wlan cloud as an alternate. The chilli cloud gets 15 minute access per day per client. Visit worldspot.net and set up your account. access points and profiles there before doing any of the following.
Please note, if the upstream Internet has "died" for any reason, it can take the hotspot five (5) minutes to get a new upstream Internet address. If you have not waited five (5) minutes, please do so now.
If you have performed a complete reset on the router, OK, otherwise push and hold the button for 30 seconds or perform a Factory Reset from the Web interface, then:
Use a LAN cable, not wireless, when doing any of this! Plug into a LAN port on the DD-WRT box. If your main LAN Ethernet IP address is not already 192.168.1.x, must manually add an IP to your LAN card to be something like 192.168.1.5, temporarily to be able to connect. Leave your existing IP, as we are going to use that also, later.
Presumptions: your local LAN operates on 192.168.2.x with 192.168.2.8 as the main router for LAN-->ISP. Alternate these for your specific setup. Usually I set the main LAN to be something other than 192.168.0.x or 192.168.1.x as it seems almost all new or reset router devices have that as a default IP, and I don't want them to conflict with the main LAN. I also like to make the main router something other than x.x.x.1.
If your main LAN is 192.168.1.x and your main router is 192.168.1.1, DO NOT plug your main LAN into the DD-WRT box at all; only plug your laptop into the ports on the DD-WRT box as indicated until you have decided on substitutes for the DD-WRT box IPs.
Plug in your LAN cable from the laptop into a LAN port on the DD-WRT box.
Start, Run. http://192.168.1.1 or open the address in the Firefox browser.
IMPORTANT: Leave all settings alone unless they are specifically mentioned below.
Main DD-WRT box page: Make your new login and password. For now, use "root" and a password of your choosing.
Connection type: Static IP (this points to the private LAN main router) WLAN IP 192.168.2.1, SUB 255.255.255.0, GW 192.168.2.8 (IP of main VDSL2 router) & DNS1 of 192.168.2.8, DNS2 4.2.2.4 (or other suitable secondary DNS)
Router name: Chillibrains or something useful to help you remember Host Name: chillibrains Domain: local
Router IP: 192.168.1.1 (this is the default IP, and for LAN-port access. It must be a different subnet than the WAN IP above! And different than the ChilliSpot subnet!) (for now, we will continue to use 192.168.1.1. later-on change this if you wish)
DHCP Server: Disable (chilli has its own dhcp module)
Server IP: 192.168.2.5 (local server IP) or 0.pool.ntp.org
Click SAVE, wait a second. Do not apply or reboot yet.
(we are using DNSOMATIC, part of opendns) DDNS Service: Custom DYNDNS Server: updates.dnsomatic.com / or for DynDns.org members.dyndns.org User Name: your username Password: your password Host Name: all.dnsomatic.com / or for Dyndns.org yourdomainname.dyndns.org URL: /nic/update? Additional DDNS options: [none for dnsomatic] / or for Dyndns.org try: --dyndns_system dyndns@dyndns.org --ip_server_name ip1.dynupdate.no-ip.com:8245 / (DynDNS service has had a problem with a non-reachable (down) checkip.dyndns.org)
Click SAVE, wait a second. Then click: MAC Address Clone: (optional) 12:34:xx or your chosen MAC 12:34:xx or your chosen MAC (Here we are only changing the first two number sets for setup.)
Click SAVE, wait.
Wireless, Basic Settings
Wireless Network Name (SSID): PrivatWLAN (Or your wireless cloud name for private LAN access.) Wireless Channel: 13 Sensitivity Range: 0 (suggested) (optional G-only) (This affects BOTH WLAN clouds)
Click SAVE, wait a bit. Click Add interface: 15minWLAN AP isolation Enabled Network configuration (leave at) bridged.
WPA2 Personal (WPA2-AES) for the primary WLAN NO SECURITY for the secondary (chilli) wlan. SAVE
Back to: Setup, networking Create bridge (ADD), Bridge 0 name br1, SAVE IP Address 192.168.181.0/255.255.255.0 SAVE Assign to bridge> Assignment 0: br0 interface eth1 Assignment 1: br1 interface wl0.1 You might have to toy with saving the settings a few times to get all the correct bridges to appear. SAVE
Wireless, advanced settings
[note these settings are specific to your radio. add or change as necessary] Wireless TX power will be at 28, I set to 251 and later the startup commands set higher. (Only the WHR-HP-G54 with hardware mods.) You can turn off Wireless GUI access for security if you like. Shortslot override Short Preamble Auto Frame burst disable Afterburner disable --- Scroll down to "Wireless Multimedia Support Settings" WMM support. Turn this off. Seems to work poorly with multiple clients connected (on the WHR-HP-G54). Click SAVE, wait a second.
Disable ttraff to save RAM WAN Traffic Counter: Disable Click SAVE, wait.
ChilliSpot: Enable Separate Yes, br1 Primary Radius: radius.worldspot.net Secondary Radius: radius2.worldspot.net "Remote Network": net 192.168.182.0/24 (This is the same thing as the "net" declaration) DNS IP (OpenDNS primary): 208.67.222.222 Redirect URL: https://secure.worldspot.net/wk/Uam (secure is the europe one, secure2 is the north american server.) The above Redirect URL is *CASE SENSITIVE* and must be entered exactly as shown above, in the box). Shared Key yoursharedkeyfrom worldspot Radius NAS ID: yourradiusnasid from worldspot UAM Secret: your UAM secret value from worldspot UAM Any DNS: 0 (leave at default) UAM Allowed: www.paypal.com,www.paypalobjects.com,paypal.112.2o7.net Additional ChilliSpot Options: domain local dns2 208.67.220.220 dynip 192.168.182.128/26 uamallowed 66.211.168.0/24,64.4.241.0/24,216.113.188.0/24 uamallowed 88.221.0.0/16,84.53.0.0/16,67.133.200.0/22,72.246.0.0/15 uamallowed 216.52.17.0/24,70.42.134.0/24,128.242.125.0/24 Click SAVE, wait. (dynip is not neccessary, as there are no static IPs in the same subnet as chilli in this tutorial)
Uncheck "Filter multicast" and "Filter ident." and "Filter anonymous ping" SAVE, wait.
Access restrictions, WAN access
Status: Enable Policy Name: Block164x Deny (this means Internet access. ) *** SCROLL DOWN CLICK "SAVE" *** Save, wait a second. *** scroll back up *** Edit list of clients Enter the IP Range of the clients 192.168.164.2 – 192.168.164.254 Block access from all IPs of 2 through 254. SAVE, then CLOSE
The goal is to block all computers that are not using ChilliSpot attempting from using the main subnet router directly on 2.x. Chilli blocks unauthorized access on the 182.x range, but not on the upstream WAN side of 2.x / Note: Otherwise, manually-configured wireless clients could potentially use a 2.x address to get online outside of chilli, crowding out other clients. [This theory is still being tested. Your results may vary.] SAVE then CLOSE SAVE
(We perform the next step NOW to make sure the DD-WRT box is accessible from the WAN port)
Web Access: Uncheck Protocol HTTP (Do not auto-load Web management interface) Disable Info Site Remote access: Web Gui management enable web gui port 80 Telnet enable
CRON (Reboot periodically, 2x a month, at 2 a.m. on the 1st and 15th. addresses leaks.) 0 2 1 * * root /sbin/reboot 0 2 15 * * root /sbin/reboot
IP Filter Settings
4096 TCP Timeout 500 UDP Timeout 90
Click SAVE, then wait.
W/VDSL2 50/10: (we split the bandwidth here between internal use and external users. External users are DD-WRT box primary WLAN cloud + ChilliSpot users.) 2500 / 25000 SAVE Select: http, click Add Skypeout, Add SkypetoSkype, Add Set http Express, Skypexxx protocols Premium (can add others here like NTP, DNS, RSTP)
Don't be surprised if the router locks out here for a bit. Wait. You may have to reboot it then plug into the WAN port, and communicate with it over the WAN IP. To restart the management Web interface, telnet into it, and run 'httpd' and continue..
Save, wait a second.
- fixes bug with ChilliSpot and MTU
/usr/sbin/iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1441:65535 -j TCPMSS --clamp-mss-to-pmtu Save Firewall. ---
- enables WOL from Internet
- ip neigh change 192.168.178.5 lladdr 00:1B:21:02:EE:4F nud permanent dev br0
- ip neigh add 192.168.178.5 lladdr 00:1B:21:02:EE:4F nud permanent dev br0
- turns on noack (optional)
- increases power to maximum (only on WHR-HP-G54 Buffalo/updated routers with hardware modification)
wl txpwr1 31 Save Startup
[edit] ChilliSpot setup: detailed options
- RADIUS Server 1 As assigned by CSP. the name or IP address of the primary RADIUS server.
- RADIUS Server 2 As assigned by CSP. the name or IP address of the secondary RADIUS server.
- If you have only one Radius Server, leave as 0.0.0.0 or specify the same field value of Radius Server 1.
- For One Network, change the default to 192.168.1.0/24, or your old subnet.
- For Two Networks, it’s 192.168.182.0/24 here by default.
- One could choose something else, like 192.168.155.0/24, so long as it is not the existing DD-WRT LAN subnet.
- Redirect URL As given by your CSP. The address of the UAM Server, the Web authentication portal.
- Shared Key As given by your CSP. It’s also called your RADIUS secret password
- RADIUS NAS ID As given by your CSP. The RADIUS name of your Hotspot
- UAM Secret is a secret password between the Redirect URL and the Hotspot. Given by the CSP.
- UAM AnyDNS Allows Clients to use their own DNS servers. Allows ANY traffic through port 53. Only set this to 1 if you know what you are doing, and can reconfigure IPTABLES properly!
- UAM Allowed is a list of Web sites that unauthenticated users are allowed to access.
- MacAUTH Enabled or Disabled. Allows authentication of clients by their WLAN or LAN card MAC (hardware) address. Not used in this guide.
- Additional ChilliSpot Options
- If your local domain is ‘local’, then
domain local - Your provider may offer another, optional setting for domain.
- If your second Internet provider’s DNS is for example 4.2.2.4, then for redundancy
dns2 4.2.2.4 - To tell ChilliSpot to limit DHCP addresses to be part of the entire subnet:
- dynip 192.168.1.128/26 (2)
- Can be most helpful in a ‘one network’ subnet setup.
- Allows fixed IP’s to exist from 192.168.1.2 through 127 for your existing devices.
- Apply Changes/Save, and if needed, reboot your DD-WRT device.
- Your ChilliSpot Hotspot should work now. If you tested your wireless client device before setting up ChilliSpot, right-click and ‘Repair’ the Wi-Fi connection in XP to get a new ChilliSpot-provided IP address.
(1) Remote Network is the same as the net command, found on the Internet, elsewhere in references to ChilliSpot configuration and chilli.conf. net defines the ChilliSpot network. In DD-WRT, the field is called Remote Network, but it is the same setting as net.
(2) dynip configures ChilliSpot to use a limited range of IP’s within the net parameter, as the client DHCP pool, instead of using the entire net range. In this example, address assignments from 192.168.1.128 to 192.168.1.191 are assigned to clients. IP’s from 2 through 127 are left for fixed assignments, and can be further specified by statip if DHCP clients come on the network needing a specific address from the ChilliSpot DHCP service.
[edit] Tips
If you are not knowledgeable about your LAN security, or have poorly configured insecure XP devices on your LAN, to reduce possible attacks from wireless clients, you can enable the option: «Separate Wi-Fi from the LAN Bridge» (your LAN won’t be visible to wireless clients). If you are certain your LAN is configured as secure, which it should be anyway, and you want to have access to your LAN equipment from your Wi-Fi, then leave «Separate. » Disabled.
- ChilliSpot will not start unless it can see the DNS Server specified the ChilliSpot settings.
- Note that after reboot, it can take a certain time before a wireless client receives an IP address. Don’t forget to switch back to automatic IP assignment (DHCP) on your client when testing!
[edit] Troubleshooting
[edit] Your client gets a ChilliSpot IP, but no welcome page, or certain Web sites don’t open (MTU Bug)
Maybe you are using a PPPOE modem and you are experiencing the MTU bug?
Add this to your Firewall Commands (Administration tab in the Web Interface, Commands sub-tab): Changes MSS to fit inside ChilliSpot tunnel. Important so some Web sites work properly, otherwise «MTU Bug»
/usr/sbin/iptables -t mangle -A POSTROUTING -p tcp —tcp-flags SYN,RST SYN -m tcpmss —mss 1421:65535 -j TCPMSS —clamp-mss-to-pmtu
[edit] ChilliSpot fails after a while, **memory full on router** on low-RAM units
This is a common problem when the infrequently-used Web Interface (httpd) is left running.
- On a hotspot (DD-WRT device) with 16 (or less) megabytes of RAM, the chilli process uses 19%.
- The Web Interface process, httpd, uses 19% also. About 3 megabytes!
- Newer builds of Chilli are supposed to use less RAM, although DD-WRT may not have these yet.
- The Web Interface uses a lot of RAM, and in any case, should not be left running on a production router.
[edit] Solution 1: SSHd (run HTTPD only when necessary)
- On the hotspot Web onterface, go to «Services, Services, Secure Shell», and turn on SSHd, and turn off Telnet.
- On «Administration, Management, Web Access», turn off HTTP Access (httpd).
- Make sure access to the hotspot WAN port is available if your setup is Configuration A: Hotspot Only. (See above)
- Save/Apply/Reboot as needed.
To use the Web Interface:
- For Configuration A, physically plug your laptop into the existing network.
- For Configuration B or C, physically plug your laptop into a LAN port on the DD-WRT device.
- Open your browser and log in to the ChilliSpot page as if you want to use the Internet, as Chilli’s firewall rules will block your client from connecting to the DD-WRT device/hotspot otherwise.
- The command may look like «putty 192.168.182.1» or
- «putty 192.168.182.1 -P 60000«, where 60000 is the chosen port number, if you changed the SSH port.
[edit] Solution 2: Telnetd alternate, in place of SSHd. Added: 2009.11.11
- Bring up the Web Interface of the DD-WRT device.
- In «Administration, Management, Web Access», turn off HTTP Access (httpd).
- In «Services, Services, Secure Shell»: Turn off SSHd.
- Scroll down and turn on Telnet (telnetd).
- Save changes
To use the Web Interface:
- Make sure your workstation or laptop data is secure to the hotspot.
- Anyone who can monitor the traffic can see the root password sent to the hotspot
[edit] Use the «top» command to check memory usage
After using Solution 2, here is the «top» output:
Mem: 9012K used, 3992K free, 0K shrd, 1136K buff, 2836K cached CPU: 0.1% usr 2.9% sys 0.0% nic 96.8% idle 0.0% io 0.0% irq 0.0% sirq Load average: 0.72 0.29 0.10 1/22 778
PID PPID USER STAT VSZ %MEM %CPU COMMAND[edit] DD-WRT Firmware: Administration/Hotspot/ChilliSpot tab does not show
Make sure you are using a package that includes ChilliSpot. ChilliSpot is not in the micro and mini versions of dd-wrt (consult this table).
[edit] Connection Failed on v24-SP2 Firmware(from SVN 14896 to SVN 15506)
if your settings seems to be correct but ChilliSpot don't start. It could come from a too long uamallowed list. Don't put more than three doamin name in this field. If you have more domain to add leave the Uamallowed field empty, and add your uamallowed domains in "Additional ChilliSpot Options" field.
[edit] Connection Failed on v23 Firmware
If your client does not recieve a ChilliSpot IP address you may have changed the ChilliSpot DHCP Interface. On older versions of DD-WRT Firmware, touching this setting breaks ChilliSpot. A fix is to reset to factory defaults and re-enter all your settings or use newer firmware.
If the UAM Secret you entered in ChilliSpot Settings is incorrect, you will have an authentication failure.
If the RADIUS Shared Secret is incorrect, the login process will hang.
[edit] More troubleshooting tips
If it does not work, you must connect with ssh or telnet to your router.
First, check that you have Internet access:
Worldspot Users: If you don't have any ping return, check the output of "ifconfig" and post it on the WorldSpot forum.
If Internet works from your router, but you don't have ChilliSpot working, check first that the chilli process is launched with
You should see a "chilli -c /tmp/chilli.conf" process. If not, recheck your ChilliSpot settings. For example, if you put a whitespace in the NAS ID, the chilli process won't launch.
[edit] For the FON Hotspot
Please see the FON Hotspot page for a guide and advice on setting up a FON hotspot using DD-WRT and ChilliSpot.
- If your local domain is ‘local’, then