search for: debugp

...mponent: ip_tables (kernel) AssignedTo: laforge@netfilter.org ReportedBy: georg.wild@gmx.de CC: netfilter-buglog@lists.netfilter.org I got errors compiling kernel modules; I think this is caused by gcc 3.3, which doesn't allow multiline strings any more?: DEBUGP("calling nat helper (exp=%p) for packet\n", exp); ip_nat_core.c:854:40: missing terminating " character ip_nat_core.c:855:49: missing terminating " character ip_nat_core.c:1038:1: unterminated argument list invoking macro "DEBUGP" ip_nat_core.c: In function `do_...

...is :( For now we use TCP source port. This breaks * multiple calls within one control session */ /* save original call ID in nat_info */ nat_pptp_info->pns_call_id = ct_pptp_info->pns_call_id; /* He Yi Oct 22, 2006 */ if( inet_addr_type(iph->daddr) == RTN_LOCAL ) { DEBUGP("DO NOT CHANGE PPTP CALL ID FOR LOCAL SERVICE!\n"); new_callid = ct_pptp_info->pns_call_id; } else { /* NATed src port is the dst port of the reply */ new_callid = ct->tuplehash [IP_CT_DIR_REPLY].tuple.dst.u.tcp.port; } /* save new call ID in ct info */ ct...

...et/ipv4/netfilte= r/ip_conntrack_core.c linux-2.4.20-del/net/ipv4/netfilter/ip_conntrack_core= =2Ec --- linux-2.4.20-base/net/ipv4/netfilter/ip_conntrack_core.c Tue Feb 18 17:= 08:21 2003 +++ linux-2.4.20-del/net/ipv4/netfilter/ip_conntrack_core.c Fri Feb 21 17:0= 1:39 2003 @@ -292,9 +292,6 @@ { DEBUGP("clean_from_lists(%p)\n", ct); MUST_BE_WRITE_LOCKED(&ip_conntrack_lock); - /* Remove from both hash lists: must not NULL out next ptrs, - otherwise we'll look unconfirmed. Fortunately, LIST_DELETE - doesn't do this. --RR */ LIST_DELETE(&ip_conntrac...

I'm wonder if anyone happens to have a simplier (slower) version of bsd-snprintf.c. It seems NeXT 3.3 (unsure about 4.2) is missing mprotect(). If I could get something to replace that for a while and fix some of theses utmp in login.c issues I may have a rough port NeXT to black hardware.=) Thanks

...(padlen < 0) { dopr_outch(' '); ++padlen; } } static void fmtnum(long_long value, int base, int dosign, int ljust, int len, int zpad) { int signvalue = 0; ulong_long uvalue; char convert[64]; int place = 0; int padlen = 0; /* amount to pad */ int caps = 0; /* * DEBUGP(("value 0x%x, base %d, dosign %d, ljust %d, len %d, zpad * %d\n", value, base, dosign, ljust, len, zpad )); */ uvalue = value; if (dosign) { if (value < 0) { signvalue = '-'; uvalue = -value; } } if (base < 0) { caps = 1; base = -base; } do { c...

...hile in case of builtin chains - will not flush and duplicate the entry. For instance: *nat -I PREROUTING -m addrtype --dst-type LOCAL -j DOCKER COMMIT I believe the bug is in iptables-restore.c line 369 if (noflush && ops->is_chain(chain, handle)) { DEBUGP("Flushing existing user defined chain '%s'\n", chain); if (!ops->flush_entries(chain, handle)) xtables_error(PARAMETER_PROBLEM, "error flushing chain " "'...

...n't occur: * if the NAT box is a gateway, and the connection is initiated on another box. * if the connection is not initiated, but accepted As SNAT happens at NF_IP_POST_ROUTING, reply translation will be performed at NF_IP_PRE_ROUTING. The following DEBUG output shows what happens (enabled DEBUGP at the top of ip_nat_core.c): icmp reply translation, ct=c3617480, hooknum=0, ctinfo=4 icmp_reply_translation: translating error c396f260 hook 0 dir REPLY, num_manips=2 icmp_reply: manip 0 dir ORIG hook 4 icmp_reply: manip 1 dir REPLY hook 0 icmp_reply: outer DST -> 192.168.131.124 As it seems...

...struct ip_ct_irc *info =3D &ct->help.ct_irc_info; =20 - - memset(&mask, 0, sizeof(struct ip_conntrack_tuple)); - - mask.dst.u.tcp.port =3D 0xFFFF; - - mask.dst.protonum =3D 0xFFFF; + mask =3D ((struct ip_conntrack_tuple) + { { 0, { 0 } }, + { 0xFFFFFFFF, { 0xFFFF }, 0xFFFF }}); =20 DEBUGP("entered\n"); /* Can't track connections formed before we registered */ CREDITS =3D=3D=3D=3D=3D=3D=3D Jozsef Kadlecsik has discovered this bug initially, Harald Welte has written the patch. COPYRIGHT =3D=3D=3D=3D=3D=3D=3D=3D=3D This advisory is copyright (C) 2002 by the netfilter...

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=448 laforge@netfilter.org changed: What |Removed |Added ---------------------------------------------------------------------------- Component|ip_conntrack |nf_conntrack ------- Additional Comments From laforge@netfilter.org 2006-02-14 09:05 MET ------- ipv6 conntrack is

...ack, @@ -837,7 +849,7 @@ packet, except it was never src/dst reversed, so where we would normally apply a dst manip, we apply a src, and vice versa. */ - if (info->manips[i].hooknum =3D=3D opposite_hook[hooknum]) { + if (map_innards(info->manips[i].hooknum, hooknum)) { DEBUGP("icmp_reply: inner %s -> %u.%u.%u.%u %u\n", info->manips[i].maniptype =3D=3D IP_NAT_MANIP_SRC ? "DST" : "SRC", diff -urN linux-2.4.19-pre6.orig/net/ipv4/netfilter/ipt_REJECT.c linux-2.4.= 19-pre6-nf-01/net/ipv4/netfilter/ipt_REJECT.c --- lin...

Hello all, After perusing the documentation, faqs, and mailing list archives, I have not been able to find a way to do the following. I''m hoping "you" can help. I want to transparently redirect all outbound SMTP connections to an SMTP server of *my* choice. This way, regardless of what a user on my network has set their SMTP server to be within their MUA, I will redirect

This patch set is intended for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for binary patch optimization for paravirt_ops. The binary patch optimization is important on native case because the paravirt_ops overhead can be reduced by converting indirect

This patch set is intended for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for binary patch optimization for paravirt_ops. The binary patch optimization is important on native case because the paravirt_ops overhead can be reduced by converting indirect

This patch set is intended for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for binary patch optimization for paravirt_ops which depends on the patch series I sent out, ia64/pv_ops, xen: more paravirtualization. The binary patch optimization is important on

This patch set is intended for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for binary patch optimization for paravirt_ops which depends on the patch series I sent out, ia64/pv_ops, xen: more paravirtualization. The binary patch optimization is important on

This patch set is for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for binary patch optimization for paravirt_ops which depends on the patch series I sent out, ia64/pv_ops, xen: more paravirtualization. The binary patch optimization is important on native

This patch set is for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for binary patch optimization for paravirt_ops which depends on the patch series I sent out, ia64/pv_ops, xen: more paravirtualization. The binary patch optimization is important on native

This patch set is for binary patch optimization for paravirt_ops. The binary patch optimization is important on native case because the paravirt_ops overhead can be reduced by converting indirect call into in-place execution or direct call. The first patch imports helper functions which themselves doesn't interesting things. The second patch replaces the indirect function calls with a

This patch set is for binary patch optimization for paravirt_ops. The binary patch optimization is important on native case because the paravirt_ops overhead can be reduced by converting indirect call into in-place execution or direct call. The first patch imports helper functions which themselves doesn't interesting things. The second patch replaces the indirect function calls with a

Hi, Is the http://xenbits.xensource.com/linux-2.6-xen.hg tree still being updated? if not, what''s the preferred Linux tree to track that has all of the Xen bits? Thanks, Muli _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel