Hi Mikhail,
This is a very old bug in FreeBSD/ipfw O_PROBE_STATE and the good news
is I have a fix for it. The fix is very easy and I will try to explain
here what the bug is and what the fix is. The issue is only related to
rules that have the F_NOT bit set and that are the beginning of the
On 2017-10-13 5:10 PM, Gleb Smirnoff wrote:
On Fri, Oct 13, 2017 at 12:59:47AM -0700, Adrian Chadd wrote:
A> When doing so m_move_pkthdr is called to copy the current PKTHDR fields
A> (tags and flags) to the mbuf that was prepended. The function also does:
A>
A> to->m_pkthdr =
On 2017-07-07 10:46 AM, Andrey V. Elsukov wrote:
On 05.07.2017 19:23, Adrian Chadd wrote:
As many of you know, when dealing with IP fragments the kernel will build a
list of packets (fragments) chained together through the m_nextpkt pointer.
This is all good until someone tries to do a M_PREPEND
Hi,
As many of you know, when dealing with IP fragments the kernel will
build a list of packets (fragments) chained together through the
m_nextpkt pointer. This is all good until someone tries to do a
M_PREPEND on one of the packet in the chain and the M_PREPEND has to
create an extra mbuf to
Hello,
It has come to my attention that when bridge_fragment() has to fragment
an IP packet it can cause mbuf leaks if, for example m_pullup() ends up
allocating a new buffer at the front of the mbuf chain or if the calls
to M_PREPEND would fail due to the mbuf pool being depleted.
One can e
Hi,
I've hit a very interesting problem with ipfw-nat and local TCP traffic
that has enough TCP options to hit a special case in m_megapullup().
Here is the story:
I am using the following NIC:
igb0@pci0:4:0:0:class=0x02 card=0x8086 chip=0x150e8086
rev=0x01 hdr=0x00
And wh
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
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
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
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 packets. In other words,
one would expect that all fragments of a packet are carrying the same
tags that were
e a queuing operation if there was already something else
on the queue. so in that model packets were not supposed to get
re-ordered. does that not still work?
Either that, or you need to explain the problem to me a bit better..
On 4/10/14, 5:25 AM, Karim Fodil-Lemelin wrote:
Hi,
Below is
: kern/188421
On 09/04/2014 9:09 PM, Adrian Chadd wrote:
Hi!
Would you mind filing a PR for this?
www.freebsd.org/send-pr.html
That way it won't (hopefully!) get lost.
Thanks!
-a
On 9 April 2014 14:25, Karim Fodil-Lemelin wrote:
Hi,
Below is a revised patch for this issue. It acc
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 List,
I'm calling out to the general wisdom ... I have seen an issue in
netgraph where, if called, a callout routine registered by ng_callout()
will trigger packet queuing inside the worklist of netgraph since
ng_callout() makes my node suddenly a WRITER node (therefore non
reentrant) for
On 10/10/2013 5:56 AM, h bagade wrote:
Hi all,
I have problem with running altq on igb cards. When trying to run altq on
these cards, it outputs an error, driver does not support altq.
I have FreeBSD 8.3-stable and tried to fix the problem, after searching in
forums, by applying changes made to
/04/2013 1:17 PM, Nick Rogers wrote:
On Tue, Apr 2, 2013 at 9:17 AM, Nick Rogers wrote:
On Tue, Apr 2, 2013 at 7:47 AM, Karim Fodil-Lemelin
wrote:
Hi Nick,
Unfortunately I do not have a FBSD 9 box around where I can compile and test
this so bear with me as this is pretty much straight out of
_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
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
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
Hi Jack,
I think this would help M. Rogers case as we have done something similar
here to circumvent the issue and it seems to work well. I would also add
that when using ALTQ we found it much more stable to set the number of
queues to 1:
static int igb_num_queues = 1;
Our approach consiste
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
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 software using the
FreeBSD bridge. Our code sometimes de
On 19/12/2012 6:40 PM, Vijay Singh wrote:
Sure but syncache_expand() is entered with the tcbinfo already write locked
which also protects the unlocking of the listening connection and the
locking of the newly created socket. Around this part:
/*
* Socket is created in
On 19/12/2012 4:01 PM, Vijay Singh wrote:
Holding the pcbinfo lock prevents races between syncache_socket() and
accept(). See rwatson's comment just above tcp_usr_accept. I noted
this too (the comment above tod->tod_offload_socket() in tcp_syncache.c)
back when I updated the TOE code in the ker
On 19/12/2012 2:31 PM, Vijay Singh wrote:
As it is today, a socket upcall on a listener socket is made with the
V_tcbinfo lock held. [tcp_input -> syncache_socket -> sonewconn ->
sowakeup].
I feel that the use of the V_tcbinfo is not consistent in the syncache code.
In syncache_add(), we drop t
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/
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 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 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: Gleb Smirnoff
Subject: Re: igb and ALTQ in 9.1-rc3
To: "Jack Vogel"
Cc: "Clement Hermann (nodens)" , "Barney Cordoba"
, freebsd-net@FreeBSD.org
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
Hi Gleb,
On 21/11/2012 1:26 AM, Gleb Smirnoff wrote:
Jack,
On Tue, Nov 20, 2012 at 09:19:54AM -0800, Jack Vogel wrote:
J> > I'd suggest the following code:
J> >
J> > if (m)
J> > drbr_enqueue(ifp, txr->br, m);
J> > err = igb_mq_start_loc
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>
Hello -net,
While testing the latest igb driver in CURRENT I came across an issue
with igb_mq_start(). More specifically this code:
...
struct mbuf *pm = NULL;
/*
** Try to queue first to avoid
** out-of-order delivery, but
** settle for it if that fail
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
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
hen a packet has been
> received,
> > which can not happen since the receive ring is empty. So how can the
> driver
> > know? I have no idea. Maybe we can periodically check for such an event
> > and call igb_refresh_mbufs().
> >
> > Does this make sense to you?
2011/2/8 Jack Vogel
>
> I have been following this, and thinking about it. I still am working from
> a theoretical
> standpoint, but based on a patch I got quite a long time back and never
> quite groked,
> I believe now that I might have a solution.
>
> The original PR and patch was kern/150516
> 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
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/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
> > >
> > >
>
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 driver from 7.4 RC3 r218406. If the driver
>> runs
>> > o
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
Hi List,
The issue is with the igb driver from 7.4 RC3 r218406. If the driver runs
out of mbuf clusters it simply stops receiving even after the clusters have
been freed.
igb0@pci0:7:0:0:class=0x02 card=0x8086 chip=0x10a78086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
Hello,
I'd like to summit a patch that fixes a hanging issue related to Rx FIFO
overrun on the following chips and rev (tested):
ID:
CHIP_ID_YUKON_EC
REV:
CHIP_REV_YU_EC_A2
CHIP_REV_YU_EC_A3
(I haven't tested it on CHIP_REV_YU_EC_A1)
@@ -3813,16 +3805,24 @@
GMR_FS_ANY_ER
On 03/10/2010 9:13 AM, Luigi Rizzo wrote:
On Sun, Oct 03, 2010 at 12:29:21AM +0100, Rui Paulo wrote:
On 2 Oct 2010, at 21:35, Juli Mallett wrote:
On Sat, Oct 2, 2010 at 12:07, Rui Paulo wrote:
On 2 Oct 2010, at 16:29, Robert Watson wrote:
On Thu, 30 Sep 2010, Julian Elischer wrote:
On 9/3
On 31/08/2010 5:32 PM, Robert Watson wrote:
On Tue, 31 Aug 2010, Andre Oppermann wrote:
I'm not entirely comfortable with this change, and would like a
chance to cogitate on it a bit more. While I'm not aware of any
applications depending on the semantic for TCP, I know that we do
use it fo
Greetings,
When doing an active connect and assuming that SYN packets are lost. The
next retransmit timeout will trigger retransmissions of the SYN
according to this code (in tcp_timer_rexmt):
rexmt = TCP_REXMTVAL(tp) * tcp_syn_backoff[tp->t_rxtshift];
Now, when doing passive connections th
Hello,
We have seen the problem reappear on msk driver (after the applying the
latest patch in gnats). The patch did improve things tremendously but
now the watchdog will timeout after 7 or 8 hours of flawless activity
(before the patch it would happen right away on the first transfer).
Usin
Hi There,
Looking at Steven's book TCP/IP Volume 2 (1995 edition) page 988
(Processing and Received Data) they call TCP_REASS(tp, ti, m, so,
tiflags) where tiflags is thflags and inside the TCP_REASS macro (page
908), this code is used (where ti is the tcpiphdr pointer):
flags = (ti)->ti_fla
Hello,
Concerning this pr:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124127, Given that I
have one of those 'strange' silicon here:
FreeBSD 7.1-RELEASE-p5 FreeBSD 7.1-RELEASE-p5
kernel: mskc2: port 0xee00-0xeeff mem
0xfdafc000-0xfdaf irq 18 at device 0.0 on pci3
kernel: msk2: on
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
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
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@f
Hi,
I got this crash while running tcpdump and saving to a file. I can't
reproduce it consistently but perhaps someone can give me some pointers
on how to fix this. It looks like the witness code is in some infinite
loop and that get stopped by an MPASS check.
(kgdb) bt
#0 kdb_enter_why (wh
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
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
My apologies for double posting (here and hackers) but I though this
might get more attention if posted here.
--- Begin Message ---
Good day,
I have stumbled into a strange problem where my FBSD 4.x box keeps
crashing under network traffic load. I have enabled INVARIANTS and
debugging and w
.
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]"
Hello,
I just noticed that RELENG_6 was frozen, I haven't downloaded the
RC1 yet but I have BETA4 and noticed that T/TCP was removed and a blank
was left in its place. I would like to know if there will be a
replacement for T/TCP in FreeBSD 6.0 STABLE or not.
Thanks,
PS: Nice work on the
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",
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
Hello,
From kernel tuning page (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-kernel-limits.html)
Some sentence about nmbclusters says:
"Under no circumstances should you specify an arbitrarily high value for
this parameter as it could lead to a boot time c
Hi,
I just did a cvsup of RELENG_5 and got some problem doing forwarding
to localhost using a rule like this:
ipfw add fwd 127.0.0.1,1234 tcp from any to any in via re1
I have those options in my kernel config:
options IPFIREWALL
options IPFIREWALL_FORWARD_EXTENDED
options IPFIREWALL_
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:
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
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
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
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
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
Hi,
I have applied Luigi's patch to a FBSD 4.8 kernel to be able to use
fwd rules in ipfw with a BRIDGE. I have to say its a very cool feature.
Now, there is two side of this, one good and one that I really need to fix.
The good side is it works in this configuration:
CLIENT (fx
Actually I did, If you look in this mailing list archive you'll find a
patch for it. I also proposed a patch for IPSEC (with IPCOMP) to work
with a gif tunnel.
http://groups.google.ca/groups?q=IPSEC+tunnel+kfl%40xiphos.ca&hl=en&lr=&ie=UTF-8&selm=1083615801.00042919.1083603002%4010.7.7.3&rnum=1
K
I was going through the hardware notes. We already use Intel's NIC's and
are planning to switch to Dual Intel® 82541 Gigabit Ethernet. Its not
listed in the the hardware notes but we use the 82555 on FBSD4.8 (fxp)
driver and it works fine (and it is not listed either). Is anyone
working with it
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
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
Hi
This code:
if (pipe.delay > 1)
errx(EX_DATAERR, "delay %d must be < 1",
pipe.delay);
in /usr/src/sbin/ipfw/ipfw.c
Limits the pipe delay for dummynet to 10 seconds. Is there any reason
for this? Also, no such limit is imposed on the bandwidth why?
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 h
Hi,
We actively use TTCP and we like it (www.xiplink.com). The problem is
that it does not behave exactly like in Steven's book. I have sample
code if you want to try it. But basically you need to set the NOPUSH
flag (setsockopt()) before using sendto() _and_ in the server as
well. For shor
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]
> [mailto:[EMAIL PRO
79 matches
Mail list logo
