Am Freitag, 7. Dezember 2007 04:20 schrieb David Miller:
If IPSEC takes a long time to resolve, and we don't block, the
connect() can hard fail (we will just keep dropping the outgoing SYN
packet send attempts, eventually hitting the retry limit) in cases
where if we did block it would not
Am Donnerstag, 6. Dezember 2007 03:25 schrieb David Miller:
POSIX says nothing about the semantics of route resolution.
Of course not. Applications must not care about what happens at the transport
layer.
Non-blocking doesn't mean cannot sleep no matter what.
... and as O_CREAT on open()
Am Donnerstag, 6. Dezember 2007 09:53 schrieb David Miller:
I think the words shall fail and immediately are quite clear.
They are, but the context in which they apply is vague.
socket is connection-mode = SOCK_STREAM
I can equally generate examples where the non-blocking behavior you
are
Am Donnerstag, 6. Dezember 2007 12:13 schrieb David Miller:
And that's why this is a grey area. Why is waiting for memory
allocation on a O_NONBLOCK socket OK but waiting for IPSEC route
resolution is not?
Because you just will put enough RAM modules into you server when setting up a
Am Donnerstag, 6. Dezember 2007 12:39 schrieb David Miller:
Because you just will put enough RAM modules into you server when
setting up a scalable system.
This suggestion is avoiding the important semantic issue, and
won't lead to a real discussion of the core problem.
When writing
Am Donnerstag, 6. Dezember 2007 14:55 schrieb David Miller:
You keep ignoring the fact that, as Herbert and I discussed, not
blocking for IPSEC resolution will make some connect() cases fail that
would otherwise not fail.
There are two sides to this issue, and we need to consider them
both.
Am Mittwoch, 5. Dezember 2007 07:51 schrieb Herbert Xu:
If he sets this sysctl to 1 as I detailed in my reply, he'll
get the behavior he wants.
Does anybody actually need the 0 setting? What would we break if
the default became 1?
I'd strongly suggest doing so. AFAIK, behaviour of
Am Mittwoch, 5. Dezember 2007 08:12 schrieb David Miller:
Actually, consider even a case like DNS. Let's say the timeout
is set to 2 seconds or something and you have 3 DNS servers
listed, on different IPSEC destinations, in your resolv.conf
Each IPSEC route that isn't currently resolved
Am Freitag, 20. Juli 2007 09:33 schrieben Sie:
Well, these useless abstractions are really annoying and nothing we allow
into other drivers either.
However, they make it easier for multiple developers to work as a team. This
is useful for development pace and makes maintainance less dependant
Am Freitag, 2. März 2007 22:26 schrieb David Miller:
The DHCP client should only care about a particular interface's
traffic, the one it wants to listen on.
Also, a DHCP client should close the socket between address acquisition and
renewal. The only interesting events in that period are
Am Mittwoch, 20. Dezember 2006 16:34 schrieb Arjan van de Ven:
5 seconds is unfair and unrealistic though. The *hardware* negotiation
before link is seen can easily take upto 45 seconds already.
That's a network topology/hardware issue (spanning tree fun) that
software or even the hardware in
Am Sonntag, 10. Dezember 2006 13:15 schrieb Thomas Graf:
Please send me the list of bugs you've spotted. Of course I want to fix
them.
Sure...
static void nl_handlemsg(struct nlmsghdr *msg, unsigned int len) {
if (len sizeof(*msg)) return;
while(NLMSG_OK(msg,len)) {
if
Am Freitag, 8. Dezember 2006 22:33 schrieb David Miller:
[IF(L)A_(RTA|PAYLOAD) macros]
iproute got fixed, dhcpclient and friends should get fixed to not use
them either
Today's git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git
contains stuff like
#ifndef IFA_RTA
#define
Am Samstag, 9. Dezember 2006 11:39 schrieb Thomas Graf:
[Added linux-kernel to CC]
Index: net-2.6/Documentation/feature-removal-schedule.txt
===
--- net-2.6.orig/Documentation/feature-removal-schedule.txt 2006-12-09
NAK.
Am Samstag, 9. Dezember 2006 13:55 schrieb Thomas Graf:
Please calm down a bit. I didn't claim that glibc should be linking to
libnl. glibc is obviously a special case which can simply copy the existing
macros into some internal compat header just like any other application
that doesn't wish
Hi Thomas,
Am Donnerstag, 7. Dezember 2006 11:55 schrieb Thomas Graf:
--- net-2.6.orig/include/linux/rtnetlink.h2006-12-07 11:25:29.0
+0100 +++ net-2.6/include/linux/rtnetlink.h 2006-12-07 11:32:25.0
+0100 @@ -3,6 +3,8 @@
#include linux/netlink.h
#include
Am Montag, 4. Dezember 2006 10:13 schrieb Thomas Graf:
I do not agree with the change to include if_addr.h in rtnetlink.h.
The point is to move bits apart and have multiple small pieces
of header files defining a specific rtnetlink family which are a
lot easier to maintain for both kernel and
Am Freitag, 6. Oktober 2006 16:59 schrieben Sie:
anyway, it's getting large, so... straight from quilt:
http://johannes.sipsolutions.net/files/cfg80211/
nice work! Is there any possibility to limit the card to a specific band (e.g.
802.11 a/b/g) using cfg80211? I'm asking because I haven't
Am Montag, 9. Oktober 2006 13:49 schrieb Johannes Berg:
Yeah, probably makes sense. Though, maybe not just the band but a set of
channels instead?
Yes, this would allow us to keep the definition of a band out of kernel. But
to distinguish between 802.11 b and g, we'd need a set of channels
is stopped at initialization time
or the device is marked not present, the state will be propagated to the
vlan device and never change. This also fixes VLAN devices being wrongly
registered as admin up since 2.6.17. Based on an analysis by Patrick
McHardy.
Signed-off-by: Stefan Rompf [EMAIL PROTECTED
-by: Stefan Rompf [EMAIL PROTECTED]
--- linux-2.6.17/net/8021q/vlan.c.orig 2006-07-07 13:00:56.0 +0200
+++ linux-2.6.17/net/8021q/vlan.c 2006-07-11 23:20:32.0 +0200
@@ -67,10 +67,6 @@ static struct packet_type vlan_packet_ty
.func = vlan_skb_recv, /* VLAN receive
Am Dienstag, 11. Juli 2006 23:28 schrieb Stephen Hemminger:
Untested, but here is the basic idea of how I think up/down should be
handled. Basically, rather than changing the flags directly the VLAN code
should call dev_open/dev_close. The notifier end's up recursively calling
but this is
[Trimmed CC list as we're off topic]
Am Sonntag, 9. Juli 2006 22:05 schrieb Krzysztof Halasa:
... and where the maintainer doesn't seem to care to use it now that the
infrastructure is there. Sigh.
This is very different from what I proposed and doesn't fit very well.
We've been
Am Montag, 10. Juli 2006 14:01 schrieb Krzysztof Halasa:
You've got two independant flags of which one does not stop the queue.
Is it ok to set that flag without synchronization with other flags?
I.e, from within another module and without using cross-module locks,
as I've shown at the
Am Montag, 10. Juli 2006 18:56 schrieb Stephen Hemminger:
1. I think vlan code should never be using the state bits directly at all.
It makes the code error prone if the bits ever change, and it means
that the proper callbacks are not being done. The existing
vlan_transfer_operstate does what
Am Sonntag, 9. Juli 2006 17:49 schrieb Ivo Van Doorn:
I have been quite busy lately, hence the reason for this late continuance
of the Hardware button support for Wireless cards discussion.
I have CC'ed the people who discussed this in earlier threads.
no problem. Look good, just one thing
Am Freitag, 7. Juli 2006 23:33 schrieb Stephen Hemminger:
Not really. The flag code last major change was to do the dormant
stuff that HDLC wanted.
... and where the maintainer doesn't seem to care to use it now that the
infrastructure is there. Sigh.
IMHO VLAN device's should mirror the
Am Donnerstag 06 Juli 2006 09:42 schrieb Patrick McHardy:
I believe this link-state logic was added by someone else. I'm not
sure exactly what these flags are supposed to do, so I am not sure if
they should be propagated to the VLAN or not.
I looked into this. The present flag used to
Am Dienstag 04 Juli 2006 12:07 schrieb Patrick McHardy:
- new_dev-state = real_dev-state VLAN_LINK_STATE_MASK;
+ new_dev-state = real_dev-state ~(1__LINK_STATE_START);
This introduced a regression by propagating the __LINK_STATE_XOFF flag,
when the queue of the underlying device is
Am Freitag 16 Juni 2006 20:36 schrieb Stefan Rompf:
(But that's an interesting point. Will sniff whether ipw2200 hardware sends
a final packet on suspend.)
neither on suspend to RAM nor on suspend to disk a disassociation is sent by
ipw2200 - for the AP, the client just vanishes.
Stefan
Am Mittwoch 21 Juni 2006 17:08 schrieb Luis R. Rodriguez:
Since d80211 is already being patched for sysfs how about we use sysfs
(and kobjects) to maintain the state at suspend() and resume(). This
would allow userspace tools like supplicant running in the background
to pick up from sysfs
Am Donnerstag 15 Juni 2006 21:58 schrieb Michael Buesch:
I am currently thinking about the best way to correctly
implement PM suspending for wireless drivers.
Currently, the 802.11 stack is not suspend aware (if I talk
about stack here, I mostly mean devicescape).
For example, if we suspend
Am Sonntag 04 Juni 2006 10:02 schrieb Ivo van Doorn:
Except for the bluetooth radio key (which should be supported by the
radiobtn interface as well) the other buttons have support through already
excisting input devices if I am correct.
You are wrong for quite a bunch of laptop models.
Am Freitag 02 Juni 2006 16:30 schrieb Ivo van Doorn:
Or actually, I don't think the radiobtn/ won't be actually needed as
prefix. The name passed to the radiobtn driver by the driver should be
sufficient.
Updated version,
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
I don't like the
Am Dienstag 30 Mai 2006 20:07 schrieb Ben Greear:
May 30 11:01:37 x64-1u avahi-daemon[2022]: Joining mDNS multicast group on
inter face eth2#18.IPv4 with address 172.1.2.20.
May 30 11:01:37 x64-1u avahi-daemon[2022]: IP_ADD_MEMBERSHIP failed: No
buffer s pace available
there is a
for one second every
49 days, avoiding 64bit operations. David, please prefer this patch over mine.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Acked-by: Stefan Rompf [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED
Am Dienstag 09 Mai 2006 20:31 schrieb Stephen Hemminger:
I moved iproute2 out of CVS. New home is:
fixed. stupid git
maybe you should have kept CVS. *Ducks and runs* ;-)
Stefan
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
with any possible delay in between.
This should be 2.6.17 stuff.
Signed-off-by: Stefan Rompf [EMAIL PROTECTED]
--- linux-2.6.17-rc3/net/core/link_watch.c.orig 2006-04-27 20:37:09.0
+0200
+++ linux-2.6.17-rc3/net/core/link_watch.c 2006-04-27 21:49:00.0
+0200
@@ -32,8 +32,8
Hi,
seems documentation got lost when the RFC2863-patch was applied. Having
documentation is good, so I resend it ;-)
Signed-off-by: Stefan Rompf [EMAIL PROTECTED]
--- /dev/null 2005-03-19 20:36:14.0 +0100
+++ linux-2.6.17-rc3/Documentation/networking/operstates.txt2006-04-27
22
Am Samstag 01 April 2006 06:25 schrieb Herbert Xu:
BTW, I like your idea of moving STP to user-space. In fact I think we
can extend it to move ARP to user-space as well.
Neighbor address resolution is such a basic networking feature that it should
not depend on a running userspace daemon to
Am Samstag 01 April 2006 12:27 schrieb David S. Miller:
Neighbor address resolution is such a basic networking feature that
it should not depend on a running userspace daemon to function
properly.
Routing is a pretty basic network feature, yet userspace manages it
and the kernel just
Am Samstag 01 April 2006 14:50 schrieb jamal:
No stefan - check arpd. Infact if you really want to scale ARP to many
many entries, you do it in user space. This has been proven more than
once in the past: Thats the main reason the current daemons exist. It is
AFAIK the primary purpose of arpd
Am Sonntag 12 März 2006 17:50 schrieb Michael Richardson:
I recently got a bug in my ear to try and get multiple-dhclients to
work on separate interfaces under Linux (a one-daemon-per-interface
model). Could use some advice from the linux masters (Jason, Andrew?)
if you can spare some time
Hi,
this makes me curious: What's the reason that e1000 driver intercepts and
somehow parses outgoing DHCP packets on the 82573?
Stefan
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Hi,
Am Freitag 17 Februar 2006 20:39 schrieb Simon Barber:
In 802.11 networks when connecting to a new AP on the same networks
(same SSID security settings) you typically don't have to do DHCP
again - but with some networks setups you do. In order to detect this,
when connecting to a new AP
Am Samstag 25 Februar 2006 11:53 schrieb Christoph Hellwig:
From a short glance over the driver code, the protocol between the _open
source_ driver and the binary user space daemon seems to be quite defined and
unobfuscated. Obviously, someone owning the device has to verify that the
daemon
dhcpclient
A DHCP client for linux 2.6, using modern kernel features, (c) 2006
Stefan Rompf.
Motivation
Using a notebook, I'm often traveling between different networks.
After replugging, I always needed to issue a ifdown/ifup sequence
because
Am Freitag 17 Februar 2006 19:39 schrieb Jean Tourrilhes:
I congratulate you on your good work.
Thanks!
I will share with you my personal gripe on most DHCP clients :
they depend too much on those link signalling. I hope you appreciate
the irony ;-)
Someone needs a feature,
Am Freitag 17 Februar 2006 20:39 schrieb Simon Barber:
In 802.11 networks when connecting to a new AP on the same networks
(same SSID security settings) you typically don't have to do DHCP
again - but with some networks setups you do. In order to detect this,
when connecting to a new AP
Am Samstag 28 Januar 2006 02:23 schrieb Jouni Malinen:
I could try to do this for Prism2/2.5/3 which takes care of management
frame processing in client mode. Please let me know if you have already
done some changes for ipw2100 that would be generic to cover other
drivers.
sorry, haven't
Am Mittwoch 25 Januar 2006 07:18 schrieb Zhu Yi:
This is what leads to the high ksoftirqd usage I reported October 2005
into the ipw bugzilla
(http://www.bughost.org/bugzilla/show_bug.cgi?id=825).
Sorry, I'm not aware of this bug since I'm not on the cc list.
Hmm, frankly the ipw
Am Mittwoch 25 Januar 2006 07:55 schrieb James Ketrenos:
The purpose for this code ever coming into existence within ieee80211
was based on discussions at OLS this past year in how to support for the
ability to start/stop independent Tx queues within a single net device
in order to support
Am Dienstag 17 Januar 2006 22:52 schrieb Stefan Rompf:
This patch implements suspend and resume methods for the starfire driver.
It allows me to put my desktop PC with a starfire dual board into S4.
Jeff, all email addresses of Ionut Badulescu I am aware of
([EMAIL PROTECTED] and [EMAIL
Am Dienstag 24 Januar 2006 09:36 schrieb Zhu Yi:
Two problems in ipw2200:
1. We now have the ieee_device-is_queue_full interface, and it will be
called at the beginning of ieee80211_xmit function. So no need to call
it at the driver xmit function.
This interface is totally broken.
Am Montag 23 Januar 2006 15:32 schrieb Johannes Berg:
Shouldn't you BSS-filter management packets too?
no, management packets are used to populate f.e. scanning results.
Stefan
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More
Am Samstag 21 Januar 2006 11:49 schrieb Lennert Buytenhek:
I ran into this problem with ixp2000 too. However, calling
netif_carrier_off calls into linkwatch_fire_event and I wasn't sure
whether this is the right thing to do when the netdev isn't even
registered yet.
This is not the right
Am Donnerstag 19 Januar 2006 16:56 schrieb John W. Linville:
The above represents my thinking on the issue. Ultimately the WiPHY
(aka radio) device should be thought of as a new class of driver,
distinct from a netdev. If we have to reroute some infrastructure
(i.e. qdisc) to make that
This patch implements suspend and resume methods for the starfire driver. It
allows me to put my desktop PC with a starfire dual board into S4.
Signed-Off-By: Stefan Rompf [EMAIL PROTECTED]
--- linux-2.6.15/drivers/net/starfire.c.orig2006-01-04 01:01:18.0
+0100
+++ linux-2.6.15
Am Dienstag 17 Januar 2006 20:42 schrieb Jouni Malinen:
Sure, you can do it that way, too. However, this is not the only use. I
just remembered another one: QoS. Devicescape 802.11 code uses a qdisc
on the master interface to take care of determining which hardware TX
queue to use with WMM
Am Sonntag 15 Januar 2006 21:11 schrieb Johannes Berg:
[iwconfig mode ...]
Yeah, I agree with this, it is much cleaner to handle in the kernel.
Think about the issues if you have a struct net_device that has 250
bytes of payload for the struct virtual_sta_device in it and you want
to switch
Am Dienstag 17 Januar 2006 19:37 schrieb Jirka Bohac:
- DeviceScape can be there so it can be polished and new drivers can
start using it.
- ieee80211 could be there with a big fat warning that it will go
away soon, just to allow ipw2x00 to work while DeviceScape and
the ipw2x00 port
Am Sonntag 15 Januar 2006 16:39 schrieb Stuffed Crust:
Internally, we're pure 802.11. One thing to keep in mind that we're not
going to be bridging/translating non-data traffic to other networks, and
with that in mind, 802.3-802.11 translation is trivial, and won't lose
anything except for a
Am Freitag 13 Januar 2006 23:32 schrieb Johannes Berg:
[Changing mode of virtual devices]
IMHO there's not much point in allowing changes. I have a feeling that
might create icky issues you don't want to have to tackle when the
solution is easy by just not allowing it. Part of my thinking is
Am Donnerstag 12 Januar 2006 13:57 schrieben Sie:
Unfortunately, I don't have time to do this right now as there are other
issues that should be addressed first - like the overall concept of
using net_devices. If you write some patches, I will really appreciate
it.
Let's first wait for the
Am Samstag 14 Januar 2006 13:28 schrieb Krzysztof Halasa:
What's the real current status of your RFC2863 patch?
Dunno, but wondering why new features for 2.6.16 have been closed without any
feedback on it.
Davem? (And frankly, if the RFC2863 and user/kernel operstate interaction
stuff is so
Am Samstag 14 Januar 2006 14:47 schrieb Ulrich Kunitz:
They one problem I can see is scanning over several frequencies.
If two virtual devices are doing this at the same time, we have a
conflict. Maybe each WiPHY would have only one active interface,
I think scanning can be easily serialized.
Am Sonntag 15 Januar 2006 16:51 schrieb Johannes Berg:
Isn't that rather a question of having good user-space tools that make
deactivating one type of interface and activating another seamless?
Well, it's always easy to point to userspace. However, unregister_netdev()
initiates a lot of
Am Mittwoch 11 Januar 2006 20:23 schrieb Jeff Garzik:
They may mean carrying some compat code in the kernel for a while, or
some other solution... The compat code could simply call netlink
internally, for example.
after all, the most important achievement for driver writers is that there is
Am Mittwoch 11 Januar 2006 16:05 schrieb Mike Kershaw:
As far as link type, theres no real reason radiotap couldn't be used
internally, but theres also no reason it's needed on anything other than
rfmon if we don't think we'll ever care about per-frame stats in
non-rfmon.
a software AP could
Hi Jiri,
to evaluate the Devicescape stack, I started porting the ipw2100 driver to it.
However I do have one major problem. At least the snapshort from January 2nd
does not seem to support devices that do scanning and associating controlled
by firmware.
Is this assumptions right, and if so,
Am Mittwoch 11 Januar 2006 15:49 schrieb Jiri Benc:
- There should be only as few net_devices as needed. I. e. when the card
acts as a client to one AP, only one device is present.
- The type of a device (AP, client, WDS link, monitor, etc.) should be
specified in the usual way (by
Hi,
so, can we agree on this:
a)we want to distinguish between physical devices and virtual devices.
Physical devices represent a network card, virtual devices a function based
on the card (access point, sta, ...). Some cards can handle multiple
functions parallel, we support it this way.
Am Donnerstag 05 Januar 2006 12:27 schrieb Ingo Oeser:
What about doing it in two steps (first RAM then FLASH)?
[...]
Is this possible or too simple to be true?
RAM firmware and flash firmware are different files, so if one works, it's no
guarantee that the other will, too.
Stefan
-
To
Hi all,
to learn about the in kernel 802.11 subsystem, driver writing and wireless in
general, I started a project to develop a driver for the prism2/prism3 usb
chipset. Goal was to get WPA support and the possibility to configure with
wireless extensions.
Unfortunately, I was rudely
. Also removed one ASSERT_RTNL() and report IF_OPER_DOWN via netlink when
device is admin down.
Signed-Off-By: Stefan Rompf [EMAIL PROTECTED]
diff -X dontdiff -uNrp linux-2.6.14/Documentation/networking/operstates.txt linux-2.6.14-rfc2863/Documentation/networking/operstates.txt
--- linux-2.6.14
on the VLAN device, not on the device the VLAN is stacked
on (as it happens in the two ;-) other places that use iflink)
Signed-Off-By: Stefan Rompf [EMAIL PROTECTED]
diff -X dontdiff -uNrp linux-2.6.14/net/8021q/vlan.c linux-2.6.14-rfc2863/net/8021q/vlan.c
--- linux-2.6.14/net/8021q/vlan.c 2005-11-02 11:07
Am Dienstag 06 Dezember 2005 22:25 schrieb Krzysztof Halasa:
Is Stefan's patch going to restore the functionality that you need?
I hope so. If done correctly, it would not only provide the
functionality my drivers were using before the breakage, it would
enable me to cut the dirty links
Am Donnerstag 01 Dezember 2005 13:48 schrieb Krzysztof Halasa:
- kernel driver signals lower-level down
- kernel driver signals lower-level up (dormant = 1)
- slow userspace (in this case, could be a kernel module if strict
serialization of all operational status changes isn't required)
Hi,
ok, seems we are getting near submission for kernel inclusion. If no new
comments arise, the only thing missing from my side is documentation. VLAN is
again included in this patch to show one use case.
Changes since last version:
-remove NETIF_F_STACKED, use dev-iflink instead. Change
Hi,
ok, at least some progress has happened:
-Replaced device-specific oper_state method with NETIF_F_STACKED flag to
select between IF_OPER_DOWN or IF_OPER_LOWERLAYERDOWN
-sysfs support to read operstate
-completed netlink support (Jamal, Thomas, can you verify the code?)
-added
Am Montag 28 November 2005 14:15 schrieb Stefan Rompf:
-complete sysfs
-test netlink userspace interaction
both done, next patch will follow when docs are written. Thomas: Thanks for
libnl, it made sending netlink messages a lot easier!
Stefan
-
To unsubscribe from this list: send the line
Am Montag 28 November 2005 23:13 schrieb Thomas Graf:
Looks good, it would be nice if you could separate the vlan part as a
separate patch for later on though.
This will happen when I submit the final patch for kernel inclusion.
The effort is nice but why do we need sysfs? Isn't netlink
Hi Jamal,
be transitioned to up/dormant etc. So an ethernet driver doesnt know it
needs to go from detecting peer link is up to next being authenticated
in the case of 802.1x. It just calls netif_carrier_on which checks
link_mode to decide on transition.
we could protect operstate with a
Hi Krzysztof,
No big deal with my generic HDLC (I may leave it one-layer though it's
quite dirty, and would be even less logical with the new
dormant/whatever).
Sorry, I don't get that and want to avoid further misunderstandings. So can
you use _ONE_ netdev_set_operstate() function to switch
Am Freitag 18 November 2005 04:03 schrieb jamal:
ok, I'll produce a patch then - first version will be available tomorrow
evening.
beauty.
Ok, here is the first 'merger' patch. At this stage, it is only compilation
tested against 2.6.14.
This is the data flow:
-Device changes
Am Donnerstag 17 November 2005 04:29 schrieb jamal:
1) There are read_only oper state IFF_XXX flags which are sent via
netlink to user space. These are set by the kernel (and not by user
space); they reflect the state of link.
We can avoid a myriad of new IFF_*-flags if we allow a
Am Dienstag 15 November 2005 18:54 schrieb Krzysztof Halasa:
You said the same to Thomas on IFF_WAIT. Both operstate_useroverride and
IFF_WAIT exist to allow userspace 802.1X/wpa supplicant interaction.
Are we sure about this? It might be the case but I don't think I've seen
such request.
Am Dienstag 15 November 2005 15:16 schrieb jamal:
Having said that, perhaps thats where the concept of useroverride you
have or IFF_WAIT needs to go. What should be done though is to select an
operational mode via admin flags - example the device is set by the
admin to dormant state or the
Am Dienstag 15 November 2005 21:22 schrieb Krzysztof Halasa:
I even responded to it. Show me where he requests anything similar to
operstate_useroverride or IFF_WAIT?
operstate_useroverride or IFF_WAIT are possible solutions to
-handle this part of Jouni's mail:
[...]
however, this would
Am Montag 14 November 2005 14:57 schrieb jamal:
My suggestion is at this point to ignore any L3 issues and have people
post their patches. RFC 2863 states MUST be taken into consideration.
Proper naming must be taken into account.
here we go. I've removed OPER_DORMANTL3* as requested and
Am Montag 14 November 2005 17:44 schrieb Krzysztof Halasa:
[As Jamal answers later, I'll just comment on the technical questions]
Why do you do that instead of atomic write?
as described in net/core/dev.c:
* The @dev_base list is protected by @dev_base_lock and the rtln
* semaphore.
*
*
Am Dienstag 15 November 2005 03:43 schrieb jamal:
I'll have more time for a comment this evening, but let me ask one question
until then:
1) I dont think operstare_useroverride is needed.
You said the same to Thomas on IFF_WAIT. Both operstate_useroverride and
IFF_WAIT exist to allow
Am Sonntag 13 November 2005 15:13 schrieb jamal:
Obviously, no. I mean route entry inactive flag (not existing yet)
which has exactly nothing to do with its destination.
I dont know what that would buy you that a blackhole route could not
give you: Packets will be dropped at the ip level
Am Sonntag 13 November 2005 16:09 schrieb jamal:
I think the discussions have been valuable despite the time they took.
This is just to bring us back to not go on a tangent and hopefully close
this sooner.
thanks for taking the time to moderate this.
We have agreed to implement based on
Am Mittwoch 09 November 2005 22:12 schrieb Thomas Graf:
Something like this should do the job, although it doesn't take care
of taking things up again for now. Now all supporters of this should
tell me how to implement any case of on demand interface after taking
the routes down.
[...]
Am Donnerstag 10 November 2005 01:02 schrieb Thomas Graf:
Assuming we use the overwrite schema you propose, right. The actual
representation would no longer be atomic though, e.g. when the bonding
master access the oper state from its slave you will suffer the exactly
same issues as with the
Am Mittwoch 09 November 2005 15:25 schrieb Thomas Graf:
It's still behind eth3 but not reachable at the moment. If you know
that the network can be reached via other interfaces then just don't
statically assign a route for it and have the routing daemon take care
of it, where's the problem?
Am Donnerstag 10 November 2005 01:10 schrieb Thomas Graf:
just one short comment, I'll have more time this evening:
But if you made the driver the proxy for making the state transitions we
should be fine, no?
I would absolutely appreciate a solution where no driver has to be
changed,
Am Montag 07 November 2005 14:50 schrieb Thomas Graf:
-migrate VLAN + BONDING to use OPER_LOWERLAYERDOWN
I think that bonding should check on the administrative status of
its slaves as well. Why not check for OPER_UP?
Yes, currently it seems to ignore admin status and does not even maintain
Am Montag 07 November 2005 18:45 schrieb Thomas Graf:
I'm sorry, I don't get the point. I assume the above is not a carrier
failure but something else to be detected by a keepalive protocol.
No, it's a carrier failure. Try this, eth1 is an ethernet interface without
the cable connected:
1 - 100 of 102 matches
Mail list logo
