rc.inet1, hostapd and wifi nic in master mode

Some 3 years ago when I tinkered with one of my dockstars to make it into an access point: I fiddled with the slackware init scripts so that they would handle putting a wifi interface into master mode.
I've lost the work I did then ... this time I'll be looking into master mode and bridge lan and wifi in master mode. If I can't manage I'll be routing.

Is there any intrest in integrating this sort of thing in slackware init scripts and maybe also packaging hostapd ?

Originally Posted by louigi600 Some 3 years ago when I tinkered with one of my dockstars to make it into an access point: I fiddled with the slackware init scripts so that they would handle putting a wifi interface into master mode. I've lost the work I did then ... this time I'll be looking into master mode and bridge lan and wifi in master mode. If I can't manage I'll be routing. Is there any intrest in integrating this sort of thing in slackware init scripts and maybe also packaging hostapd ?

This rings a bell - didn't you mail them to the old mailing list? have a look through the old archive.
Pat would need to merge the changes into x86 - I only carry necessary patches for ARM specific stuff.

I don't think the stuff I did last time made it to mailing list: I was working on my clashNG miniroot with modified versions of the Slackware innit scripts to work with busybox ash ... and also modified udev rules and helpers to do things automatically if the wifi and/or 3g modem usb dongles were plugged in, I also had put something up to allow for different AP's to be initiated according to the MAC address of the inserted wifi dongle.
I might had talked about some changes I made to udev to bring up automatically network dongles tough ;-)
This time I'm working on a pure Slackware ARM 14.1 so anything I do could be recycled if of any interest.
Well if it's not of direct interest to Slackware maybe I can write an article on slackware docs.

A looked up in the maling list archive and I found a post where I talked about the features that were supported on mu clashNG miniroot thingy. I forgot that some of the stuff I did got actually included in clashNG, I thought it was all lost as custom config work on the AP I was making at the time when I reformatted and repartitioned the internal flash to use UBI.
Well good to know that at least some of the work needs not be done again

Ok I've the basics working (no scripting done just a few commands in rc.local and a lot of site dependent configuration in hostapd and dnsmasq config files).
Bridging works as expected ... eccept that ip_forward must be enabled via sysctl (did not expect that if the interfaces were bridged together).

I exchanged a message with Pat and he's willing to have a look at what I come up with ... but I've an issue with that (hoping he will reply) so I'll pose the same question here as my guess is that anyone wanting to do this sort of thing straight from boot is probably running it on ARM anyway ... you really don't want to leave an x86 machine on all the time just to have a WiFi access point working.

There are many possible things one could do with a WiFi nic in master mode, allowing for all of them would make the scripting difficult and require a lot of debugging to make sure everything is working right (I mean you could have open, WEP or WPA encryption, you could run static or dynamic IP addresses, you could be routing or bridging packets through your box, there are a variety of pairing algorithms and a variety of ways you could go about wpa2).
I think that a good starting point could be to get the most common things working so this is I'm proposing:
open or WPA2 passphrase (WEP is intrinsically as safe as open),
static or dhcp (via dnsmask),
bridge WiFi with Ethernet (as that's what most low end access points do and possibly that's what most would expect anyway).

Would this be OK ?


If anyone wants the quick and dirty commands for rc.local here they are:
echo 1 > /proc/sys/net/ipv4/ip_forward
hostapd -B /etc/hostapd/hostapd.conf
brctl addbr br0
brctl stp br0 off #turn off spanning tree
brctl addif br0 wlan0
brctl addif br0 eth0
ifconfig wlan0 0.0.0.0 up
ifconfig eth0 0.0.0.0 up
ifconfig br0 <your IP> up


Whatever your IP is, it must belong to the subnet from which dnsmasq assigns addresses or it will not work.

Originally Posted by louigi600 I exchanged a message with Pat and he's willing to have a look at what I come up with ... but I've an issue with that (hoping he will reply) so I'll pose the same question here as my guess is that anyone wanting to do this sort of thing straight from boot is probably running it on ARM anyway ... you really don't want to leave an x86 machine on all the time just to have a WiFi access point working.

I have a Slackware64 server on 24x7. I hadn't thought of making it into a WiFi access point but it actually sounds like a good idea, particularly since the old WRT54G I have only does the slower wireless speeds. I also have enough NICs on the server do it.

Originally Posted by louigi600 I think that a good starting point could be to get the most common things working so this is I'm proposing: open or WPA2 passphrase (WEP is intrinsically as safe as open), static or dhcp (via dnsmask),

Do you have to use dnsmasq? I already run dhcpd and bind. If that is configurable, that'd be great.

Originally Posted by louigi600 bridge WiFi with Ethernet (as that's what most low end access points do and possibly that's what most would expect anyway). Would this be OK ?

Sounds good to me.
What wireless card are you using? Is it USB?

I actually don't have any spare ARM devices since they're all configured ready to be used for their purpose when needed: otherwise a Sheevaplug perhaps booting from NAND or SD card would do the job.
I actually just had a crazy idea to ditch Slackware ARM soft float and do a hard float port instead since I already have all of the systems in place to build one, and that would free up the armv5 machines. Crazy ideas!
To clarify why that's a crazy idea - quite simply it'd take months of work to get a working system into the -current state, which would mean I would probably be divorced within 2 months ;-) In addition, ARM is going 64-bit so if any major re-porting work was to be done (by me) it'd be to 64bit systems. But if I win the lottery big time and don't need to work any more, I'll have a hard float port out within a few months.

Originally Posted by drmozes I actually just had a crazy idea to ditch Slackware ARM soft float and do a hard float port instead since I already have all of the systems in place to build one, and that would free up the armv5 machines. Crazy ideas!

\o/

Originally Posted by drmozes I have a Slackware64 server on 24x7. I hadn't thought of making it into a WiFi access point but it actually sounds like a good idea, particularly since the old WRT54G I have only does the slower wireless speeds. I also have enough NICs on the server do it.

But you have other reasons, appart from needing a heating device, for keeping it on 24x7 not just for having a fast AP. Well maybe a laptop makes a poor heating device

Do you have to use dnsmasq? I already run dhcpd and bind. If that is configurable, that'd be great.

No ... I'm actually going to leave that out and just let the other init scripts deal with dhcp and dns.
I'm already using rc.dnsmasq that came stock with the package, just with modified dnsmasq.conf to suit my needs, if anyone likes the could possibly use udchcp and some other dns forwarder.

What wireless card are you using? Is it USB?

Yes that's the only type of wireless network device I can have connected to my seagate plug like devices. It's an rt28xx based usb dongle ... you probably already know this but there are people who may not: currently master mode has been moved out of most (if not all) the wirless drivers and moved into userspace hostapd that in turn uses nl80211 interface, common to all mac80211 complient drivers. As a result you can run an AP even on hardware that previously did not support putting the device directly into Master mode.
As for the bus it makes no difference where the wifi device is connected (disregarding performance) as long as there's a working mac80211 driver for it.

I actually don't have any spare ARM devices since they're all configured ready to be used for their purpose when needed: otherwise a Sheevaplug perhaps booting from NAND or SD card would do the job.

The Sheevaplug would beat the crap out of most of the low end AP ... why not try. But if you have an x86 machine on all the time anyway why not use that ... it will do one more usefull thing.

I actually just had a crazy idea to ditch Slackware ARM soft float and do a hard float port instead since I already have all of the systems in place to build one, and that would free up the armv5 machines. Crazy ideas! To clarify why that's a crazy idea - quite simply it'd take months of work to get a working system into the -current state, which would mean I would probably be divorced within 2 months ;-) In addition, ARM is going 64-bit so if any major re-porting work was to be done (by me) it'd be to 64bit systems. But if I win the lottery big time and don't need to work any more, I'll have a hard float port out within a few months.

Let's hope you win the lottery then
Well If I win the lottery I'll hire you to do it ok ?
I know how it works ... got wife and kids too ... I'm having a tough time just by making my own custom AP

After having gathered some mized opinions on the x86 forum I started an article on docs slackware:
http://docs.slackware.com/howtos:mis..._slackware_box