Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 03 Apr 2007 16:03:27 -0700
From:      Julian Elischer <julian@elischer.org>
To:        Julian Elischer <julian@elischer.org>
Cc:        freebsd-stable@freebsd.org, "Andrey V. Elsukov" <bu7cher@yandex.ru>, julian@freebsd.org, JoaoBR <joao@matik.com.br>
Subject:   Re: ipfw add pipe broken in RELENG_6
Message-ID:  <4612DD3F.1010401@elischer.org>
In-Reply-To: <4612238D.6070504@elischer.org>
References:  <200704011107.22750.joao@matik.com.br>	<200704030239.l332dC89044128@lava.sentex.ca> <4611FAB6.4090201@elischer.org> <46120138.5090702@yandex.ru> <4612238D.6070504@elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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=111177
>>
>> 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.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4612DD3F.1010401>