I recently read an article from facebook on password cracking. It got
me thinking about how useful dedicated hardware might be for hashing
passwords.
Source:
http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/
Fairly basic stuff (MD5, brute
On 8/7/2013 2:09 AM, Stuart Henderson wrote:
Normally port-restricted cone, or with static-port it's similar to symmetric
(but obviously static-port can't work when two internal machines use
the same port).
With increasing use of cgnat in some large service provider networks you can
be sure to
I'm dealing with old software that uses old NAT traversal techniques. I
specifically need to select the NAT variation as defined by RFC 3489
(section 5).
Generally I've used nat-to's 'static-port' option and gotten around this
issue. After adding some clients host-side, it seems like NAT
I've always taken for granted the compiler I used -- until I read this
thread. I've used buggy compilers before, such as fxc. I was even
greatly affected by a bug in gcc and Apple. Although it caused me to
contentedly switch to Microsoft, I still did not acknowledge my
compiler's
I have a disk -- IIRC, Seagate Barracuda 160gb 7200RPM 8MB Cache SATA
3.0GB/s
dmesg:
wd0 at pciide0 channel 0 drive 0: ST3160811AS
wd0: 16-sector PIO, LBA48, 152626MB, 312579695 sectors
wd0 (pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6
However, when I run `dd if=/dev/zero of=/dev/wd0c
port 0xf0/16: reported by CPUID; using exception 16
mtrr: Pentium Pro MTRR support
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on wd1a (b3cecc3a21d4131c.a) swap on wd1b dump on wd1b
On 7/12/2013 3:50 PM, Nathan Goings wrote:
I have a disk
On 7/12/2013 5:12 PM, Alexander Hall wrote:
use the raw device, /dev/rwd0c, not the block device.
Tried: dd if=/dev/zero of=/dev/rwd0c bs=64k
It runs at ~72MB/s.
Thanks!
I just setup NFS, and have gotten it working with my Windows 7 machine.
Basically, I'm working on a driver and want to use a graphical IDE.
/etc/exports:
#
/usr -maproot=root -alldirs -network=192.168.37 -mask=255.255.255.0
/usr/src -maproot=root -alldirs -network=192.168.37
On 7/5/2013 7:33 PM, Andres Perera wrote:
you want nested nfs mounts which nfsv3/2 can't provide
the export is associated to the mount point, it won't cross device limits
either put /usr/src in the same file system, or use another nfs host
Thanks! I think for now, I'll just export
On 7/5/2013 8:50 PM, Andres Perera wrote:
so yes that indeed seems like crazy things in windows
The documentation says to send a HUP signal to mountd to reload the
changes in /etc/exports. However, after making changes, I am still able
to mount *and* open files from entries I removed in
On 7/4/2013 10:27 AM, Remco wrote:
On Wednesday 03 July 2013 19:11:19 Nathan Goings wrote:
...
I would think if the attach failed it would be in /var/log/messages.
How would I debug this? If the attach is failing, I might try crafting
it to use a different driver. (guess I should try printf
On 7/4/2013 10:27 AM, Remco wrote:
It has an AUTOCONF_VERBOSE define that can be used to get more verbose output,
though I don't remember how useful it is.
Looking at config(8), I think you should be able to set it in your copy of the
GENERIC file as:
option AUTOCONF_VERBOSE=1
ugh, I enabled
Thanks for your response!
On 7/3/2013 1:07 AM, Remco wrote:
AFAIK this is step one. Assuming you added the PCI IDs correctly, the driver's
attach function should run. However, to the best of my understanding, you
chose a more or less random attach function for your unsupported device.
My guess
I purchased an Edimax EW-7128Gn that contains a ralink RT3060 chip and
it's unrecognized.
dmesg:
vendor Ralink, unknown product 0x3060 (class network subclass
miscellaneous, rev 0x00) at pci4 dev 0 function 0 not configured
The documentation says a/g/n but this is a b/g/n. Ralink's drivers
14 matches
Mail list logo
