Re:?

Re:?

[Ian Latter]

Hello Eugen,

  I'm sorry but I'm not the H323 author ... and I haven't used netfilter H323
support since ipchains.  I have CCd the netfilter list in case someone 
there can help.





----- Original Message -----
>From: "Soporte Meranetwork" <mera@fibertel.com.ar>
>To: <Ian.Latter@mq.edu.au>
>Subject:  ?
>Date: Mon, 31 Mar 2003 18:56:17 -0300
>
> Good day.I have used IPTabels 1.2.5-3,and dont know that it have or not H323 modul .But 
for recive Call from outside(internet) to inside(throught NAT) - Netmeeting(ATA 186) i use 
thet rules: 
> $IPTABLES -t nat -A POSTROUTING -o $EXTIF -s 192.168.0.0/24 -j MASQUERADE 
>   (intern LAN)
> PORTFWIP="192.168.0.201" ( PC with Netmeting or ATA 186)
> $IPTABLES -A FORWARD -i $EXTIF -o $INTIF -p tcp --dport 1720 -m state --state
> NEW,ESTABLISHED,RELATED -j ACCEPT
> $IPTABLES -A PREROUTING -t nat -p tcp -d $EXTIP --dport 1720 -j DNAT --to 
$PORTFWIP:1720
> But i want to use NAT without  FORWARD ,PREROUTING with H323 ability for any IP in 
LAN.Where i can find IPtables with ability of H323(version) or where is the patch(modul) for 
that ability? Thank your. 
> Buy,
> Eugen

--
Ian Latter
Internet and Networking Security Officer
Macquarie University

Re:

[David Stes]

> Date: Mon, 12 Sep 2005 16:29:38 +0000
> From: Cory Visi <merlin@gentoo.org>
> Subject: patchlets patch submission
> To: netfilter-devel@lists.netfilter.org
> Message-ID: <20050912162938.GB15843@toucan.gentoo.org>
> Content-Type: text/plain; charset="us-ascii"
> 
> I did some work on fixing the conntrack pom addons for the lockhelp.h 
> patch (2.6.13 support essentially). I think I got everything setup except 
> for 2 files.
> 
> Attached is all my work in patch form against a full kernel source. I have 
> a feeling you'd prefer I sent this in some other format or in some other 
> structure of a diff. This is my first time contributing so just let me 
> know how you'd prefer this in the future.
> 
> What's left is:
> - rtsp (part of rsh)

Did you also do the RPC modules ? (RPC for UDP/TCP)

I wonder whether the author(s) of RSH/RPC modules are still reading this list.

If they are, then maybe your 2.6.13 patch (and my older 2.6.12 patches)
could be incorporated.  If they are not, then maybe it's time to see how
future changes to these modules can be coordinated.

Re:

[Patrick McHardy]

Jan Engelhardt wrote:
> Hi,
> 
> 
> here are a number of patches I am suggesting for the -master branch
> (-stable is separate in my view and my management, but see other
> discussion thread).
> Pullable from
> 	git://dev.medozas.de/iptables master
> 
> 
> Jan Engelhardt (9):
>       libiptc: split v4 and v6
>       extensions: collapse registration structures
>       iptables: allow for parse-less extensions
>       iptables: allow for help-less extensions
>       extensions: remove empty help and parse functions
>       xtables: add multi-registration functions
>       extensions: collapse data variables to use multi-reg calls
>       xtables: warn of missing version identifier in extensions
>       COMMIT_NOTES: notice to check for soversion bumps
> 
> Michael Granzow (1):
>       iptables: accept multiple IP address specifications for -s, -d

Looks good, pulled and pushed out again, thanks.

> (Shall I post the entire mergestat, or just the "X files changed" line?)

This is fine, I mainly want something comparable to the git pull output.

Re:

[Patrick McHardy]

Jan Engelhardt wrote:
> Hi Patrick,
> 
> Please pull from
> 	git://dev.medozas.de/iptables master
> 
> which contains a pack of patches to build iptables without libdl,
> obsoleting iptables-static (leaving -multi) and using the -multi
> program exclusively.

Pulled and pushed out again, thanks.

Re:

[Patrick McHardy]

Jan Engelhardt wrote:
> Please pull from
> 	git://dev.medozas.de/iptables master
> 
> to receive
> 
> Jan Engelhardt (2+1):
>       xt_conntrack: revision 2 for enlarged state_mask member
>       libxt_helper: fix invalid passed option to check_inverse

Pulled and pushed back out again, thanks.

(unknown),

[Jan Engelhardt]

Hi,


here are three commits that fix bugzilla entries and/or other
problems encountered. There are also two extra commits prepended
without any changes, which only provide missing log entries for
already-merged commits.


The following changes since commit 7fa7329fc972513021131416dbd9d535141bd2ea:
  Jan Engelhardt (1):
        iprange: roll address parsing into a loop

are available in the git repository at:

  git://dev.medozas.de/iptables master

Jan Engelhardt (4):
      iprange: do accept non-ranges for xt_iprange v1 (log)
      iprange: warn on reverse range (log)
      libiptc: fix wrong maptype of base chain counters on restore
      iptables: fix undersized deletion mask creation

Olaf Rempel (1):
      build: restore --disable-ipv6 functionality on system w/o v6 headers

 ip6tables.c       |   14 ++++++++------
 iptables.c        |   14 ++++++++------
 libiptc/libiptc.c |    2 +-
 xtables.c         |    3 ++-
 4 files changed, 19 insertions(+), 14 deletions(-)

[PATCH 1/3] build: restore --disable-ipv6 functionality on system w/o v6 headers

[Jan Engelhardt]

From: Olaf Rempel <razzor@kopf-tisch.de>

Commit 332e4acc (iptables: accept multiple IP address specifications
for -s, d) broke the --disable-ipv6 configure option.

> ./.libs/libxtables.so: undefined reference to `in6addr_any'

Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
 xtables.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/xtables.c b/xtables.c
index 4520124..bda49f8 100644
--- a/xtables.c
+++ b/xtables.c
@@ -1484,6 +1484,7 @@ void
 xtables_ip6parse_multiple(const char *name, struct in6_addr **addrpp,
 		      struct in6_addr **maskpp, unsigned int *naddrs)
 {
+	static const struct in6_addr zero_addr;
 	struct in6_addr *addrp;
 	char buf[256], *p;
 	unsigned int len, i, j, n, count = 1;
@@ -1526,7 +1527,7 @@ xtables_ip6parse_multiple(const char *name, struct in6_addr **addrpp,
 		memcpy(*maskpp + i, addrp, sizeof(*addrp));
 
 		/* if a null mask is given, the name is ignored, like in "any/0" */
-		if (memcmp(*maskpp + i, &in6addr_any, sizeof(in6addr_any)) == 0)
+		if (memcmp(*maskpp + i, &zero_addr, sizeof(zero_addr)) == 0)
 			strcpy(buf, "::");
 
 		addrp = ip6parse_hostnetwork(buf, &n);
-- 
1.6.5.1

[PATCH 2/3] libiptc: fix wrong maptype of base chain counters on restore

[Jan Engelhardt]

When a ruleset that does not reset any chain policies/counters, such as

	*filter
	COMMIT

is sourced by iptables-restore, the previous policy and counters
(i.e. the ones read from the kernel) are reused. The counter skew
offsetting is wrong however, causing the read value to be readded to
the kernel value. This manifests itself in practice by the counter
value almost doubling everytime iptables-restore is called.

Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
 libiptc/libiptc.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libiptc/libiptc.c b/libiptc/libiptc.c
index 670acf5..7a9c742 100644
--- a/libiptc/libiptc.c
+++ b/libiptc/libiptc.c
@@ -829,7 +829,7 @@ static int __iptcc_p_del_policy(struct xtc_handle *h, unsigned int num)
 
 		/* save counter and counter_map information */
 		h->chain_iterator_cur->counter_map.maptype =
-						COUNTER_MAP_NORMAL_MAP;
+						COUNTER_MAP_ZEROED;
 		h->chain_iterator_cur->counter_map.mappos = num-1;
 		memcpy(&h->chain_iterator_cur->counters, &pr->entry->counters,
 			sizeof(h->chain_iterator_cur->counters));
-- 
1.6.5.1

[PATCH 3/3] iptables: fix undersized deletion mask creation

[Jan Engelhardt]

The mask created for the -D rulespec is simply too small.
xtables_targets points to whatever target has last been loaded, so
xtables_targets->size is quite almost wrong, as we need to use the
size of the target for the specific rule that is about to be deleted.

This bug existed ever since iptables history is tracked, and requires
certain circumstances to be visible, where the deletion operation is
one. Furthermore, multiple userspace target extensions must have been
loaded, and a target B whose .size is smaller than the target A of
the rule we are about to delete must have been loaded more recently
than target A. The minimal testcase is (rule 60007 gets wrongly
removed)

	*nat
	-F
	-X
	-A POSTROUTING -p udp -j SNAT --to 192.168.1.1:60007
	-A POSTROUTING -p udp -j SNAT --to 192.168.1.1:60008
	-A POSTROUTING -p udp -j CONNMARK --set-mark 0
	-D POSTROUTING -p udp -j SNAT --to 192.168.1.1:60008
	COMMIT

References: http://bugzilla.netfilter.org/show_bug.cgi?id=606
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
 ip6tables.c |   14 ++++++++------
 iptables.c  |   14 ++++++++------
 2 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/ip6tables.c b/ip6tables.c
index 8f653e8..53a1a5d 100644
--- a/ip6tables.c
+++ b/ip6tables.c
@@ -803,7 +803,8 @@ insert_entry(const ip6t_chainlabel chain,
 }
 
 static unsigned char *
-make_delete_mask(struct xtables_rule_match *matches)
+make_delete_mask(struct xtables_rule_match *matches,
+		 const struct xtables_target *target)
 {
 	/* Establish mask for comparison */
 	unsigned int size;
@@ -816,7 +817,7 @@ make_delete_mask(struct xtables_rule_match *matches)
 
 	mask = xtables_calloc(1, size
 			 + IP6T_ALIGN(sizeof(struct ip6t_entry_target))
-			 + xtables_targets->size);
+			 + target->size);
 
 	memset(mask, 0xFF, sizeof(struct ip6t_entry));
 	mptr = mask + sizeof(struct ip6t_entry);
@@ -830,7 +831,7 @@ make_delete_mask(struct xtables_rule_match *matches)
 
 	memset(mptr, 0xFF,
 	       IP6T_ALIGN(sizeof(struct ip6t_entry_target))
-	       + xtables_targets->userspacesize);
+	       + target->userspacesize);
 
 	return mask;
 }
@@ -846,13 +847,14 @@ delete_entry(const ip6t_chainlabel chain,
 	     const struct in6_addr dmasks[],
 	     int verbose,
 	     struct ip6tc_handle *handle,
-	     struct xtables_rule_match *matches)
+	     struct xtables_rule_match *matches,
+	     const struct xtables_target *target)
 {
 	unsigned int i, j;
 	int ret = 1;
 	unsigned char *mask;
 
-	mask = make_delete_mask(matches);
+	mask = make_delete_mask(matches, target);
 	for (i = 0; i < nsaddrs; i++) {
 		fw->ipv6.src = saddrs[i];
 		fw->ipv6.smsk = smasks[i];
@@ -1938,7 +1940,7 @@ int do_command6(int argc, char *argv[], char **table, struct ip6tc_handle **hand
 				   nsaddrs, saddrs, smasks,
 				   ndaddrs, daddrs, dmasks,
 				   options&OPT_VERBOSE,
-				   *handle, matches);
+				   *handle, matches, target);
 		break;
 	case CMD_DELETE_NUM:
 		ret = ip6tc_delete_num_entry(chain, rulenum - 1, *handle);
diff --git a/iptables.c b/iptables.c
index 7228721..1160171 100644
--- a/iptables.c
+++ b/iptables.c
@@ -805,7 +805,8 @@ insert_entry(const ipt_chainlabel chain,
 }
 
 static unsigned char *
-make_delete_mask(struct xtables_rule_match *matches)
+make_delete_mask(struct xtables_rule_match *matches,
+		 const struct xtables_target *target)
 {
 	/* Establish mask for comparison */
 	unsigned int size;
@@ -818,7 +819,7 @@ make_delete_mask(struct xtables_rule_match *matches)
 
 	mask = xtables_calloc(1, size
 			 + IPT_ALIGN(sizeof(struct ipt_entry_target))
-			 + xtables_targets->size);
+			 + target->size);
 
 	memset(mask, 0xFF, sizeof(struct ipt_entry));
 	mptr = mask + sizeof(struct ipt_entry);
@@ -832,7 +833,7 @@ make_delete_mask(struct xtables_rule_match *matches)
 
 	memset(mptr, 0xFF,
 	       IPT_ALIGN(sizeof(struct ipt_entry_target))
-	       + xtables_targets->userspacesize);
+	       + target->userspacesize);
 
 	return mask;
 }
@@ -848,13 +849,14 @@ delete_entry(const ipt_chainlabel chain,
 	     const struct in_addr dmasks[],
 	     int verbose,
 	     struct iptc_handle *handle,
-	     struct xtables_rule_match *matches)
+	     struct xtables_rule_match *matches,
+	     const struct xtables_target *target)
 {
 	unsigned int i, j;
 	int ret = 1;
 	unsigned char *mask;
 
-	mask = make_delete_mask(matches);
+	mask = make_delete_mask(matches, target);
 	for (i = 0; i < nsaddrs; i++) {
 		fw->ip.src.s_addr = saddrs[i].s_addr;
 		fw->ip.smsk.s_addr = smasks[i].s_addr;
@@ -1979,7 +1981,7 @@ int do_command(int argc, char *argv[], char **table, struct iptc_handle **handle
 				   nsaddrs, saddrs, smasks,
 				   ndaddrs, daddrs, dmasks,
 				   options&OPT_VERBOSE,
-				   *handle, matches);
+				   *handle, matches, target);
 		break;
 	case CMD_DELETE_NUM:
 		ret = iptc_delete_num_entry(chain, rulenum - 1, *handle);
-- 
1.6.5.1

Re:

[Patrick McHardy]

Jan Engelhardt wrote:
> here are three commits that fix bugzilla entries and/or other
> problems encountered. There are also two extra commits prepended
> without any changes, which only provide missing log entries for
> already-merged commits.

Just to clarify before I apply this - how does adding changelog
entries afterwards work? Am I correct to assume that this won't
affect this history of the tree and existing clones?

Re:

[Jan Engelhardt]

On Thursday 2009-10-29 23:26, Patrick McHardy wrote:

>Jan Engelhardt wrote:
>> here are three commits that fix bugzilla entries and/or other
>> problems encountered. There are also two extra commits prepended
>> without any changes, which only provide missing log entries for
>> already-merged commits.
>
>Just to clarify before I apply this - how does adding changelog
>entries afterwards work? Am I correct to assume that this won't
>affect this history of the tree and existing clones?

I just used `git commit --allow-empty -e` to record a plain commit on 
top, just without any change in the tree object. Take a look in 
git-forest/gitk if in doubt ;-)

Re:

[Patrick McHardy]

Jan Engelhardt wrote:
> On Thursday 2009-10-29 23:26, Patrick McHardy wrote:
> 
>> Jan Engelhardt wrote:
>>> here are three commits that fix bugzilla entries and/or other
>>> problems encountered. There are also two extra commits prepended
>>> without any changes, which only provide missing log entries for
>>> already-merged commits.
>> Just to clarify before I apply this - how does adding changelog
>> entries afterwards work? Am I correct to assume that this won't
>> affect this history of the tree and existing clones?
> 
> I just used `git commit --allow-empty -e` to record a plain commit on 
> top, just without any change in the tree object. Take a look in 
> git-forest/gitk if in doubt ;-)

Nice. Pulled and pushed out again, thanks.

Re: [PATCH 3/3] iptables: fix undersized deletion mask creation

[Patrick McHardy]

Jan Engelhardt wrote:
> The mask created for the -D rulespec is simply too small.
> xtables_targets points to whatever target has last been loaded, so
> xtables_targets->size is quite almost wrong, as we need to use the
> size of the target for the specific rule that is about to be deleted.
> 
> This bug existed ever since iptables history is tracked, and requires
> certain circumstances to be visible, where the deletion operation is
> one. Furthermore, multiple userspace target extensions must have been
> loaded, and a target B whose .size is smaller than the target A of
> the rule we are about to delete must have been loaded more recently
> than target A. The minimal testcase is (rule 60007 gets wrongly
> removed)
> 
> 	*nat
> 	-F
> 	-X
> 	-A POSTROUTING -p udp -j SNAT --to 192.168.1.1:60007
> 	-A POSTROUTING -p udp -j SNAT --to 192.168.1.1:60008
> 	-A POSTROUTING -p udp -j CONNMARK --set-mark 0
> 	-D POSTROUTING -p udp -j SNAT --to 192.168.1.1:60008
> 	COMMIT
> 
> References: http://bugzilla.netfilter.org/show_bug.cgi?id=606

Very nice catch, thanks Jan.

Re:

[William Wilcox]

Good day!
My name is Sir William Wilcox,I work with the Euro Lottery. I can help you
win 4,528,000 GBP.But I charge 40% of the winning.Can we do this deal
together? Email me; william.wilcox98@gmail.com

Re:

[Mistick Levi]

What's up with all those mail's about business proposal's that are
sent to the mailing list?!

On Sat, Oct 9, 2010 at 7:26 PM, Mr.Young Chang <info@yahoo.com> wrote:
> My name is Mr.Young Chang,Credit officer MEVAS BANK,HK.I have a Business
> Proposal of $19.7 million usd for you to handle with me.Are you interested?
>
>
>
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re:

[James Brown]

https://docs.google.com/document/d/1yAkUys2osN7co_KbzphWLLsoe-TPq7ELZhoySYvzjF0/edit

RE:

[W. Cheung]

 I have a very lucrative business transaction which requires the utmost discretion. If you are interested, kindly contact me ASAP for full details.

Warm Regards,
William Cheung

Re:

[christain147]

Good day,hoping you read this email and respond to me in good time.I do not intend to solicit for funds but  your time and energy in using my own resources to assist the less privileged.I am medically confined at the moment hence I request your indulgence.
I will give you a comprehensive brief once I hear from you.

Please forward your response to my private email address:
gudworks104@yahoo.com

Thanks and reply.

Robert Grondahl

RE:

[JO Bower]

Your email address has brought you an unexpected luck, which was selected in The Euro Millions Lottery and subsequently won you the sum of €1,000,000.00 Euros. Contact Monica Torres Email: monicatorresesp@gmail.com to claim your prize.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE:

[Qin's Yanjun]

----
How are you today and your family? I require your attention and honest
co-operation about some issues which i will really want to discuss with you
which.  Looking forward to read from you soon.  

Qin's


______________________________

Sky Silk, http://aknet.kz

Re:

[Amos Kalonzo]

Attn:

I am wondering why You haven't respond to my email for some days now.
reference to my client's contract balance payment of (11.7M,USD)
Kindly get back to me for more details.

Best Regards

Amos Kalonzo

Re:

[Pablo Neira Ayuso]

On Wed, Aug 27, 2025 at 10:43:42PM +0800, Zhang Tengfei wrote:
> Hi everyone,
> 
> Here is the v2 patch that incorporates the feedback.

Patch without subject will not fly too far, I'm afraid you will have
to resubmit. One more comment below.

> Many thanks to Julian for his thorough review and for providing 
> the detailed plan for this new version, and thanks to Florian 
> and Eric for suggestions.
> 
> Subject: [PATCH v2] net/netfilter/ipvs: Use READ_ONCE/WRITE_ONCE for
>  ipvs->enable
> 
> KCSAN reported a data-race on the `ipvs->enable` flag, which is
> written in the control path and read concurrently from many other
> contexts.
> 
> Following a suggestion by Julian, this patch fixes the race by
> converting all accesses to use `WRITE_ONCE()/READ_ONCE()`.
> This lightweight approach ensures atomic access and acts as a
> compiler barrier, preventing unsafe optimizations where the flag
> is checked in loops (e.g., in ip_vs_est.c).
> 
> Additionally, the now-obsolete `enable` checks in the fast path
> hooks (`ip_vs_in_hook`, `ip_vs_out_hook`, `ip_vs_forward_icmp`)
> are removed. These are unnecessary since commit 857ca89711de
> ("ipvs: register hooks only with services").
> 
> Reported-by: syzbot+1651b5234028c294c339@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=1651b5234028c294c339
> Suggested-by: Julian Anastasov <ja@ssi.bg>
> Link: https://lore.kernel.org/lvs-devel/2189fc62-e51e-78c9-d1de-d35b8e3657e3@ssi.bg/
> Signed-off-by: Zhang Tengfei <zhtfdev@gmail.com>
> 
> ---
> v2:
> - Switched from atomic_t to the suggested READ_ONCE()/WRITE_ONCE().
> - Removed obsolete checks from the packet processing hooks.
> - Polished commit message based on feedback.
> ---
>  net/netfilter/ipvs/ip_vs_conn.c |  4 ++--
>  net/netfilter/ipvs/ip_vs_core.c | 11 ++++-------
>  net/netfilter/ipvs/ip_vs_ctl.c  |  6 +++---
>  net/netfilter/ipvs/ip_vs_est.c  | 16 ++++++++--------
>  4 files changed, 17 insertions(+), 20 deletions(-)
[...]
> diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
> index c7a8a08b7..5ea7ab8bf 100644
> --- a/net/netfilter/ipvs/ip_vs_core.c
> +++ b/net/netfilter/ipvs/ip_vs_core.c
> @@ -1353,9 +1353,6 @@ ip_vs_out_hook(void *priv, struct sk_buff *skb, const struct nf_hook_state *stat
>  	if (unlikely(!skb_dst(skb)))
>  		return NF_ACCEPT;
>  
> -	if (!ipvs->enable)
> -		return NF_ACCEPT;

Patch does say why is this going away? If you think this is not
necessary, then make a separated patch and example why this is needed?

Thanks

>  	ip_vs_fill_iph_skb(af, skb, false, &iph);
>  #ifdef CONFIG_IP_VS_IPV6
>  	if (af == AF_INET6) {