On Tue, 21 Jan 2003, Jacques A. Vidrine wrote:
> Long, lng ago, someone reported a dc driver bug. However,
> a couple of us have tried and failed to reproduce the problem. I
> thought I'd bounce the issue here before completely forgetting about
> it.
I'm not seeing it on 4.5. MBUF exha
Hi ran this again with larger values, still no problem. Tried a variety of
tests, pining an interface on the DC card, pinging through the BSD box as a
gateway.
all seems fine (well on 4.3) .
To the original reporters, any chances of a dmesg output for the chipsets
that are given to exhibiting th
we have an ipsec tunnel where one endpoint is a ravlin, the other endpoint
is FreeBSD/KAME. Its extremely stable except for this one thing...
if you scp a file of about 3M, it hangs at between 400-600k.
and it breaks the entire tunnel.
I don;t really have much more clues, nothing in the logs or
Crist J. Clark wrote:
I'm running RELENG_4_5. Could revision 1.214 to ip_input.c have
something to do with this?
That is definitely a possibility. I didn't see this behaviour
on my kernel build from Oct 11 sources, but I do see it on later
ones. However, there was a long time after Oct 11 bef
On Tue, Jan 21, 2003 at 03:16:28PM +0200, Pekka Nikander wrote:
> Crist,
>
> Crist J. Clark wrote:
> >I don't see this. I have one rule on my external interface,
> >
> > block in log quick on de0 all head 2000
> >...
> >pass in quick proto esp from any to 12
On Tue, Jan 21, 2003 at 08:50:03AM -0700, Mike Durian wrote:
> On Monday 20 January 2003 11:34 pm, Crist J. Clark wrote:
> >
> > I don't see this. I have one rule on my external interface,
> >
> > block in log quick on de0 all head 2000
> > ...
> > pass in q
First of all, I hope that this isn't something obvious that I've
missed. I've searched everything I can think of, but have come up
empty so far. Maybe somebody here will be able to help. If this is
the wrong mailing list, sorry, and please let me know which one I
should post to.
I am trying to ge
On Tue, 21 Jan 2003, Jacques A. Vidrine wrote:
> Long, lng ago, someone reported a dc driver bug. However,
> a couple of us have tried and failed to reproduce the problem. I
> thought I'd bounce the issue here before completely forgetting about
> it.
>
> Cheers,
> --
> Jacques A. Vidrin
On Tuesday 21 January 2003 06:08 am, Pekka Nikander wrote:
>
> then the IPsec code *requires* than any received packet
> that has a source address within 192.168.2.0/24 was
> indeed protected by the specified tunnel, and if it wasn't,
> it drops the packet.
That's good news. I'll feel better abou
On Monday 20 January 2003 11:34 pm, Crist J. Clark wrote:
>
> I don't see this. I have one rule on my external interface,
>
> block in log quick on de0 all head 2000
> ...
> pass in quick proto esp from any to 12.234.89.252/32
> group 2000
First
Hi All,
For what it is worth, I just tried it on a 4.3 box running the DLINK 570TX
quad port cards
>From linux box
[root@web1 labsadmin]# ping -s 5000 victim
PING victim (10.10.10.1 ) from 192.168.7.7 : 5000(5028) bytes of data.
5008 bytes from devco.net (196.15.188.2): icmp_seq=0 ttl=255 time=2
Long, lng ago, someone reported a dc driver bug. However,
a couple of us have tried and failed to reproduce the problem. I
thought I'd bounce the issue here before completely forgetting about
it.
Cheers,
--
Jacques A. Vidrine <[EMAIL PROTECTED]> http://www.celabo.org/
NTT/Verio
Crist,
Crist J. Clark wrote:
I don't see this. I have one rule on my external interface,
block in log quick on de0 all head 2000
...
pass in quick proto esp from any to 12.234.89.252/32 group 2000
That allows in ESP traffic from any host. No
Mike Durian wrote:
I was looking through the FreeBSD mailing list archives trying to figure
out why ipfilter is filtering on both encapsulated ESP packets and the
decrypted packets (NetBSD says it should only filter on the line packets),
when I saw a relevent posting. It looks like other people a
14 matches
Mail list logo
