Re: ipfw add pipe broken in RELENG_6
Mike Tancsa wrote: At 10:07 AM 4/1/2007, JoaoBR wrote: it seems I can not add pipes with releng6 sources from the last days ipfw add pipe 1 ip from any to any ipfw: getsockopt(IP_FW_ADD): Invalid argument I think this is whats needed in /usr/src/sbin/ipfw. Looking at the diffs between HEAD and RELENG_6 (apart from the kernel nat stuff), below seems to be whats different. somewhere between my MFC testing and the commits there seems to have been a screwup. I think it happenned because I reverted a MFC out of my list of MFC's to do after I had done some tests because they causled a failure and I hadn't realised that they affected this code too. I'm doing testing now and should be able to confirm this in a short while. [smicro1U]# diff -u ipfw2.c.orig ipfw2.c --- ipfw2.c.origMon Apr 2 22:28:33 2007 +++ ipfw2.c Mon Apr 2 22:30:45 2007 @@ -3973,11 +3973,9 @@ break; case TOK_QUEUE: - action-len = F_INSN_SIZE(ipfw_insn_pipe); action-opcode = O_QUEUE; goto chkarg; case TOK_PIPE: - action-len = F_INSN_SIZE(ipfw_insn_pipe); action-opcode = O_PIPE; goto chkarg; case TOK_SKIPTO: @@ -4043,11 +4041,13 @@ illegal forwarding port ``%s'', s); p-sa.sin_port = (u_short)i; } - lookup_host(*av, (p-sa.sin_addr)); - } + if (_substrcmp(*av, tablearg) == 0) + p-sa.sin_addr.s_addr = INADDR_ANY; + else + lookup_host(*av, (p-sa.sin_addr)); ac--; av++; break; - +} case TOK_COMMENT: /* pretend it is a 'count' rule followed by the comment */ action-opcode = O_COUNT; [smicro1U]# The command seems to be getting tripped up in /usr/src/sys/netinet/ip_fw2.c case O_QUEUE: if (cmdlen != F_INSN_SIZE(ipfw_insn)) goto bad_size; goto check_action; where size=2 and cmdlen=1 on opcode=50 ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw add pipe broken in RELENG_6
Julian Elischer пишет: somewhere between my MFC testing and the commits there seems to have been a screwup. I think it happenned because I reverted a MFC out of my list of MFC's to do after I had done some tests because they causled a failure and I hadn't realised that they affected this code too. I'm doing testing now and should be able to confirm this in a short while. Hi, Julian! Seems, that converting from time_second to time_uptime broke `ipfw -t show'. Now we have one PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=77 And i see similar problem on the my CURRENT. -- WBR, Andrey V. Elsukov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw add pipe broken in RELENG_6
Andrey V. Elsukov wrote: Julian Elischer пишет: somewhere between my MFC testing and the commits there seems to have been a screwup. I think it happenned because I reverted a MFC out of my list of MFC's to do after I had done some tests because they causled a failure and I hadn't realised that they affected this code too. I'm doing testing now and should be able to confirm this in a short while. Hi, Julian! Seems, that converting from time_second to time_uptime broke `ipfw -t show'. Now we have one PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=77 And i see similar problem on the my CURRENT. yeah I seem to have MFC'd a BUG.. I confirmed they behaved the same. but I was looking at binary data and didn't notice the date.. I'm preparing a revert, however it is a no-win situation as that leaves you open to sessions timing out immediately when the time is changed forward. So, which is more important? accurate timeouts or accurate reporting? Ont thing that COULD be done would be to add the boot-time to the reported times. this would never let a session time out too early, but would give slightly misleading report numbers if the time is adjusted. They would 'adjust' to the same offset against the 'new time'. i.e. if it shows 2 hours before now before the change it will show 2 hours before the new now after the time is changed. This may be acceptable. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw add pipe broken in RELENG_6
Julian Elischer wrote: Andrey V. Elsukov wrote: Julian Elischer пишет: somewhere between my MFC testing and the commits there seems to have been a screwup. I think it happenned because I reverted a MFC out of my list of MFC's to do after I had done some tests because they causled a failure and I hadn't realised that they affected this code too. I'm doing testing now and should be able to confirm this in a short while. Hi, Julian! Seems, that converting from time_second to time_uptime broke `ipfw -t show'. Now we have one PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=77 And i see similar problem on the my CURRENT. I have committed a fix in -current please check ip_fw2.c version 1.162 If this meets with general happiness I will re-MFC this 1.112 along with this fix to it. yeah I seem to have MFC'd a BUG.. I confirmed they behaved the same. but I was looking at binary data and didn't notice the date.. I'm preparing a revert, however it is a no-win situation as that leaves you open to sessions timing out immediately when the time is changed forward. So, which is more important? accurate timeouts or accurate reporting? Ont thing that COULD be done would be to add the boot-time to the reported times. this would never let a session time out too early, but would give slightly misleading report numbers if the time is adjusted. They would 'adjust' to the same offset against the 'new time'. i.e. if it shows 2 hours before now before the change it will show 2 hours before the new now after the time is changed. This may be acceptable. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw add pipe broken in RELENG_6
At 10:07 AM 4/1/2007, JoaoBR wrote: it seems I can not add pipes with releng6 sources from the last days ipfw add pipe 1 ip from any to any ipfw: getsockopt(IP_FW_ADD): Invalid argument I think this is whats needed in /usr/src/sbin/ipfw. Looking at the diffs between HEAD and RELENG_6 (apart from the kernel nat stuff), below seems to be whats different. [smicro1U]# diff -u ipfw2.c.orig ipfw2.c --- ipfw2.c.origMon Apr 2 22:28:33 2007 +++ ipfw2.c Mon Apr 2 22:30:45 2007 @@ -3973,11 +3973,9 @@ break; case TOK_QUEUE: - action-len = F_INSN_SIZE(ipfw_insn_pipe); action-opcode = O_QUEUE; goto chkarg; case TOK_PIPE: - action-len = F_INSN_SIZE(ipfw_insn_pipe); action-opcode = O_PIPE; goto chkarg; case TOK_SKIPTO: @@ -4043,11 +4041,13 @@ illegal forwarding port ``%s'', s); p-sa.sin_port = (u_short)i; } - lookup_host(*av, (p-sa.sin_addr)); - } + if (_substrcmp(*av, tablearg) == 0) + p-sa.sin_addr.s_addr = INADDR_ANY; + else + lookup_host(*av, (p-sa.sin_addr)); ac--; av++; break; - +} case TOK_COMMENT: /* pretend it is a 'count' rule followed by the comment */ action-opcode = O_COUNT; [smicro1U]# The command seems to be getting tripped up in /usr/src/sys/netinet/ip_fw2.c case O_QUEUE: if (cmdlen != F_INSN_SIZE(ipfw_insn)) goto bad_size; goto check_action; where size=2 and cmdlen=1 on opcode=50 ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
