Kage wrote:
Well, no, see it's hitting natd just fine as shown by my natd verbose
logs, if you're assuming ipfw is blocking me from reaching natd. Are
you talking about adding a firewall rule for each of my round-robin
addresses, too?
Yes
How would that do any good?
All response paquet to
Synopsis: [ral] Lock order reversal in ral0 at bootup (regression)
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: remko
Responsible-Changed-When: Mon Mar 24 11:01:07 UTC 2008
Responsible-Changed-Why:
Send to -net team, this is a nic.
http://www.freebsd.org/cgi/que
Current FreeBSD problem reports
Critical problems
Serious problems
S Tracker Resp. Description
o kern/35442 net[sis] [patch] Problem transmitting runts in if_sis dri
a kern/38554 netchang
On Wed, 1 Aug 2007, blue wrote:
Hi,
Dear all:
I do not know the purpose of the following codes in the very beginning in
ip6_input():
#ifdef IPSEC
/*
* should the inner packet be considered authentic?
* see comment in ah4_input().
*/
if (m) {
m->m_flags &= ~M_AUTHIPHDR;
Sorry, maybe my words make you confused.
What I meant is "AH tunnel" only, and the code base is FAST_IPSEC, which
is currently IPSEC in FreeBSD-7.0.
BR,
Yi-Wen
Bjoern A. Zeeb wrote:
On Wed, 1 Aug 2007, blue wrote:
Hi,
Dear all:
I do not know the purpose of the following codes in the ve
On Mon, 24 Mar 2008, Christian S.J. Peron wrote:
I just want everyone to know that I have completed the zerocopy bpf commit.
Please be on the "lookout" for any strange bpf related issues.
For people that want to test the new zerocopy bpf implementation, a patch
can be found here:
http://peo
I just want everyone to know that I have completed the zerocopy bpf
commit. Please be on the "lookout" for any strange bpf related issues.
For people that want to test the new zerocopy bpf implementation, a
patch can be found here:
http://people.freebsd.org/~csjp/pcap.1206364304.diff
Any comme
Pardon the basic question, but is the current patchset "zero copy" or
"one copy"? The paper I saw a link to described a mechanism to eliminate
one of the two copies the traditional bpf approach makes but I haven't
taken a look into the actual code.
Pete
_
On Mon, 24 Mar 2008, Petri Helenius wrote:
Pardon the basic question, but is the current patchset "zero copy" or "one
copy"? The paper I saw a link to described a mechanism to eliminate one of
the two copies the traditional bpf approach makes but I haven't taken a look
into the actual code.
Still not working, but I DO have natd aliasing properly. Here's my
natd output (remember which IP is mine, the IRC jail, and the example
round-robin IP):
[EMAIL PROTECTED] /etc]# natd -f /etc/natd.conf
In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased to
[TCP] 7
On Thu, Mar 20, 2008 at 2:03 AM, Vadim Goncharov <[EMAIL PROTECTED]> wrote:
> This is behaviour of ipfw2 - options are independently ANDed. Thus, man page
> explicitly says:
>
> established
> Matches TCP packets that have the RST or ACK bits set.
>
> So, it is obvious that udp
On Mon, 24 Mar 2008, blue wrote:
Hi,
Sorry, maybe my words make you confused.
What I meant is "AH tunnel" only, and the code base is FAST_IPSEC, which is
currently IPSEC in FreeBSD-7.0.
thanks for the clarification. Can you open a PR with all this
information so a) it woon't be lost and b)
The following reply was made to PR kern/116077; it has been noted by GNATS.
From: Norbert Papke <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc:
Subject: Re: kern/116077: 6.2-STABLE panic during use of multi-cast networking
client
Date: Mon, 24 Mar 2008 10:29:51 -0700
I have a
Stephan,
I tried to use your example, but the packet is replying to wrong
interface Do you think that it's a bug?
Best regards,
Wesley
On Thu, Mar 20, 2008 at 9:57 AM, Stefan Lambrev <
[EMAIL PROTECTED]> wrote:
> Greetings,
>
>
> Wesley wrote:
> > Dear people,
> >
> > I have 2 links on a
Robert Jenssen wrote:
Hi,
Since upgrading to FreeBSD 7 I have been experiencing some frustrating
problems with my RAL wifi card. In particular, it seems to me that dhclient
fails when the ral device driver times out while scanning for my access
point. At the same time my HP PDA with Spectec W
Kage wrote:
Still not working, but I DO have natd aliasing properly. Here's my
natd output (remember which IP is mine, the IRC jail, and the example
round-robin IP):
[EMAIL PROTECTED] /etc]# natd -f /etc/natd.conf
In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased to
I changed my rules, and it's still not working:
$IPF 50220 divert natd all from 72.20.28.202 6667 to any via rl0
$IPF 50221 divert natd all from any to 207.210.114.45 6667 via rl0
It's still timing connections out.
On Mon, Mar 24, 2008 at 4:24 PM, Henri Hennebert <[EMAIL PROTECTED]> wrote:
> Kag
Old Synopsis: Panic on em1: taskq
New Synopsis: [em] [panic] Panic on em1: taskq
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Tue Mar 25 06:16:30 UTC 2008
Responsible-Changed-Why:
Over to maintainer(s).
http://www.freebsd.org/cg
18 matches
Mail list logo
