2008年12月9日 星期二

free-radius server/client config

In order to implement RADIUS to my project. I take some practices it on X86 linux.

Here are some simplest setting for PAP, client only pass Username/Password to RADIUS server.

For server side, I only want test basic username/password.
Here are 3 files involved.
"client.conf","users" and "modules/pap"
[peter@localhost raddb]$ vim clients.conf
# Allowed values are:
# dotted quad (1.2.3.4)
# hostname (radius.example.com)
#ipaddr = 127.0.0.1
ipaddr = 172.21.33.112

secret = testing123


#vim modules/pap
pap {
auto_header = yes
}

#vi users
peter Cleartext-Password := "4321"

-----------------------
For client test.
----------------------
[peter@localhost raddb]$ vim /share/rootfs/etc/radiusclient/radiusclient.conf
authserver 172.21.46.133

#vim /share/rootfs/etc/radiusclient/servers
172.21.46.133 testing123

conclusion:
The shared secrets ("testing123" in this case) MUST match with client/server.
The User-Passowrd was sent by s MD5(password, secrets). so the clear-password was never sent to network.



TIP:
#server daemon in my environment.
LD_LIBRARY_PATH=/usr/lib:/lib/:/lib/tls/:$LD_LIBRARY_PATH ./radiusd -s -X
#client test utility
echo "User-Name = test" | /usr/local/bin/radclient localhost:1812 auth s3cr3t
echo "User-Name=test,Password=mypass,Framed-Protocol=PPP " | /usr/local/bin/radclient localhost:1812 auth s3cr3t


--------------------
A debug mode of radiusd -s -X
-------------
Listening on authentication address * port 1812
Listening on accounting address * port 1813
Listening on proxy address * port 1814
Ready to process requests.
rad_recv: Access-Request packet from host 172.21.33.112 port 1054, id=60, length=63
User-Name = "peter"
User-Password = "4321"
Service-Type = Authenticate-Only
NAS-Port = 0
NAS-IP-Address = 172.21.33.112
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
[suffix] No '@' in User-Name = "peter", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
++[unix] returns notfound
[files] users: Matched entry peter at line 93
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
++[pap] returns updated
Found Auth-Type = PAP
+- entering group PAP {...}
[pap] login attempt with password "4321"
[pap] Using clear text password "4321"
[pap] User authenticated successfully
++[pap] returns ok
+- entering group post-auth {...}
++[exec] returns noop
Sending Access-Accept of id 60 to 172.21.33.112 port 1054
Finished request 0.
Going to the next request
Waking up in 4.9 seconds.
Cleaning up request 0 ID 60 with timestamp +9
Ready to process requests.

2008年11月10日 星期一

pptpd server aligned issues/bug

I was porting PPTPD to ARM board, recently. After tested with other platforms including X86.
It always workable with any client, but only invalid on my target board ...
It takes my around week to figure out the problem.
M.., eventually. I find the problem: memory alignment issues on ARM.
A struct gre_header points to a char buf[]. and char does NOT ficking aligned memory.
This problem delays my schedule almost 1 week....

I just modified as:
int decaps_gre(....)
static unsigned char buffer[PACKT_MAX + 64] __attribute__ ((aligned(4)));

GOT IT! I fixed this bug.

But I want to know: Why compile does not alignment global static varibles? a risk might occurred on some platforms.

2008年9月16日 星期二

Build openssl with shared vs static

for openssl-0.9.8h

$ ./Configure linux-generic32 no-asm shared
$make CC=arm-linux-gcc AR="arm-linux-ar r"


[peter@localhost openssl-0.9.8h]$ ls -l lib*
-rw-rw-r-- 1 peter peter 2230728 Sep 16 09:27 libcrypto.a
-rw-rw-r-- 1 peter peter 236 Sep 16 09:28 libcrypto.pc
lrwxrwxrwx 1 peter peter 18 Sep 16 09:27 libcrypto.so -> libcrypto.so.0.9.8*
-rwxrwxr-x 1 peter peter 1444708 Sep 16 09:27 libcrypto.so.0.9.8*
-rw-rw-r-- 1 peter peter 400404 Sep 16 09:27 libssl.a
-rw-rw-r-- 1 peter peter 251 Sep 16 09:28 libssl.pc
lrwxrwxrwx 1 peter peter 15 Sep 16 09:27 libssl.so -> libssl.so.0.9.8*
-rwxrwxr-x 1 peter peter 275668 Sep 16 09:27 libssl.so.0.9.8*

[peter@localhost openssl-0.9.8h]$ file lib*
libcrypto.a: current ar archive
libcrypto.pc: ASCII text
libcrypto.so: symbolic link to `libcrypto.so.0.9.8'
libcrypto.so.0.9.8: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped
libssl.a: current ar archive
libssl.pc: ASCII text
libssl.so: symbolic link to `libssl.so.0.9.8'
libssl.so.0.9.8: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped


[peter@localhost openssl-0.9.8h]$ ll lib*
-rw-rw-r-- 1 peter peter 2230728 Sep 16 09:27 libcrypto.a
-rw-rw-r-- 1 peter peter 236 Sep 16 09:28 libcrypto.pc
lrwxrwxrwx 1 peter peter 18 Sep 16 09:27 libcrypto.so -> libcrypto.so.0.9.8*
-rwxrwxr-x 1 peter peter 1191608 Sep 16 09:59 libcrypto.so.0.9.8*
-rw-rw-r-- 1 peter peter 400404 Sep 16 09:27 libssl.a
-rw-rw-r-- 1 peter peter 251 Sep 16 09:28 libssl.pc
lrwxrwxrwx 1 peter peter 15 Sep 16 09:27 libssl.so -> libssl.so.0.9.8*
-rwxrwxr-x 1 peter peter 233704 Sep 16 09:59 libssl.so.0.9.8*
[peter@localhost openssl-0.9.8h]$
[peter@localhost openssl-0.9.8h]$ file lib*
libcrypto.a: current ar archive
libcrypto.pc: ASCII text
libcrypto.so: symbolic link to `libcrypto.so.0.9.8'
libcrypto.so.0.9.8: ELF 32-bit LSB shared object, ARM, version 1 (ARM), stripped
libssl.a: current ar archive
libssl.pc: ASCII text
libssl.so: symbolic link to `libssl.so.0.9.8'
libssl.so.0.9.8: ELF 32-bit LSB shared object, ARM, version 1 (ARM), stripped




[peter@localhost busybox-1.6.1]$ file busybox
busybox: ELF 32-bit LSB executable, ARM, version 1 (ARM), dynamically linked (uses shared libs), stripped
[peter@localhost busybox-1.6.1]$ ll busybox
-rwxrwxr-x 1 peter peter 699736 Sep 16 09:50 busybox*
[peter@localhost busybox-1.6.1]$ arm_920t_le-ldd busybox
libssl.so.0.9.8 => not found
libcrypto.so.0.9.8 => not found
libdl.so.2 => /share/project/test/buildroot/Storlink/usr/local/920t_le/target/lib/libdl.so.2 (0xdead1000)
libcrypt.so.1 => /share/project/test/buildroot/Storlink/usr/local/920t_le/target/lib/libcrypt.so.1 (0xdead2000)
libc.so.6 => /share/project/test/buildroot/Storlink/usr/local/920t_le/target/lib/libc.so.6 (0xdead3000)
/lib/ld-linux.so.2 => /share/project/test/buildroot/Storlink/usr/local/920t_le/target/lib/ld-linux.so.2 (0xdead4000)


----------------------------------------------------------------------
static link to SSL.
-rwxr-xr-x 1 peter peter 1444068 Sep 16 10:03 busybox.static_ssl

-------------------------------------------------------------------------
dynamic: 420214 openssl (not strip) 368120 openssl(striped)
static : 1641517 openssl(not strip)

----------------------------------------------------------------------
static openvpn: 1283804 (striped)
dynamic openvpn: 389852(striped)



Summary:
static:
busybox-SSL(1444068) + openssl(1641517) + openvpn(1283804)


dynamic:
busybox with SSL: 699736 + oenssl(368120) + openvpn (389852) + libraries (1191608+ 275668)


thanks

有用的blog,文章,文件

http://gaznjang.blogspot.com/search/label/kernel

2008年8月25日 星期一

IPsec相關

ipsec openswan vs ipsec-tools(racoon)
http://www.wogri.at/fileadmin/ipsec/multiple_pages/publication.html
http://www.wogri.at/fileadmin/ipsec/multiple_pages/node22.html

IPSec DHCP over IPsec....formus
http://osdir.com/ml/redhat.fedora.devel/2004-01/msg00099.html
http://wiki.guoshuang.com/Openswan

2008年8月24日 星期日

模擬器

來玩紅白機吧: http://olderliu.myweb.hinet.net/stg.htm
骨灰日誌
http://boneash.oldgame.tw/index.html

http://www.geocities.com/superhero1b04/
http://romhustler.net/
http://www.romnation.net/srv/roms.html

DEMO快速破關
http://www.wretch.cc/blog/cat069&category_id=8153493
任天堂攻略
http://www.askalee.com/game_guide/fc_game_teach.htm

ff有pic,中英對照
http://www.askalee.com/fc_gamephoto/fc_gamephoto_g1.htm
http://game-midi.blogspot.com/2008/07/sega-mega-drive.html
mame 中文化和大量的rom
http://boneash.oldgame.tw/MAME/mame.html
mame中文說明
http://www.puffer.idv.tw/mame32use1.htm

2008年8月12日 星期二

除3,mod 3... for arm cross-compile

article from:
http://osdir.com/ml/debian.devel.gcc/2002-08/msg00071.html
在cros compile時意外發現的問題
當compile share libraries *.so時有用 '%3' (ex 100 % 3)會出現問題
這是在run time時會有unresolved symbol '__modsi3' ,但不會在linking時warnning
but if compiled as ELF executable file, it is work fine.
同樣地,好像除3也會有__divsi3的問題(沒驗證)

這似乎和.hidden section有關,以下文章可供參考


Okay, HJ Lu has helped resolve the remaining issues in our transition to
building glibc under gcc 3.2. There have been several critical binutils
bugs fixed related to this issue that Chris Chimelis will get into the
next binutils package. The remaining portion of this is the attached patch
from Franz Sirl that will be going into glibc-2-2-branch. I will attempt to
explain the rational of these changes so you understand their importance.
Previous to gcc 3.1, gcc was exporting certain libgcc symbols, in error,
for linking. Starting with gcc 3.1, these symbols are now .hidden. This means
that if glibc is rebuilt with gcc >= 3.1, old binaries expecting to have
these symbols resolved will fail. In order to address this, ia64 and ppc
have provided libgcc-compat code in glibc to present these symbols for
resolution at run-time but not linking. The current glibc-2-2-branch as
of yesterday is insufficient to properly do this as Ulrich demands that
such symbols not be exported for linking. Unfortunately the current
patch there for this libgcc-compat code exports several of these symbols
for linking. The attached patch stops this behavior limiting all the
libgcc-compat symbols to just run-time resolution.
In getting to the patch attached below we tickled several
obscure binutils bugs with HJ Lu has been kind enough to fix
and check into binutils cvs...

http://sources.redhat.com/ml/binutils/2002-08/msg00175.html
http://sources.redhat.com/ml/binutils/2002-08/msg00217.html
http://sources.redhat.com/ml/binutils/2002-08/msg00221.html

..these patches are essential! Without them binutils will either
have problems linking other programs (complaining in error about
duplicate symbols with __divdi3) and creating a libgcc_s.so.1
in gcc 3.2 with a properly versioned __divdi3 symbol.
As soon as Chris has released the next binutils package and either
we use the attached patch or resample upstream from glibc-2-2-branch
for the same patch, we will be set to start building with gcc 3.2 on
ppc. It would be very good idea for us to get this resolved in
2.2.5-14, because current glibc-2-2-branch is exporting versioned
symbols for __divdi3, and few others, with a GLIBC_2.0 versioning.
This didn't happen in glibc prior to glibc 2.2.5-14 and it won't
after we add the patch below (which makes those symbols run-time
resolution only). It would be best if we don't muck around and
build a bunch of stuff on ppc against current glibc-2-2-branch without
the fix so as not to have to worry about those symbols.
Let me know if you have any specific questions. The process is
really simple..

1) updated binutils from HJ or 2.13.90.0.3 with binutils-version-add and
bfd-version-dso patches from this weekend and today.
2) add in glibc-libgcc-compat-ppc-8-2_2d from below or resample
glibc-2-2-branch once Franz has it in.
3) add a depends to gcc 3.2 for the binutils (>=2.13.90.0.4) and
for glibc (>=2.2.5-14). This step is essential to prevent the
build machines from using gcc-3.2 to build against the wrong,
i.e. old, binutils and/or libc accidentally.

Thanks in advance for helping get this transition to gcc 3.2
correctly done on ppc.