https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247652
Alexander Vereeken changed:
What|Removed |Added
Keywords|patch |
--
You are receiving this m
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277125
Alexander V. Chernikov changed:
What|Removed |Added
CC||melif...@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277125
Eugene Grosbein changed:
What|Removed |Added
CC||eu...@freebsd.org
See
#1 from Jose Luis Duran ---
A shorter way to reproduce it:
# route add -net 192.0.2.0/24 -interface vtnet0
add net 192.0.2.0: gateway vtnet0
# ifconfig epair create
epair0a
# ifconfig epair0a inet 192.0.2.1/24
ifconfig: ioctl (SIOCAIFADDR): File exists
I'm also not
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277125
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=247652
Mark Linimon changed:
What|Removed |Added
Attachment #216059|0 |1
is patch|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250366
Kubilay Kocak changed:
What|Removed |Added
URL||https://reviews.freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250366
Michael Tuexen changed:
What|Removed |Added
Status|In Progress |Closed
Flags|mfc-sta
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250366
--- Comment #4 from commit-h...@freebsd.org ---
A commit references this bug:
Author: tuexen
Date: Mon Nov 30 09:21:02 UTC 2020
New revision: 368179
URL: https://svnweb.freebsd.org/changeset/base/368179
Log:
MFC r367464:
The ioctl
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250366
--- Comment #3 from commit-h...@freebsd.org ---
A commit references this bug:
Author: tuexen
Date: Sat Nov 7 21:17:49 UTC 2020
New revision: 367464
URL: https://svnweb.freebsd.org/changeset/base/367464
Log:
The ioctl() calls using
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250366
Michael Tuexen changed:
What|Removed |Added
Flags||mfc-stable12?
--
You are receivi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250366
Michael Tuexen changed:
What|Removed |Added
Status|New |In Progress
--- Comment #2 from M
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250366
Michael Tuexen changed:
What|Removed |Added
CC||n...@freebsd.org,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250366
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
Keywords||patch
Summary|Unwanted leaved on AllHost |Unwanted leave on AllHost
|multicast group |multicast group when
||calling SIOCAIFADDR ioctl
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240539
Kyle Evans changed:
What|Removed |Added
Status|In Progress |Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240539
--- Comment #8 from commit-h...@freebsd.org ---
A commit references this bug:
Author: kevans
Date: Sat Sep 21 01:39:50 UTC 2019
New revision: 352571
URL: https://svnweb.freebsd.org/changeset/base/352571
Log:
MFS r352565: SIOCSIFNAME: Do
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240539
--- Comment #7 from commit-h...@freebsd.org ---
A commit references this bug:
Author: kevans
Date: Fri Sep 20 21:27:42 UTC 2019
New revision: 352565
URL: https://svnweb.freebsd.org/changeset/base/352565
Log:
MFC r352246: SIOCSIFNAME: Do
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240539
Kubilay Kocak changed:
What|Removed |Added
Resolution|FIXED |---
Status|Closed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240539
Mateusz Piotrowski <0...@freebsd.org> changed:
What|Removed |Added
Status|New |Closed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240539
Kyle Evans changed:
What|Removed |Added
Assignee|n...@freebsd.org |kev...@freebsd.org
C
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240539
--- Comment #3 from commit-h...@freebsd.org ---
A commit references this bug:
Author: kevans
Date: Thu Sep 12 15:36:49 UTC 2019
New revision: 352246
URL: https://svnweb.freebsd.org/changeset/base/352246
Log:
SIOCSIFNAME: Do nothing if we
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240539
Kyle Evans changed:
What|Removed |Added
CC||kev...@freebsd.org
--- Comment #2 fro
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240539
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=237655
Li-Wen Hsu changed:
What|Removed |Added
Status|Open|Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237655
Kubilay Kocak changed:
What|Removed |Added
Keywords||needs-qa
Status|New
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237655
Kristof Provost changed:
What|Removed |Added
Assignee|k...@freebsd.org |n...@freebsd.org
--- Comment #
On 03/12/2018 14:34, Andriy Gapon wrote:
> My idea is that there should be something like 'if_freed' or 'if_destroyed'
> method that could be used by drivers for their cleaning up. That method would
> be called from if_destroy() when we really know that the interface has no
> references and, thus,
On 30/11/2018 14:27, Andriy Gapon wrote:
> Q1. Is the described race plausible?
>
> Q2. If yes, then has this class[*] of races been fixed by the epoch mechanism?
> I suspect that lagg_ioctl() can still have that race if it's called
> concurrently
> with lagg_clone_destroy().
So, to re-iterate,
I am working on analyzing a crash with the following stack trace:
_sx_slock_hard lagg_media_status ifmedia_ioctl lagg_ioctl ifioctl kern_ioctl
sys_ioctl
It appears that the crash happened because of a destroyed sx lock.
Please note that the code base is the CURRENT from just before the time when
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227058
Eitan Adler changed:
What|Removed |Added
Status|New |Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227086
Marek changed:
What|Removed |Added
Resolution|--- |Not A Bug
Status|Open
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227086
--- Comment #3 from Eugene Grosbein ---
(In reply to Marek from comment #2)
The problem is the address 10.20.20.1 that is bounded first to "local system"
by means of assigning it to local side of tun0. Then, an attempt is made to
assign it
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227086
--- Comment #2 from Marek ---
Hi Eugene,
I can test old revision only (home server "in production") :)
Some more outputs from working/current configuration:
# ifconfig tun0
tun0: flags=8051 metric 0 mtu 1500
options=8
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227086
Eugene Grosbein changed:
What|Removed |Added
CC||eu...@freebsd.org,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227086
Mark Linimon changed:
What|Removed |Added
Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org
K
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227058
Brooks Davis changed:
What|Removed |Added
Keywords||easy
--- Comment #1 from Brooks Dav
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227058
Mark Linimon changed:
What|Removed |Added
Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org
--
You are
On 08/11/15 at 08:04P, Lakshmi Narasimhan Sundararajan wrote:
> Hi FreeBSD Team,
>
> We have been working on LACP timeout tunable to help expedite link failure
> propagation through a IOCtl interface.
>
>
>
> The changes have been tested and review is in progress.
&
Hi FreeBSD Team,
We have been working on LACP timeout tunable to help expedite link failure
propagation through a IOCtl interface.
The changes have been tested and review is in progress.
The phabricator link is https://reviews.freebsd.org/D3300
We would kindly appreciate if the changes can
+++ sys/net/ieee8023ad_lacp.c (working copy)
@@ -522,7 +522,7 @@
int error;
boolean_t active = TRUE; /* XXX should be configurable */
- boolean_t fast = FALSE; /* XXX should be configurable */
+ boolean_t fast = FALSE; /* Configurable via ioctl */
link_init_sdl(i
uot;Tallam, Sreen"
Subject: FreeBSD LAG LACP timeout tunable through IOCTL
>Hi FreeBSD team,
>In FreeBSD-10 and in Current, by default LACP supports only long timeout.
>FreeBSD does not provide the way to configure LACP timeout period.
>We made code changes for LACP Fast-timeou
Hi FreeBSD team,
In FreeBSD-10 and in Current, by default LACP supports only long timeout.
FreeBSD does not provide the way to configure LACP timeout period.
We made code changes for LACP Fast-timeout (Using IOCTL, both GET / SET) on
FreeBSD-11.
And we were able to successfully test the
On Tuesday 17 March 2015 15:25:09 Gleb Smirnoff wrote:
> On Mon, Mar 16, 2015 at 02:49:58AM +0300, Oleg Ginzburg wrote:
> O> b) On FreeBSD-current r276500M CARP IP is established for some seconds,
then vanishes:
> In my case on r280167, all works okay, despite the carp_alloc_if warning:
>
> #/sb
On Mon, Mar 16, 2015 at 02:49:58AM +0300, Oleg Ginzburg wrote:
O> b) On FreeBSD-current r276500M CARP IP is established for some seconds, then
O> vanishes:
O>
O> % /sbin/ifconfig vtnet0 vhid 1 advskew 100 pass navuhodonosor
192.168.1.210/24
O> state master alias
O> % ifconfig vtnet0
O> vtnet0:
On Monday 29 December 2014 14:18:01 Bryan Venteicher wrote:
> On Fri, Dec 26, 2014 at 8:09 AM, Oleg Ginzburg wrote:
> > is it possible to use the carp(4) protocol with
> > vtnet(4) interfaces ( which is used, for example, in bhyve(8) )
> > Currently, the standard carp init operation causes an SIOC
On Fri, Dec 26, 2014 at 8:09 AM, Oleg Ginzburg wrote:
> is it possible to use the carp(4) protocol with
> vtnet(4) interfaces ( which is used, for example, in bhyve(8) )
> Currently, the standard carp init operation causes an SIOCGVH error:
>
> /sbin/ifconfig vtnet0 vhid 1 advskew 100 pass pass 1
is it possible to use the carp(4) protocol with
vtnet(4) interfaces ( which is used, for example, in bhyve(8) )
Currently, the standard carp init operation causes an SIOCGVH error:
/sbin/ifconfig vtnet0 vhid 1 advskew 100 pass pass 10.10.10.10/24 alias
ifconfig: SIOCGVH: Protocol not supported
Hello John,
On 09/30/2014 07:31 PM, John Baldwin wrote:
On Monday, September 29, 2014 8:36:22 am Andrew Rybchenko wrote:
Hello,
we need to add private ioctl to the driver sfxge(4) to make FW update,
do internal diagnostics commands etc.
We see at least two approaches in other drivers:
1
On Monday, September 29, 2014 8:36:22 am Andrew Rybchenko wrote:
> Hello,
>
> we need to add private ioctl to the driver sfxge(4) to make FW update,
> do internal diagnostics commands etc.
> We see at least two approaches in other drivers:
> 1. SIOCGPRIVATE_0/ SIOCGPRIVATE_1 o
Hello,
we need to add private ioctl to the driver sfxge(4) to make FW update,
do internal diagnostics commands etc.
We see at least two approaches in other drivers:
1. SIOCGPRIVATE_0/ SIOCGPRIVATE_1 on net device
2. dedicated char device with its own ioctl's
Is there any recommendatio
those
info, but in a different way.
I'd like to add SIOCGI2C as standard ioctl for that, picking value like
61, if there are no objections.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe,
Synopsis: [ipfilter] ipfilter ioctl SIOCDELST broken
Responsible-Changed-From-To: freebsd-net->cy
Responsible-Changed-By: cy
Responsible-Changed-When: Wed Jul 3 05:22:06 UTC 2013
Responsible-Changed-Why:
Mine.
http://www.freebsd.org/cgi/query-pr.cgi?pr=139
Synopsis: [ipfilter] [patch] ipfilter ioctl SIOCGNATL does not match active
sessions properly
Responsible-Changed-From-To: freebsd-net->cy
Responsible-Changed-By: cy
Responsible-Changed-When: Wed Jul 3 05:16:59 UTC 2013
Responsible-Changed-Why:
Mine.
http://www.freebsd.org/cgi/query-pr.cgi
Synopsis: ifconfig(8): ioctl (SIOCAIFADDR): File exists on directly connected
networks
Responsible-Changed-From-To: freebsd-net->melifaro
Responsible-Changed-By: melifaro
Responsible-Changed-When: Fri Mar 8 20:45:18 UTC 2013
Responsible-Changed-Why:
Take
http://www.freebsd.org/cgi/query-pr.
Old Synopsis: ioctl SIOCGIFCONF reports interface names which are blank
New Synopsis: [ioctl] ioctl SIOCGIFCONF reports interface names which are blank
State-Changed-From-To: open->closed
State-Changed-By: linimon
State-Changed-When: Mon Jul 25 02:58:18 UTC 2011
State-Changed-Why:
Duplicate
Hi,
From: Nikolay Denev
To: bug-follo...@freebsd.org,
s...@ecom24.ru
Cc:
Subject: Re: kern/155772: ifconfig(8): ioctl (SIOCAIFADDR): File exists on
directly connected networks
Date: Tue, 5 Apr 2011 14:46:35 +0300
I'm not sure if this can be solved unless RADIX_MPATH is used.
My worka
The following reply was made to PR kern/155772; it has been noted by GNATS.
From: Nikolay Denev
To: bug-follo...@freebsd.org,
s...@ecom24.ru
Cc:
Subject: Re: kern/155772: ifconfig(8): ioctl (SIOCAIFADDR): File exists on
directly connected networks
Date: Tue, 5 Apr 2011 14:46:35 +0300
I&#
Old Synopsis: ifconfig: ioctl (SIOCAIFADDR): File exists on directly connected
networks
New Synopsis: ifconfig(8): ioctl (SIOCAIFADDR): File exists on directly
connected networks
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When:
I'm writing a simple char device. So far everything went so good
(read/write), but here I'm going to add support for ioctl.
int
ioctl(struct cdev *dev, u_long cmd, caddr_t data, int flags, struct thread *td)
{
int error = 0;
uprintf("Here...\n");
retu
Synopsis: [ppp] "ioctl (SIOCAIFADDR): File exists" error when configuring ppp
interfaces
Responsible-Changed-From-To: freebsd-net->qingli
Responsible-Changed-By: qingli
Responsible-Changed-When: Fri Dec 4 18:05:10 UTC 2009
Responsible-Changed-Why:
Take ownership of th
Old Synopsis: "ioctl (SIOCAIFADDR): File exists" error when configuring ppp
interfaces
New Synopsis: [ppp] "ioctl (SIOCAIFADDR): File exists" error when configuring
ppp interfaces
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
R
Old Synopsis: ipfilter ioctl SIOCDELST broken
New Synopsis: [ipfilter] ipfilter ioctl SIOCDELST broken
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Thu Oct 15 01:00:16 UTC 2009
Responsible-Changed-Why:
Over to maintaine
REQ(ifr) \
>>>>> ((ifr).ifr_addr.sa_len > sizeof(struct sockaddr) ? \
>>>>>(sizeof(struct ifreq) - sizeof(struct sockaddr) + \
>>>>> (ifr).ifr_addr.sa_len) : sizeof(struct ifreq))
>>>>> #endif
>>>>>
>>>>&g
f(*ifr) );
do
{
n *= 2;
ifr = realloc( ifr, sizeof(*ifr) * n );
bzero( ifr, sizeof(*ifr) * n );
ifc.ifc_req = ifr;
ifc.ifc_len = n * sizeof(*ifr);
} while( ( ioctl( fd, SIOCGIFCONF, &ifc ) == -1 ) || (
ifc.ifc_len == n * si
f ifc;
>>> struct ifreq *ifr, *lifr;
>>> int fd;
>>> unsigned int n;
>>>
>>> fd = socket( AF_INET, SOCK_STREAM, 0 );
>>> bzero(&ifc, sizeof(ifc));
>>> n = 3;
>>> ifr = calloc( ifc.ifc_len, siz
ifr, sizeof(*ifr) * n );
bzero( ifr, sizeof(*ifr) * n );
ifc.ifc_req = ifr;
ifc.ifc_len = n * sizeof(*ifr);
} while( ( ioctl( fd, SIOCGIFCONF, &ifc ) == -1 ) || ( ifc.ifc_len
== n * sizeof(*ifr)) );
There are several problems with this loop. First, icoctl won
int fd;
> unsigned int n;
>
> fd = socket( AF_INET, SOCK_STREAM, 0 );
> bzero(&ifc, sizeof(ifc));
> n = 3;
> ifr = calloc( ifc.ifc_len, sizeof(*ifr) );
> do
> {
> n *= 2;
> ifr = realloc( ifr, sizeof(
ifc.ifc_req = ifr;
ifc.ifc_len = n * sizeof(*ifr);
} while( ( ioctl( fd, SIOCGIFCONF, &ifc ) == -1 ) || ( ifc.ifc_len
== n * sizeof(*ifr)) );
lifr = (struct ifreq *)&ifc.ifc_buf[ifc.ifc_len];
while (ifr < lifr)
{
printf( "%s\n", ifr->ifr_name )
> Hi,
>
> maybe this question is better asked in this list ...
>
> I was searching why ports/net/p5-Net-Interface was not working as
> expected and found some reasons. Most of them I can answer by implementing
> some test code as attached, but now I'm wondering why em0 is shown twice
> and lo0 is
Hi,
maybe this question is better asked in this list ...
I was searching why ports/net/p5-Net-Interface was not working as
expected and found some reasons. Most of them I can answer by implementing
some test code as attached, but now I'm wondering why em0 is shown twice
and lo0 is not included.
On Wed, Mar 14, 2007 at 10:01:38AM -0500, Brooks Davis wrote:
> On Wed, Mar 14, 2007 at 01:20:23PM +0300, Yar Tikhiy wrote:
> > Hi folks,
> >
> > Quite a while ago I noticed that our ioctl handlers get the ioctl
> > command via u_long, but ether_ioctl()'s c
On Wed, Mar 14, 2007 at 12:50:12PM +, Bruce M. Simpson wrote:
> Yar Tikhiy wrote:
> >Hi folks,
> >
> >Quite a while ago I noticed that our ioctl handlers get the ioctl
> >command via u_long, but ether_ioctl()'s command argument is int.
> >This disarray da
On Wed, Mar 14, 2007 at 01:20:23PM +0300, Yar Tikhiy wrote:
> Hi folks,
>
> Quite a while ago I noticed that our ioctl handlers get the ioctl
> command via u_long, but ether_ioctl()'s command argument is int.
> This disarray dates back to 1998, when ioctl functions started to
Yar Tikhiy wrote:
Hi folks,
Quite a while ago I noticed that our ioctl handlers get the ioctl
command via u_long, but ether_ioctl()'s command argument is int.
This disarray dates back to 1998, when ioctl functions started to
take u_long as the command, but ether_ioctl() was never
Hi folks,
Quite a while ago I noticed that our ioctl handlers get the ioctl
command via u_long, but ether_ioctl()'s command argument is int.
This disarray dates back to 1998, when ioctl functions started to
take u_long as the command, but ether_ioctl() was never fixed.
Fortunately, our
I have now added a regression test for this bug in HEAD, under
src/tools/regression/ethernet/ethermulti.
BMS
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECT
On 2/17/07, Bruce M. Simpson <[EMAIL PROTECTED]> wrote:
Jouke Witteveen wrote:
>
> So my apologies for suggesting it doesn't work at all; it seems that
> the application I'm trying to get to work (wpa_supplicant for wired
> interfaces) just doesn't _send_ its packets the right way.
That's a big r
Jouke Witteveen wrote:
I hope someone can find a spare minute to look at if_findmulti. It
would help me quite much.
I verified with mtest that FreeBSD cannot delete an AF_LINK multicast
membership, reproduced with both 7-CURRENT and 6.2-RELEASE.
if_findmulti() appears to be doing a possibly i
Here is a better patch for the netstat output. I haven't had time to
look at the kernel yet.
If this patch is good for you I'll commit it on -CURRENT. It cleans up
the group membership output significantly and displays the Link-layer
information separately.
If anyone 'out there' has been rel
Jouke Witteveen wrote:
So my apologies for suggesting it doesn't work at all; it seems that
the application I'm trying to get to work (wpa_supplicant for wired
interfaces) just doesn't _send_ its packets the right way.
That's a big relief! I added an item to the Wiki for someone to write a
regr
CDELMULTI rn it appears nothing was added:
> ENOENT), At least not for the values I tested, 1.80.c2.0.0.1 in
> particular. I presume it doesn't work because the program has not been
> revised in 3 years and revision 1.4 notes that it might not work.
> If this ioctl is depricated then
sted, 1.80.c2.0.0.1 in
particular. I presume it doesn't work because the program has not been
revised in 3 years and revision 1.4 notes that it might not work.
If this ioctl is depricated then please tell me what is the best way
to receive multicast messages from the 01.80.c2.00.00.0x (802.
ticular. I presume it doesn't work because the program has not been
revised in 3 years and revision 1.4 notes that it might not work.
If this ioctl is depricated then please tell me what is the best way
to receive multicast messages from the 01.80.c2.00.00.0x (802.1)
range? It is ofcourse poss
supplicant.conf
> > Trying to associate with SSID 'OFFICE-PEAP'
> > ioctl[SIOCS80211, op 21, len 42]: Invalid argument
> > Association request to the driver failed
> > ...
>
> "op 21" is the request to associate. The error most likely indicates
> t
Vladimir Grebenschikov wrote:
> Hi
>
> i am triing to connect Intel(R) PRO/Wireless 2200BG - iwi0 to WPA-EAP
> wireless network with PEAP:
>
> # wpa_supplicant -i iwi0 -c /usr/local/etc/wpa_supplicant.conf
> Trying to associate with SSID 'OFFICE-PEAP'
> ioctl[S
On Tuesday 19 September 2006 10:34, Vladimir Grebenschikov wrote:
> i am triing to connect Intel(R) PRO/Wireless 2200BG - iwi0 to WPA-EAP
> wireless network with PEAP:
>
> # wpa_supplicant -i iwi0 -c /usr/local/etc/wpa_supplicant.conf
> Trying to associate with SSID '
Hi
i am triing to connect Intel(R) PRO/Wireless 2200BG - iwi0 to WPA-EAP
wireless network with PEAP:
# wpa_supplicant -i iwi0 -c /usr/local/etc/wpa_supplicant.conf
Trying to associate with SSID 'OFFICE-PEAP'
ioctl[SIOCS80211, op 21, len 42]: Invalid argument
Association request to
!
Jul 30 12:22:35 sputnik ppp[1120]: Phase: deflink: IPV6CP protocol reject
closes IPV6CP !
Jul 30 12:22:38 sputnik ppp[1120]: Warning: iface add: ioctl(SIOCAIFADDR,
85.195.153.121 -> 82.198.6.19): File exists
Jul 30 12:22:38 sputnik ppp[1120]: Error: ipcp_InterfaceUp: unable to set ip
address
Jul
you?
!
! We should probably catch a sa_len of 0 as early as possible in ioctl paths
! too (suggested by gnn).
!
Index: route.c
===
RCS file: /shared/mirror/FreeBSD/r/ncvs/src/sys/net/route.c,v
retrieving revision 1.114
A coworker of mine discovered a bug in bpf with BIOCSEESENT.
In sys/net/bpf.c, bpf_mtap() does
if (pktlen == m->m_len) {
bpf_tap(bp, mtod(m, u_char *), pktlen);
return;
}
BPFIF_LOCK(bp);
LIST_FOREACH(d, &bp->bif_dlist, bd_next) {
= COM2 now this happens
both on PCI and ISA I figured with ISA it would be different.. )
router# /etc/ppp/pppserv
ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
?Connection on /dev/cuaa0 is not open.
?Connection on /dev/cuaa0 is not open.
?Connection on /dev/cuaa0 is no
Matthew Luckie wrote:
The motivation for this patch was to obtain something resembling the
timestamp closest to when a packet I generated and transmitted hit the
wire, to infer a more accurate RTT with an associated response packet.
That's certainly a worthy goal, but the patch might not help muc
This is probably a pointless optimization, as you probably relatively
rarely have multiple BPF devices bound to the same interface receiving
the bulk of the packets (as opposed to some daemon with a filter that
passes only the packets it's interested in), but would there be any
advantage to hav
In some email I received from Guy Harris, sie wrote:
> On Sep 8, 2004, at 2:26 AM, Bruce M Simpson wrote:
>
> > Here's a patch against 5.3 to add a per-instance switch which allows
> > the user to specify if captured packets should be timestamped (and,
> > if so, whether microtime() or the faster
(Noise to defeat the duplicate-message detector for
[EMAIL PROTECTED])
Guy Harris wrote:
This is probably a pointless optimization,
"This" referring not to Bruce's proposed change, but to my proposed
change to have one time stamp call per packet.
___
[
Guy Harris wrote:
This is probably a pointless optimization,
"This" referring not to your change, but to having one time stamp call
per packet.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send
>From Bruce's patch:
+ if (d->bd_tstamp == BPF_TSTAMP_MICROTIME)
+ microtime(&hp->bh_tstamp);
+ else if (d->bd_tstamp == BPF_TSTAMP_GETMICROTIME)
+ getmicrotime(&hp->bh_tstamp);
Perhaps set the timestamp to zero in the else case?
Ed Maste
Sandvine Inc.
___
es to libpcap and/or tcpdump,
> and would work with any application.
I think an ioctl is the right way to do it, since you could have
multiple BPF listeners with different requirements. For example,
realtime inspection like Snort may not care about timestamps while
manual inspection with tcpdump
On Sep 8, 2004, at 2:26 AM, Bruce M Simpson wrote:
Here's a patch against 5.3 to add a per-instance switch which allows
the user to specify if captured packets should be timestamped (and,
if so, whether microtime() or the faster but less accurate
getmicrotime() call should be used).
This is probabl
1 - 100 of 112 matches
Mail list logo
