On Fri, May 27, 2016 at 12:57:34AM -0400, Garrett Wollman wrote:
> In article
> you
> write:
>
> ># ifconfig -m cxgbe0
> >cxgbe0: flags=8943
>
> ># ifconfig cxgbe0 mtu 9000
> >ifconfig: ioctl SIOCSIFMTU (set mtu): Invalid argument
>
> I believe this device, like many others, does not allow th
On Thu, May 26, 2016 at 11:52:45PM -0500, Dustin Marquess wrote:
> After my many issues with ixgbe & ixv, I ended up removing the Intel
> X520s with Chelsio T420-CR and the Intel X710s with Chelsio T520-CR.
> So far so good, except I can't seem to change the MTU away from 1500.
> In fact, ifconfig
I tried setting it via ifconfig_cxgbe0 in rc.conf, but that didn't seem to work
either.
-Dustin
On Thu, May 26, 2016 at 9:57 PM -0700, "Garrett Wollman"
wrote:
In article you write:
># ifconfig -m cxgbe0
>cxgbe0: flags=8943
># ifconfig cxgbe0 mtu 9000
>ifconfig: ioctl SIOCSIFMT
On 27/May/16 06:11, Kevin Oberman wrote:
> There are a lot of excellent reasons to avoid ULAs. There are a very few
> good, or even so-so reasons to use them. The most commonly cited reason is
> security which is almost always wrong. In almost 20 years of working with
> IPv6 I have yet to see any
On 26/May/16 21:36, Niklaas Baudet von Gersdorff wrote:
> Here lies the first problem. It seems that it's not legitimate to assign
> /96 subnets when using unique local addresses (ULAs). I was right
> getting some /48 subnet for my local IPv6 network; some easy way to get
> one generated randoml
In article
you write:
># ifconfig -m cxgbe0
>cxgbe0: flags=8943
># ifconfig cxgbe0 mtu 9000
>ifconfig: ioctl SIOCSIFMTU (set mtu): Invalid argument
I believe this device, like many others, does not allow the MTU (or
actually the MRU) to be changed once the receive ring has been set up
You may
After my many issues with ixgbe & ixv, I ended up removing the Intel
X520s with Chelsio T420-CR and the Intel X710s with Chelsio T520-CR.
So far so good, except I can't seem to change the MTU away from 1500.
In fact, ifconfig can't seem to change the mtu at all. On -CURRENT as
of yesterday:
# ifc
On Thu, May 26, 2016 at 12:36 PM, Niklaas Baudet von Gersdorff <
st...@niklaas.eu> wrote:
> I was eventually able to solve this issue. I asked for help on several
> mailing lists. So, for reference, here are links to the relevant
> threads:
>
> https://lists.freebsd.org/pipermail/freebsd-questions
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209471
--- Comment #21 from Robert Blayzor ---
This finally showed it's head again...
sonewconn: pcb 0xf80001b2bc40: Listen queue overflow: 301 already in queue
awaiting acceptance (25 occurrences)
sonewconn: pcb 0xf80001b2bc40: Listen q
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209758
--- Comment #10 from Ngie Cooper ---
(In reply to Giuliano from comment #9)
The command I provided is for use with FreeBSD.
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209758
--- Comment #9 from Giuliano ---
Dear Ngie,
I have triple checked typing to be sure it is not my mistake. There is a error:
fetch: No match. Hmm... I can't seem to find a patch in there anywhere.
Best regards,
Giuliano
--
You are receiv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209758
--- Comment #8 from Ngie Cooper ---
(In reply to Giuliano from comment #7)
cd /usr/src
fetch -o - https://bz-attachments.freebsd.org/attachment.cgi?id=170681 | patch
-p1
--
You are receiving this mail because:
You are the assignee for th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209758
--- Comment #7 from Giuliano ---
Dear Sepherosa,
I wish to thank you very much for your help. I'm sorry my ignorance but I have
looked for how to compile this patch and I did not found. Is it possible to
return the necessary commands to do
I was eventually able to solve this issue. I asked for help on several
mailing lists. So, for reference, here are links to the relevant
threads:
https://lists.freebsd.org/pipermail/freebsd-questions/2016-May/271810.html
https://lists.freebsd.org/pipermail/freebsd-net/2016-May/045349.html
https://w
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201694
--- Comment #18 from Paul Armstrong ---
As far as I know, this is only a PF (well, more specifically, ALTQ) problem (I
haven't tested the others extensively).
Last I checked, compiling PF in directly was a non-starter.
PF must be a module
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201694
--- Comment #17 from Bjoern A. Zeeb ---
Just to confirm: this is believed to a problem with pf only at this point,
right?
Is it also still true, that this only happens with pf compiled in but not if
loaded as a module?
I have various oth
> On May 20, 2016, at 12:30 AM, Aqz wrote:
>
> Hello,
>
> I have a very strange issue with passing ARP traffic through bridge
> interface.
> I'm using FreeBSD 10.3-REL VMWare virtual machine as bridge between two
> networks using the same IP address space. Bridge interface doesn't have IP
> addr
Moving this to net@ per request.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166255
--- Comment #26 from Chris Hutchinson ---
(In reply to eugen from comment #25)
Default system behaviour is not changed. Reboot is required to disable
logging after a change to loader.conf. So, no patchin
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166255
--- Comment #28 from Nick Hibma ---
Guys, please stop discussing this topic in a bug report. Take it to
freebsd-net@, freebsd-security@, freebsd-current@, etc.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166255
--- Comment #27 from eu...@grosbein.net ---
(In reply to Chris Hutchinson from comment #26)
> Must a decision on this be made right now? Or could more time be given,
in hopes a better solution might be found?
The problem report's presented
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166255
--- Comment #26 from Chris Hutchinson ---
(In reply to eugen from comment #25)
> Default system behaviour is not changed. Reboot is required to disable
> logging after a change to loader.conf. So, no patching should be required to
> stay sa
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209758
--- Comment #6 from Sepherosa Ziehau ---
Heh, it was added a long time ago.
And as for why bnx(4) in DragonflyBSD, its mainly because the bnx(4) support 4
RX rings on all chips, and 4 TX rings on 5717C/5719/5720, and well of course
multi-v
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209758
Sepherosa Ziehau changed:
What|Removed |Added
CC||sepher...@gmail.com
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166255
--- Comment #25 from eu...@grosbein.net ---
Default system behaviour is not changed. Reboot is required to disable logging
after a change to loader.conf. So, no patching should be required to stay safe.
--
You are receiving this mail becau
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166255
--- Comment #24 from Chris Hutchinson ---
(In reply to eugen from comment #21)
> (In reply to Chris Hutchinson from comment #20)
>
> You are essentially proposing the system to spend CPU time generating tons
> of messages, pass them from t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209758
--- Comment #4 from Giuliano ---
Actually, I have tried first to install FreeNAS 9.10. As the system doesn't
works, I started to look for why it is not working.
As I could retrieve, the source code of DragonFly BSD includes the 5717 C NIC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209758
--- Comment #3 from Giuliano ---
(In reply to Ngie Cooper from comment #1)
Dear Ngie Cooper,
I have attached the output pciconf at file pciconf.out.txt.
DragonFlyBSD has also a if_bge driver. I cannot understand the difference
between if_
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209758
--- Comment #2 from Giuliano ---
Created attachment 170672
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=170672&action=edit
pciconf output
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166255
--- Comment #23 from eu...@grosbein.net ---
(In reply to Nick Hibma from comment #22)
Please close it after MFC.
--
You are receiving this mail because:
You are the assignee for the bug.
___
fre
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166255
--- Comment #22 from Nick Hibma ---
Let's not have a discussion here on logging techniques. Both points are valid.
Period.
The bug report is effectively closed. I'll get someone to close it.
--
You are receiving this mail because:
You ar
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166255
--- Comment #21 from eu...@grosbein.net ---
(In reply to Chris Hutchinson from comment #20)
You are essentially proposing the system to spend CPU time generating tons of
messages, pass them from the kernel to userland daemon using socket su
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209758
Mark Linimon changed:
What|Removed |Added
Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org
--
You are
33 matches
Mail list logo
