13.08.2015, 18:22, "Alexander V. Chernikov" <[email protected]>:
> 13.08.2015, 18:21, "Luigi Rizzo" <[email protected]>:
>> On Thu, Aug 13, 2015 at 5:18 PM, Julian Elischer <[email protected]> wrote:
>>> On 8/13/15 10:41 PM, Ian Smith wrote:
>>>> On Thu, 13 Aug 2015 16:30:15 +0200, Luigi Rizzo wrote:
>>>> > On Thu, Aug 13, 2015 at 4:00 PM, Ian Smith <[email protected]>
>>>> wrote:
>>>> > > On Thu, 13 Aug 2015 12:24:31 +0800, Julian Elischer wrote:
>>>> > > > BTW, any ideas as to what causes this?
>>>> > > > # ipfw show
>>>> > > > [...]
>>>> > > > 00400 0 0 deny ip from 10.12.1.0/24 to
>>>> any in recv
>>>> > > > xn0
>>>> > > > 00500 0 16045693110842147038 deny ip from 204.109.63.0/25 to
>>>> any in recv
>>>> > > > xn1
>>>> > > > 00600 0 0 allow ip from any to any in
>>>> recv xn1
>>>> > > > [...]
>>>> > > > 65535 8251 16045693110842147290 deny ip from any to any
>>>> > > >
>>>> > > >
>>>> > > > -current as of the 5th of august
>>>> > > > FreeBSD vps1.elischer.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1
>>>> r286304: Wed
>>>> > > > Aug 5 14:31:10 PDT 2015
>>>> > > > [email protected]:/usr/obj/usr/src-current/sys/VPS1 i386
>>>> > > >
>>>> > > > note i386, not amd64.
>>>> > >
>>>> > > Assuming all digits were shown, on a wild hunch:
>>>> > >
>>>> > > t23% echo 'scale=20; 2^64 - 16045693110842147038' | bc
>>>> > > 2401050962867404578
>>>> > > t23% echo 'scale=20; 2^63 - 16045693110842147038' | bc
>>>> > > -6822321073987371230
>>>> > >
>>>> >
>>>> > bc
>>>> > obase=16
>>>> > 16045693110842147038
>>>> > DEADC0DEDEADC0DE
>>>> >
>>>> > so... somehow pointing in a bad place.
>>>>
>>>> Ah, quite so .. and rule 65535 looks like a slightly worse place.
>>>>
>>>> t23% echo 'obase=16; 16045693110842147290' | bc
>>>> DEADC0DEDEADC1DA
>>>
>>> that's deadcode when it's had some packets added to it :-)
>>>
>>> I think our friend Mr Chernikov may have tripped up over something..
>>
>> looks more like the "counter" API. The old counters were inline in the
>> rules.
>
> In that case we would probably have garbage in pkts counter, too.
> Anyway, I'm setting up the VM to see if this is kernel or userland problem..
This is actually counters-related problem.
The attached diff should fix it.
(But it looks like I'd better get a bit more counter(9) support for that case).
>> cheers
>> luigi
>>
>>>> thanks, Ian
>>>
>>> _______________________________________________
>>> [email protected] mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
>>> To unsubscribe, send any mail to "[email protected]"
>>
>> --
>> -----------------------------------------+-------------------------------
>> Prof. Luigi RIZZO, [email protected] . Dip. di Ing. dell'Informazione
>> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
>> TEL +39-050-2217533 . via Diotisalvi 2
>> Mobile +39-338-6809875 . 56122 PISA (Italy)
>> -----------------------------------------+-------------------------------
Index: sys/netpfil/ipfw/ip_fw_private.h
===================================================================
--- sys/netpfil/ipfw/ip_fw_private.h (revision 286770)
+++ sys/netpfil/ipfw/ip_fw_private.h (working copy)
@@ -256,7 +256,7 @@ struct ip_fw {
ipfw_insn cmd[1]; /* storage for commands */
};
-#define IPFW_RULE_CNTR_SIZE (2 * sizeof(counter_u64_t))
+#define IPFW_RULE_CNTR_SIZE (2 * sizeof(uint64_t))
#endif
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[email protected]"
