Clifton Royston wrote:
For those who don't know what I'm talking about, try executing host
thisdomainhasneverexistedandneverwill.com, or any other domain you'd
care to make up in .com or .net. Verisign has abused the trust placed
in them to operate a root name server, by creating wildcard A
[EMAIL PROTECTED] wrote:
sendto in send_tcp_raw: sendto(3, packet, 40, 0, X.X.X.X, 16) = No buffer
space available
Your interface is down. This happens all the time.
If you use PPP on a dialup modem with a normal net connection,
and unplug the modem while you are doing a ping, you will see
Mike Durian wrote:
I'm trying to implement a serial protocol that is timing sensitive.
I'm noticing things like drains and reads and blocking until the
next kernel tick. I believe this is due to the lbolt sleeps
in the tty.c code.
It looks like I can avoid these sleeps if isbackground()
Hello hackers.
I recently examined rijndael implementation, which ships in sys/crypto/rijndael and
there
is code in function rijndael_padEncrypt()(from rijndael-api-fst.c):
numBlocks = inputOctets/16;
...
...
padLen = 16 - (inputOctets - 16*numBlocks);
if (padLen 0 padLen = 16)
lg wrote:
Hello hackers.
I recently examined rijndael implementation, which ships in sys/crypto/rijndael and
there
is code in function rijndael_padEncrypt()(from rijndael-api-fst.c):
numBlocks = inputOctets/16;
...
...
padLen = 16 - (inputOctets - 16*numBlocks);
if (padLen 0 padLen = 16)
Hi,
On Wed, 17 Sep 2003 11:25:44 +0400 (MSD)
[EMAIL PROTECTED] (lg) said:
zevlg I recently examined rijndael implementation, which ships in sys/crypto/rijndael
and there
zevlg is code in function rijndael_padEncrypt()(from rijndael-api-fst.c):
zevlg numBlocks = inputOctets/16;
zevlg ...
Hajimu UMEMOTO wrote:
Hi,
On Wed, 17 Sep 2003 11:25:44 +0400 (MSD)
[EMAIL PROTECTED] (lg) said:
zevlg I recently examined rijndael implementation, which ships in sys/crypto/rijndael
and there
zevlg is code in function rijndael_padEncrypt()(from rijndael-api-fst.c):
zevlg numBlocks =
Lev Walkin wrote:
Absolutely NOT.
According to RFC1423 and FIPS81, the padding length may be somewhere
in between 1 to 16 bytes, which translated into
if(padLen 0 || padLen = 16)
for this particular code.
Sorry, ignore this comment.
--
Lev Walkin
[EMAIL PROTECTED]
Hi terry,
i can corroborate this problem, with 4.x AND 5.x, without beeing the network
interface down. We are also using a pppoe link outsides, and i can do a ping
in parallel, which is working continously, so the tun0 stays online.
My theorie is, that he keeps the sockets open in state
Hi,
On Wed, 17 Sep 2003 01:09:24 -0700
[EMAIL PROTECTED] (Lev Walkin) said:
I saw it during working on next KAME merge into 5-CURRENT.
KAME/NetBSD uses assert() here like:
assert(padLen 0 padLen = 16);
Since FreeBSD doesn't have assert() in kernel, this line was changed
to:
Hajimu UMEMOTO wrote:
Hi,
On Wed, 17 Sep 2003 01:09:24 -0700
[EMAIL PROTECTED] (Lev Walkin) said:
I saw it during working on next KAME merge into 5-CURRENT.
KAME/NetBSD uses assert() here like:
assert(padLen 0 padLen = 16);
Since FreeBSD doesn't have assert() in kernel, this line was
vlm Absolutely NOT.
vlm According to RFC1423 and FIPS81, the padding length may be somewhere
vlm in between 1 to 16 bytes, which translated into
vlm if(padLen 0 || padLen = 16)
vlm for this particular code.
Ah, yes. Then, `assert(padLen 0 padLen = 16)'; should be wrong.
The thing
On Tue, 16 Sep 2003, M. Warner Losh wrote:
I think we should put a filter for this nonsense into the base
system.
ISC is in the process of releasing patched versions of BIND, which I
plan to take advantage of. :)
Doug
--
This .signature sanitized for your protection
I tried with a ping in parallel to the nmaped machine and the same error
message happens.
ppp bug ?
pppoe bug ?
Hi terry,
i can corroborate this problem, with 4.x AND 5.x, without beeing the
network interface down. We are also using a pppoe link outsides, and i
can do a ping in parallel,
On Tue, Sep 16, 2003 at 10:23:56AM -1000, Clifton Royston wrote:
In the meantime I'm trying to figure out if there's some simple hack
to disregard these wildcard A records, short of requesting zone
transfers of the root nameservers (e.g. via peering with
f.root-servers.net) and purging
Doug Barton wrote:
ISC is in the process of releasing patched versions of BIND, which I
plan to take advantage of. :)
Doug
Patch to port dns/bind9 to upgrade bind9 to 9.2.2-P1:
http://www.isc.org/products/BIND/delegation-only.html
--- bind9.patch begins here ---
diff -u Makefile.orig Makefile
---
On 16 Sep 2003 at 20:49, Daniel Eischen wrote:
On Tue, 16 Sep 2003, Dan Langille wrote:
I've had preliminary success with this patch. More testing needs
to be done, but in the meantime, I would appreciate reviews and
comments. The patched code is available from
Hi,
attached is a patch that tries to keep track of the major numbers that
were assigned automatically by make_dev() if you use MAJOR_AUTO.
The number of times make_dev() was called with this major number is
stored in the reserved_majors_refcnt array, the entry is decreased again
if you call
Hi,
I did a quick port of the Annex management suite to FreeBSD today,
incorporating Chuck Cranor's patches for NetBSD.
I've put a sharball at http://people.freebsd.org/~bms/annextools.shar.
Let me know what you think.
BMS
___
[EMAIL PROTECTED]
On Wednesday 17 September 2003 12:55 am, Terry Lambert wrote:
You need your process to become a process group leader, and then
you need the serial port you are interested in to become the
controlling tty for your process.
I thought daemon(3) and TIOCSCTTY would do the trick, however
after a
--- xxx.pkg_vulnerabilities begins here ---
#!/bin/sh -
#
# Usage:
# ./xxx.pkg_vulnerabilities
#
PKG_INFO=/usr/local/sbin/pkg_info
export PKG_INFO
if [ ! -x ${PKG_INFO} ]; then
echo ${PKG_INFO} missing, please install port sysutils/pkg_install
exit 1
fi
if [ `${PKG_INFO} -qP` -lt 20030917 ]; then
echo
Hi Jacques
I want to port NetBSD's security/audit-packages to FreeBSD. The system is
described in:
http://www.netbsd.org/Documentation/pkgsrc/features.html#id2980060
FYI, I'm working on something similar but different ;-) It should see
the light of day before the end of this month. Normally I
I was toying with a programmable PCI card and wrote some code
which DMAs a small block of data to the host, and then interrupts the
host. The host checks the end of the block, and sees if it gets the
value it expects.
On an SMP P4 (hyperthreaded, with ServerWorks chipset) FreeBSD 4.8 UP,
Is there a utility/hack/patch that would allow a diligent sysadmin to obtain
which specific TCP connections are generating retransmits and receiving
packet drops? netstat will show me drops on an interface, but not on a
specific source/dest pair?
I am guessing something like a netstat -n, but
We seem to have an issue where traffic going over an IPSEC
tunnel is getting tunneled, before it hits our NAT process...
For example.
Node A, running NAT on its external interface sis0 which has an IP of 10.177.1.1
has an interface sis1 which is its internal interface with an IP of
At 20:34 17/09/2003 -0400, Deepak Jain wrote:
Is there a utility/hack/patch that would allow a diligent sysadmin to obtain
which specific TCP connections are generating retransmits and receiving
packet drops? netstat will show me drops on an interface, but not on a
specific source/dest pair?
If
[Ooops, looks like I sent out two mails to this list with the wrong
address, so most of your anti-spam filters probably bitbucketed them
where they belong. Fixed, I hope, with an IPv6-only address. But
just reply to the list and drop me, I'll catch up from the archives... ]
Terry Lambert
27 matches
Mail list logo
