Searched hist:111 (Results 1 - 17 of 17) sorted by relevance
| /freebsd-11.0-release/share/man/man4/ | ||
| H A D | rum.4 | diff 182147 Mon Aug 25 06:06:59 MDT 2008 kevlo Add DWA-110 and DWA-111 to the list of devices supported by rum(4) |
| /freebsd-11.0-release/sys/security/audit/ | ||
| H A D | audit.c | diff 172995 Fri Oct 26 01:23:07 MDT 2007 csjp Implement AUE_CORE, which adds process core dump support into the kernel. This change introduces audit_proc_coredump() which is called by coredump(9) to create an audit record for the coredump event. When a process dumps a core, it could be security relevant. It could be an indicator that a stack within the process has been overflowed with an incorrectly constructed malicious payload or a number of other events. The record that is generated looks like this: header,111,10,process dumped core,0,Thu Oct 25 19:36:29 2007, + 179 msec argument,0,0xb,signal path,/usr/home/csjp/test.core subject,csjp,csjp,staff,csjp,staff,1101,1095,50457,10.37.129.2 return,success,1 trailer,111 - We allocate a completely new record to make sure we arent clobbering the audit data associated with the syscall that produced the core (assuming the core is being generated in response to SIGABRT and not an invalid memory access). - Shuffle around expand_name() so we can use the coredump name at the very beginning of the coredump call. Make sure we free the storage referenced by "name" if we need to bail out early. - Audit both successful and failed coredump creation efforts Obtained from: TrustedBSD Project Reviewed by: rwatson MFC after: 1 month diff 172995 Fri Oct 26 01:23:07 MDT 2007 csjp Implement AUE_CORE, which adds process core dump support into the kernel. This change introduces audit_proc_coredump() which is called by coredump(9) to create an audit record for the coredump event. When a process dumps a core, it could be security relevant. It could be an indicator that a stack within the process has been overflowed with an incorrectly constructed malicious payload or a number of other events. The record that is generated looks like this: header,111,10,process dumped core,0,Thu Oct 25 19:36:29 2007, + 179 msec argument,0,0xb,signal path,/usr/home/csjp/test.core subject,csjp,csjp,staff,csjp,staff,1101,1095,50457,10.37.129.2 return,success,1 trailer,111 - We allocate a completely new record to make sure we arent clobbering the audit data associated with the syscall that produced the core (assuming the core is being generated in response to SIGABRT and not an invalid memory access). - Shuffle around expand_name() so we can use the coredump name at the very beginning of the coredump call. Make sure we free the storage referenced by "name" if we need to bail out early. - Audit both successful and failed coredump creation efforts Obtained from: TrustedBSD Project Reviewed by: rwatson MFC after: 1 month |
| H A D | audit.h | diff 172995 Fri Oct 26 01:23:07 MDT 2007 csjp Implement AUE_CORE, which adds process core dump support into the kernel. This change introduces audit_proc_coredump() which is called by coredump(9) to create an audit record for the coredump event. When a process dumps a core, it could be security relevant. It could be an indicator that a stack within the process has been overflowed with an incorrectly constructed malicious payload or a number of other events. The record that is generated looks like this: header,111,10,process dumped core,0,Thu Oct 25 19:36:29 2007, + 179 msec argument,0,0xb,signal path,/usr/home/csjp/test.core subject,csjp,csjp,staff,csjp,staff,1101,1095,50457,10.37.129.2 return,success,1 trailer,111 - We allocate a completely new record to make sure we arent clobbering the audit data associated with the syscall that produced the core (assuming the core is being generated in response to SIGABRT and not an invalid memory access). - Shuffle around expand_name() so we can use the coredump name at the very beginning of the coredump call. Make sure we free the storage referenced by "name" if we need to bail out early. - Audit both successful and failed coredump creation efforts Obtained from: TrustedBSD Project Reviewed by: rwatson MFC after: 1 month diff 172995 Fri Oct 26 01:23:07 MDT 2007 csjp Implement AUE_CORE, which adds process core dump support into the kernel. This change introduces audit_proc_coredump() which is called by coredump(9) to create an audit record for the coredump event. When a process dumps a core, it could be security relevant. It could be an indicator that a stack within the process has been overflowed with an incorrectly constructed malicious payload or a number of other events. The record that is generated looks like this: header,111,10,process dumped core,0,Thu Oct 25 19:36:29 2007, + 179 msec argument,0,0xb,signal path,/usr/home/csjp/test.core subject,csjp,csjp,staff,csjp,staff,1101,1095,50457,10.37.129.2 return,success,1 trailer,111 - We allocate a completely new record to make sure we arent clobbering the audit data associated with the syscall that produced the core (assuming the core is being generated in response to SIGABRT and not an invalid memory access). - Shuffle around expand_name() so we can use the coredump name at the very beginning of the coredump call. Make sure we free the storage referenced by "name" if we need to bail out early. - Audit both successful and failed coredump creation efforts Obtained from: TrustedBSD Project Reviewed by: rwatson MFC after: 1 month |
| H A D | audit_bsm.c | diff 172995 Fri Oct 26 01:23:07 MDT 2007 csjp Implement AUE_CORE, which adds process core dump support into the kernel. This change introduces audit_proc_coredump() which is called by coredump(9) to create an audit record for the coredump event. When a process dumps a core, it could be security relevant. It could be an indicator that a stack within the process has been overflowed with an incorrectly constructed malicious payload or a number of other events. The record that is generated looks like this: header,111,10,process dumped core,0,Thu Oct 25 19:36:29 2007, + 179 msec argument,0,0xb,signal path,/usr/home/csjp/test.core subject,csjp,csjp,staff,csjp,staff,1101,1095,50457,10.37.129.2 return,success,1 trailer,111 - We allocate a completely new record to make sure we arent clobbering the audit data associated with the syscall that produced the core (assuming the core is being generated in response to SIGABRT and not an invalid memory access). - Shuffle around expand_name() so we can use the coredump name at the very beginning of the coredump call. Make sure we free the storage referenced by "name" if we need to bail out early. - Audit both successful and failed coredump creation efforts Obtained from: TrustedBSD Project Reviewed by: rwatson MFC after: 1 month diff 172995 Fri Oct 26 01:23:07 MDT 2007 csjp Implement AUE_CORE, which adds process core dump support into the kernel. This change introduces audit_proc_coredump() which is called by coredump(9) to create an audit record for the coredump event. When a process dumps a core, it could be security relevant. It could be an indicator that a stack within the process has been overflowed with an incorrectly constructed malicious payload or a number of other events. The record that is generated looks like this: header,111,10,process dumped core,0,Thu Oct 25 19:36:29 2007, + 179 msec argument,0,0xb,signal path,/usr/home/csjp/test.core subject,csjp,csjp,staff,csjp,staff,1101,1095,50457,10.37.129.2 return,success,1 trailer,111 - We allocate a completely new record to make sure we arent clobbering the audit data associated with the syscall that produced the core (assuming the core is being generated in response to SIGABRT and not an invalid memory access). - Shuffle around expand_name() so we can use the coredump name at the very beginning of the coredump call. Make sure we free the storage referenced by "name" if we need to bail out early. - Audit both successful and failed coredump creation efforts Obtained from: TrustedBSD Project Reviewed by: rwatson MFC after: 1 month |
| /freebsd-11.0-release/lib/msun/ld128/ | ||
| H A D | e_rem_pio2l.h | diff 176465 Fri Feb 22 15:55:14 MST 2008 bde Optimize the 9pi/2 < |x| <= 2**19pi/2 case on amd64 and i386 by avoiding the the double to int conversion operation which is very slow on these arches. Assume that the current rounding mode is the default of round-to-nearest and use rounding operations in this mode instead of faking this mode using the round-towards-zero mode for conversion to int. Round the double to an integer as a double first and as an int second since the double result is needed much earler. Double rounding isn't a problem since we only need a rough approximation. We didn't support other current rounding modes and produce much larger errors than before if called in a non-default mode. This saves an average about 10 cycles on amd64 (A64) and about 25 on i386 (A64) for x in the above range. In some cases the saving is over 25%. Most cases with |x| < 1000pi now take about 88 cycles for cos and sin (with certain CFLAGS, etc.), except on i386 where cos and sin (but not cosf and sinf) are much slower at 111 and 121 cycles respectivly due to the compiler only optimizing well for float precision. A64 hardware cos and sin are slower at 105 cycles on i386 and 110 cycles on amd64. |
| /freebsd-11.0-release/lib/msun/ld80/ | ||
| H A D | e_rem_pio2l.h | diff 176465 Fri Feb 22 15:55:14 MST 2008 bde Optimize the 9pi/2 < |x| <= 2**19pi/2 case on amd64 and i386 by avoiding the the double to int conversion operation which is very slow on these arches. Assume that the current rounding mode is the default of round-to-nearest and use rounding operations in this mode instead of faking this mode using the round-towards-zero mode for conversion to int. Round the double to an integer as a double first and as an int second since the double result is needed much earler. Double rounding isn't a problem since we only need a rough approximation. We didn't support other current rounding modes and produce much larger errors than before if called in a non-default mode. This saves an average about 10 cycles on amd64 (A64) and about 25 on i386 (A64) for x in the above range. In some cases the saving is over 25%. Most cases with |x| < 1000pi now take about 88 cycles for cos and sin (with certain CFLAGS, etc.), except on i386 where cos and sin (but not cosf and sinf) are much slower at 111 and 121 cycles respectivly due to the compiler only optimizing well for float precision. A64 hardware cos and sin are slower at 105 cycles on i386 and 110 cycles on amd64. |
| /freebsd-11.0-release/lib/msun/src/ | ||
| H A D | e_rem_pio2.c | diff 176465 Fri Feb 22 15:55:14 MST 2008 bde Optimize the 9pi/2 < |x| <= 2**19pi/2 case on amd64 and i386 by avoiding the the double to int conversion operation which is very slow on these arches. Assume that the current rounding mode is the default of round-to-nearest and use rounding operations in this mode instead of faking this mode using the round-towards-zero mode for conversion to int. Round the double to an integer as a double first and as an int second since the double result is needed much earler. Double rounding isn't a problem since we only need a rough approximation. We didn't support other current rounding modes and produce much larger errors than before if called in a non-default mode. This saves an average about 10 cycles on amd64 (A64) and about 25 on i386 (A64) for x in the above range. In some cases the saving is over 25%. Most cases with |x| < 1000pi now take about 88 cycles for cos and sin (with certain CFLAGS, etc.), except on i386 where cos and sin (but not cosf and sinf) are much slower at 111 and 121 cycles respectivly due to the compiler only optimizing well for float precision. A64 hardware cos and sin are slower at 105 cycles on i386 and 110 cycles on amd64. |
| H A D | e_rem_pio2f.c | diff 176465 Fri Feb 22 15:55:14 MST 2008 bde Optimize the 9pi/2 < |x| <= 2**19pi/2 case on amd64 and i386 by avoiding the the double to int conversion operation which is very slow on these arches. Assume that the current rounding mode is the default of round-to-nearest and use rounding operations in this mode instead of faking this mode using the round-towards-zero mode for conversion to int. Round the double to an integer as a double first and as an int second since the double result is needed much earler. Double rounding isn't a problem since we only need a rough approximation. We didn't support other current rounding modes and produce much larger errors than before if called in a non-default mode. This saves an average about 10 cycles on amd64 (A64) and about 25 on i386 (A64) for x in the above range. In some cases the saving is over 25%. Most cases with |x| < 1000pi now take about 88 cycles for cos and sin (with certain CFLAGS, etc.), except on i386 where cos and sin (but not cosf and sinf) are much slower at 111 and 121 cycles respectivly due to the compiler only optimizing well for float precision. A64 hardware cos and sin are slower at 105 cycles on i386 and 110 cycles on amd64. |
| /freebsd-11.0-release/sys/arm/arm/ | ||
| H A D | busdma_machdep-v4.c | diff 244471 Thu Dec 20 00:38:54 MST 2012 cognet Busdma enhancements, especially for managing small uncacheable buffers. - Use the new architecture-agnostic buffer pool manager that uses uma(9) to manage a set of power-of-2 sized buffers for bus_dmamem_alloc(). - Create pools of buffers backed by both regular and uncacheable memory, and use them to handle regular versus BUS_DMA_COHERENT allocations. - Use uma(9) to manage a pool of bus_dmamap structs instead of local code to manage a static list of 500 items (it took 3300 maps to get to multi-user mode, so the static pool wasn't much of an optimization). - Small BUS_DMA_COHERENT allocations no longer waste an entire page per allocation, or set pages to uncached when they contain data other than DMA buffers. There's no longer a need for drivers to work around the inefficiency by allocing large buffers then sub-dividing them. - Because we know the alignment and padding of buffers allocated by bus_dmamem_alloc() (whether coherent or regular memory, and whether obtained from the pool allocator or directly from the kernel) we can avoid doing partial cacheline flushes on them. - Add a fast-out to _bus_dma_could_bounce() (and some comments about what the routine really does because the old misplaced comment was wrong). - Everywhere the dma tag alignment is used, the interpretation is that an alignment of 1 means no special alignment. If the tag is created with an alignment argument of zero, store it in the tag as one, and remove all the code scattered around that changed 0->1 at point of use. - Remove stack-allocated arrays of segments, use a local array of two segments within the tag struct, or dynamically allocate an array at first use if nsegments > 2. On an arm system I tested, only 5 of 97 tags used more than two segments. On my x86 desktop it was only 7 of 111 tags. Submitted by: Ian Lepore <freebsd@damnhippie.dyndns.org> |
| /freebsd-11.0-release/sys/arm/include/ | ||
| H A D | pmap-v4.h | diff 250297 Mon May 06 15:34:14 MDT 2013 gber Fix L2 PTE access permissions management. Keep following access permissions: APX AP Kernel User 1 01 R N 1 10 R R 0 01 R/W N 0 11 R/W R/W Avoid using reserved in ARMv6 APX|AP settings: - In case of unprivileged (user) access without permission to write, the access permission bits were being set to reserved for ARMv6 (but valid for ARMv7) value of APX|AP = 111. Fix-up faulting userland accesses properly: - Wrong condition statement in pmap_fault_fixup() caused that any genuine, unprivileged access was being fixed-up instead of just skip doing anything and return. Staring from now we ensure proper reaction for illicit user accesses. L2_S_PROT_R and L2_S_PROT_U names might be misleading as they do not reflect real permission levels. It will be clarified in following patches (switch to AP[2:1] permissions model). Obtained from: Semihalf |
| /freebsd-11.0-release/sys/i386/linux/ | ||
| H A D | syscalls.master | diff 31795 Wed Dec 17 03:12:35 MST 1997 kato I should not edit linux_prot.h directly. Fix the argument of linux_nice. Pointed out by: Eivind Eklund <eivind@FreeBSD.ORG> NOPROTO LINUX { int getpgrp(void); } 66 NOPROTO LINUX { int setsid(void); } 67 STD LINUX { int linux_sigaction(int sig, \ struct linux_sigaction *nsa, \ struct linux_sigaction *osa); } 68 STD LINUX { int linux_siggetmask(void); } 69 STD LINUX { int linux_sigsetmask(linux_sigset_t mask); } 70 NOPROTO LINUX { int setreuid(int ruid, int euid); } 71 NOPROTO LINUX { int setregid(int rgid, int egid); } 72 STD LINUX { int linux_sigsuspend(int restart, \ linux_sigset_t oldmask, linux_sigset_t mask); } 73 STD LINUX { int linux_sigpending(linux_sigset_t *mask); } 74 NOPROTO LINUX { int osethostname(char *hostname, \ u_int len);} 75 NOPROTO LINUX { int osetrlimit(u_int which, \ struct ogetrlimit *rlp); } 76 NOPROTO LINUX { int ogetrlimit(u_int which, \ struct ogetrlimit *rlp); } 77 NOPROTO LINUX { int getrusage(int who, struct rusage *rusage); } 78 NOPROTO LINUX { int gettimeofday(struct timeval *tp, \ struct timezone *tzp); } 79 NOPROTO LINUX { int settimeofday(struct timeval *tp, \ struct timezone *tzp); } 80 NOPROTO LINUX { int getgroups(u_int gidsetsize, gid_t *gidset); } 81 NOPROTO LINUX { int setgroups(u_int gidsetsize, gid_t *gidset); } 82 STD LINUX { int linux_select(struct linux_select_argv *ptr); } 83 STD LINUX { int linux_symlink(char *path, char *to); } 84 NOPROTO LINUX { int ostat(char *path, struct ostat *up); } 85 STD LINUX { int linux_readlink(char *name, char *buf, \ int count); } 86 STD LINUX { int linux_uselib(char *library); } 87 NOPROTO LINUX { int swapon(char *name); } 88 NOPROTO LINUX { int reboot(int opt); } 89 STD LINUX { int linux_readdir(int fd, struct linux_dirent *dent, \ unsigned int count); } 90 STD LINUX { int linux_mmap(struct linux_mmap_argv *ptr); } 91 NOPROTO LINUX { int munmap(caddr_t addr, int len); } 92 STD LINUX { int linux_truncate(char *path, long length); } 93 NOPROTO LINUX { int oftruncate(int fd, long length); } 94 NOPROTO LINUX { int fchmod(int fd, int mode); } 95 NOPROTO LINUX { int fchown(int fd, int uid, int gid); } 96 NOPROTO LINUX { int getpriority(int which, int who); } 97 NOPROTO LINUX { int setpriority(int which, int who, int prio); } 98 NOPROTO LINUX { int profil(caddr_t samples, u_int size, \ u_int offset, u_int scale); } 99 STD LINUX { int linux_statfs(char *path, \ struct linux_statfs_buf *buf); } 100 STD LINUX { int linux_fstatfs(int fd, \ struct linux_statfs_buf *buf); } 101 STD LINUX { int linux_ioperm(unsigned int lo, \ unsigned int hi, int val); } 102 STD LINUX { int linux_socketcall(int what, void *args); } 103 STD LINUX { int linux_ksyslog(int what); } 104 STD LINUX { int linux_setitimer(u_int which, \ struct itimerval *itv, struct itimerval *oitv); } 105 STD LINUX { int linux_getitimer(u_int which, \ struct itimerval *itv); } 106 STD LINUX { int linux_newstat(char *path, \ struct linux_newstat *buf); } 107 STD LINUX { int linux_newlstat(char *path, \ struct linux_newstat *buf); } 108 STD LINUX { int linux_newfstat(int fd, struct linux_newstat *buf); } 109 STD LINUX { int linux_uname(struct linux_old_utsname *up); } 110 STD LINUX { int linux_iopl(int level); } 111 STD LINUX { int linux_vhangup(void); } 112 STD LINUX { int linux_idle(void); } 113 STD LINUX { int linux_vm86(void); } 114 STD LINUX { int linux_wait4(int pid, int *status, \ int options, struct rusage *rusage); } 115 STD LINUX { int linux_swapoff(void); } 116 STD LINUX { int linux_sysinfo(void); } 117 STD LINUX { int linux_ipc(int what, int arg1, int arg2, int arg3, \ caddr_t ptr); } 118 NOPROTO LINUX { int fsync(int fd); } 119 STD LINUX { int linux_sigreturn(struct linux_sigcontext *scp); } access |
| /freebsd-11.0-release/sys/conf/ | ||
| H A D | kern.mk | diff 232473 Sat Mar 03 19:10:49 MST 2012 dim After r232322, it turned out many people (and some ports) are building kernel modules using their old installed /usr/share/mk/bsd.*.mk files, instead of the updated ones in their source tree. This leads to errors like: "sys/conf/kmod.mk", line 111: Malformed conditional (${MK_CLANG_IS_CC} == "no" && ${CC:T:Mclang} != "clang") Obviously, these errors will go away after a "make installworld", or alternatively, by using "make buildenv" before attempting to manually build modules. However, since it is apparently an expected use case to build using old .mk files, change the way we test for clang, so it also works when the MK_CLANG_IS_CC macro doesn't exist. Note the conditional expressions are becoming rather unreadable now, but I will attempt to fix that on a followup commit. MFC after: 2 weeks |
| H A D | kern.pre.mk | diff 232473 Sat Mar 03 19:10:49 MST 2012 dim After r232322, it turned out many people (and some ports) are building kernel modules using their old installed /usr/share/mk/bsd.*.mk files, instead of the updated ones in their source tree. This leads to errors like: "sys/conf/kmod.mk", line 111: Malformed conditional (${MK_CLANG_IS_CC} == "no" && ${CC:T:Mclang} != "clang") Obviously, these errors will go away after a "make installworld", or alternatively, by using "make buildenv" before attempting to manually build modules. However, since it is apparently an expected use case to build using old .mk files, change the way we test for clang, so it also works when the MK_CLANG_IS_CC macro doesn't exist. Note the conditional expressions are becoming rather unreadable now, but I will attempt to fix that on a followup commit. MFC after: 2 weeks |
| H A D | kmod.mk | diff 232473 Sat Mar 03 19:10:49 MST 2012 dim After r232322, it turned out many people (and some ports) are building kernel modules using their old installed /usr/share/mk/bsd.*.mk files, instead of the updated ones in their source tree. This leads to errors like: "sys/conf/kmod.mk", line 111: Malformed conditional (${MK_CLANG_IS_CC} == "no" && ${CC:T:Mclang} != "clang") Obviously, these errors will go away after a "make installworld", or alternatively, by using "make buildenv" before attempting to manually build modules. However, since it is apparently an expected use case to build using old .mk files, change the way we test for clang, so it also works when the MK_CLANG_IS_CC macro doesn't exist. Note the conditional expressions are becoming rather unreadable now, but I will attempt to fix that on a followup commit. MFC after: 2 weeks |
| /freebsd-11.0-release/share/mk/ | ||
| H A D | bsd.sys.mk | diff 232473 Sat Mar 03 19:10:49 MST 2012 dim After r232322, it turned out many people (and some ports) are building kernel modules using their old installed /usr/share/mk/bsd.*.mk files, instead of the updated ones in their source tree. This leads to errors like: "sys/conf/kmod.mk", line 111: Malformed conditional (${MK_CLANG_IS_CC} == "no" && ${CC:T:Mclang} != "clang") Obviously, these errors will go away after a "make installworld", or alternatively, by using "make buildenv" before attempting to manually build modules. However, since it is apparently an expected use case to build using old .mk files, change the way we test for clang, so it also works when the MK_CLANG_IS_CC macro doesn't exist. Note the conditional expressions are becoming rather unreadable now, but I will attempt to fix that on a followup commit. MFC after: 2 weeks |
| /freebsd-11.0-release/sys/kern/ | ||
| H A D | kern_sig.c | diff 172995 Fri Oct 26 01:23:07 MDT 2007 csjp Implement AUE_CORE, which adds process core dump support into the kernel. This change introduces audit_proc_coredump() which is called by coredump(9) to create an audit record for the coredump event. When a process dumps a core, it could be security relevant. It could be an indicator that a stack within the process has been overflowed with an incorrectly constructed malicious payload or a number of other events. The record that is generated looks like this: header,111,10,process dumped core,0,Thu Oct 25 19:36:29 2007, + 179 msec argument,0,0xb,signal path,/usr/home/csjp/test.core subject,csjp,csjp,staff,csjp,staff,1101,1095,50457,10.37.129.2 return,success,1 trailer,111 - We allocate a completely new record to make sure we arent clobbering the audit data associated with the syscall that produced the core (assuming the core is being generated in response to SIGABRT and not an invalid memory access). - Shuffle around expand_name() so we can use the coredump name at the very beginning of the coredump call. Make sure we free the storage referenced by "name" if we need to bail out early. - Audit both successful and failed coredump creation efforts Obtained from: TrustedBSD Project Reviewed by: rwatson MFC after: 1 month diff 172995 Fri Oct 26 01:23:07 MDT 2007 csjp Implement AUE_CORE, which adds process core dump support into the kernel. This change introduces audit_proc_coredump() which is called by coredump(9) to create an audit record for the coredump event. When a process dumps a core, it could be security relevant. It could be an indicator that a stack within the process has been overflowed with an incorrectly constructed malicious payload or a number of other events. The record that is generated looks like this: header,111,10,process dumped core,0,Thu Oct 25 19:36:29 2007, + 179 msec argument,0,0xb,signal path,/usr/home/csjp/test.core subject,csjp,csjp,staff,csjp,staff,1101,1095,50457,10.37.129.2 return,success,1 trailer,111 - We allocate a completely new record to make sure we arent clobbering the audit data associated with the syscall that produced the core (assuming the core is being generated in response to SIGABRT and not an invalid memory access). - Shuffle around expand_name() so we can use the coredump name at the very beginning of the coredump call. Make sure we free the storage referenced by "name" if we need to bail out early. - Audit both successful and failed coredump creation efforts Obtained from: TrustedBSD Project Reviewed by: rwatson MFC after: 1 month |
| /freebsd-11.0-release/sys/dev/usb/ | ||
| H A D | usbdevs | diff 179773 Fri Jun 13 02:07:58 MDT 2008 kevlo Add the D-Link DWA-111 |
Completed in 524 milliseconds