On Sat, 4 Dec 2004, Bjoern A. Zeeb wrote:
On Sat, 4 Dec 2004, Andre Oppermann wrote:
i just found a patch from Pawel Jakub Dawidek(mijail5) which do not
...
Do you have a link? I'd like to have a look at the code.
http://garage.freebsd.pl/
This code is borken on 5.3, because of mfc's.
There is a s
On Sat, 4 Dec 2004, Andre Oppermann wrote:
> > i just found a patch from Pawel Jakub Dawidek(mijail5) which do not
...
> Do you have a link? I'd like to have a look at the code.
http://garage.freebsd.pl/
--
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
_
Meno Abels wrote:
>
> Hello,
>
> i just found a patch from Pawel Jakub Dawidek(mijail5) which do not
> need the pcb bind
> to multiple ip's. He solve the problem my marking the socket that is bound to
> a
> jail with inaddr_any. With this mark he is filtering the incoming
> connection lookup to
Fri, Nov 26, 2004 at 13:24:31, anthonyv wrote about "FreeBSD kernel pppd -
mppe/mschapv1/2/radius support":
> After extensively googling FreeBSD pppd's support for mppe, mschapv1,
> mschapv2 and radius, I've stumbled into a mess of patches for very random
> versions of pppd and FreeBSD.
> Does
On Sun, Dec 05, 2004 at 12:53:52AM +0300, Maxim Konovalov wrote:
M> IMHO restoring the historic behaviour (even broken in some respects)
M> is the best thing we can do at the moment.
+ my vote.
Using 'ipfw fwd' on packets just being nated, is a very common and used
technique. I know several place
Max Laier wrote:
>
> On Thursday 02 December 2004 19:45, Petr Holub wrote:
> > Hi all,
> >
> > I wonder if it is possible to use the new pf firewall together with
> > bridging as it is possible to use it with ipf and ipfw.
>
> Unfortunately the PFIL_HOOKS in bridge.c don't work too well for pf (o
Michal Mertl wrote:
>
> I looked at the project page and noticed one thing I found code for.
>
> Task: Rework code in FreeBSD's ip_icmp.c such that ICMP responses for
> forwarding can be throttled also. Call badport_bandlim() before icmp_error()?
>
> Andres Oppermann wrote simple patch for it an
On Sat, 4 Dec 2004, 21:37+0100, Andre Oppermann wrote:
[...]
> > Investigating pre-PFIL_HOOKS ipfw I have not found any analog of
> > this check. These checks do break some useful functionality:
> >
> > 1) policy routing of hosts from connected networks
> > 2) policy routing of locally originated
Gleb Smirnoff wrote:
>
> On Sat, Dec 04, 2004 at 09:02:46PM +0100, Andre Oppermann wrote:
> A> If we are talking about a multi-gigabit gif tunnel server then I'd agree
> A> that we need some form of optimzation. But for everything it's simply
> A> not going to make a difference. Doing a route lo
On Sat, Dec 04, 2004 at 09:02:46PM +0100, Andre Oppermann wrote:
A> If we are talking about a multi-gigabit gif tunnel server then I'd agree
A> that we need some form of optimzation. But for everything it's simply
A> not going to make a difference. Doing a route lookup is fast enough for
A> any n
Hello,
i just found a patch from Pawel Jakub Dawidek(mijail5) which do not
need the pcb bind
to multiple ip's. He solve the problem my marking the socket that is bound to a
jail with inaddr_any. With this mark he is filtering the incoming
connection lookup to
the pcb structure on jail bases. This
Meno Abels wrote:
>
> Hello,
>
> i had made a patch for 5_X (kern/69064) jail code which enables ipv6 and
> multi ip numbers to a jail.
> I currently solved the INADDR_ANY binding to map to the first ip of
> the jail. But this is not really the good solution it would be better to bind
> to all ip
Gleb Smirnoff wrote:
>
> Andre,
>
> what is reason for these two checks in ip_output():
>
> if (!in_localip(ip->ip_src) && !in_localaddr(ip->ip_dst)) {
> dst = (struct sockaddr_in *)&ro->ro_dst;
> bcopy((fwd_tag+1), dst, sizeof(
Hello,
i had made a patch for 5_X (kern/69064) jail code which enables ipv6 and
multi ip numbers to a jail.
I currently solved the INADDR_ANY binding to map to the first ip of
the jail. But this is not really the good solution it would be better to bind
to all ip's of the jail. Which are simple
Valentin Nechayev wrote:
>
> Hi,
>
> Mon, Nov 29, 2004 at 19:15:29, glebius wrote about "Re: route cacheing for
> gif(4) should be optional":
>
> A>> However there have been reasons for
> A>> storing the rtentry pointer in struct gif. In the old days ip_output()
> A>> required an rtentry poin
Hi,
Mon, Nov 29, 2004 at 19:15:29, glebius wrote about "Re: route cacheing for
gif(4) should be optional":
A>> However there have been reasons for
A>> storing the rtentry pointer in struct gif. In the old days ip_output()
A>> required an rtentry pointer to be passed on, this is no longer the
On Sat, Dec 04, 2004 at 05:52:30PM +0100, Andre Oppermann wrote:
> Nice, needs some cleanup though. Once you have cleaned it up you can run
> it either through me or [EMAIL PROTECTED] He is more of a IPv6 fan than I am
> (in my
> book IPv6 is broken by design^TM).
Indeed, my first code I submit
James wrote:
>
> Folks,
>
> Attached is initial code for ip6_fastforward() that I'm proposing for FreeBSD
> 5.x. This code was written for an internally modified FreeBSD 4.9, however in
> the next few weeks, I will be porting this into FreeBSD 5.3 tree and submit a
> final draft for review back t
> After more than a day's mail-archive reading and FreeBSD 4.10 source
> code browsing, I don't think ALTQ has been integrated into 4.x branch
> (I know it is for the 5.x branch). Is that correct? I was wondering if
> some folks would know the status of ALTQ on FreeBSD 4.x; alternatively
> I'd appr
Ian Smith wrote:
[ ... ]
Read those ones for interest, but it leaves me wondering: can you use
stateful filtering in ipfw, then? (here ipfw1 on a 4.8-RELEASE box with
BRIDGE in kernel so far, but I imagine this would apply also to ipfw2?)
Yes, you ought to be able to perform stateful packet filte
El Sábado, 4 de Diciembre de 2004 01:56, Bruce M Simpson escribió:
> On Fri, Dec 03, 2004 at 09:25:56PM +0100, Jose M Rodriguez wrote:
> > But noted strong differences between atm boards and adsl modems.
> >
> > - atm boards are hardware assisted. usb adsl modems are bare
> > assisted. - atm board
21 matches
Mail list logo
