nas dies without radius server/How do you invoke nas?

[tomilius]

I'm using 1.9.2.7-4 and have freeradius set up. The problem is, if the router is accessed wirelessly before freeradius loads, nas either crashes or realizes the radius server is not available and purposely goes away (never to return; I'm not sure which of those is true). ps shows something like this in relation to nas:
nas /tmp/nas.lan.conf /tmp/nas.lan.pid lan

Executing that leads to a Segmentation fault. So... how may it be executed? Fixing the problem of nas "running away" under these circumstances is not likely to be possible (it's binary-only, right?).

[tomilius]

Yeah... Okey dokey. I'm trying to figure out how to work nas by looking at how the source uses it. So far this is all I have figured out so you have an idea of what I'm trying to do, which is to launch nas any time post-boot to resolve my problem, and I'd appreciate help from anyone who also has the source (1.9.2.7 unmodified):


# services.c
# start_nas
# when used with lan and wan (it's used with both)
nas /tmp/nas.lan.conf /tmp/nas.lan.pid lan
nas /tmp/nas.wan.conf /tmp/nas.wan.pid wan

# network.c
# notify_nas
#
# /* Notify NAS of adding the interface */
# if (!strncmp(lan_ifname, "br", 2) &&
# eval("brctl", "addif", lan_ifname, interface))
# return 0;
#
# Deduced that lan_ifname must be br0, interface likely eth2 (what else)
#
# notify_nas("lan", interface, "up");
#
# translates to notify_nas("lan","eth2","up")
# observed notify_nas functionality ignoring WDS

crypto=`nvram get wl0_crypto`
akm=`nvram get wl0_akm`
wpa_psk=`nvram get wl0_wpa_psk`
ssid=`nvram get wl0_ssid`
nas4not lan eth2 up auto $crypto $akm $wpa_psk $ssid


UPDATE: Though it may seem that the contrary is true, it appears that nas is what writes to and creates /tmp/nas.lan.conf and /tmp/nas.lan.pid, etc--it doesn't read from them. Weird. I'm waiting to try out some of this. Still, I'd imagine I'd just get another Segmentation fault.

UPDATE: Yep. Endless segmentation faults with that. From the output of nas it can be inferred that it actually builds a command-line, perhaps to be used by something else--trying to use the command-line with nas itself... doesn't work.

[tomilius]

S'more info:

I isolated the "Segmentation fault" problem, when executing the contents of nas.lan.conf independently (perhaps nas creates the command line and executes it afterward), to the -m parameter. It's 66. Even when nas is functioning correctly nas.lan.conf says -m 66. Looking at the WL-HDD syntax for nas, I see -m is the authentication type. It's probably a bitmask too.

When I use 0 or something else for -m, it gives me this:
eth2: ignore i/f due to error(s)

This causes the above:
nas -P /tmp/nas.pid -l br0 -H 34954 -i eth2 -A -m 0 -r secret -s Family -w 6 -g 60 -h 127.0.0.1 -p 1812 -t 36000 -d 1

But, apparently, it has no trouble with this on boot. Hmm. Anything different about the way _eval handles arguments as opposed to spaces? ....

Let me mention that when using -m 0, nas continues running, but it doesn't work.

[tomilius]

Communication occurs between the router and a wireless client before the radius server is loaded causes nas to die. Here's what I've tried in regard to circumventing the problem:
Blocking all traffic at first sign of nas and once more in post-boot (rules removed at end of post-boot): nas still died
wl radio off in pre-boot and post-boot (wl radio on at end of post-boot): nas survives and things act normally, but wlan interface is completely unresponsive (light solid but can't be connected to, can't be found)
ifconfig eth2 down (ifconfig eth2 up at end): same thing
wl down (wl up at end; also tried wl restart along with wl up): same thing

To repeat the problem, if there's any sort of communication by a wireless client with the router during its initialization (after nas has loaded), nas will die and won't come back until the router restarts (which it may not if the same thing happens). This is because it can't communicate with the radius server which isn't yet running... but in my eyes, that's no reason for it to just die.

So, the stuff mentioned above (everything but the first item mentioned) are successful attempts to stop nas from dying, but they seem to break the wireless driver for the remainder of the router's use (a lose-lose situation).

What would be cool to know:
How to stop nas from dying
How to use the nas command without a segmentation fault in order to bring it back when it dies
How to prevent on the router side any wireless communication without halting important initialization routines, thereby causing the wireless driver to be dead for the remainder of the router's uptime

UPDATE: Another way to view the situation:
Some commands need to be performed on eth2 (some commands on the "wireless driver" I suppose) that fail when the radio is off by any method. These commands take a certain amount of time determined by now to be less than 400ms. So, I can't turn off the wireless radio until that amount of time is up. However, it's possible that the router will receive a "message" in that short amount of time from a wireless device looking for it, which will trigger nas to check the radius and die. ... I welcome any and all suggestions, comments, your money...

[tomilius]

Oh boy. I know I keep posting, but I'm acting as separate users who actually care, so just pretend all of these posts are from different people..

Figured out an annoying solution. I have in the web interface (therefore nvram) it set to use an SSID consisting of a space (" "). That way no devices look for or try to connect to it. I give the router 2 seconds after nas launches to perform operations that cannot be successfully performed with the radio off (for whatever reason). Then, I turn off the radio. I change the SSID back to the one of my choice 10 seconds after freeradius has been launched in post-boot (to ensure it has fully loaded) and then turn the radio back on.

Very tricky. I wish I didn't have to do that. If/when anyone really cares about radius stuff, hopefully this probably will be realized.

[Oleg]

tomilius, in fact your dialogs are VERY helpful, so please keep posting. The freeradius problem is very interesting to me also, so your decisions saves our time. :)
This is like interesting reading.
So, here is my findings with radius turned off:


killall nas
nas /tmp/nas.lan.conf /tmp/nas.lan.pid lan

works fine, it does not segfaults. So it's probably related to radius. Please try running it with strace to see, what happens here.
Keep us posted.
The only solution to workaround this problem would be creating "fake" server which would listen at port 1812 and then forward request to real server. Alternatively you could delay nas loading by adding this to pre-boot


mount -obind /dev/null /usr/sbin/nas

and this


umount /usr/bin/nas
nas /tmp/nas.lan.conf /tmp/nas.lan.pid lan

to post-boot.

Also, if it still segfaults delete /tmp/nas.lan.conf and /tmp/nas.lan.pid , as they get created by nas itself.

[tomilius]

Thank you very much Oleg for the response! I will look into all of that.

Right now I'm excited about getting certificates to work (EAP-TLS). They just wouldn't work with Windows XP SP2's Wireless Zero... works with Odyssey Client trial though. It's a 30-day trial, but the most fundamental method of extending that is available... *cough cough* gee it feels like 2006 already *cough cough*... And that's to buy it, of course!

[tomilius]

Another long post...

Ah... didn't seem to work. Here's the strace log performed independently (after killing nas manually, not in post-boot or anything; note that I don't know anything about strace):

% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
25.40 0.004807 209 23 read
20.82 0.003939 207 19 old_mmap
17.13 0.003242 180 18 socket
10.43 0.001974 152 13 5 open
7.69 0.001455 86 17 close
7.58 0.001434 75 19 3 ioctl
4.28 0.000810 203 4 mprotect
2.18 0.000413 59 7 brk
1.76 0.000333 56 6 bind
1.07 0.000203 203 1 write
0.51 0.000096 96 1 1 readlink
0.43 0.000081 81 1 connect
0.32 0.000061 31 2 setitimer
0.21 0.000040 40 1 rt_sigaction
0.18 0.000035 35 1 getsockname
------ ----------- ----------- --------- --------- ----------------
100.00 0.018923 133 9 total

I created a little... thing... to save a list of processes every half a second beginning in pre-boot, and I can confirm that nas never gets launched (it's not supposed to with the setup of yours that I started using). Also, nas.lan.conf and nas.lan.pid are never created. Another possibly-useful note: although there's a segmentation fault, nas.lan.conf is created but nas.lan.pid is not. It's always been like that.

My knowledge of linux isn't too great. Do you have any suggestions for... perhaps... redirecting the arguments sent to /usr/sbin/nas to another file for review later? Not that that would be useful, but you never know.

Here's my setup:
pre-boot calls keep-it-down (named this for historic reasons ;)) with & (making it a "daemon") (aka "keep-it-down &"). This file has this in it:

#!/bin/sh
i=1
while [ "$i" -lt "60" ]
do
echo $i >> /tmp/psres
ps x >> /tmp/psres
let "i += 1"
usleep 500000
done

May not be the most efficient but hey, it works. ... Pardon me, I'm not sure what relevance that even has here. ... Oh yeah. I was thinking maybe in a million years (I doubt it) this has something to do with /sbin/init. It is called a number of times, I assume with a different function each time ? I have no idea. I would post psres but it's too big obviously and there's not that much useful information in it that I know of.

My pre-boot, after doing the keep-it-down loading as a daemon thing, runs, as you said, "mount -obind /dev/null /usr/sbin/nas". That assumedly works because nas never shows up in psres.

In post-boot... well, I'll just show you:

#!/bin/sh
#ifconfig eth2 down
dropbear
mount -text3 /dev/scsi/host0/bus0/target0/lun0/part5 /usr/lib
mount -text3 /dev/scsi/host0/bus0/target0/lun0/part6 /opt
killall -9 waveservermain
killall -9 rcamdmain
killall -9 lpd
killall -9 p9100d
killall -9 p9101d
killall -9 infosvr
killall -9 p910nd
#killall khubd
killall -9 telnetd
killall -9 dnsmasq
# some signal/speed enhancements
#wl atten 0 0 60

while [ ! -e /opt/sbin/radiusd ]; do
sleep 1
done

# post-firewall launches dnsmasq at its end
# so, halt execution until post-firewall has completed
until [ ! -z "$running" ]
do
running=`ps x | grep -v "grep" | grep "dnsmasq"`
sleep 1
done

killall -9 stupid-ftpd

while [ ! -e /tmp/harddisk/swp ]; do
sleep 1
done

swapon /tmp/harddisk/swp
sleep 2

rmmod audio
rmmod videodev
rmmod printer
rmmod parport
rmmod parport_splink
rmmod ip_nat_starcraft
rmmod soundcore
rmmod -a

# NOTE: I've modified S55freeradius to pass the arguments
# -y -z -X -A. It doesn't seem to work without, at least,
# an implied -s (all in one process rather than broken up
# into client processes). But that's irrelevant for this case.
# Oh, and I have to loading as a daemon also (&) and logging
# to /opt/radius.log with a pipe--or whatever it's called.
/opt/etc/init.d/S55freeradius
#wl ssid "Family"
#sleep 10
#ifconfig eth2 up
#wl ssid "Family"
#sleep 3
#wl ssid "Family"
sleep 10
ps x > /opt/bogus/running
# ^ nothing useful comes of that...
cp /tmp/nas.* /opt/bogus
# ^ NOTE: no nas files appear in /opt/bogus, so...
rm /tmp/nas.*
umount /usr/sbin/nas
nas /tmp/nas.lan.conf /tmp/nas.lan.pid lan

And... lo and behold, at the end nas is not running as it should be. nas.lan.conf exists in /tmp as usually, but not nas.lan.pid. I can easily assume it gets the usual segmentation fault--trying it again, it has one.

Sorry if I made any simple mistakes there that I'm just not catching. Thanks again, Oleg, for the review, and glad to know I'm actually contributing somehow rather than just flooding the board (maybe it's a mixture of the two :rolleyes: ).

UPDATE: If anybody happens to know how to "scriptomatically" (sure, why not make up a cool word like that) make the SSID hidden (stop the broadcast of the SSID through a command to "wl" or something), that would help too--at least for my temporary situation, and to satisfy my curiosity.

[tomilius]

Felt the need to post this as a new reply... Sorry about my last strace output. Here's a more useful one (in case it's not obvious enough, the 127.0.0.1 refers to the RADIUS server I specified and the 1812 refers to the RADIUS server port I specified):

execve("/usr/sbin/nas", ["/usr/sbin/nas", "/tmp/nas.lan.conf", "/tmp/nas.lan.pid", "lan"], [/* 7 vars */]) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x2aaa8000
mprotect(0x2aac0000, 25392, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0x400000, 106032, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
readlink("/lib/ld-uClibc.so.0", 0x7fff7948, 1024) = -1 EINVAL (Invalid argument)
open("/lib/libnvram.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("//usr/X11R6/lib/libnvram.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("//usr/lib/libnvram.so", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\10\0\1\0\0\0\2 00\6"..., 4096) = 4096
old_mmap(NULL, 270336, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ab07000
old_mmap(0x2ab07000, 4064, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x2ab07000
old_mmap(0x2ab47000, 4164, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x2ab47000
close(3) = 0
open("/lib/libshared.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("//usr/X11R6/lib/libshared.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("//usr/lib/libshared.so", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\10\0\1\0\0\0 -\0\000"..., 4096) = 4096
old_mmap(NULL, 335872, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ab49000
old_mmap(0x2ab49000, 66240, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x2ab49000
old_mmap(0x2ab99000, 5744, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x10000) = 0x2ab99000
close(3) = 0
open("/lib/libcrypto.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("//usr/X11R6/lib/libcrypto.so", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\10\0\1\0\0\0\2 60\234"..., 4096) = 4096
old_mmap(NULL, 1814528, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ab9b000
old_mmap(0x2ab9b000, 1458028, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x2ab9b000
old_mmap(0x2ad3e000, 81908, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x163000) = 0x2ad3e000
old_mmap(0x2ad52000, 14416, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ad52000
close(3) = 0
open("/lib/libc.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\10\0\1\0\0\0\3 60\250"..., 4096) = 4096
old_mmap(NULL, 733184, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ad56000
old_mmap(0x2ad56000, 448308, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x2ad56000
old_mmap(0x2ae03000, 11692, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x6d000) = 0x2ae03000
old_mmap(0x2ae06000, 10392, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ae06000
close(3) = 0
open("/lib/libdl.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\10\0\1\0\0\0\0 \t\0"..., 4096) = 4096
old_mmap(NULL, 270336, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ae09000
old_mmap(0x2ae09000, 7828, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x2ae09000
old_mmap(0x2ae4a000, 3928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 0x2ae4a000
close(3) = 0
mprotect(0x400000, 106032, PROT_READ|PROT_EXEC) = 0
mprotect(0x2aac0000, 25392, PROT_READ|PROT_EXEC) = 0
ioctl(0, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
brk(0x10003e70) = 0x10003e70
brk(0x10004000) = 0x10004000
brk(0x10005000) = 0x10005000
open("/dev/nvram", O_RDWR) = 3
old_mmap(NULL, 32768, PROT_READ, MAP_SHARED, 3, 0) = 0x2ae80000
read(3, "\224\7\0\0", 11) = 4
read(3, "H\6\0\0", 12) = 4
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
ioctl(4, 0x8946, 0x7fff78f8) = 0
close(4) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
ioctl(4, 0x8946, 0x7fff78f8) = 0
close(4) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
ioctl(4, 0x89f0, 0x7fff79a8) = 0
close(4) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
ioctl(4, 0x89f0, 0x7fff79e0) = 0
close(4) = 0
socket(PF_INET, SOCK_RAW, IPPROTO_RAW) = 4
ioctl(4, 0x8913, 0x7fff7a08) = 0
close(4) = 0
read(3, "\t\t\0\0", 10) = 4
read(3, "d\6\0\0", 9) = 4
read(3, "=\n\0\0", 14) = 4
read(3, "f\0\0\0", 8) = 4
read(3, "L\7\0\0", 8) = 4
read(3, "S\n\0\0", 11) = 4
read(3, "J\1\0\0", 9) = 4
read(3, "\277\t\0\0", 15) = 4
read(3, "\224\n\0\0", 9) = 4
read(3, "h\10\0\0", 18) = 4
read(3, "j\6\0\0", 18) = 4
read(3, "_\6\0\0", 16) = 4
read(3, "\303\5\0\0", 15) = 4
read(3, "J\t\0\0", 12) = 4
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
ioctl(4, 0x8946, 0x7fff78f8) = -1 ENODEV (No such device)
close(4) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
ioctl(4, 0x8946, 0x7fff78f8) = -1 ENODEV (No such device)
close(4) = 0
brk(0x10006000) = 0x10006000
open("/tmp/nas.lan.conf", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
ioctl(4, TIOCNXCL, 0x7fff7b18) = -1 ENOTTY (Inappropriate ioctl for device)
write(4, "nas -P /tmp/nas.lan.pid -l br0 -"..., 142) = 142
close(4) = 0
brk(0x10008000) = 0x10008000
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
ioctl(4, 0x8946, 0x7fff7a78) = 0
close(4) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
ioctl(4, 0x89f0, 0x7fff7b28) = 0
close(4) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
ioctl(4, 0x89f0, 0x7fff7b60) = 0
close(4) = 0
brk(0x10012000) = 0x10012000
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
ioctl(4, 0x8927, 0x7fff7b80) = 0
close(4) = 0
brk(0x1001b000) = 0x1001b000
setitimer(ITIMER_REAL, {it_interval={0, 1}, it_value={0, 0}}, NULL) = 0
setitimer(ITIMER_REAL, NULL, {it_interval={0, 10000}, it_value={0, 0}}) = 0
rt_sigaction(SIGALRM, {0x10000000, [], SA_STACK|SA_INTERRUPT|SA_NOCLDWAIT|0x2b450a4}, {SIG_DFL}, 16) = 0
socket(PF_PACKET, SOCK_RAW, 1024) = 4
ioctl(4, 0x8933, {6, "br0"}) = 0
bind(4, {sa_family=AF_PACKET, proto=0x04, if6, pkttype=PACKET_HOST, addr(0)={0, }, 20) = 0
socket(PF_PACKET, SOCK_RAW, 51080) = 5
ioctl(5, 0x8933, {6, "br0"}) = 0
bind(5, {sa_family=AF_PACKET, proto=0x88c7, if6, pkttype=PACKET_HOST, addr(0)={0, }, 20) = 0
socket(PF_PACKET, SOCK_RAW, 1024) = 6
ioctl(6, 0x8933, {5, "eth2"}) = 0
bind(6, {sa_family=AF_PACKET, proto=0x04, if5, pkttype=PACKET_HOST, addr(0)={0, }, 20) = 0
socket(PF_PACKET, SOCK_RAW, 39577) = 8
ioctl(8, 0x8933, {6, "br0"}) = 0
bind(8, {sa_family=AF_PACKET, proto=0x999a, if6, pkttype=PACKET_HOST, addr(0)={0, }, 20) = 0
socket(PF_PACKET, SOCK_RAW, 36488) = 9
ioctl(9, 0x8933, {5, "eth2"}) = 0
bind(9, {sa_family=AF_PACKET, proto=0x888e, if5, pkttype=PACKET_HOST, addr(0)={0, }, 20) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 10
connect(10, {sa_family=AF_INET, sin_port=htons(1812), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
getsockname(10, {sa_family=AF_INET, sin_port=htons(2053), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 11
bind(11, {sa_family=AF_INET, sin_port=htons(34954), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
open("/dev/urandom", O_RDONLY|O_NONBLOCK) = 12
read(12, "D%\226n\370\"\337\224$\255\220\375C\fL\306", 16) = 16
read(12, "\251k\33\266X\310j\340>\271\247\267\361\21\221\321", 16) = 16
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

Just so you know, I won't be around for the weekend or probably much of the beginning of next week. But let me repeat that it appears Odyssey Client has solved many of my other unrelated problems (for one thing, it constantly scans, so I shouldn't ever, even if the computer does get temporarily disconnected, have it stuck that way until intervention like Windows' Wireless Zero had, and for another it handles certificates simply and correctly).

Now, doesn't that suggest that it dies when reading a random .. number string thing? That's kind of sad if so.

[tomilius]

I couldn't keep away from the forum for long...

Hehe. I got the idea (whether or not it was a good one) to "proxy" nas requests. I figured it would work since I knew nas loaded after pre-boot did (obvious--this is mentioned earlier). So, I told pre-boot to copy /usr/sbin/nas to /tmp/nas. Then, using Oleg's example, mounted /usr/local/sbin/nas_proxy to /usr/sbin/nas (and /usr/sbin/nas4not). Here's what nas_proxy looks like:

#!/bin/sh

par=0

while [ -e /tmp/nas_params$par ]
do
let "par += 1"
done

echo $1 $2 $3 > /tmp/nas_params$par
/tmp/nas $1 $2 $3 > /tmp/nas_resp$par &

I tried it with $4 $5 $6 to catch any unknown arguments, to rule that out. Anyway, here's what I got (and expected):

nas_params0: /tmp/nas.lan.conf /tmp/nas.lan.pid lan
nas_params1: /tmp/nas.wan.conf /tmp/nas.wan.pid wan

I didn't exactly expect the response, but it's a familiar one:
nas_resp0: No interface specified. Quitting...
nas_resp1: No interface specified. Quitting...

And here's the configuration stuffs:
nas.lan.conf: nas -P /tmp/nas.lan.pid -l br0 -H 34954
nas.wan.conf: nas -P /tmp/nas.wan.pid -H 34970

Looks a bit different from the usual nas output, but it's nothing new. I believe this happened when I tried to start nas after loading the router with the radio off. Also, no .pids were generated.

So... That suggests that nas cannot be called from bash, I suppose, doesn't it? I'm not sure how else to interpret it. I know, Oleg, that under certain circumstances you had no trouble running nas from the command-line, but I vaguely recall attempting to before without free-radius (vaguely, as in maybe I didn't) and it failing with a "Segmentation fault" as usual.

[tomilius]

Hmm... our results aren't the same.

nas doesn't seem even to run for anything unrelated to WPA. For no encryption or WEP, it doesn't even start, and it doesn't need to. Even when I try to start it after boot manually, it's the usual Segmentation fault alternative--"No interface specified." But--otherwise, with WPA, it's Segmentation fault.

Any details about the conditions you're attempting to run nas under, Oleg? Note that I'm running it in 1.9.2.7-4.

[tomilius]

We've already established that I write a lot here... so I guess I don't need to explain myself about that.

I found out strace could be used to begin tracing an active process, so I decided to do that with nas when it was working. It turns out that it purposely unlinks nas.lan.pid and shuts down when it can't connect to the radius server. That's not much news, so if I figure out how to establish a USB filesystem so that I can monitor nas from (close to) its start, I'll update information in this post to reflect that.

[Oleg]

Any details about the conditions you're attempting to run nas under, Oleg? Note that I'm running it in 1.9.2.7-4.
I've tried it with WPA-PSK.

[tomilius]

I've tried it with WPA-PSK.

Hmm... not sure why, but same problem with WPA-PSK. Segmentation fault.

[tomilius]

Did I mention nas has no trouble with 1.8.1.7-3? No, because I just figured that out. It works without any Segmentation faults in 1.8.1.7-3. OK--signing out.

P.S. I would have no objection to a 1.8.1.7-4... with ipkg added.. and /opt added. radiusd seemed as though it would run, it just kept trying to find /opt stuff. ipkg also seemed to run.

[Oleg]

One more thought. Do you've openssl installed? if so, then this could the reason for crash: nas uses library called libcrypto.so, which is not the same as openssl has. Could you please try unmounting /opt and try running nas again?
As for 1.8.1.7-4 - this is nearly impossible.

[tomilius]

Ah... I haven't tried it yet, but I'm about certain you're correct. Thanks, Oleg! I'll keep you posted anyway...

UPDATE: OK.. I think I was wrong if I said WPA-PSK was related to nas. I mean, it seems it is but I killed it wirelessly and.. I'm still here... Oh, wait. Hmm. Odd. It connects and authenticates but no communication. Guess I was wrong about that. Anyway, I was able to get it started again with WPA-PSK without /opt mounted.

And here's the results everyone's been waiting for...
It works. Excellent. Finally my mind can rest in peace knowing everything is set up and working how I've wanted it to work from day 1... and with a built-in RADIUS server, too! :) Well, not built-in.. but on the router. Client certificates work, I have a client that actually reconnects should it ever become disconnected... Great.

Thanks again, Oleg.

start-nas:

#!/bin/sh
export LD_LIBRARY_PATH=/usr/lib
umount /usr/sbin/nas
usleep 10000
nas /tmp/nas.lan.conf /tmp/nas.lan.pid lan &
The usleep probably isn't necessary but I put it in in the process of troubleshooting and there's no need to take it out and fix what isn't broken.

Eventually... I may write a guide for setting up freeradius. A complete one. Including stuff about getting things to work with Windows XP (SP2). Then again, maybe I won't find the time. It should be done, anyhow. It won't hurt me if anybody else does it.

[Oleg]

Excellent. Yes, everyone is waiting for wiki now. ;-)
As for libcrypto - in the next custom firmware release this should not be a problem, nas will use libkrypto instead. :)

[tomilius]

Just a little side-note... I have had absolutely no connection drops (that's not to say no packet loss as it's a minor part of every wireless connection) in over 30 hours (yay). This doesn't have as much to do with freeradius, I suspect, as it does with NOT using the Wireless Zero configuration built-in to Windows XP SP2. I think somewhere, if it is not already done, this potential disconnection flaw (and in such an event the lack of an automatic reconnection) of the operating system's built-in service should at least be pointed out to save the trouble for other users (though I may be the only person to have experienced it, though not as much at all with the MN-710 gone)--not to mention once more that Windows XP SP2, for me, had trouble recognizing, or at least using, the TLS certificates I installed. ... More on all of this shall come in a guide someday (really), as in in the next few weeks. Everybody should document his/her information in regard to this router in order to make it the best it can be and make it go beyond its advertised functionality while still maintaining a high degree of stability (something yet to be fully understood, as far as I know, with this router).

Again, this post is mostly unrelated to the topic. Shoot me if you want.

Oh, I feel the need to once more express my gratitude to the helpful members of this forum--especially (and, in this and many other threads, only) Oleg--for their time reviewing this information. It really has eased my mind, personally, knowing there's no more that I feel needs to be done for security or stability in my case involving this router. So thanks. :)

[tomilius]

Excellent. Yes, everyone is waiting for wiki now. ;-)

Hehe.. apparently nobody finds it that important. I haven't written a wiki yet because I've forgotten each step exactly ;). I'll wait until somebody starts a thread trying to set it up or something. Then I'll try to help them and when they get it working maybe I'll use the thread to write a wiki... or maybe they will :D

[magla]

%SUBJ%

thx

[limpo]

Please post a guide or howto for freeradius on asus wl500g!!

It would make this router som much more cool!:)
And besides it is indead needen.