https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211730
--- Comment #9 from Kristof Provost ---
That's a good question. I'd have to find a decent example somewhere myself.
The ioctl codes actually encode the size of the struct, so perhaps there's an
alternate approach.
A good first step would
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211730
--- Comment #8 from Mahdi Mokhtari ---
(In reply to Mahdi Mokhtari from comment #7)
Also, What about structs?
Should we use Macros around/inside them of old/new versions?
Or we should redefine new structs too ?
--
You are receiving this m
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211730
--- Comment #7 from Mahdi Mokhtari ---
(In reply to Kristof Provost from comment #6)
Aha :)
I see.
So you suggest we solve it by adding new IOCTL command.
Okay, lemme do a try.
When i did it, I'll upload a patch for review (if you have time
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211730
--- Comment #6 from Kristof Provost ---
(In reply to Mahdi Mokhtari from comment #4)
The problem with the ABI is that we can't rely on user space and kernel space
running the same code versions. If someone were to update the kernel, but not
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211730
--- Comment #5 from r...@starnet.cz ---
(In reply to Mahdi Mokhtari from comment #4)
Hello,
I have hardware but its production box - so when you say that you have working
patch, I can test it.
Radek
--
You are receiving this mail because
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211730
--- Comment #4 from Mahdi Mokhtari ---
(In reply to Kristof Provost from comment #3)
Ah, yes i see most of pf_altq.h is int32.
And i guess we should change it too.
About your point on kernel ABI and ioctl(), i didn't get your point.
Do you
On 10 Aug 2016, at 16:23, Radek Krejča wrote:
> this patch seems to be working.
>
Thanks for testing!
> I will post bugreport.
>
The patch has already been committed to head (r303663).
A bug would still be useful so I don’t forget to merge it back to 11 and 10.
Regards,
Kristof
__
> On 31 Jul 2016, at 19:46, Radek Krejča wrote:
> > I need to set TOS to 0 and remark it with rules.
> >
> > I am trying to use scrub to set tos to 0, but I have problem:
> >
> > scrub all fragment reassemble no-df set-tos 0
> >
> > give Illegal value
> >
> > but scrub all fragment reassemble no-df
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211730
--- Comment #3 from Kristof Provost ---
I don't have the hardware to test this, but I'm afraid the problem is a fair
bit harder to fix than just that.
It looks like the altq internals also use 32 bit values for bandwidth
configuration, so a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211730
--- Comment #2 from Mahdi Mokhtari ---
Created attachment 173509
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=173509&action=edit
Patch Makes pf_ifspeed.baudrate uint64_t
(In reply to Kristof Provost from comment #1)
Does the a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211730
Kristof Provost changed:
What|Removed |Added
CC||k...@freebsd.org
Assig
> Please do file a bug, because you’ve discovered a real problem and
> I’d hate for it to get forgotten about.
Hello Kristof,
bug sended.
Thank you very much
Radek
___
freebsd-pf@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/fre
> I’d expect that ‘altq on $int_if cbq bandwidth 85% queue {
> default_nat.’ would do what you want.
> Looking at the code, I’m not at all sure that it’ll end up working
> either, but it’s worth a try.
>
> Fundamentally, we’ll have to change pf (and worse, the interface to
> user space) to
On 10 Aug 2016, at 14:38, Radek Krejča wrote:
I have changed bandwidth to 100%, 90% or 95%. Syntax OK, but value
stops at 1.27Gbit (it looks, that 1Gbit is default)
When I give ifconfig, I see:
media: Ethernet autoselect (10Gbase-SR )
It looks that "autodetection" of pf is broken to.
I was
Max wrote:
> Probably you should use
> pass out log on $if_dvr reply-to ($if_wan2 $gw_wan2) to
thank you, Max, this helped
--
Zeus V. Panchenko jid:z...@im.ibs.dn.ua
IT Dpt., I.B.S. LLC GMT+2 (EET)
___
On 10 Aug 2016, at 11:19, Radek Krejča wrote:
That looks like you might be hitting the maximum of an unsigned
integer.
Try using relative specifications (i.e. as a percentage) instead.
Yes, I think so. But I dont know, that I can say relative
specification for inteface bandwidth. Could you show
> That looks like you might be hitting the maximum of an unsigned
> integer.
> Try using relative specifications (i.e. as a percentage) instead.
>
Hello Kristof,
Yes, I think so. But I dont know, that I can say relative specification for
inteface bandwidth. Could you show me how?
I have 10Gb
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201519
Kristof Provost changed:
What|Removed |Added
Version|9.3-RELEASE |10.3-STABLE
Status|C
On 10 Aug 2016, at 9:28, Radek Krejča wrote:
I need to shape 10G traffic, but I cant make bandwidth higher than
4.26 Gbit:
pfctl shows:
altq on int0 cbq bandwidth 4.26Gb tbrsize 36000 queue {
default_nat..
but in pf.conf is:
altq on $int_if cbq bandwidth 8550Mb queue { default_
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201519
Franco Fichtner changed:
What|Removed |Added
CC||fra...@opnsense.org
--- Comment
Hello again,
I need to shape 10G traffic, but I cant make bandwidth higher than 4.26 Gbit:
pfctl shows:
altq on int0 cbq bandwidth 4.26Gb tbrsize 36000 queue {
default_nat..
but in pf.conf is:
altq on $int_if cbq bandwidth 8550Mb queue { default_nat..
or
altq on $int_if
21 matches
Mail list logo
