ause I am interested in your comments on how this
can be fixed properly looking forward. The whole range of suggestions;
from 'don't compile with EM_MULTIQUEUE defined' to 'here is how you can
make ALTQ use drbr' will help.
Thanks you,
Karim.
___
On 12-11-12 03:27 PM, Andre Oppermann wrote:
On 12.11.2012 20:15, Karim wrote:
Hi all,
I have been following the current discussions on igb tx/rx locking
with great interest and I though
I would point out (as it was before pointed out in kern/138392) that
any driver setting if_start to
NULL
lter is seeing large block of data to be
segmented by your network interface.
I hope this helps,
Karim.
I've tried with as many hardware options disabled as I could find, but
no change
-tso -rxcsum -txcsum -lro -vlanhwtag
net.inet.tcp.tso=0
dev.igb.0.enable_aim=0
dev.igb.0.flow_control
y on a 7.4 system this was happening every 10 min. Using a
driver from FBSD9 back ported to 7.4 we see the issue at a much lower
frequency (every 30 min) but the issue is still there.
Cheers,
Karim.
___
freebsd-net@freebsd.org mailing
On 11-10-11 01:31 PM, Kevin Oberman wrote:
On Tue, Oct 11, 2011 at 10:10 AM, YongHyeon PYUN wrote:
On Tue, Oct 11, 2011 at 11:40:42AM -0400, Karim wrote:
Hi List,
Using a Marvell NIC plugged into a CISCO switch I see the
auto-negotiation failing and even when forcing the device to full
On 11-10-12 11:08 AM, Arnaud Lacombe wrote:
Hi,
On Wed, Oct 12, 2011 at 10:07 AM, Karim wrote:
[...]
Hi,
Thanks for the feedback and detailed information.
I have to clarify here; I get the issue even with forcing full duplex.
The driver modifications are minor and shouldn't affect
On 11-10-12 11:15 AM, Karim wrote:
On 11-10-12 11:08 AM, Arnaud Lacombe wrote:
Hi,
On Wed, Oct 12, 2011 at 10:07 AM, Karim
wrote:
[...]
Hi,
Thanks for the feedback and detailed information.
I have to clarify here; I get the issue even with forcing full duplex.
The driver modifications
Hi,
On 11-10-12 01:03 PM, YongHyeon PYUN wrote:
On Wed, Oct 12, 2011 at 10:07:02AM -0400, Karim wrote:
On 11-10-11 01:31 PM, Kevin Oberman wrote:
On Tue, Oct 11, 2011 at 10:10 AM, YongHyeon PYUN wrote:
On Tue, Oct 11, 2011 at 11:40:42AM -0400, Karim wrote:
Hi List,
Using a Marvell NIC
On 11-10-12 03:27 PM, YongHyeon PYUN wrote:
On Wed, Oct 12, 2011 at 02:35:23PM -0400, Karim wrote:
Hi,
On 11-10-12 01:03 PM, YongHyeon PYUN wrote:
On Wed, Oct 12, 2011 at 10:07:02AM -0400, Karim wrote:
[...]
Hmm, that indicates driver lost established link. msk(4) will
detect this condition
Hi,
On 11-10-12 03:27 PM, YongHyeon PYUN wrote:
On Wed, Oct 12, 2011 at 02:35:23PM -0400, Karim wrote:
Hi,
On 11-10-12 01:03 PM, YongHyeon PYUN wrote:
On Wed, Oct 12, 2011 at 10:07:02AM -0400, Karim wrote:
[...]
Hmm, that indicates driver lost established link. msk(4) will
detect this
ll I'm sure you
remember that, because O_LOG is inserted _before_ O_TAG and that O_LOG
doesn't have the F_NOT bit set then match is still 1 at the end of the
loop and the actual cmd (LOG in this case) will have a chance to execute.
Finally, if your still reading, I think this bug has b
line assembly of the in_cksum_hdr
function for 64bit? Should in_cksum_hdr() in amd64 changed to deal with
misaligned addresses? Other solutions?
Thanks,
Karim.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
On 01/02/2013 9:53 AM, Karim Fodil-Lemelin wrote:
Hi -net,
Sorry for the lengthy email.
TLDR: If the IP header is not aligned on an even address then the
amd64 version of in_cksum_hdr() will not work while the i386 version
of it will.
I came across this problem while working on custom
consisted in keeping igb_start() defined and using
igb_mq_start_locked() inside it instead of igb_start_locked().
Regards,
Karim.
On 28/03/2013 7:16 PM, Jack Vogel wrote:
Have been kept fairly busy with other matters, one thing I could do short
term is
change the defines in igb the way I did in the
Hi Nick,
Can you verify that you have at least one of those options in your
kernel config file:
ALTQ_CBQ
ALTQ_PRIQ
ALTQ_HFSC
Regards,
Karim.
On 01/04/2013 8:22 PM, Nick Rogers wrote:
On Mon, Apr 1, 2013 at 8:44 AM, Karim Fodil-Lemelin
wrote:
Hi Jack,
I think this would help M. Rogers
IFQ_SET_READY(&ifp->if_snd);
The call to IFQ_SET_READY() is what will enable ALTQ on your device.
Regards,
Karim.
On 02/04/2013 9:58 AM, Nick Rogers wrote:
On Tuesday, April 2, 2013, Karim Fodil-Lemelin wrote:
Hi Nick,
Can you verify that you have at least one of those options
_tx_desc - 1);
ifp->if_snd.ifq_drv_maxlen = adapter->num_tx_desc - 1;
IFQ_SET_READY(&ifp->if_snd);
-#endif
ether_ifattach(ifp, adapter->hw.mac.addr);
On 02/04/2013 9:58 AM, Nick Rogers wrote:
On Tuesday, April 2, 2013, Karim Fodil-Lemelin wrote:
Hi Nick,
Can
Hi Nick,
Thanks for the testing, I am glad I could help. Please note that by setting:
static int igb_num_queues = 1;
You are effectively only using 1 TX queue from the hardware (instead of
4 or 8) so this might not be applicable to a generic kernel without ALTQ.
Best regards,
Karim.
On 02
eebsd-net-unsubscr...@freebsd.org"
Hi,
Those modifications require that you define IGB_LEGACY_TX in the driver
code to get ALTQ running on igb.
Regards,
Karim.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/fre
eturn (ENOMEM);
- item->el_flags |= NGQF_WRITER;
+ item->el_flags = NGQF_READER;
NG_NODE_REF(node); /* and one for the item */
NGI_SET_NODE(item, node);
if (hook) {
Best regards,
Karim.
___
DER;
+
NG_NODE_REF(node); /* and one for the item */
NGI_SET_NODE(item, node);
if (hook) {
Regards,
Karim.
On 09/04/2014 3:16 PM, Karim Fodil-Lemelin wrote:
Hi List,
I'm calling out to the general wisdom ... I have seen an issue in
netgraph where, if called, a callout rout
Hi,
By the way this change has opened the gates to greater performance for
us when using ng_callout() inside nodes. In some cases we see twice as
much pps since packets are direct dispatched instead of being queued in
software interrupts threads (swi*).
Thanks,
Karim
PS: I did file a PR
a timer event (ng_callout) can execute
asynchronously, but I digress.
Regards,
Karim.
On 11/04/2014 2:59 PM, Julian Elischer wrote:
disclaimer: I'm not looking at the code now.. I want to go to bed: :-)
When I wrote that code, the idea was that even a direct node execution
should becom
est regards,
Karim.
diff --git a/sys/dev/e1000/if_igb.c b/sys/dev/e1000/if_igb.c
index 1318910..be1719a 100644
--- a/sys/dev/e1000/if_igb.c
+++ b/sys/dev/e1000/if_igb.c
@@ -961,15 +961,7 @@ igb_mq_start(struct ifnet *ifp, struct mbuf *m)
que = &adapter->queues[i];
if ((
Gleb,
On 20/11/2012 6:18 AM, Gleb Smirnoff wrote:
Karim,
On Mon, Nov 19, 2012 at 02:57:24PM -0500, Karim Fodil-Lemelin wrote:
K> While testing the latest igb driver in CURRENT I came across an issue
K> with igb_mq_start(). More specifically this code:
K>
K> ...
K>
K>
ten
J> it committed yet.
Since ixgbe work is performance tuning and this patch closes a kernel crash,
I'd ask to preempt the ixgbe job with this patch. :)
Or you can approve my patch and I will check it in.
What about protecting the em driver from the same out
Hi,
On 04/12/2012 3:02 PM, Andre Oppermann wrote:
On 04.12.2012 20:34, Adrian Chadd wrote:
.. and it's important to note that buf_ring itself doesn't have the
race condition; it's the general driver implementation that's racy.
I have the same races in ath(4) with the watchdog programming. Exac
Hi,
On 04/12/2012 3:02 PM, Andre Oppermann wrote:
On 04.12.2012 20:34, Adrian Chadd wrote:
.. and it's important to note that buf_ring itself doesn't have the
race condition; it's the general driver implementation that's racy.
I have the same races in ath(4) with the watchdog programming. Exac
tion on ALTQ discussion
and igb please read this thread:
http://freebsd.1045724.n5.nabble.com/em-igb-if-transmit-drbr-and-ALTQ-td5760338.html
Best regards,
Karim.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
On 11/12/2012 11:27 AM, Ermal Luçi wrote:
On Tue, Dec 11, 2012 at 3:56 PM, Karim Fodil-Lemelin <
fodillemlinka...@gmail.com> wrote:
On 11/12/2012 9:15 AM, Ermal Luçi wrote:
On Tue, Dec 11, 2012 at 2:05 PM, Barney Cordoba
**wrote:
--- On Tue, 12/11/12, Gleb Smirnoff wrote:
From
On 11/12/2012 1:03 PM, Adrian Chadd wrote:
The if_transmit versus multiqueue thing is orthogonal.
Indeed, although ALTQ isn't using if_transmit and doing a simple drop in
(replacing if_start with if_transmit) breaks ALTQ with multiqueue
capable drivers.
I'm planning to make net80211 and ath(4
On 12/12/2012 2:49 AM, Ermal Luçi wrote:
On Tue, Dec 11, 2012 at 9:06 PM, Karim Fodil-Lemelin <
fodillemlinka...@gmail.com> wrote:
On 11/12/2012 11:27 AM, Ermal Luçi wrote:
On Tue, Dec 11, 2012 at 3:56 PM, Karim Fodil-Lemelin <
fodillemlinka...@gmail.com> wrote:
On 11/12/
istening socket into a full blown accepted socket,
including creating its associated control block in the process.
By the way I don't think V_tcbinfo lock is held for syncache_chkrst() or
needed for that matter but I could be wrong since I'm looking at 7.x code.
Karim.
__
the locking of the
new one.
Karim.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
tely get rid of the lock all
together?
Karim.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
essly on that chip. This patch helps support that old chip.
I hope this helps someone,
Karim.
PS: The patch line numbers are against 'CURRENT' r214406 but should also
apply to FBSD 7 and 8.
___
freebsd-net@freebsd.org mailing list
http://l
he code in "igb_refresh_mbufs()" does not handle well running out
of mbufs but that is how far we can get at the moment. We are seeking your
help and wisdom, and are willing to test patches or suggested settings.
Thanks in advance,
Karim.
___
freebsd-net
apologies if this gets in twice.
-- Forwarded message --
From: Karim Fodil-Lemelin
Date: 2011/2/7
Subject: Re: igb driver tx hangs when out of mbuf clusters
To: Lev Serebryakov
Cc: freebsd-net@freebsd.org
2011/2/7 Lev Serebryakov
Hello, Karim.
> You wrote 7 февраля 201
Subject: Re: igb driver tx hangs when out of mbuf clusters
> To: Lev Serebryakov
> Cc: freebsd-net@freebsd.org
>
>
> 2011/2/7 Lev Serebryakov
>
> Hello, Karim.
>> You wrote 7 февраля 2011 г., 19:58:04:
>>
>>
>> > The issue is with the igb dr
2011/2/7 Pyun YongHyeon
> On Mon, Feb 07, 2011 at 05:33:47PM -0500, Karim Fodil-Lemelin wrote:
> > Subject: Re: igb driver tx hangs when out of mbuf clusters
> >
> > > To: Lev Serebryakov
> > > Cc: freebsd-net@freebsd.org
> > >
> > >
>
2011/2/7 Pyun YongHyeon
> On Mon, Feb 07, 2011 at 09:21:45PM -0500, Karim Fodil-Lemelin wrote:
> > 2011/2/7 Pyun YongHyeon
> >
> > > On Mon, Feb 07, 2011 at 05:33:47PM -0500, Karim Fodil-Lemelin wrote:
> > > > Subject: Re: igb driver tx hangs when out of mbu
> 2011/2/8 Michael Tüxen
>
>> On Feb 8, 2011, at 4:29 AM, Karim Fodil-Lemelin wrote:
>>
>> > 2011/2/7 Pyun YongHyeon
>> >
>> >> On Mon, Feb 07, 2011 at 09:21:45PM -0500, Karim Fodil-Lemelin wrote:
>> >>> 2011/2/7 Pyun YongHyeon
)
0/4/6656 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routines
# dmesg | grep commit
At this point RX has hung.
Somehow the check (i == rxr->next_to_refresh) is never true
Hi,
I see a commit was made in current (r218530 | jfv | 2011-02-10 20:00:26
-0500 (Thu, 10 Feb 2011)). Is that commit done to address this issue?
And if so Is there any MFC planned for 7.4 for this?
Thanks,
Karim.
2011/2/9 Michael Tuexen
> On Feb 9, 2011, at 6:35 PM, Jack Vogel wr
7 for you asap.
>
> Jack
>
>
>
> On Fri, Feb 11, 2011 at 11:53 AM, Karim Fodil-Lemelin <
> fodillemlinka...@gmail.com> wrote:
>
>> Hi,
>>
>> I see a commit was made in current (r218530 | jfv | 2011-02-10 20:00:26
>> -0500 (Thu, 10 Feb 2011)). Is
Yes.
2011/2/16 Jack Vogel
> I've been in email conversation with Beezar, and he's clarified some
> things, I think
> I would like to try his approach to the issue, it will mean one more
> iteration of changes
> to test, would you be willing to do so? It would be good to know for sure
> if his a
array in
syncache_timeout?
Regards,
Karim.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
bscr...@freebsd.org"
Hi,
For what its worth, we at Xiphos (now XipLink), are still using sendto
and T/TCP and is one of the reasons we've chosen FreeBSD more then 10
years ago!
Best regards,
Karim.
___
freebsd-net@freebsd.org mailing l
eral purpose OS but
its certainly possible.
Finally, we did see speed increase for our application and if someone is
interested I could provide a patch although I would have to rewrite it
without the proprietary bits in it.
Best regards,
Karim.
Mungyung Ryu wrote:
Hi freeBSD users,
I've developed couple of server applications on Windows platform with ACE
Proactor
and it worked quite well. But, because of the expensive Windows Server,
I wanna move to Linux or freeBSD.
Recently, I'm considering to build a server application on freeBSD b
pf.c", w_line = 452,
w_level = 0, w_refcount = 2, w_Giant_squawked = 0 '\0',
w_other_squawked = 0 '\0', w_same_squawked = 0 '\0', w_displayed = 0 '\0'}
Anyone that can shed some light on this? Btw I've never witnessed that
crash without WITNES
Hello,
Is there any plans on getting the mbuf tags sub-system integrated with
the universal memory allocator? Getting tags for mbufs is still calling
malloc in uipc_mbuf.c ... What would be the benefits of using uma instead?
Karim.
___
freebsd-net
Robert Watson wrote:
On Fri, 10 Apr 2009, Karim Fodil-Lemelin wrote:
Is there any plans on getting the mbuf tags sub-system integrated
with the universal memory allocator? Getting tags for mbufs is still
calling malloc in uipc_mbuf.c ... What would be the benefits of using
uma instead?
Hi
Robert Watson wrote:
On Fri, 10 Apr 2009, Karim Fodil-Lemelin wrote:
Thank you for the answer, clear and concise. I asked the question
because I had modified pf_get_mtag() to use uma directly in the hope
that it would be faster then calling malloc. But since pf_mtag is
20bytes, malloc will
ed
the problem. But applying the attached patch (written by Pyun I believe)
also solved the problem.
I think your patch should be committed for others to benefit.
Best regards,
Karim.
Index: sys/dev/msk/if_msk.c
===
---
s problem is confirmed you've probably found an original
implementation bug. Can you describe better the test condition to
reproduce this problem?
Cheers,
Karim.
Harti Brandt wrote:
Hi all,
one of my TCP test cases breaks in what one could call an edge case:
When the TCP is in S
).
Using the legacy interrupt sysctl (on top of the patched kernel atm) is
giving us better result, haven't seen a failure in days now.
Regards,
Karim.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-n
2efff38..6ad8439 100644
--- a/freebsd/sys/sys/mbuf.h
I hope this helps,
Karim.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
On 2015-03-20 1:57 PM, Hans Petter Selasky wrote:
On 03/20/15 16:18, Karim Fodil-Lemelin wrote:
Hi,
While reading through a previous comment on this list about fragments
I've noticed that mbuf tags aren't being copied from the leading
fragment (header) to the subsequent fragment p
On 2015-03-21 5:14 AM, Hans Petter Selasky wrote:
On 03/20/15 21:03, Karim Fodil-Lemelin wrote:
On 2015-03-20 1:57 PM, Hans Petter Selasky wrote:
On 03/20/15 16:18, Karim Fodil-Lemelin wrote:
Hi,
While reading through a previous comment on this list about fragments
I've noticed that
FYI: I've created a bug report for this. Thanks.
On 2015-03-23 9:40 AM, Karim Fodil-Lemelin wrote:
On 2015-03-21 5:14 AM, Hans Petter Selasky wrote:
On 03/20/15 21:03, Karim Fodil-Lemelin wrote:
On 2015-03-20 1:57 PM, Hans Petter Selasky wrote:
On 03/20/15 16:18, Karim Fodil-Lemelin
+ ztotal is bigger the zmax ...
3) If we are in zalloci() why is the zlock not held (0)?
What else should I be looking for here, the crash only happens after a
certain amount of items are used (>20k so far).
Thanks,
Karim.
___
[EMAIL PROTECTE
Doug Barton wrote:
Karim Fodil-Lemelin wrote:
I have stumbled into a strange problem where my FBSD 4.x box
FreeBSD 4.x is no longer supported. Your best bet at this point would
be to evaluate the 7.0 release candidates, since that branch has a lot
of both stability and performance
rking with it or have tried it (the 82541)? What is the status? any
plans for a driver that would support those? Also, will the fxp driver
work (enabling functionality at 100Mbps only) but a
patch/another_driver is required to get the gigabit?
Rega
002%4010.7.7.3&rnum=1
Karim.
Thiago Pinto Damas wrote:
Hi,
I configured a tunnel between two FreeBSD machines with IPSEC,
for just using the IPCOMP (without ESP and AH), but the
performance wasn't good.
Has someone configured a tunnel for only compressing data?
Sor
t_ being "fwded"!!
If anyone could help me to figure at least why tcp packets are going
through whitout being sucked in, I would really appreciate.
Obviously if you know how to fix this then please let me know :).
Regards,
Karim.
___
[EMAI
cannot envision TCP doing something
like this. What am I missing?
Thanks,
allman
--
Mark Allman -- ICIR -- http://www.icir.org/mallman/
--
Karim Fodil-Lemelin
Lead Programmer
Xiphos Technologies Inc.
www.xiplink.com
___
[EMAIL PROTECTE
start and we actually made some modifications to FreeBSD's T/TCP
but the rfc1644 principles are the same.
Julian Elischer wrote:
Karim Fodil-Lemelin wrote:
Hi,
I am jumping in here, was too busy to read the list for the last 2
weeks, so please excuse my intrusion. We are using T/TCP i
as they can live with FreeBSD 5.3 I don't think it causes a problem
whatsoever does it?
Right, Actually we are based on FBSD 4.9 and we are planning to port to
5.3 as soon as it gets stable, which could be anytime soon ;).
--
Karim Fodil-Lemelin
Lead Programmer
Xiphos Technologies Inc.
(514) 8
name it will have). Do you have any plan to include
that knowledge in your design or is it too much of a special case to
really care?
Andre Oppermann wrote:
Karim Fodil-Lemelin wrote:
Now,
I have a question. In our application which can be described as:
Client > (Client Gate
tep 1)
This way the protocol would use knowledge that there is a transparent
proxy (found at step2) that is doing T/TCP on behalf of the SERVERs.
What do you think?
Regards,
Andre Oppermann wrote:
Karim Fodil-Lemelin wrote:
In the case where all connections go through the SATLINK and are
sp
server_valid() tries to get the 220 command due to the lack of \n in
the buffer (striped by len = MIN(mlen, FTP_BUFSZ / 2); in ip_ftp_pxy.c).
I have attached the solution.
Regards,
--
Karim Fodil-Lemelin
Lead Programmer
Xiphos Technologies Inc.
www.xiplink.com
Index:
ncountered this problem?
Karim.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
is mainly just experimentation.
I would like some pointers toward fixing this. Is there another variable tied
into this (I guess so)? Could anybody points me to a technical document that
would explain the relationship with that (those) other(s) presumed variable(s)?
Thank yo
ote:
AFAIK the number of mbufs (and consequently nmbclusters) has to be a power
of 2, so you should set it to 131072
MorEl
- Original Message -
From: "Karim Fodil-Lemelin" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, June 15, 2005 6:08 PM
Subject: (panic) Lots of netwo
vm_kmem_size = mem_size / VM_KMEM_SIZE_SCALE;
#endif
#if defined(VM_KMEM_SIZE_MAX)
if (vm_kmem_size >= VM_KMEM_SIZE_MAX)
vm_kmem_size = VM_KMEM_SIZE_MAX;
#endif
/* Allow final override from the kernel environment */
TUNABLE_INT_FETCH("kern.vm.kmem.size",
rk on the new FreeBSD project web site, things are much
easier to find now.
--
Karim
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
1, t->m_tag_len); /* Copy the data */
+ p->m_tag_free = t->m_tag_free; /* copy the 'free' function pointer */
return p;
}
This is because m_tag_copy uses m_tag_alloc() that resets the m_tag_free
pointer to m_tag_free_default. It woul
owever, I tend to agree
with the patch. But shouldn't we first copy the m_nextpkt to the new mbuf:
+ to->m_nextpkt = from->m_nextpkt;
+ from->m_nextpkt = NULL;
Same way as we deal with tags.
Hi Gleb,
I think you are correct. If we look at the 'spirit' of m_m
cl->m_pkthdr.len = len;
m_freem(m);
It would be nice if some FBSD comitter could review and hopefully add
this patch to FBSD.
Thank you,
Karim.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
orts of number of fragments (varying the
initial packet size).
I see this seems to affect all modern versions of FreeBSD, please feel
free to test or contest. I would like to see this added to FreeBSD
eventually in one shape or another.
Best regards,
Karim.
diff --git a/freebsd/sys/net/if_brid
from->m_nextpkt = NULL;
}
It will reset the m_nextpkt so we don't have two mbufs pointing to the
same next packet. This is fairly harmless and solves a problem for us
here at XipLink.
Best regards,
Karim.
___
freebsd-net@freebsd.org
.
Regards,
--
Karim Fodil-Lemelin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Hi,
I tried that before and couldn't get it working :(
Then I asked the Kame peps and it seems that ipcomp
is not supported yet in tunnel mode. That was for
FreeBSD 4.8 and I don't think it has changed since then.
Karim.
> -Original Message-
> From: [EMAIL PROTECTED]
n the connection closes. BTW don't mind the option
20 (opt-20) Its our implementation of SCPS-TP.
Karim
Xiphos Technologies.
Andre Oppermann wrote:
Danny Braniss wrote:
I have been the last one fuzz around in the TTCP code areas. However
there could be problems that were lurking ther
Hi,
Your problem here is that your TTCP connection times out and the
data is retransmitted (loosing all the benefits of TTCP) see my other
email for why this happens.
Karim.
Danny Braniss wrote:
hi,
im running some experiments, and it seems to me that
setting net.inet.tcp.rfc1644
he bandwidth why?
Memory (amount of mbufs/mbclusters) is obviously a limit here but I was
wondering if something else was hidden in this statement.
Regards,
Karim
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ne
I
would like to have myself and Xiphos mentionned in realsing the patch.
Regards,
Karim Fodil-Lemelin
Xiphos Technologies Inc
Marco Berizzi wrote:
Hello everybody.
I'm running an interop issue with IPSec tunnels
between FreeS/WAN and FreeBSD 5.2
Without IPComp tunnel are successfully est
il if you use the attachment.
Let me know how it goes.
Regards,
Karim Fodil-Lemelin
Network Eng.
Xiphos Technologies Inc.
The Patch code:
diff --exclude CVS -C 3 /usr/src/sys/netinet6/ipcomp.h ./ipcomp.h
*** /usr/src/sys/netinet6/ipcomp.h Sun Apr 28 01:40:27 2002
--- ./ipcomp.h Sat May 1
89 matches
Mail list logo
