Re: ipfw changes and jails

Am Mon, 17 Mar 2025 13:37:40 +0100 (CET) Ronald Klop schrieb: > Hi, > > When running 14.2-RELEASE VNET jails on 15-CURRENT ipfw does not work anymore > in the jail. > > Can this commit be involved? > https://cgit.freebsd.org/src/commit/?id=4a77657cbc01 > > Copying the /sbin/ipfw binary from 1

Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

Hi Andrey, With your patch applied I don't have the symptoms of 'hanging' tcp connections anymore. Thanks for looking into it. Regards, Ronald. *Van:* "Andrey V. Elsukov" *Datum:* donderdag, 12 december 2024 09:53 *Aan:* freebsd-current@freebsd.org *Onderwerp:* R

Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

On 11.12.2024 16:25, Ronald Klop wrote: I did a bisect of commits and my finding is that commit 347dd053 on 2024-11-29 is the cause. "tcp: add TH_AE capabilities to ppp and pf" https://github.com/freebsd/freebsd-src/commit/347dd0539f3a75fdf2128dd4620ca99e96f311e9 The commit before (0fc7bdc978)

Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

On Wed, 11 Dec 2024 14:25:02 +0100 Ronald Klop wrote: > Op 09-12-2024 om 19:24 schreef Juraj Lutter: > > > > > >> On 9 Dec 2024, at 19:19, FreeBSD User wrote: > >> > >> Am Tue, 10 Dec 2024 02:27:10 +0900 > >> Tomoaki AOKI schrieb: > >> > >> My apology for topposting. > >> > >> The host I firs

Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

Am Wed, 11 Dec 2024 14:25:02 +0100 Ronald Klop schrieb: > Op 09-12-2024 om 19:24 schreef Juraj Lutter: > > > > > >> On 9 Dec 2024, at 19:19, FreeBSD User wrote: > >> > >> Am Tue, 10 Dec 2024 02:27:10 +0900 > >> Tomoaki AOKI schrieb: > >> > >> My apology for topposting. > >> > >> The host I

Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

Op 09-12-2024 om 19:24 schreef Juraj Lutter: On 9 Dec 2024, at 19:19, FreeBSD User wrote: Am Tue, 10 Dec 2024 02:27:10 +0900 Tomoaki AOKI schrieb: My apology for topposting. The host I first realised the problems is updated on an almost daily basis and the issue reported started last wee

Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

> On 9 Dec 2024, at 19:19, FreeBSD User wrote: > > Am Tue, 10 Dec 2024 02:27:10 +0900 > Tomoaki AOKI schrieb: > > My apology for topposting. > > The host I first realised the problems is updated on an almost daily basis > and the issue > reported started last weekend. > > A possible candi

Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

On Mon, 9 Dec 2024 17:45:14 +0100 FreeBSD User wrote: > Am Mon, 9 Dec 2024 21:43:14 +0900 > Tomoaki AOKI schrieb: > > > On Mon, 9 Dec 2024 11:09:14 +0100 > > Juraj Lutter wrote: > > > > > > On 8 Dec 2024, at 20:30, Ronald Klop wrote: > > > > > > > > Hi, > > > > > > > > I can reproduce your

Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

Am Mon, 9 Dec 2024 21:43:14 +0900 Tomoaki AOKI schrieb: > On Mon, 9 Dec 2024 11:09:14 +0100 > Juraj Lutter wrote: > > > > On 8 Dec 2024, at 20:30, Ronald Klop wrote: > > > > > > Hi, > > > > > > I can reproduce your error. > > > > > > A cronjob which does a scp to another server didn't work

Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

On Mon, 9 Dec 2024 11:09:14 +0100 Juraj Lutter wrote: > > On 8 Dec 2024, at 20:30, Ronald Klop wrote: > > > > Hi, > > > > I can reproduce your error. > > > > A cronjob which does a scp to another server didn't work anymore. When I go > > back to the previous BE it works fine again. > > Ipfw

Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

> On 8 Dec 2024, at 20:30, Ronald Klop wrote: > > Hi, > > I can reproduce your error. > > A cronjob which does a scp to another server didn't work anymore. When I go > back to the previous BE it works fine again. > Ipfw disable firewall also makes the scp work. > > Scp also seems to work f

Re: IPFW/IPv6 problem with JAIL: JAIL cannot ping -6 host until host first pings jail (ipv6)

Am Mon, 8 Jan 2024 01:33:53 +0100 (CET) Felix Reichenberger schrieb: > > Hello, > > > > I've got a problem with recent CURRENT, running vnet JAILs. > > FreeBSD 15.0-CURRENT #28 main-n267432-e5b33e6eef7: Sun Jan 7 13:18:15 CET > > 2024 amd64 > > > > Main Host has IPFW configured and is open for

Re: IPFW/IPv6 problem with JAIL: JAIL cannot ping -6 host until host first pings jail (ipv6)

> On Jan 8, 2024, at 1:50 AM, FreeBSD User wrote: > > Hello, > > I've got a problem with recent CURRENT, running vnet JAILs. > FreeBSD 15.0-CURRENT #28 main-n267432-e5b33e6eef7: Sun Jan 7 13:18:15 CET > 2024 amd64 > > Main Host has IPFW configured and is open for services like OpenLDAP on

Re: IPFW: IPv6 and NPTv6 issues: multiple IPv6 addresses confuses IPFW

Am Sun, 19 Feb 2023 13:30:13 +0300 "Andrey V. Elsukov" schrieb: > 18.02.2023 18:42, FreeBSD User пишет: > > On a 24 hour basis, the ISP changes the IPv4 and IPv6 on the WAN > > interface. We use NPTv6 to translate ULA addresses for the inner > > IPv6 networks. We use IPv6 privacy on the tun0 int

Re: IPFW: IPv6 and NPTv6 issues: multiple IPv6 addresses confuses IPFW

18.02.2023 18:42, FreeBSD User пишет: On a 24 hour basis, the ISP changes the IPv4 and IPv6 on the WAN interface. We use NPTv6 to translate ULA addresses for the inner IPv6 networks. We use IPv6 privacy on the tun0 interface. The router/firewall is operating after a reboot or restart of mpd5 cor

Re: ipfw: setsockopt(IP_FW_NAT44_XCONFIG): Invalid argument

Thanx very much Цитирую "Alexander V. Chernikov" : On 12 Sep 2021, at 11:51, Yuri Tcherkasov wrote: ipfw nat 1 config ip XXX.XXX.XXX.xx reset unreg_only same_ports Looks pretty close to https://reviews.freebsd.org/D23450 I guess rebuilding the ipf

Re: ipfw: setsockopt(IP_FW_NAT44_XCONFIG): Invalid argument

> On 12 Sep 2021, at 11:51, Yuri Tcherkasov wrote: > > ipfw nat 1 config ip XXX.XXX.XXX.xx reset unreg_only same_ports Looks pretty close to https://reviews.freebsd.org/D23450 I guess rebuilding the ipfw(8) binary should help.

Re: ipfw: setsockopt(IP_FW_NAT44_XCONFIG): Invalid argument

The command is root@gw:/home/tyv # ipfw nat 1 config ip XXX.XXX.XXX.xx reset unreg_only same_ports ipfw nat 1 config ip 195.138.73.206 same_ports unreg_only reset root@gw:/home/tyv # Цитирую "Alexander V. Chernikov" : On 12 Sep 2021, at 06:52, Yuri Tcherkasov wrote: Hi I'm binary up

Re: ipfw: setsockopt(IP_FW_NAT44_XCONFIG): Invalid argument

Thanx, i try. Цитирую "Alexander V. Chernikov" : On 12 Sep 2021, at 06:52, Yuri Tcherkasov wrote: Hi I'm binary upgrade FreeBSD from 10.2 to 13.0 After upgrate all workin well, but I need add one more routing table. So add to GENERIC kernel You can add 'net.fibs=2' in the loader.conf,

Re: ipfw: setsockopt(IP_FW_NAT44_XCONFIG): Invalid argument

Thanx, i try. Цитирую "Alexander V. Chernikov" : On 12 Sep 2021, at 06:52, Yuri Tcherkasov wrote: Hi I'm binary upgrade FreeBSD from 10.2 to 13.0 After upgrate all workin well, but I need add one more routing table. So add to GENERIC kernel You can add 'net.fibs=2' in the loader.conf,

Re: ipfw: setsockopt(IP_FW_NAT44_XCONFIG): Invalid argument

> On 12 Sep 2021, at 06:52, Yuri Tcherkasov wrote: > > Hi > > I'm binary upgrade FreeBSD from 10.2 to 13.0 > > After upgrate all workin well, but I need add one more routing table. So add > to > GENERIC kernel You can add 'net.fibs=2' in the loader.conf, there is no need to recompile the ke

Re: ipfw: manpage: semantics of "receive" and "xmit" interfaces

On Tue, 9 Jan 2018 21:23:54 +0300 "Andrey V. Elsukov" wrote: > On 09.01.2018 12:28, O. Hartmann wrote: > > In section RULE OPTIONS, there is recv|xmit|via explained (a bit). There is > > also an example: > > > > ipfw add deny ip from any to any out recv ed0 xmit ed1 > > > > Can someone explain

Re: ipfw: manpage: semantics of "receive" and "xmit" interfaces

> On 09.01.2018 12:28, O. Hartmann wrote: > > In section RULE OPTIONS, there is recv|xmit|via explained (a bit). There is > > also an example: > > > > ipfw add deny ip from any to any out recv ed0 xmit ed1 > > > > Can someone explain a bit more what the semantics of these is? I get > > especiall

Re: ipfw: manpage: semantics of "receive" and "xmit" interfaces

On 09.01.2018 12:28, O. Hartmann wrote: > In section RULE OPTIONS, there is recv|xmit|via explained (a bit). There is > also an example: > > ipfw add deny ip from any to any out recv ed0 xmit ed1 > > Can someone explain a bit more what the semantics of these is? I get > especially > confused by

Re: ipfw kernel module not being built

On Fri, Aug 11, 2017 at 03:14:39PM -0700, Ngie Cooper wrote: > > > On Aug 11, 2017, at 12:34, Bob Willcox wrote: > > > >> On Fri, Aug 11, 2017 at 12:21:49PM -0700, Mark Johnston wrote: > >> On Fri, Aug 11, 2017 at 02:06:02PM -0500, Bob Willcox wrote: > > On Aug 11, 2017, at 10:36, Bob Willco

Re: ipfw kernel module not being built

> On Aug 11, 2017, at 12:34, Bob Willcox wrote: > >> On Fri, Aug 11, 2017 at 12:21:49PM -0700, Mark Johnston wrote: >> On Fri, Aug 11, 2017 at 02:06:02PM -0500, Bob Willcox wrote: > On Aug 11, 2017, at 10:36, Bob Willcox wrote: > > When I rebuild my kernel on Jun 13th none of the p

Re: ipfw kernel module not being built

On Fri, Aug 11, 2017 at 12:21:49PM -0700, Mark Johnston wrote: > On Fri, Aug 11, 2017 at 02:06:02PM -0500, Bob Willcox wrote: > > > > On Aug 11, 2017, at 10:36, Bob Willcox wrote: > > > > > > > > When I rebuild my kernel on Jun 13th none of the previous ipfw kernel > > > > modules were built: >

Re: ipfw kernel module not being built

On Fri, Aug 11, 2017 at 02:06:02PM -0500, Bob Willcox wrote: > > > On Aug 11, 2017, at 10:36, Bob Willcox wrote: > > > > > > When I rebuild my kernel on Jun 13th none of the previous ipfw kernel > > > modules were built: > > > > > > ipfw.ko > > > ipfw_nat.ko > > > ipfw_nat64.ko > > > ipfw_nptv6

Re: ipfw kernel module not being built

On Fri, Aug 11, 2017 at 12:55:14PM -0600, Ngie Cooper wrote: > > > On Aug 11, 2017, at 10:36, Bob Willcox wrote: > > > > When I rebuild my kernel on Jun 13th none of the previous ipfw kernel > > modules were built: > > > > ipfw.ko > > ipfw_nat.ko > > ipfw_nat64.ko > > ipfw_nptv6.ko > > ng_ipfw

Re: ipfw kernel module not being built

> On Aug 11, 2017, at 10:36, Bob Willcox wrote: > > When I rebuild my kernel on Jun 13th none of the previous ipfw kernel modules > were built: > > ipfw.ko > ipfw_nat.ko > ipfw_nat64.ko > ipfw_nptv6.ko > ng_ipfw.ko > > and only this ipfw module was built: > > ng_ipfw.ko > > However, the ver

Re: IPFW: shape and status in CURRENT

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am Thu, 29 Sep 2016 21:02:16 +0200 "O. Hartmann" schrieb: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > > Since a couple of months now, I use IPFW on several projects. I use IPFW > again after a > long term hiatus since ~ 2003. Before

Re: IPFW on CURRENT: NAT forwarding exposes internal IP!

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am Thu, 29 Sep 2016 16:00:10 +0300 Daniel Kalchev schrieb: Yes, your are right :-) Yes, I'm wrong, it is not NAT :-( Thanks a lot, Oliver > It looks like your httpd server is doing a redirect to your internal IP > address, which > it thinks is

Re: IPFW on CURRENT: NAT forwarding exposes internal IP!

It looks like your httpd server is doing a redirect to your internal IP address, which it thinks is it’s ServerName. Don’t think NAT has anything to do with it. Daniel > On 29.09.2016 г., at 15:47, O. Hartmann wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > > Despite other

Re: IPFW panic on boot

On Tue, Nov 3, 2015, at 21:29, David Wolfskill wrote: > On Tue, Nov 03, 2015 at 09:08:28PM -0600, Mark Felder wrote: > > Recent ipfw commits now cause my firewall to panic on boot. I had to > > revert them and only pull in Adrian's ath fix which was to fix yet a > > different panic I was encounte

Re: IPFW panic on boot

On Tue, Nov 03, 2015 at 09:08:28PM -0600, Mark Felder wrote: > Recent ipfw commits now cause my firewall to panic on boot. I had to > revert them and only pull in Adrian's ath fix which was to fix yet a > different panic I was encountering... :-) > > KDB: stack backtrace: > db_trace_self_wrapper()

Re: ipfw rules for connect port 993

On 8/25/15 4:02 PM, Petr Chocholáč wrote: Hello , ignore my previous email, you have answered my questions here. the firewall set you show is pretty horrible. It really needs a rewrite. do you want to block the two LANs from each other or block any machines on the LANs from reaching the fire

Re: ipfw rules for connect port 993

On 8/24/15 9:05 PM, Petr Chocholáč wrote: Hello, I would like to ask you for advice. I can not connect to imap.gmail.com on port 993 from my local network. My LAN is behind freeBSD server with IPFW. Server has two network cards rl0=Internet and re0=LAN(10.0.0.0/16). Tcpdump on re0 shows three

Re: ipfw rules for connect port 993

Hello , thank you for your answer. ad1. i send my current firewall rules and record from tcpdump on re0 . My LAN is 172.16.0.0/22 (10... it was easy. I think it does not matter) My second LAN is 192.168.1.0/24(on this network connection to the IMAP port 993 works) My public IP is 86.49.91.98 a

Re: ipfw rules for connect port 993

On 2015-08-24 09:05, Petr Chocholáč wrote: > Hello, > > I would like to ask you for advice. I can not connect to imap.gmail.com > on port 993 from my local network. My LAN is behind freeBSD server with > IPFW. Server has two network cards rl0=Internet and > re0=LAN(10.0.0.0/16). Tcpdump on re0 sho

Re: ipfw: fetch doesn't reach ftp://fttp.sites.foo

On Fri, 07 Mar 2014 17:51:11 -0500 Allan Jude wrote: > On 2014-03-07 16:55, O. Hartmann wrote: > > On Fri, 07 Mar 2014 15:33:39 -0500 > > Allan Jude wrote: > > > >> On 2014-03-07 13:57, O. Hartmann wrote: > >>> > >>> Recently I swaitched from pf to ipfw on some CURRENT boxes and for > >>> conv

Re: ipfw: fetch doesn't reach ftp://fttp.sites.foo

On 2014-03-07 16:55, O. Hartmann wrote: > On Fri, 07 Mar 2014 15:33:39 -0500 > Allan Jude wrote: > >> On 2014-03-07 13:57, O. Hartmann wrote: >>> >>> Recently I swaitched from pf to ipfw on some CURRENT boxes and for >>> convenience I used >>> the "workstation" predefinition of FreeBSD. But with

Re: ipfw: fetch doesn't reach ftp://fttp.sites.foo

On Fri, 07 Mar 2014 15:33:39 -0500 Allan Jude wrote: > On 2014-03-07 13:57, O. Hartmann wrote: > > > > Recently I swaitched from pf to ipfw on some CURRENT boxes and for > > convenience I used > > the "workstation" predefinition of FreeBSD. But with that change, all > > access of ports > > via

Re: ipfw: fetch doesn't reach ftp://fttp.sites.foo

On 2014-03-07 13:57, O. Hartmann wrote: > > Recently I swaitched from pf to ipfw on some CURRENT boxes and for > convenience I used the > "workstation" predefinition of FreeBSD. But with that change, all access of > ports via > fetch located at ftp-sites stopped passing the filter. > > Even swi

Re: ipfw build error with WITHOUT_PF (pfvar.h)

On Sat, Nov 23, 2013 at 12:20:40PM +0400, Andrey Chernov wrote: A> > On Sat, Nov 23, 2013 at 12:07:35PM +0400, Andrey Chernov wrote: A> > A> There is a problem in recent -current to build ipfw with WITHOUT_PF A> > A> option, introduced in r257215. altq.c file produce error due to included A> > A>

Re: ipfw build error with WITHOUT_PF (pfvar.h)

On 23.11.2013 12:12, Gleb Smirnoff wrote: > Andrey, > > On Sat, Nov 23, 2013 at 12:07:35PM +0400, Andrey Chernov wrote: > A> There is a problem in recent -current to build ipfw with WITHOUT_PF > A> option, introduced in r257215. altq.c file produce error due to included > A> have following incl

Re: ipfw build error with WITHOUT_PF (pfvar.h)

Andrey, On Sat, Nov 23, 2013 at 12:07:35PM +0400, Andrey Chernov wrote: A> There is a problem in recent -current to build ipfw with WITHOUT_PF A> option, introduced in r257215. altq.c file produce error due to included A> have following includes A> A> #include A> #include A> #include A> A>

Re: IPFW in CURRENT: SMP-friendly?

Am 03/07/13 16:48, schrieb Gleb Smirnoff: > On Thu, Mar 07, 2013 at 01:31:19PM +0100, O. Hartmann wrote: > O> There is work going on to move the OpenBSD pf(1) towards a more SMP > O> friendly entity - this reduces CPU load and should raise throughput. > O> > O> Are there any plans for FreeBSD "nat

Re: IPFW in CURRENT: SMP-friendly?

On Thu, Mar 07, 2013 at 01:31:19PM +0100, O. Hartmann wrote: O> There is work going on to move the OpenBSD pf(1) towards a more SMP O> friendly entity - this reduces CPU load and should raise throughput. O> O> Are there any plans for FreeBSD "native" packet filter IPFW2 to gain the O> same? Or, to

Re: ipfw bug on i386

On Mon, Apr 12, 2010 at 11:15:45AM +0400, Hizel Ildar wrote: > ?? Mon, 12 Apr 2010 10:42:25 +0400 > "Andrey V. Elsukov" ??: > > > On 12.04.2010 10:07, Hizel Ildar wrote: > > > Hey! I'm fix this bug :D > > > > > > patch: > > > > > > foo# diff -ruN main.c~ main.c > > > --- main.c~ 2010-

Re: ipfw bug on i386

В Mon, 12 Apr 2010 10:42:25 +0400 "Andrey V. Elsukov" пишет: > On 12.04.2010 10:07, Hizel Ildar wrote: > > Hey! I'm fix this bug :D > > > > patch: > > > > foo# diff -ruN main.c~ main.c > > --- main.c~ 2010-03-04 19:54:56.0 +0300 > > +++ main.c 2010-04-12 09:37:21.0 +0400

Re: ipfw bug on i386

On 12.04.2010 10:07, Hizel Ildar wrote: Hey! I'm fix this bug :D patch: foo# diff -ruN main.c~ main.c --- main.c~ 2010-03-04 19:54:56.0 +0300 +++ main.c 2010-04-12 09:37:21.0 +0400 @@ -553,7 +553,7 @@ } while (fgets(buf, BUFSIZ, f)) { /* read

Re: ipfw bug on i386

12.04.2010 10:07, Hizel Ildar пишет: В Sun, 11 Apr 2010 11:23:59 +0400 Alex Keda пишет: srv5# more /tmp/a.sh table="24" ipfw table $table flush for octet3 in `jot - 1 60` do for octet4 in `jot - 1 254` do echo "table $table add 192.168.$octet3.$octet4">> /tmp/$$.txt done don

Re: ipfw bug on i386

В Mon, 12 Apr 2010 10:07:56 +0400 Hizel Ildar пишет: > В Sun, 11 Apr 2010 11:23:59 +0400 > Alex Keda пишет: > > > srv5# more /tmp/a.sh > > table="24" > > ipfw table $table flush > > for octet3 in `jot - 1 60` > > do > > for octet4 in `jot - 1 254` > >do > > echo "table $table add 192

Re: ipfw bug on i386

В Sun, 11 Apr 2010 11:23:59 +0400 Alex Keda пишет: > srv5# more /tmp/a.sh > table="24" > ipfw table $table flush > for octet3 in `jot - 1 60` > do > for octet4 in `jot - 1 254` >do > echo "table $table add 192.168.$octet3.$octet4" >> /tmp/$$.txt >done > done > ipfw /tmp/$$.txt > rm

Re: ipfw - default to accept + bootp = confusion.

On Thursday, August 7, 2003, at 02:23 AM, Juli Mallett wrote: * James Quick <[EMAIL PROTECTED]> [ Date: 2003-08-07 ] [ w.r.t. Re: ipfw - default to accept + bootp = confusion. ] On Thursday, August 7, 2003, at 12:22 AM, Juli Mallett wrote: Does someone have any idea what appro

Re: ipfw feature request

You're looking for the "me" keyword. See the manpage for details. A. On Fri Aug 08, 2003 at 08:52:07AM -0400, David Hill wrote: > Hello - > I apologize in advance if this feature is already implemented. > > Is there anyway for ipfw to automatically get the IP from the interface? In > OpenBSD's

Re: ipfw - default to accept + bootp = confusion.

* James Quick <[EMAIL PROTECTED]> [ Date: 2003-08-07 ] [ w.r.t. Re: ipfw - default to accept + bootp = confusion. ] > > On Thursday, August 7, 2003, at 12:22 AM, Juli Mallett wrote: > > > Does someone have any idea what approach to take for the following >

Re: ipfw - default to accept + bootp = confusion.

On Thursday, August 7, 2003, at 12:22 AM, Juli Mallett wrote: Does someone have any idea what approach to take for the following scenario? I'm leaning towards a compile time failure, or an informative panic at the beginning of bootp... You have IPFIREWALL, but not the default to accept option,

Re: IPFW and/or rc rule parsing not working since today's cvsup

just committed a fix cheers luigi On Sun, Jul 13, 2003 at 01:31:07PM +0100, Matt wrote: > > Matt said: > > I normally sync to current once a week and have just done it today: > > > > FreeBSD tao.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sun Jul 13 > > 12:24:40 BST 2003 [

Re: IPFW and/or rc rule parsing not working since today's cvsup

thanks for pointing out -- it turns out that by mistake i have changed the handling of blank lines in ipfw configs. I will restore the old behaviour ASAP (it's a trivial 1-2 line change). cheers luigi On Sun, Jul 13, 2003 at 01:31:07PM +0100, Matt wrote: > > Matt said: >

Re: IPFW and/or rc rule parsing not working since today's cvsup

On Sun, 13 Jul 2003 13:17:36 +0100 (BST), "Matt" wrote: | The problem I have is this. In rc.conf I have the following: | | firewall_enable="YES" | firewall_script="/etc/rc.firewall" | firewall_type="/etc/ipfw.conf" | | And in /etc/ipfw.conf I have sets of rules one line at a time like: | | add

Re: IPFW and/or rc rule parsing not working since today's cvsup

Matt said: > I normally sync to current once a week and have just done it today: > > FreeBSD tao.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sun Jul 13 > 12:24:40 BST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TAO > i386 > > The problem is though that it looks like IPFW or RC has changed h

Re: IPFW/socheckuid() patch

On 03:18+0200, Feb 18, 2003, Giorgos Keramidas wrote: > On 2003-02-18 00:02, Wiktor Niesiobedzki <[EMAIL PROTECTED]> wrote: > > On Mon, Feb 17, 2003 at 11:47:32PM +0100, Wiktor Niesiobedzki wrote: > > There is an obvious mistake in patch (or change in ip_fw2.c should > > be considered). > > [...]

Re: IPFW/socheckuid() patch

On 2003-02-18 00:02, Wiktor Niesiobedzki <[EMAIL PROTECTED]> wrote: > On Mon, Feb 17, 2003 at 11:47:32PM +0100, Wiktor Niesiobedzki wrote: > There is an obvious mistake in patch (or change in ip_fw2.c should > be considered). > [...] > --- sys/kern/uipc_socket.c 2003/02/17 22:37:58 1.144 >

Re: IPFW/socheckuid() patch

On Mon, Feb 17, 2003 at 11:47:32PM +0100, Wiktor Niesiobedzki wrote: [...] There is an obvious mistake in patch (or change in ip_fw2.c should be considered). Cheers, Wiktor Niesiobedzki === RCS file: sys/kern/uipc_socket.c,v retri

Re: ipfw userland breaks again.

[EMAIL PROTECTED] wrote, On 12/14/02 23:13: > I have a patch here which makes the IPFIREWALL_DEFAULT_TO_ACCEPT tunable > at module load time using a kernel environment variable. Looks to me > that it would do what you want. Should we think about kldload logic change ? Loading modules giving th

Re: ipfw userland breaks again.

On Tue, Dec 17, 2002 at 10:23:15AM -0800, Matthew Dillon wrote: > Huh. Interesting. The IP_FW_ADD test threw me but now that I > look at the code more closely it is only there because IP_FW_ADD > is a valid SOPT_GET op as well as a SOPT_SET op. But FLUSH and friends > are SOPT_SE

Re: ipfw userland breaks again.

Huh. Interesting. The IP_FW_ADD test threw me but now that I look at the code more closely it is only there because IP_FW_ADD is a valid SOPT_GET op as well as a SOPT_SET op. But FLUSH and friends are SOPT_SET only. Now I see how it works :-)

Re: ipfw userland breaks again.

In message: <[EMAIL PROTECTED]> Matthew Dillon <[EMAIL PROTECTED]> writes: : Here's a new patch. But there isn't much of a point if we do not : also disallow ipfw DELETE and FLUSH. And the pipe config commands : as well as anything else that changes the firewall state. Fi

Re: ipfw userland breaks again.

:How this could be helpful in a remote upgrade scenario that has :IPFW ABI incompatibility issues? : :One alternative approach would be to not compile IPFW into a :kernel but rather have it loaded as a module. Then, you :install new kernel, edit out ipfw_enable=3D"YES" for the time :being, reboot

Re: ipfw userland breaks again.

On Mon, 16 Dec 2002, Ruslan Ermilov wrote: > On Sat, Dec 14, 2002 at 02:09:13PM -0800, Matthew Dillon wrote: > > > > : > > :On Sat, Dec 14, 2002 at 12:38:13PM -0800, Matthew Dillon wrote: > > :> then, as usual, IPFW with the new kernel and > > :> old world fails utterly and now the frag

Re: ipfw userland breaks again.

On Sat, Dec 14, 2002 at 02:09:13PM -0800, Matthew Dillon wrote: > > : > :On Sat, Dec 14, 2002 at 12:38:13PM -0800, Matthew Dillon wrote: > :> then, as usual, IPFW with the new kernel and > :> old world fails utterly and now the fragging machine can't access the > : > :Hear hear!! I am ><

Re: ipfw userland breaks again.

On Sun, Dec 15, 2002 at 08:47:23PM +, Nik Clayton wrote: > On Sun, Dec 15, 2002 at 11:08:01AM -0800, Matthew Dillon wrote: > > > > : > > ::This is complete BULLSHIT, Warner. > > : > > :Your attitude it totally unacceptible. Learn to play well with > > :others, or get the fuck out of the

Re: ipfw userland breaks again.

On Sun, Dec 15, 2002 at 11:08:01AM -0800, Matthew Dillon wrote: > > : > ::This is complete BULLSHIT, Warner. > : > :Your attitude it totally unacceptible. Learn to play well with > :others, or get the fuck out of the project. > > Really? You think I should learn to play well with oth

Re: ipfw userland breaks again.

What it comes down to is what developers are willing to do. My contribution is 'ipfw unbreak'. If someone else has a solution that they are willing to work on and commit in the next four weeks, then fine. But if nobody is willing to work on and commit another solution in the next

Re: ipfw userland breaks again.

On Sun, 15 Dec 2002, Matthew Dillon wrote: > Here's a new patch. But there isn't much of a point if we do not > also disallow ipfw DELETE and FLUSH. And the pipe config commands > as well as anything else that changes the firewall state. Firewalls > are there to protect the syste

Re: ipfw userland breaks again.

< said: > If people are reasonable with me, I am reasonable right back. If > people are unreasonable, they shouldn't expect me to be reasonable > in response. It's really that simple. As a FreeBSD developer, you are expected to be civil to your fellow developers at all times, as sta

Re: ipfw userland breaks again.

: :< said: : :> Now you are forcing me to go to core. It's absolutely ridiculous and :> you know it. Goddamn it, next time I won't even bother posting if all :> I get is this sort of crap. : :All the better, if you refuse to be civil to your fellow developers. : :-GAWollman If p

Re: ipfw userland breaks again.

:I've answered this in other email, but you need to expand the check at :the top of ipfw_ctl to include this new message as one of the ones :that is disallowed at high security levels. : :Warner Here's a new patch. But there isn't much of a point if we do not also disallow ipfw DELETE and

Re: ipfw userland breaks again.

< said: > Now you are forcing me to go to core. It's absolutely ridiculous and > you know it. Goddamn it, next time I won't even bother posting if all > I get is this sort of crap. All the better, if you refuse to be civil to your fellow developers. -GAWollman To Unsubscribe: sen

Re: ipfw userland breaks again.

:Also, fixing the ipfw2 abi is probably a good item to put on the list :for getting 5.x to 5-STABLE. Please don't waste time with band-aids :that will make people forget that ipfw2 needs attention. : :Scott This is a reasonable line of argument but my opinion is that it hasn't been fix

Re: ipfw userland breaks again.

Matthew Dillon wrote: > [ useless drivel removed ] There's still a TODO list for 5.0. It was even mailed out to developers@ this morning. If you have time to spare in your day, please focus your attention to that right now. Also, fixing the ipfw2 abi is probably a good item to put on the lis

Re: ipfw userland breaks again.

In message: <[EMAIL PROTECTED]> Matthew Dillon <[EMAIL PROTECTED]> writes: : When people say and do reasonable things I am a reasonable guy. When : people say and do unreasonable things then I fight tooth and nail. : It's that simple. If you don't like it, then tough.

Re: ipfw userland breaks again.

In message: <[EMAIL PROTECTED]> Matthew Dillon <[EMAIL PROTECTED]> writes: : : : : ::This is complete BULLSHIT, Warner. : : : :Your attitude it totally unacceptible. Learn to play well with : :others, or get the fuck out of the project. : : : :I am *NOT* blocking you. I'm telli

Re: ipfw userland breaks again.

: ::This is complete BULLSHIT, Warner. : :Your attitude it totally unacceptible. Learn to play well with :others, or get the fuck out of the project. Really? You think I should learn to play well with others? You think it's appropriate to request that I spend a man week rewriti

Re: ipfw userland breaks again.

: ::This is complete BULLSHIT, Warner. : :Your attitude it totally unacceptible. Learn to play well with :others, or get the fuck out of the project. : :I am *NOT* blocking you. I'm telling you you need to get the SO's :sign off to make sure that there isn't a security issue because the :c

Re: ipfw userland breaks again.

: :In message: <[EMAIL PROTECTED]> :Matthew Dillon <[EMAIL PROTECTED]> writes: :: : :: :The real fix is to fix the abi problems. :: : :: :Warner :: :: Doh!!Thanks for volunteering to fix the ABI problems. No? You :: don't want to do it? Gee, I saw that one coming a mile

Re: ipfw userland breaks again.

In message: <[EMAIL PROTECTED]> Matthew Dillon <[EMAIL PROTECTED]> writes: : : : :The real fix is to fix the abi problems. : : : :Warner : : Doh!!Thanks for volunteering to fix the ABI problems. No? You : don't want to do it? Gee, I saw that one coming a mile away! :

Re: ipfw userland breaks again.

:This is complete BULLSHIT, Warner. Your attitude it totally unacceptible. Learn to play well with others, or get the fuck out of the project. I am *NOT* blocking you. I'm telling you you need to get the SO's sign off to make sure that there isn't a security issue because the current defa

Re: ipfw userland breaks again.

On Sun, 15 Dec 2002 10:26:22 -0800 (PST) Matthew Dillon <[EMAIL PROTECTED]> wrote: Hi, must...resist... > So don't give me this bullshit about the patch being a security > issue. YOU KNOW IT ISN'T. No, Warner has a point, that patch is simply bandaid (albeit a good one). > Now you

Re: ipfw userland breaks again.

:How about sending the patch to the Technical Review Board, trb@ instead. : :Thanks. : :Cheers, : :-- :Anders. Getting bored sitting on your buns? It's already gone to core and, frankly, I think core is the proper forum now that Warner has declared it a security issue (when it obvio

Re: ipfw userland breaks again.

Hi, On Sun, Dec 15, 2002 at 10:26:22AM -0800, Matthew Dillon wrote: > This is complete BULLSHIT, Warner. This patch exists precisely so > the firewall can be turned on in secure mode. It does not make it > any easier to turn off then adding a rule: > > ipfw add 2 allow all from

Re: ipfw userland breaks again.

: :The real fix is to fix the abi problems. : :Warner Doh!!Thanks for volunteering to fix the ABI problems. No? You don't want to do it? Gee, I saw that one coming a mile away! THEN DON'T COMPLAIN. This is not a fucking security issue. This is a patch that solves a ma

Re: ipfw userland breaks again.

:I don't like the patch from a security standpoint. It makes it to :easy to turn off a firewall. If you want to be that stupid about :security, you should just make the default be 'accept all' and be done :with it. I'm opposed to this patch unless you can get the security :officer to sign off on

Re: ipfw userland breaks again.

In message: <[EMAIL PROTECTED]> Matthew Dillon <[EMAIL PROTECTED]> writes: : :I disagree with committing this hack; keep it as a local mod if you must. : : : :As to the problem; don't wait for Luigi to "fix the ABI problems", do it : :yourself. Good things happen when folks are PO'd a

Re: ipfw userland breaks again.

:I disagree with committing this hack; keep it as a local mod if you must. : :As to the problem; don't wait for Luigi to "fix the ABI problems", do it :yourself. Good things happen when folks are PO'd and won't settle for the :status quo. : :Sam I'm sorry you disagree, but it doesn't chan

Re: ipfw userland breaks again.

> :Now I would really dislike seeing your patch in the tree, since I > :consider it's a rather crude hack to circumvent the ABI problems of > :ipfw. As I've already said to luigi in private e-mail (I would be > :surprised if this hasn't been already discussed in the lists as well), > :the proper w

Re: ipfw userland breaks again.

:Now I would really dislike seeing your patch in the tree, since I :consider it's a rather crude hack to circumvent the ABI problems of :ipfw. As I've already said to luigi in private e-mail (I would be :surprised if this hasn't been already discussed in the lists as well), :the proper way to fi

Re: ipfw userland breaks again.

Matthew Dillon wrote: > :I have a patch here which makes the IPFIREWALL_DEFAULT_TO_ACCEPT tunable > :at module load time using a kernel environment variable. Looks to me > :that it would do what you want. > > No, this isn't what I want. I want something that can be articulated > without

Re: ipfw userland breaks again.

: :I have a patch here which makes the IPFIREWALL_DEFAULT_TO_ACCEPT tunable :at module load time using a kernel environment variable. Looks to me :that it would do what you want. : :Maxime No, this isn't what I want. I want something that can be articulated without having to reboot the

  1   2   >