As title. To my imagination (I have taken a sight on the kernel networking
code), the fastforwarding path is intended for routers only, so if I want
some functionalities, for example, NAT, the fastforwarding is not useful,
and my experiment shows that if I enable it, ipfilter's NAT will be broken.
On Tue, 13 Jan 2004, Kelly Yancey wrote:
>
> On Fri, 2 Jan 2004, Kelly Yancey wrote:
>
> >
> > We've got Broadcom BCM5701 cards configured for vlan tagging on a
> > FreeBSD 4.7 based router; a vlan switch then terminates the trunked
> > segment and splits it into separate physical subnets. It
On Sat, Jan 17, 2004 at 12:50:04AM +0100, Sten Daniel S?rsdal wrote:
>
> Apologies for the cross-post, i wasnt sure if this was hackers or net material.
>
> I've often wondered why ip checksumming is done on every incoming
> packet and not only on the packets that need to be delivered locally.
>
Apologies for the cross-post, i wasnt sure if this was hackers or net material.
I've often wondered why ip checksumming is done on every incoming
packet and not only on the packets that need to be delivered locally.
It looks like a very expensive way of doing it, especially on high
PPS. Basicall
> it seems there is no protection from TCP session
> mucking up the tsecr values
> in some cases [t_rxtcur] ends up as say -45000
> because the secr has been forged.
I looked into this a couple of months ago, and thought at that time
that the "max allowable REXMT value" TCPTV_REXMTMAX (64 sec
Hello list,
i have a problem using my D-Link DFE-550FX interface. Its inclued
in the kernel and recognised correctly due boot. As long as there
is no ip bound to the interface ifconfig tells me about
ste0: flags=8802 mtu 1500
ether 00:05:5d:8a:a6:2c
media: Ethernet autose
We have an application that periodically sees
the tp->t_rxtcur go to a large -ve number
it seems there is no protection from TCP session
mucking up the tsecr values
tcp_input() receives it and does (ticks - tsecr + 1)
in some cases this ends up as say -45000
because the secr has been forged.
> E> As you can see the client does not agree with MRU of 1488 (I tried
initially with the default of 1492). Bug in RASPPPOE implementation?
>
G> Surely. One more person faced this bug. :)
G>
G> On PPPoE ACes I use a patched mpd, where MRU negotiation is commented
out.
G> You should send a bug repo
On Fri, Jan 16, 2004 at 04:22:05PM +0200, Emil Filipov wrote:
<==skip==>
E> Jan 16 15:46:28 opera mpd: [pppoe1] LCP: SendConfigReq #3
E> Jan 16 15:46:28 opera mpd: MRU 1488
E> Jan 16 15:46:28 opera mpd: MAGICNUM 1c5e3cf8
E> Jan 16 15:46:28 opera mpd: AUTHPROTO CHAP MSOFTv2
E> Jan 16 15:46:30 ope
Oops I was wrong sorry , I did not read the docs well enough
My fault:(
--
===
Christophe Prevotaux Email: [EMAIL PROTECTED]
HEXANET SARLURL: http://www.hexanet.fr/
Z.A.C Les CharmillesTel: +33 (0)3 26 7
OK guys, according to your advice I'm now trying with mpd (v.3.16).
Works like magic with a SMC Router, but when I try to connect from a Win2k box with
RASPPPOE installed, the LCP negotiation fails.
Here is a logged example of one such failure:
Jan 16 15:46:28 opera mpd: Incoming PPPoE connectio
Hi,
On Fri, 16 Jan 2004, Emil Filipov wrote:
>
> G> Why don't you try /usr/ports/net/mpd instead of pppoed+ppp?
>
> Because the last time I read the mpd manual, it said that mpd can only act
> as a ppoe client and not as a pppoe server. Which is not true for the last
> mpd version (3.16). So thank
On Fri, Jan 16, 2004 at 01:08:07PM +0200, Emil Filipov wrote:
E> However this does not answer the question about the (broken?) mppe
E> implementation in ppp(8). And I feel more comfortable using base
E> applications, than 3rd party software. It's not that I don't like mpd, it's
E> great, but why us
G> Why don't you try /usr/ports/net/mpd instead of pppoed+ppp?
Because the last time I read the mpd manual, it said that mpd can only act
as a ppoe client and not as a pppoe server. Which is not true for the last
mpd version (3.16). So thanks, this is a possibility that I will test
immediately :)
On Fri, Jan 16, 2004 at 12:31:00PM +0200, Emil Filipov wrote:
E> I am trying to configure a secure pppoe server.So far it works perfectly with
Windows clients authenticating with MSChapv2. However, if MPPE is negotiated, the
client receives only about 1/4th(30-40 kbytes/s) of the bandwidth availa
Hi,
I am trying to configure a secure pppoe server.So far it works perfectly with Windows
clients authenticating with MSChapv2. However, if MPPE is negotiated, the client
receives only about 1/4th(30-40 kbytes/s) of the bandwidth available while
downloading.
Download seem 'leapy' : it starts w
16 matches
Mail list logo
