https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275774
Emmanuel Vadot changed:
What|Removed |Added
Status|In Progress |Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277456
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277435
--- Comment #12 from Nikolay Borodin ---
(In reply to Kyle Evans from comment #11)
> Is it doing some fork or fork/exec? Any fd passing or anything funky?
I doubt it.
> Interface renaming?
Not yet. :)
Here's the code (minus TAPSTRANSIEN
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277435
--- Comment #11 from Kyle Evans ---
(In reply to Nikolay Borodin from comment #10)
That's fascinating. Can you tell us a little more about your application? Is it
doing some fork or fork/exec? Any fd passing or anything funky? Interface
re
Hi everyone!
I'd like to report, that there's some issue with the ix driver's
vlanhwfilter feature.
To be more specific, I'm not sure, if this is a driver issue, a hardware
issue, or a firmware issue.
I'm just happy, that I could catch it.
If someone more experienced fella is interested here, I'
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218579
--- Comment #56 from Keve Nagy ---
I will also try your new patch on 13.2R and 14.0R, and report back with my
findings.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218579
--- Comment #55 from Keve Nagy ---
(In reply to Cy Schubert from comment #50)
With my bge-patched GENERIC kernels, WOL displayed on both 13.2R and 14.0R by
default, without the need to issue an `ifconfig bge0 wol` or setting this in
rc.conf
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277435
--- Comment #10 from Nikolay Borodin ---
(In reply to Kyle Evans from comment #8)
(In reply to Nikolay Borodin from comment #9)
To clarify, it's not the ioctl call that hangs, it's the code in the kernel.
--
You are receiving this mail be
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277435
--- Comment #9 from Nikolay Borodin ---
(In reply to Kyle Evans from comment #8)
After this option is set, the system hangs when the application is closed.
i = 1;
if (ioctl(fd, TAPSTRANSIENT, &i) < 0) {
printf("error: ioctl(TAPSTRANSI
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275774
--- Comment #12 from Michael Tuexen ---
Can we close this?
--
You are receiving this mail because:
You are the assignee for the bug.
To view an individual PR, use:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id).
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and ob
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277435
--- Comment #8 from Kyle Evans ---
Something like this should do the trick: https://reviews.freebsd.org/D44200
(tun(4)/tap(4): allow devices to be configured as transient)
--
You are receiving this mail because:
You are the assignee for t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277435
--- Comment #7 from Kyle Evans ---
(In reply to Nikolay Borodin from comment #6)
Right, but the automatic destroy functionality wouldn't work until the process
closes anyways if you leaked an fd to the tap device somewhere, which may or
ma
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277435
--- Comment #6 from Nikolay Borodin ---
(In reply to Kyle Evans from comment #5)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242841#c0(In reply to Kyle
Evans from comment #5)
I understand, in any case it doesn't apply to the automati
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277435
--- Comment #5 from Kyle Evans ---
(In reply to Nikolay Borodin from comment #4)
That is a bug, then, unless you have a dangling reference that you didn't
expect.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277435
--- Comment #4 from Nikolay Borodin ---
(In reply to Kyle Evans from comment #3)
> though you can destroy it, you just have to close it first
You can't. If you try to do this via SIOCIFDESTROY inside an application which
uses the descripto
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277435
Kyle Evans changed:
What|Removed |Added
CC||kev...@freebsd.org
--- Comment #3 fro
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277435
--- Comment #2 from Nikolay Borodin ---
(In reply to Alan Somers from comment #1)
> On the last close of the data device, the interface is brought down (as if
> with “ifconfig tapN down”)
It's completely different. What I am suggesting re
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277435
Alan Somers changed:
What|Removed |Added
CC||asom...@freebsd.org
--- Comment #1 f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218579
--- Comment #54 from Cy Schubert ---
When bge(4) is a member of a lagg(4) you will not see WOL listed in ifconfig
bge0 output. You must /etc/rc.d/netif stop lagg0 before power off in
/etc/rc.shutdown or /etc/rc.final.
And when bge(4) is a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218579
--- Comment #53 from Cy Schubert ---
Created attachment 248891
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=248891&action=edit
13-STABLE version of the patch
Use this patch on 13-STABLE.
--
You are receiving this mail becaus
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218579
--- Comment #52 from Cy Schubert ---
Created attachment 248890
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=248890&action=edit
Latest version of patch for 14-STABLE
Use this patch on 14-STABLE.
--
You are receiving this mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218579
Cy Schubert changed:
What|Removed |Added
Attachment #212388|0 |1
is obsolete|
23 matches
Mail list logo
