Maybe this is covered elsewhere. i have 2 internal wlan cards.wlan0, wlan1. id lke to use both: one as a friendly AP and one as an IoT AP.
So I installed hostapd, but I can only configure one card. i dont even get an option to select the other card. Both are recognized in the system. It would be mice to be able to add multiple cards in setup instead of just one.
Im unsure where the hostapd config files live to be able to add the other wlan and have it appear in the WUI. But then if I do this, will it survive a version update?
R&R hostapd doesnt change anything because the config files arent purged. SO the old settings come right back. Maybe how to purge all the hostapd files?
Even more strange is When I change to WPA2 the network disappears. If i rename the network to something else (egfrom Wireless to Wireless-1) it shows up with WPA working. Change SSID back to original (eg Wireless) and the network is gone. So it seems i have something, somewhere surviving across R&R of hostapd.
You can definitely start two separate instances of hostapd with two separate configuration files. That’s not the problem. What you can’t do is having more than 4 zones in IPFire 2.X. Therefore you can’t have two blue zones with different firewall rules. If you do this, you need to use one of the other two zones, green or orange, which you will have to bind to one of the two wifi card. If you have an excess of network devices compared to the 4 zones, say 3 network cards and two wifi cards, you can only bridge two of them to bind the same zone.
The configuration file of hostapd is this one: /etc/hostapd.conf and is overwritten by the web user interface when you save. There you can create a different configuration file and start a second instance of hostapd pointing to it.
In synthesis, you create a second conf file, e.g. /etc/hostapd2.conf with the interface=green0 directive set correctly to the right interface (e.g. green0), then bridge the second device to another zone (again, e.g. green) (see wiki.ipfire.org - Zone Configuration and wiki.ipfire.org - Network Modes to create the bridge), start the second instance of hostapd using the other conf file.
/usr/bin/hostapd -B /etc/hostapd2.conf
I think you do not have to care about the .pid file as shown in many tutorials, as it will be created automatically and it will be named based on the zone associated with the interface, thus avoiding collisions.
To make it permanent, you can include the command in /etc/sysconfig/rc.local.
Thanks for reply. Here is how I have it set currently in zones:
I think your suggestion about the zone config is already implemented.
The only wireless in the blue zone is the intended target for IoT things.
The problem is occur when I visit tab: ipfire → WlanAP.
I do not get a choice of what card to select. I dont even know which card this is! See:
I do see something interesting at the bottom of the channel list though:
Lastly, here is the output of the /etc/hostapd.conf file:
driver=nl80211
######################### basic hostapd configuration ##########################
country_code=US
ieee80211d=1
ieee80211h=1
channel=- Automatic Channel Selection -
hw_mode=g
ieee80211n=1
wmm_enabled=1
ht_capab=[HT40+][SHORT-GI-20][SHORT-GI-40][DSSS_CCK-40][RX-STBC1][TX-STBC][RXLDPC][U-APSD]
logger_syslog=-1
logger_syslog_level=0
logger_stdout=-1
logger_stdout_level=4
auth_algs=1
ctrl_interface=/var/run/hostapd
ctrl_interface_group=0
disassoc_low_ack=1
ssid=Starship Vornak
ignore_broadcast_ssid=0
noscan=0
ieee80211w=0
######################### wpa hostapd configuration ############################
wpa=2
wpa_passphrase=
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
you cannot pick and choose the card in the Web interface.
I can only repeat that if you want to have the classic setting “guest wlan” vs “admin wlan” you need to run TWO instances of hostpad and to achieve this goal you need to use the console and follow the tutorial I outlined in my previous message. In the WUI you are seeing the settings of /etc/hostpad.conf generated when you click save. That wlan is the one bound to the blue zone which is the one you selected during the setup phase when you installed IPFire, I think. If you want the other one running, you need to create a SECOND conf file, with the interface specified inside, pointing to the green0 bridge and run a second instance of hostapd with the -B option (background) reading that SECOND config files (which you need to define as you did for the first one).
I doubt it. I think you need to manually associate the ethernet ID with the bridge in green, as described here.
EDIT: no, you are right. It should be correctly defined AND green0p0 should be the name of the bridged card. Still, you need to manually intervene. You can’t use the hostapd web user interface.
it will be the one you see associated with blue zone when you issue this command
ip link show
the command should show you also the same bridge in green as shown in your log. That I believe is the name you need to put in interface directive of the second hostapd conf file.
you can also check which card you see in the web interface, issuing the following command:
ps -ef | grep hostapd
I believe you will see something like this:
root 1963 1 0 Sep18 ? 00:00:22 /usr/bin/hostapd -B /etc/hostapd.conf -i blue0
which shows how hostapd has been lunched by IPFire so that it binds to the blue interface.
In summary, this is what I believe you should do:
- write a correct /etc/hostapd-2.conf <— change the name as you like
- issue the following command
/usr/bin/hostapd -B /etc/hostapd-2.conf -i green0p0
or you put green0p0 inside /etc/hostapd-2.conf and issue simply /usr/bin/hostapd -B /etc/hostapd-2.conf .
If it works, you should see the second SSID, if so, you can make it permanent in rc.local
Hello again.
So it seems i have some other sorcery happening here. This install is 72 hours old, so nothing sinister “should” have happened.
Here is the output:
[root@Station51 ~]# ps -ef | grep hostapd
root 12538 12524 0 20:42 pts/0 00:00:00 grep hostapd
Here is the output:
[root@Station51 etc]# [root@Station51 etc]# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: red0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP mode DEFAULT group default qlen 1000
link/ether a8:c8:7f:00:32:2e brd ff:ff:ff:ff:ff:ff
3: green0p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc cake master green0 state UP mode DEFAULT group default qlen 1000
link/ether a8:c8:7f:10:32:2e brd ff:ff:ff:ff:ff:ff
4: green0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 02:f7:c7:78:17:ad brd ff:ff:ff:ff:ff:ff
5: green0p0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc cake master green0 state DOWN mode DEFAULT group default qlen 1000
link/ether 48:51:b7:a6:45:19 brd ff:ff:ff:ff:ff:ff
6: blue0p0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc cake master blue0 state DOWN mode DEFAULT group default qlen 1000
link/ether 7c:50:79:e7:8c:e0 brd ff:ff:ff:ff:ff:ff
7: blue0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
link/ether 02:14:eb:7e:ca:d1 brd ff:ff:ff:ff:ff:ff
8: ifb0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 32
link/ether de:b5:58:11:21:3f brd ff:ff:ff:ff:ff:ff
9: ifb1: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 32
link/ether 8a:b3:82:d8:7c:d5 brd ff:ff:ff:ff:ff:ff
10: imq0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc htb state UNKNOWN mode DEFAULT group default qlen 32
link/ether de:37:a5:dd:81:a6 brd ff:ff:ff:ff:ff:ff
[root@Station51 etc]#
I will draw your attention to the following MACs: a6:45:19 (a wireless card) e7:8c:e0 (the other wireless card) Notice how they are both claiming to be down. Also, notice blue0 is also claiming to be down. The reality of it is, one wireless card is actually broadcasting; I can connect and surf on it. Even better is I change the SSID via WUI, but it actually doesnt change.
It seems silly to me we cant have a drop box to select a card (if there are multiple present), and see its config from the WUI. Not trying to be a tool here, but really…?
I am trying to do the following via wireless: GREEN = friendly, known clients-such as jellybones, people I know, a couple lappys, and a desktop. BLUE=the pesky IoT things, such as the TV, Nest, the chicken coop, and some other things.
I think you are surfing on some other network not in IPFire, it’s the only explanation of the facts as you described them that comes to mind (including that the SSID does not change). Even if we ignore what you have noticed, meaning that the ip link command tells us that those interfaces are down, the process running on the IPFire CPU that should generate the WIFI traffic is not listed by ps. Where is it? Did you notice that in your screenshot where it says “running” there is no process ID? There should be one. I have one. That “running”, green message is wrong. This is a bug of the WUI, I think.
If you want to prove me wrong and that this unlikely traffic really exists on your IPFire machine, you need to show that it goes through the IPFire kernel.
This is one way to do that, you connect to the WIFI (whatever it is) and start generating traffic, and while you do this, in a console of IPFire you issue this command
grep -E "green0p0|blue0" /var/log/messages
What this will do is showing any kernel log of traffic that is directed to, or coming from either of those two WIFI cards devices. On a negative result (which I expect), you should do a positive test as well, to show that this command is working, by using the other two interfaces in the search:
grep -E "green0p1|red0" /var/log/messages
My (very skeptical) prediction: the first search will give you 0 results, the second a ton.
May I ask to use the preformatted tag for code or logs, the one that looks like this </> in your menu bar? It make the text so much more readable.
You are seeing things only from your point of view. From that prospective, what you are saying is sensible. But, someone has to write code to implement that functionality. Yours is a corner case, and the the IPFire people are heavily understaffed. They have many more urgent issues to deal with.
If I were in your place, I would consider writing two bug reports.
One, asking to implement a WUI interface for each WIFI card present and in use of the system, so that the complexity of creating two background processes of hostapd is hidden to the user. This might get this feature in their todo list.
Two, reporting the bug that you have just discovered: the WUI should never tell the user that hostapd is running if there is no process ID and memory consumption detected. This way, you help the project and you help improving the product you are using.
If you want to further help the project, I am sure it will be pretty much appreciated. Several ways you can do that, contributing financially, write documentation in the wiki, help users in the forum, write good bug reports or even learn to code in Perl and javascript and implement the functionality you would like to have on the Web User Interface, to name few.
Hi cfusco.
I appreciate you patience with me on this. Ill report the bug you mentioned. In the meantime, Ill continue to work on this to see what is the matter.
Yes ill do this
Because I spent waaaaayy too much time on this. I blew my install away, and tried again. This time, everything you spoke of worked as you mentioned. Thanks again…