My favorites | Sign in
Project Logo
                
Details: Show all Hide all

Older

  • Dec 03, 2009
    r96 (Small changes (like directory access rights)) committed by TomaszFortuna   -   Small changes (like directory access rights)
    Small changes (like directory access rights)
  • Dec 03, 2009
    r95 (README update, fixed entropy source for key generator That'...) committed by TomaszFortuna   -   README update, fixed entropy source for key generator That's part of 0.2.5 work; README got some install tips fixed, pppauth does better at generating random data for the key.
    README update, fixed entropy source for key generator That's part of 0.2.5 work; README got some install tips fixed, pppauth does better at generating random data for the key.
  • Dec 03, 2009
    r94 (Makefile fixes; releasing as 0.2.5.) committed by TomaszFortuna   -   Makefile fixes; releasing as 0.2.5.
    Makefile fixes; releasing as 0.2.5.
  • Dec 03, 2009
    r93 (File parsing fixes. User shouldn't be able to segv uid 0 ss...) committed by TomaszFortuna   -   File parsing fixes. User shouldn't be able to segv uid 0 sshd processes by mangling it's ~/.pppauth which was the case.
    File parsing fixes. User shouldn't be able to segv uid 0 sshd processes by mangling it's ~/.pppauth which was the case.
  • Dec 03, 2009
    r92 (Bug fixed, pam msg on enforce, examplary .php .php file for...) committed by TomaszFortuna   -   Bug fixed, pam msg on enforce, examplary .php .php file for sending OTP passcode over email or SMS (using email gateway!)
    Bug fixed, pam msg on enforce, examplary .php .php file for sending OTP passcode over email or SMS (using email gateway!)
  • Dec 03, 2009
    r91 (Options to module added. README written. dontSkip changed -...) committed by TomaszFortuna   -   Options to module added. README written. dontSkip changed --dontSkip enabled, but can be disabled in module configuration and some warning added in help. Also some whitespace cleared.
    Options to module added. README written. dontSkip changed --dontSkip enabled, but can be disabled in module configuration and some warning added in help. Also some whitespace cleared.
  • Dec 03, 2009
    r90 (README added, --help corrected, make corrected Make should ...) committed by TomaszFortuna   -   README added, --help corrected, make corrected Make should add -fPIC to .so file now (Makefile.in) change.
    README added, --help corrected, make corrected Make should add -fPIC to .so file now (Makefile.in) change.
  • Dec 03, 2009
    r89 (Fixed locating HOME directory. I needed this so I can deter...) committed by TomaszFortuna   -   Fixed locating HOME directory. I needed this so I can determine next OTP from php and then send as SMS. Since it required also suPHP I could do without it. Yet, that's more flexible.
    Fixed locating HOME directory. I needed this so I can determine next OTP from php and then send as SMS. Since it required also suPHP I could do without it. Yet, that's more flexible.
  • Dec 03, 2009
    r88 (Added -p current option. Prints current (next to be used du...) committed by TomaszFortuna   -   Added -p current option. Prints current (next to be used during authentication). Fun for using with for example SMS generation.
    Added -p current option. Prints current (next to be used during authentication). Fun for using with for example SMS generation.
  • Dec 03, 2009
    r87 (Added locking of files. Lock is created before reading and ...) committed by TomaszFortuna   -   Added locking of files. Lock is created before reading and removed when the key number is incremented. Being unable to lock results in change of prompt (no lock) Passcode... but doesn't make it impossible to login.
    Added locking of files. Lock is created before reading and removed when the key number is incremented. Being unable to lock results in change of prompt (no lock) Passcode... but doesn't make it impossible to login.
  • Dec 03, 2009
    r86 (Fixed a bit previous idea. And tested as well, previous did...) committed by TomaszFortuna   -   Fixed a bit previous idea. And tested as well, previous didn't worked.
    Fixed a bit previous idea. And tested as well, previous didn't worked.
  • Dec 03, 2009
    r85 (FIX: Reserve passcode before authentication. One-time passc...) committed by TomaszFortuna   -   FIX: Reserve passcode before authentication. One-time passcodes could be successfully used twice and more if more then one ssh session were opened before performing authentication. Currently this problem is reduced to race condition...
    FIX: Reserve passcode before authentication. One-time passcodes could be successfully used twice and more if more then one ssh session were opened before performing authentication. Currently this problem is reduced to race condition...
  • Dec 03, 2009
    r84 (Cleaning up the code Added consts to function arguments whe...) committed by TomaszFortuna   -   Cleaning up the code Added consts to function arguments where appropriate (mpi, which doesn't use consts is a problem here). Added memset() before reading keyfile and removed one unnecessary variable.
    Cleaning up the code Added consts to function arguments where appropriate (mpi, which doesn't use consts is a problem here). Added memset() before reading keyfile and removed one unnecessary variable.
  • Dec 03, 2009
    r83 (Latex output (6 pages at a time)) committed by TomaszFortuna   -   Latex output (6 pages at a time)
    Latex output (6 pages at a time)
  • Dec 03, 2009
    r82 (Whitespace corrections (spaces / tabs)) committed by TomaszFortuna   -   Whitespace corrections (spaces / tabs)
    Whitespace corrections (spaces / tabs)
  • Dec 03, 2009
    r81 (FIX: Support for userdirs not matching /home/$USER) committed by TomaszFortuna   -   FIX: Support for userdirs not matching /home/$USER
    FIX: Support for userdirs not matching /home/$USER
  • Dec 03, 2009
    r80 (Corrected const-cast in setUser and whitespace.) committed by TomaszFortuna   -   Corrected const-cast in setUser and whitespace.
    Corrected const-cast in setUser and whitespace.
  • Dec 03, 2009
    r79 (FIX: Memory leak when .pppauth doesn't exist) committed by TomaszFortuna   -   FIX: Memory leak when .pppauth doesn't exist
    FIX: Memory leak when .pppauth doesn't exist
  • Nov 11, 2009
    Building (How to build and install PPP-PAM from the source code.) Wiki page commented on by TomaszFortuna   -   Just to update previous comment... I kind of forked ppp-pam, as I can't contact author for now. http://thera.be/my_public/my_projects/ppp-pam.git/ that's git repos, http://thera.be/my_public/my_projects/ppp-pam/ here are sources and ebuilds. On issues there's description of some fixed problems and git log can reveal the rest.
    Just to update previous comment... I kind of forked ppp-pam, as I can't contact author for now. http://thera.be/my_public/my_projects/ppp-pam.git/ that's git repos, http://thera.be/my_public/my_projects/ppp-pam/ here are sources and ebuilds. On issues there's description of some fixed problems and git log can reveal the rest.
  • Nov 11, 2009
    issue 26 (UUID doesn't seem to be a Perfect source of randomness) reported by TomaszFortuna   -   Test program generating random 256 bit keys like pppauth does without/with use of sha256: #include <stdio.h> #include <uuid/uuid.h> int main(int argc, char **argv) { uuid_t uuid; int i; unsigned char entropy[32]; for (;;) { uuid_generate_time(uuid); for (i=0; i<16; i++) { entropy[i] = uuid[i]; } uuid_generate_random(uuid); for (i=0; i<16; i++) { entropy[i+16] = uuid[i]; } // without sha256 for now if (fwrite(entropy, sizeof(entropy), 1, stdout) != 1) return 1; } return 0; } Randomity test: % ./uuid_test | rngtest -c 5000 rngtest 2 Copyright (c) 2004 by Henrique de Moraes Holschuh This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. rngtest: starting FIPS tests... rngtest: bits received from input: 100000032 rngtest: FIPS 140-2 successes: 0 rngtest: FIPS 140-2 failures: 5000 rngtest: FIPS 140-2(2001-10-10) Monobit: 4962 rngtest: FIPS 140-2(2001-10-10) Poker: 5000 rngtest: FIPS 140-2(2001-10-10) Runs: 4997 rngtest: FIPS 140-2(2001-10-10) Long run: 0 rngtest: FIPS 140-2(2001-10-10) Continuous run: 0 rngtest: input channel speed: (min=4.318; avg=26.187; max=19073.486)Mibits/s rngtest: FIPS tests speed: (min=122.266; avg=194.849; max=202.909)Mibits/s rngtest: Program run time: 4143023 microseconds That's lots of failures! Compare to: % cat /dev/urandom| rngtest -c 5000 rngtest: bits received from input: 100000032 rngtest: FIPS 140-2 successes: 4992 rngtest: FIPS 140-2 failures: 8 rngtest: input channel speed: (min=1.042; avg=97.223; max=19073.486)Mibits/s rngtest: FIPS tests speed: (min=50.863; avg=148.624; max=160.281)Mibits/s rngtest: Program run time: 1649105 microseconds Of course calculating sha256 from this data makes it a lot better (30 failures/5000 successes instead of 100%), but worries me nevertheless, as calculating sha256 from a variable, which is incremented by one in each pass also gets this rate but is not random at all. Using openssl like this: int main(int argc, char **argv) { uuid_t uuid; int i; unsigned char entropy[32]; for (;;) { if (RAND_bytes(entropy, 32) == 0) return 1; if (fwrite(entropy, sizeof(entropy), 1, stdout) != 1) return 1; } return 0; } Will result in more tests passed: rngtest: starting FIPS tests... rngtest: bits received from input: 100000032 rngtest: FIPS 140-2 successes: 4994 rngtest: FIPS 140-2 failures: 6 rngtest: input channel speed: (min=2.951; avg=566.423; max=19073.486)Mibits/s rngtest: FIPS tests speed: (min=45.305; avg=137.873; max=160.281)Mibits/s rngtest: Program run time: 868945 microseconds While most secure would be to read /dev/random I guess. Previous methods worked nearly instantly, while this approach for -c 5000 would take ages. I left it with -c 50... and after 8 minutes it generated only one block (20000 bits) which were a... SUCCESS! Duh. But 258 bits can be generated pretty fast especially if one moves the mouse/types on keyboard. I don't want to pull openssl as dependency, I'll try with some combined approach.
    Test program generating random 256 bit keys like pppauth does without/with use of sha256: #include <stdio.h> #include <uuid/uuid.h> int main(int argc, char **argv) { uuid_t uuid; int i; unsigned char entropy[32]; for (;;) { uuid_generate_time(uuid); for (i=0; i<16; i++) { entropy[i] = uuid[i]; } uuid_generate_random(uuid); for (i=0; i<16; i++) { entropy[i+16] = uuid[i]; } // without sha256 for now if (fwrite(entropy, sizeof(entropy), 1, stdout) != 1) return 1; } return 0; } Randomity test: % ./uuid_test | rngtest -c 5000 rngtest 2 Copyright (c) 2004 by Henrique de Moraes Holschuh This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. rngtest: starting FIPS tests... rngtest: bits received from input: 100000032 rngtest: FIPS 140-2 successes: 0 rngtest: FIPS 140-2 failures: 5000 rngtest: FIPS 140-2(2001-10-10) Monobit: 4962 rngtest: FIPS 140-2(2001-10-10) Poker: 5000 rngtest: FIPS 140-2(2001-10-10) Runs: 4997 rngtest: FIPS 140-2(2001-10-10) Long run: 0 rngtest: FIPS 140-2(2001-10-10) Continuous run: 0 rngtest: input channel speed: (min=4.318; avg=26.187; max=19073.486)Mibits/s rngtest: FIPS tests speed: (min=122.266; avg=194.849; max=202.909)Mibits/s rngtest: Program run time: 4143023 microseconds That's lots of failures! Compare to: % cat /dev/urandom| rngtest -c 5000 rngtest: bits received from input: 100000032 rngtest: FIPS 140-2 successes: 4992 rngtest: FIPS 140-2 failures: 8 rngtest: input channel speed: (min=1.042; avg=97.223; max=19073.486)Mibits/s rngtest: FIPS tests speed: (min=50.863; avg=148.624; max=160.281)Mibits/s rngtest: Program run time: 1649105 microseconds Of course calculating sha256 from this data makes it a lot better (30 failures/5000 successes instead of 100%), but worries me nevertheless, as calculating sha256 from a variable, which is incremented by one in each pass also gets this rate but is not random at all. Using openssl like this: int main(int argc, char **argv) { uuid_t uuid; int i; unsigned char entropy[32]; for (;;) { if (RAND_bytes(entropy, 32) == 0) return 1; if (fwrite(entropy, sizeof(entropy), 1, stdout) != 1) return 1; } return 0; } Will result in more tests passed: rngtest: starting FIPS tests... rngtest: bits received from input: 100000032 rngtest: FIPS 140-2 successes: 4994 rngtest: FIPS 140-2 failures: 6 rngtest: input channel speed: (min=2.951; avg=566.423; max=19073.486)Mibits/s rngtest: FIPS tests speed: (min=45.305; avg=137.873; max=160.281)Mibits/s rngtest: Program run time: 868945 microseconds While most secure would be to read /dev/random I guess. Previous methods worked nearly instantly, while this approach for -c 5000 would take ages. I left it with -c 50... and after 8 minutes it generated only one block (20000 bits) which were a... SUCCESS! Duh. But 258 bits can be generated pretty fast especially if one moves the mouse/types on keyboard. I don't want to pull openssl as dependency, I'll try with some combined approach.
  • Nov 10, 2009
    issue 25 (Makefile fails to support parallel compilation) reported by TomaszFortuna   -   What steps will reproduce the problem? 1. ./configure 2. make -j4 What is the expected output? What do you see instead? Correct compilation, but it fails: % make -j4 /usr/bin/perl ././mpi/types.pl 2 gcc "-I././rijndael -I././sha2 -I././mpi -Wall -O3 -funsigned-char" > mpi-types.h source='././ppp/cmdline.c' object='pppauth-cmdline.o' libtool=no \ depfile='.deps/pppauth-cmdline.Po' tmpdepfile='.deps/pppauth-cmdline.TPo' \ depmode=gcc3 /bin/sh ./depcomp \ gcc -DPACKAGE_NAME=\"pppauth\" -DPACKAGE_TARNAME=\"pppauth\" -DPACKAGE_VERSION=\"0.2\" -DPACKAGE_STRING=\"pppauth\ 0.2\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"pppauth\" -DVERSION=\"0.2\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_UUID_UUID_H=1 -DHAVE_SECURITY_PAM_MODULES_H=1 -DOS_IS_LINUX=1 -I. -I. -I././rijndael -I././sha2 -I././mpi -Wall -O3 -funsigned-char -g -O2 -c -o pppauth-cmdline.o `test -f '././ppp/cmdline.c' || echo './'`././ppp/cmdline.c source='././ppp/print.c' object='pppauth-print.o' libtool=no \ depfile='.deps/pppauth-print.Po' tmpdepfile='.deps/pppauth-print.TPo' \ depmode=gcc3 /bin/sh ./depcomp \ gcc -DPACKAGE_NAME=\"pppauth\" -DPACKAGE_TARNAME=\"pppauth\" -DPACKAGE_VERSION=\"0.2\" -DPACKAGE_STRING=\"pppauth\ 0.2\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"pppauth\" -DVERSION=\"0.2\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_UUID_UUID_H=1 -DHAVE_SECURITY_PAM_MODULES_H=1 -DOS_IS_LINUX=1 -I. -I. -I././rijndael -I././sha2 -I././mpi -Wall -O3 -funsigned-char -g -O2 -c -o pppauth-print.o `test -f '././ppp/print.c' || echo './'`././ppp/print.c source='././ppp/http.c' object='pppauth-http.o' libtool=no \ depfile='.deps/pppauth-http.Po' tmpdepfile='.deps/pppauth-http.TPo' \ depmode=gcc3 /bin/sh ./depcomp \ gcc -DPACKAGE_NAME=\"pppauth\" -DPACKAGE_TARNAME=\"pppauth\" -DPACKAGE_VERSION=\"0.2\" -DPACKAGE_STRING=\"pppauth\ 0.2\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"pppauth\" -DVERSION=\"0.2\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_UUID_UUID_H=1 -DHAVE_SECURITY_PAM_MODULES_H=1 -DOS_IS_LINUX=1 -I. -I. -I././rijndael -I././sha2 -I././mpi -Wall -O3 -funsigned-char -g -O2 -c -o pppauth-http.o `test -f '././ppp/http.c' || echo './'`././ppp/http.c Using 'gcc' as the C compiler. Using '-I././rijndael -I././sha2 -I././mpi -Wall -O3 -funsigned-char' as options. Determining type sizes ... In file included from ././ppp/cmdline.h:32, from ././ppp/cmdline.c:35: ././mpi/mpi.h:71: error: expected specifier-qualifier-list before ‘mp_sign’ ././mpi/mpi.h:86: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘mp_init’ ././mpi/mpi.h:87: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘mp_init_array’ ././mpi/mpi.h:88: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘mp_init_size’ ././mpi/mpi.h:89: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘mp_init_copy’ ././mpi/mpi.h:90: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘mp_copy’ What version of the product are you using? On what operating system? 0.2 (with my changes including 0.2.4). Gentoo GNU/Linux Please provide any additional information below. I guess something is wrong with dependencies.
    What steps will reproduce the problem? 1. ./configure 2. make -j4 What is the expected output? What do you see instead? Correct compilation, but it fails: % make -j4 /usr/bin/perl ././mpi/types.pl 2 gcc "-I././rijndael -I././sha2 -I././mpi -Wall -O3 -funsigned-char" > mpi-types.h source='././ppp/cmdline.c' object='pppauth-cmdline.o' libtool=no \ depfile='.deps/pppauth-cmdline.Po' tmpdepfile='.deps/pppauth-cmdline.TPo' \ depmode=gcc3 /bin/sh ./depcomp \ gcc -DPACKAGE_NAME=\"pppauth\" -DPACKAGE_TARNAME=\"pppauth\" -DPACKAGE_VERSION=\"0.2\" -DPACKAGE_STRING=\"pppauth\ 0.2\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"pppauth\" -DVERSION=\"0.2\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_UUID_UUID_H=1 -DHAVE_SECURITY_PAM_MODULES_H=1 -DOS_IS_LINUX=1 -I. -I. -I././rijndael -I././sha2 -I././mpi -Wall -O3 -funsigned-char -g -O2 -c -o pppauth-cmdline.o `test -f '././ppp/cmdline.c' || echo './'`././ppp/cmdline.c source='././ppp/print.c' object='pppauth-print.o' libtool=no \ depfile='.deps/pppauth-print.Po' tmpdepfile='.deps/pppauth-print.TPo' \ depmode=gcc3 /bin/sh ./depcomp \ gcc -DPACKAGE_NAME=\"pppauth\" -DPACKAGE_TARNAME=\"pppauth\" -DPACKAGE_VERSION=\"0.2\" -DPACKAGE_STRING=\"pppauth\ 0.2\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"pppauth\" -DVERSION=\"0.2\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_UUID_UUID_H=1 -DHAVE_SECURITY_PAM_MODULES_H=1 -DOS_IS_LINUX=1 -I. -I. -I././rijndael -I././sha2 -I././mpi -Wall -O3 -funsigned-char -g -O2 -c -o pppauth-print.o `test -f '././ppp/print.c' || echo './'`././ppp/print.c source='././ppp/http.c' object='pppauth-http.o' libtool=no \ depfile='.deps/pppauth-http.Po' tmpdepfile='.deps/pppauth-http.TPo' \ depmode=gcc3 /bin/sh ./depcomp \ gcc -DPACKAGE_NAME=\"pppauth\" -DPACKAGE_TARNAME=\"pppauth\" -DPACKAGE_VERSION=\"0.2\" -DPACKAGE_STRING=\"pppauth\ 0.2\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"pppauth\" -DVERSION=\"0.2\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_UUID_UUID_H=1 -DHAVE_SECURITY_PAM_MODULES_H=1 -DOS_IS_LINUX=1 -I. -I. -I././rijndael -I././sha2 -I././mpi -Wall -O3 -funsigned-char -g -O2 -c -o pppauth-http.o `test -f '././ppp/http.c' || echo './'`././ppp/http.c Using 'gcc' as the C compiler. Using '-I././rijndael -I././sha2 -I././mpi -Wall -O3 -funsigned-char' as options. Determining type sizes ... In file included from ././ppp/cmdline.h:32, from ././ppp/cmdline.c:35: ././mpi/mpi.h:71: error: expected specifier-qualifier-list before ‘mp_sign’ ././mpi/mpi.h:86: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘mp_init’ ././mpi/mpi.h:87: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘mp_init_array’ ././mpi/mpi.h:88: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘mp_init_size’ ././mpi/mpi.h:89: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘mp_init_copy’ ././mpi/mpi.h:90: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘mp_copy’ What version of the product are you using? On what operating system? 0.2 (with my changes including 0.2.4). Gentoo GNU/Linux Please provide any additional information below. I guess something is wrong with dependencies.
  • Nov 09, 2009
    issue 19 (enhancement to enforce usage) commented on by TomaszFortuna   -   Implemented in 0.2.4 as "enforce" option. Needs some tests, yet this requires some other means of creating passcodes for users as theirs ssh logins will be blocked. Can be generated over http, or by root.
    Implemented in 0.2.4 as "enforce" option. Needs some tests, yet this requires some other means of creating passcodes for users as theirs ssh logins will be blocked. Can be generated over http, or by root.
  • Nov 09, 2009
    issue 17 (64-bit support) commented on by TomaszFortuna   -   In 0.2.4 (my mods to 0.2) there's a fix in Makefile.am (and .in) which should solve the issue, but it generally just adds -fPIC to LD/C FLAGS of .so file.: -pam_ppp_so_LDFLAGS = -shared -lc -lpam $(UUID_LIBS) -pam_ppp_so_CFLAGS = $(MYCFLAGS) -DPAM_DYNAMIC +pam_ppp_so_LDFLAGS = -shared -fPIC -lc -lpam $(UUID_LIBS) +pam_ppp_so_CFLAGS = $(MYCFLAGS) -fPIC -DPAM_DYNAMIC
    In 0.2.4 (my mods to 0.2) there's a fix in Makefile.am (and .in) which should solve the issue, but it generally just adds -fPIC to LD/C FLAGS of .so file.: -pam_ppp_so_LDFLAGS = -shared -lc -lpam $(UUID_LIBS) -pam_ppp_so_CFLAGS = $(MYCFLAGS) -DPAM_DYNAMIC +pam_ppp_so_LDFLAGS = -shared -fPIC -lc -lpam $(UUID_LIBS) +pam_ppp_so_CFLAGS = $(MYCFLAGS) -fPIC -DPAM_DYNAMIC
  • Nov 08, 2009
    issue 24 (Added locking mechanism) reported by TomaszFortuna   -   ~/.pppauth/lock is used for locking whole directory. When users logs in pam-ppp tries to lock this file for at most 0.014s (20 trials every 700us). Normally this file shouldn't be locked this long, so if it can't lock it, it assumes something went wrong (something locked, and then died in a funny manner), but the user is prompted for the password nevertheless, although the prompt gets "(no lock)" prefix to tell user that something is bad. If the file is normally locked (which should happen all the time) keys are read, incremented and saved back. Then the lock is released. This should remove the race-condition with two parallel ssh sessions. As usual patch attached; the repos: http://thera.be/my_public/my_projects/ppp-pam.git/ Has all changes so far and I can merge it upstream if given r/w access to svn. Source with changes: http://xn--tp-fna.thera.be/ppp-pam/ppp-pam-0.2.3.tar.bz2 Checked more/less to work on x86 and x86_64; tried also to lock the file is artificial way, and it worked as it should. Nevertheless do your checks. ;d Question: shouldn't we check if memory is correctly allocated in pam module?
    ~/.pppauth/lock is used for locking whole directory. When users logs in pam-ppp tries to lock this file for at most 0.014s (20 trials every 700us). Normally this file shouldn't be locked this long, so if it can't lock it, it assumes something went wrong (something locked, and then died in a funny manner), but the user is prompted for the password nevertheless, although the prompt gets "(no lock)" prefix to tell user that something is bad. If the file is normally locked (which should happen all the time) keys are read, incremented and saved back. Then the lock is released. This should remove the race-condition with two parallel ssh sessions. As usual patch attached; the repos: http://thera.be/my_public/my_projects/ppp-pam.git/ Has all changes so far and I can merge it upstream if given r/w access to svn. Source with changes: http://xn--tp-fna.thera.be/ppp-pam/ppp-pam-0.2.3.tar.bz2 Checked more/less to work on x86 and x86_64; tried also to lock the file is artificial way, and it worked as it should. Nevertheless do your checks. ;d Question: shouldn't we check if memory is correctly allocated in pam module?
  • Nov 08, 2009
    issue 23 (Reserving passcodes to ensure OTP is used only One-Time) reported by TomaszFortuna   -   What steps will reproduce the problem? 1. ssh user@host in one terminal, don't log! 2. start the same ssh user@host in second terminal. 3. Send your regular password to both sshs - you will be prompted to enter the same one-time password and if it's correct it will work. What is the expected output? What do you see instead? This can allow an attacker without any additional software (except for seeing in real-time your keypresses!) to circumvent opt authentication and log in. What version of the product are you using? On what operating system? Applies to current svn version. Please provide any additional information below. I tried to solve this issue by reserving passcodes before authentication, so before the prompt is even shown passcode is reserved and current passcode number on disc - incremented (even when dontSkip is enabled). The prompt is printed and we wait for input. After input comes, user is checked against that reserved passcode. If it fails - we do nothing (except if the dontSkip is enabled. Then we decrease the stored number!) Any session opened at near-the-same time will read the incremented passcode number from disc and therefore OTP will be really one-time passwords. There are two problems: 1) Race. Two sessions opened at the SAME time can first read the file, then increment key and store it on disc (the same incremented key two times). They will use the same otp password twice then. This can be fixed by creating a lock file. (I'll try to do it if I have some time). 2) dontSkip behaviour currently is weird. I probably messed it up. Disc passcode = 1A Guy A logs in, get's key 1A, and key on disc is incremented (to 2A) then guy B logs in and he gets key 2A, key on disc = 3A Everything is ok if both are accepted, but imagine: If A fails first, then it decreases number on disc to 1A once again. if B guy logs correctly the next guy to log into will get 1A question again. And 2A can be known to attackers by this time. If B fails - the 2A question will be repeated which failed, so behaviour is generally ok. This can be used by attacker. Open ssh connection first, wait for next key to be entered, fail the login, and then log again - you'll get asked for something you know. So... I don't like dontSkip behaviour. I think the "requisite" for pam_unix is better security against DOS attacks here. Patch: http://temp.thera.be/ppp-pam/reserving_passcodes.patch Sources: http://temp.thera.be/ppp-pam/ppp-pam-0.2.2.tar.bz2
    What steps will reproduce the problem? 1. ssh user@host in one terminal, don't log! 2. start the same ssh user@host in second terminal. 3. Send your regular password to both sshs - you will be prompted to enter the same one-time password and if it's correct it will work. What is the expected output? What do you see instead? This can allow an attacker without any additional software (except for seeing in real-time your keypresses!) to circumvent opt authentication and log in. What version of the product are you using? On what operating system? Applies to current svn version. Please provide any additional information below. I tried to solve this issue by reserving passcodes before authentication, so before the prompt is even shown passcode is reserved and current passcode number on disc - incremented (even when dontSkip is enabled). The prompt is printed and we wait for input. After input comes, user is checked against that reserved passcode. If it fails - we do nothing (except if the dontSkip is enabled. Then we decrease the stored number!) Any session opened at near-the-same time will read the incremented passcode number from disc and therefore OTP will be really one-time passwords. There are two problems: 1) Race. Two sessions opened at the SAME time can first read the file, then increment key and store it on disc (the same incremented key two times). They will use the same otp password twice then. This can be fixed by creating a lock file. (I'll try to do it if I have some time). 2) dontSkip behaviour currently is weird. I probably messed it up. Disc passcode = 1A Guy A logs in, get's key 1A, and key on disc is incremented (to 2A) then guy B logs in and he gets key 2A, key on disc = 3A Everything is ok if both are accepted, but imagine: If A fails first, then it decreases number on disc to 1A once again. if B guy logs correctly the next guy to log into will get 1A question again. And 2A can be known to attackers by this time. If B fails - the 2A question will be repeated which failed, so behaviour is generally ok. This can be used by attacker. Open ssh connection first, wait for next key to be entered, fail the login, and then log again - you'll get asked for something you know. So... I don't like dontSkip behaviour. I think the "requisite" for pam_unix is better security against DOS attacks here. Patch: http://temp.thera.be/ppp-pam/reserving_passcodes.patch Sources: http://temp.thera.be/ppp-pam/ppp-pam-0.2.2.tar.bz2
  • Nov 07, 2009
    issue 22 (Latex output of 6 pages for pppauth) reported by TomaszFortuna   -   Latex output for pppauth 6 pages at a time (can be cut). I'm not very happy with how I added latex.c and latex.h files to autoconf/make. latexSingleCard is not currently used, but I left it as it might be handy to change and use it in future. I've got my branch in GIT repos (imported from svn) can be imported like this: git clone http://thera.be/my_public/my_projects/ppp-pam.git/ Following bz2 has all my changes so far: http://temp.thera.be/ppp-pam/ppp-pam-0.2.1.tar.bz2 Also I've got no idea how to mark this as an enhancement.
    Latex output for pppauth 6 pages at a time (can be cut). I'm not very happy with how I added latex.c and latex.h files to autoconf/make. latexSingleCard is not currently used, but I left it as it might be handy to change and use it in future. I've got my branch in GIT repos (imported from svn) can be imported like this: git clone http://thera.be/my_public/my_projects/ppp-pam.git/ Following bz2 has all my changes so far: http://temp.thera.be/ppp-pam/ppp-pam-0.2.1.tar.bz2 Also I've got no idea how to mark this as an enhancement.
  • Nov 07, 2009
    issue 21 (pppCleanup() not called when user lacks ~/.pppauth directory) reported by TomaszFortuna   -   What steps will reproduce the problem? 1. Login with user without ~/.pppauth directory SVN version. Please provide any additional information below. When readKeyFile() fails after pppInit() is done there's no call to pppCleanup() which cause soft to leak 32 bytes at: ==7209== 32 bytes in 1 blocks are definitely lost in loss record 5 of 5 ==7209== at 0x4022C3B: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==7209== by 0x804A008: mp_init_size (mpi.c:284) ==7209== by 0x8049F2E: mp_init (mpi.c:238) ==7209== by 0x8049933: readKeyFile (keyfiles.c:352) ==7209== by 0x8048EFF: pam_sm_authenticate (memtest.c:56) ==7209== by 0x8048FED: main (memtest.c:110) UPDATE: it's also readKeyFile() which calls mp_init, but won't call mp_clear on error. Also it might sometimes not zero buf, which holds the key. I did a .c file which simulates logins without help of PAM so I can run it on valgrind; that's the only case of leak I've found so far. I'm not entirely sure how PAM works, but I think that this leak wouldn't lead to some big memory usage on long-running systems (in sshd?) therefore this leak might not be so important, yet it would be nice to patch it up. Setting user to NULL at exit of pam_sm_authenticate doesn't do anything important as I think, so possible fix, using common goto-method is in attached patch. (Also fixed whitespace 4 spaces vs. tab and removed drop of const keyword on const char *user; will work fine if setUser prototype is changed to accept const (as in my previous patch) ).
    What steps will reproduce the problem? 1. Login with user without ~/.pppauth directory SVN version. Please provide any additional information below. When readKeyFile() fails after pppInit() is done there's no call to pppCleanup() which cause soft to leak 32 bytes at: ==7209== 32 bytes in 1 blocks are definitely lost in loss record 5 of 5 ==7209== at 0x4022C3B: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==7209== by 0x804A008: mp_init_size (mpi.c:284) ==7209== by 0x8049F2E: mp_init (mpi.c:238) ==7209== by 0x8049933: readKeyFile (keyfiles.c:352) ==7209== by 0x8048EFF: pam_sm_authenticate (memtest.c:56) ==7209== by 0x8048FED: main (memtest.c:110) UPDATE: it's also readKeyFile() which calls mp_init, but won't call mp_clear on error. Also it might sometimes not zero buf, which holds the key. I did a .c file which simulates logins without help of PAM so I can run it on valgrind; that's the only case of leak I've found so far. I'm not entirely sure how PAM works, but I think that this leak wouldn't lead to some big memory usage on long-running systems (in sshd?) therefore this leak might not be so important, yet it would be nice to patch it up. Setting user to NULL at exit of pam_sm_authenticate doesn't do anything important as I think, so possible fix, using common goto-method is in attached patch. (Also fixed whitespace 4 spaces vs. tab and removed drop of const keyword on const char *user; will work fine if setUser prototype is changed to accept const (as in my previous patch) ).
  • Nov 07, 2009
    issue 17 (64-bit support) commented on by TomaszFortuna   -   Easiest fix is to just compile with command: make CFLAGS="-fPIC" on x86_64 systems. (pppauth compiled and worked when I did this; didn't checked PAM). Pity I don't know autotools.
    Easiest fix is to just compile with command: make CFLAGS="-fPIC" on x86_64 systems. (pppauth compiled and worked when I did this; didn't checked PAM). Pity I don't know autotools.
  • Nov 06, 2009
    issue 16 (Option to only require PPP from WAN) commented on by TomaszFortuna   -   I personally use public/private key authentication from trusted machines and therefore I can log in without passcodes from anywhere with them. I wonder if what you're trying to do can't be done in PAM itself. No idea.
    I personally use public/private key authentication from trusted machines and therefore I can log in without passcodes from anywhere with them. I wonder if what you're trying to do can't be done in PAM itself. No idea.
  • Nov 06, 2009
    issue 20 (Support for users with homes not matching /home/$USERNAME) reported by TomaszFortuna   -   What steps will reproduce the problem? 1. Create a user with home not matching /home/$USERNAME. 2. setUser() would fail to create a correct directory name then. What is the expected output? What do you see instead? Should work for any home dirs. What version of the product are you using? On what operating system? Linux, 0.2v from tarball; svn also seems to have this issue. Please provide any additional information below. This patch should do for users not in /home/$USER directories on Linux (mac should be similar, but can't help there). Also - it compiles, works in my separate .c file, but I haven't checked it in pam. http://temp.thera.be/ppp-pam/home_fix.patch It might be that I'm mistaken. BTW. Great project, I'd love to help you work on it somehow.
    What steps will reproduce the problem? 1. Create a user with home not matching /home/$USERNAME. 2. setUser() would fail to create a correct directory name then. What is the expected output? What do you see instead? Should work for any home dirs. What version of the product are you using? On what operating system? Linux, 0.2v from tarball; svn also seems to have this issue. Please provide any additional information below. This patch should do for users not in /home/$USER directories on Linux (mac should be similar, but can't help there). Also - it compiles, works in my separate .c file, but I haven't checked it in pam. http://temp.thera.be/ppp-pam/home_fix.patch It might be that I'm mistaken. BTW. Great project, I'd love to help you work on it somehow.
  • Nov 06, 2009
    Building (How to build and install PPP-PAM from the source code.) Wiki page commented on by TomaszFortuna   -   This is maybe not best place to post it, but can't find better. ;-) This code should do for users not in /home/$USER directories on Linux (mac should be similar, but can't help there). Also - it compiles, works in my separate .c file, but I haven't checked it in pam. http://temp.thera.be/ppp-pam/home_fix.patch (pasting it here made it look awful.)
    This is maybe not best place to post it, but can't find better. ;-) This code should do for users not in /home/$USER directories on Linux (mac should be similar, but can't help there). Also - it compiles, works in my separate .c file, but I haven't checked it in pam. http://temp.thera.be/ppp-pam/home_fix.patch (pasting it here made it look awful.)
  • Nov 06, 2009
    Building (How to build and install PPP-PAM from the source code.) Wiki page commented on by TomaszFortuna   -   This is maybe not best place to post it, but can't find better. ;-) This code should do for users not in /home/$USER directories on Linux (mac should be similar, but can't help there). Also - it compiles, works in my separate .c file, but I haven't checked it in pam. Index: ppp/keyfiles.h =================================================================== --- ppp/keyfiles.h (wersja 78) +++ ppp/keyfiles.h (kopia robocza) @@ -31,7 +31,7 @@ #include "ppp.h" -void setUser(char *user); +void setUser(const char *user); int keyfileExists(); int writeKeyFile(); int writeState(); Index: ppp/keyfiles.c =================================================================== --- ppp/keyfiles.c (wersja 78) +++ ppp/keyfiles.c (kopia robocza) @@ -319,14 +319,23 @@ return 1; } -void setUser(char *user) { +void setUser(const char *user) { #ifdef OS_IS_MACOSX strncpy(userhome, "/Users/", 7); + strncat(userhome, user, 120); #endif #ifdef OS_IS_LINUX - strncpy(userhome, "/home/", 6); + const struct passwd *pwent; + + while ((pwent = getpwent()) != NULL) { + if (strcmp(pwent->pw_name, user) == 0) { + strncpy(userhome, pwent->pw_dir, 126); + endpwent(); + return; + } + } + strcpy(userhome, "/"); /* If user doesn't exists return something more/less sane */ #endif - strncat(userhome, user, 120); } int keyfileExists() {
    This is maybe not best place to post it, but can't find better. ;-) This code should do for users not in /home/$USER directories on Linux (mac should be similar, but can't help there). Also - it compiles, works in my separate .c file, but I haven't checked it in pam. Index: ppp/keyfiles.h =================================================================== --- ppp/keyfiles.h (wersja 78) +++ ppp/keyfiles.h (kopia robocza) @@ -31,7 +31,7 @@ #include "ppp.h" -void setUser(char *user); +void setUser(const char *user); int keyfileExists(); int writeKeyFile(); int writeState(); Index: ppp/keyfiles.c =================================================================== --- ppp/keyfiles.c (wersja 78) +++ ppp/keyfiles.c (kopia robocza) @@ -319,14 +319,23 @@ return 1; } -void setUser(char *user) { +void setUser(const char *user) { #ifdef OS_IS_MACOSX strncpy(userhome, "/Users/", 7); + strncat(userhome, user, 120); #endif #ifdef OS_IS_LINUX - strncpy(userhome, "/home/", 6); + const struct passwd *pwent; + + while ((pwent = getpwent()) != NULL) { + if (strcmp(pwent->pw_name, user) == 0) { + strncpy(userhome, pwent->pw_dir, 126); + endpwent(); + return; + } + } + strcpy(userhome, "/"); /* If user doesn't exists return something more/less sane */ #endif - strncat(userhome, user, 120); } int keyfileExists() {
  • Nov 06, 2009
    Building (How to build and install PPP-PAM from the source code.) Wiki page commented on by TomaszFortuna   -   ebuild with which I built in on Gentoo: http://temp.thera.be/ppp-pam/ppp-pam-0.2.ebuild 0.2 version won't work with user homes outside /home.
    ebuild with which I built in on Gentoo: http://temp.thera.be/ppp-pam/ppp-pam-0.2.ebuild 0.2 version won't work with user homes outside /home.
  • Sep 11, 2009
    Building (How to build and install PPP-PAM from the source code.) Wiki page commented on by roncraig007   -   =A couple of important notes= *Do *not* forget to restart your sshd service after fiddling with /etc/pam.d/sshd or /etc/pam.conf. Otherwise you may spend hours wondering why it does not work! *The code that is available as a tar file is an older version than that available off the svn source code tree. In particular, I noticed that the tar'd code does not properly display nice password pages on Linux with the --html option. This was later worked around in the version on svn. *The more recent news on pam_ppp is in the Google group mentioned above. I hope that helps somebody avoid spending hours debugging something that actually works or is outdated. -FrugalGuy
    =A couple of important notes= *Do *not* forget to restart your sshd service after fiddling with /etc/pam.d/sshd or /etc/pam.conf. Otherwise you may spend hours wondering why it does not work! *The code that is available as a tar file is an older version than that available off the svn source code tree. In particular, I noticed that the tar'd code does not properly display nice password pages on Linux with the --html option. This was later worked around in the version on svn. *The more recent news on pam_ppp is in the Google group mentioned above. I hope that helps somebody avoid spending hours debugging something that actually works or is outdated. -FrugalGuy
  • Sep 02, 2009
    Building (How to build and install PPP-PAM from the source code.) Wiki page commented on by robertharder   -   To compile on Mac OS X 10.6 Snow Leopard, I had to find the _pam_macros.h file in the 10.5 frameworks. I changed pam_ppp.c to from #include <security/_pam_macros.h> to #include "/Developer/SDKs/MacOSX10.5.sdk/usr/include/pam/_pam_macros.h" I posted notes here: http://iharder.freepgs.com/2009/09/02/ppp-two-factor-authentication-in-snow-leopard-ssh-with-perfect-paper-passwords/ -Rob
    To compile on Mac OS X 10.6 Snow Leopard, I had to find the _pam_macros.h file in the 10.5 frameworks. I changed pam_ppp.c to from #include <security/_pam_macros.h> to #include "/Developer/SDKs/MacOSX10.5.sdk/usr/include/pam/_pam_macros.h" I posted notes here: http://iharder.freepgs.com/2009/09/02/ppp-two-factor-authentication-in-snow-leopard-ssh-with-perfect-paper-passwords/ -Rob
  • Apr 22, 2009
    issue 19 (enhancement to enforce usage) reported by kevm...@accesscomm.ca   -   I'd like to see a change so that logins fail if the .pppauth directory doesn't exist in a user's home directory. The otpw package has this behaviour when users haven't generated their passcodes.
    I'd like to see a change so that logins fail if the .pppauth directory doesn't exist in a user's home directory. The otpw package has this behaviour when users haven't generated their passcodes.
  • Apr 21, 2009
    issue 18 (Unable to run under sudo) reported by tylermenezes   -   By default, the program can't run under sudo, because it gets the user's directory by grabbing the UID and looking it up in the users file. On any sane system, the environment variable HOME will contain the user's home directory, and more importantly, this won't change when doing sudo. Using a getenv() call in keyfiles.c will make it work.
    By default, the program can't run under sudo, because it gets the user's directory by grabbing the UID and looking it up in the users file. On any sane system, the environment variable HOME will contain the user's home directory, and more importantly, this won't change when doing sudo. Using a getenv() call in keyfiles.c will make it work.
  • Apr 21, 2009
    issue 17 (64-bit support) reported by tylermenezes   -   Configure doesn't support 64-bit systems, as it doesn't set -fPIC on the make options for the shared libraries if it's running on a 64-bit system.
    Configure doesn't support 64-bit systems, as it doesn't set -fPIC on the make options for the shared libraries if it's running on a 64-bit system.
  • Jan 13, 2009
    issue 15 (PPP causes failure when using nomachine/freeNX) commented on by weisbm   -   Other one time use passwords (I've tested RSA SecurID) use a single input field, and seem to work fine. I think it is a function of the second prompt that ppp_pam presents. Any ideas?
    Other one time use passwords (I've tested RSA SecurID) use a single input field, and seem to work fine. I think it is a function of the second prompt that ppp_pam presents. Any ideas?
  • Jan 09, 2009
    r78 (Remove cache files we don't need kept in VCS ) committed by Luke.Faraone   -   Remove cache files we don't need kept in VCS
    Remove cache files we don't need kept in VCS
  • Jan 09, 2009
    r77 (Compatability modifcations for debian; no change for most us...) committed by Luke.Faraone   -   Compatability modifcations for debian; no change for most users.
    Compatability modifcations for debian; no change for most users.
  • Jan 08, 2009
    issue 15 (PPP causes failure when using nomachine/freeNX) commented on by Luke.Faraone   -   weisbm, Does this issue occur when you use other onetimepassword modules?
    weisbm, Does this issue occur when you use other onetimepassword modules?
  • Jan 08, 2009
    issue 14 (Suceptable to DOS attack.) Labels changed by Luke.Faraone   -  
    Labels: Security Usability
    Labels: Security Usability
  • Jan 08, 2009
    issue 13 (Upgrade mpi library in preparation for PPP v3) changed by Luke.Faraone   -  
    Owner: Luke.Faraone
    Labels: Component-Logic Maintainability
    Owner: Luke.Faraone
    Labels: Component-Logic Maintainability
  • Jan 08, 2009
    issue 2 (Add logging to pam_ppp.so) Labels changed by Luke.Faraone   -  
    Labels: Type-Enhancement Type-Defect
    Labels: Type-Enhancement Type-Defect
  • Aug 14, 2008
    issue 9 (Create an iPhone Client) commented on by kurtisnelson   -   I have written a java GUI passcode generator that does the same thing for desktops. Could it be easily modded for iPhone?
    I have written a java GUI passcode generator that does the same thing for desktops. Could it be easily modded for iPhone?
  • Aug 14, 2008
    issue 16 (Option to only require PPP from WAN) reported by kurtisnelson   -   My main server I ssh into is at home and is thus behind my router. I would like to skip PPP authentication when I connect from anywhere in my LAN or if I am VPN'ed. Basically I would like to skip PPP if the connection source is in the 192.168.255.255 or 10. range so I don't burn through passcodes as quickly.
    My main server I ssh into is at home and is thus behind my router. I would like to skip PPP authentication when I connect from anywhere in my LAN or if I am VPN'ed. Basically I would like to skip PPP if the connection source is in the 192.168.255.255 or 10. range so I don't burn through passcodes as quickly.
 
Hosted by Google Code