* Re: [RFC] SECMARK 1.1
From: Patrick McHardy @ 2006-05-15 5:29 UTC (permalink / raw)
To: James Morris
Cc: selinux, netdev, netfilter-devel, Stephen Smalley, Daniel J Walsh,
Karl MacMillan, David S. Miller, Thomas Bleher
In-Reply-To: <Pine.LNX.4.64.0605150004590.645@d.namei>
James Morris wrote:
> On Sun, 14 May 2006, Patrick McHardy wrote:
>
>
>>James Morris wrote:
>>
>>>@@ -135,6 +175,9 @@ static int __init xt_secmark_init(void)
>>> {
>>> int err;
>>>
>>>+ if (tracking_enabled())
>>>+ need_conntrack();
>>>+
>>
>>This will load the conntrack modules even if the track flag is not set.
>
>
> I guess need_conntrack() could be moved to checkentry() and only called
> if the track flag is set.
That won't help, the function itself does nothing, its just a symbol
dependency.
>>Wouldn't it be better to put everything related to connection marking
>>in the CONNSECMARK target?
>
>
> It's more efficient this way, and simpler to manage.
>
> Currently, after security marking, the chain should normally terminate
> with a -j ACCEPT. Requiring the use of CONNSECMARK to label connections
> means inserting another rule before terminating the chain.
>
> Also, security marking for connections only occurs in the context of
> copying the security mark from packets, so there's no reason to build a
> general feature to do this into CONNSECMARK.
>
> Another possibility would be to get rid of CONNSECMARK completely and have
> SECMARK copy security marks from connections to packets via the use of a
> different flag (perhaps change --track into --save-state and then have
> --restore-state, or similar).
The reason why I'm asking is because my understanding is that SECMARK
would also be useful without conntrack, but automatically pulling in
the module leaves no option not to use conntrack except not to compile
this part in.
^ permalink raw reply
* Re: [RFC] SECMARK 1.1
From: James Morris @ 2006-05-15 5:57 UTC (permalink / raw)
To: Patrick McHardy
Cc: selinux, netdev, netfilter-devel, Stephen Smalley, Daniel J Walsh,
Karl MacMillan, David S. Miller, Thomas Bleher
In-Reply-To: <446811D3.5080905@trash.net>
On Mon, 15 May 2006, Patrick McHardy wrote:
> >>This will load the conntrack modules even if the track flag is not set.
> >
> >
> > I guess need_conntrack() could be moved to checkentry() and only called
> > if the track flag is set.
>
>
> That won't help, the function itself does nothing, its just a symbol
> dependency.
Not sure what you mean: it will cause ip_conntrack to be loaded, which
is needed when you specify the track flag.
> > Another possibility would be to get rid of CONNSECMARK completely and have
> > SECMARK copy security marks from connections to packets via the use of a
> > different flag (perhaps change --track into --save-state and then have
> > --restore-state, or similar).
>
>
> The reason why I'm asking is because my understanding is that SECMARK
> would also be useful without conntrack,
Yes.
> but automatically pulling in the module leaves no option not to use
> conntrack except not to compile this part in.
Conntrack will only be loaded if someone uses "SECMARK --track", which is
exactly what is desired. Without --track, conntrack will not be loaded
by SECMARK.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [RFC] SECMARK 1.1
From: Patrick McHardy @ 2006-05-15 6:04 UTC (permalink / raw)
To: James Morris
Cc: selinux, netdev, netfilter-devel, Stephen Smalley, Daniel J Walsh,
Karl MacMillan, David S. Miller, Thomas Bleher
In-Reply-To: <Pine.LNX.4.64.0605150153590.1275@d.namei>
James Morris wrote:
> On Mon, 15 May 2006, Patrick McHardy wrote:
>
>
>>>>This will load the conntrack modules even if the track flag is not set.
>>>
>>>
>>>I guess need_conntrack() could be moved to checkentry() and only called
>>>if the track flag is set.
>>
>>
>>That won't help, the function itself does nothing, its just a symbol
>>dependency.
>
>
> Not sure what you mean: it will cause ip_conntrack to be loaded, which
> is needed when you specify the track flag.
Yes, but the reason why it is loaded is because the module loader needs
to resolve the symbol, not because of anything done at module runtime.
^ permalink raw reply
* ipv6 routing broken in 2.6.17-rc3,4
From: Meelis Roos @ 2006-05-15 6:18 UTC (permalink / raw)
To: netdev
On my home 6to4 gw, ipv6 routing seems to be broken and everything is
sent to 6to4 tunnel (the default route). It worked with
fine for a long time and with 2.6.17-rc2-g4d5c34ec and it's broken with
vmlinuz-2.6.17-rc3-g3cd73eed and 2.6.17-rc4-g9be2f7c3 (yesterdays
kernel).
Example (I add an unreachable route to an ipv6 address to force going
there by ipv4 and it still uses the route):
vaarikas:~# ip -6 route add unreachable 2001:7a8:1:5::14
vaarikas:~# ping6 2001:7a8:1:5::14
PING 2001:7a8:1:5::14(2001:7a8:1:5::14) 56 data bytes
64 bytes from 2001:7a8:1:5::14: icmp_seq=1 ttl=55 time=56.7 ms
64 bytes from 2001:7a8:1:5::14: icmp_seq=2 ttl=55 time=55.5 ms
--- 2001:7a8:1:5::14 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 55.573/56.155/56.738/0.628 ms
vaarikas:~# ip -6 route
::/96 via :: dev tun6to4 metric 256 expires 21332659sec mtu 1480 advmss 1420 hoplimit 4294967295
unreachable 2001:7a8:1:5::14 dev lo metric 1024 expires 21334221sec error -101 mtu 16436 advmss 16376 hoplimit 4294967295
2002:5283:297e:2::/64 dev eth0 metric 256 expires 21332659sec mtu 1500 advmss 1440 hoplimit 4294967295
2002:5283:297e::/48 dev tun6to4 metric 256 expires 21332659sec mtu 1480 advmss 1420 hoplimit 4294967295
2000::/3 via ::192.88.99.1 dev tun6to4 metric 1 expires 21332659sec mtu 1480 advmss 1420 hoplimit 4294967295
fe80::/64 dev eth0 metric 256 expires 21332650sec mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev eth1 metric 256 expires 21332654sec mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev tun6to4 metric 256 expires 21332659sec mtu 1480 advmss 1420 hoplimit 4294967295
ff00::/8 dev eth1 metric 256 expires 21332654sec mtu 1500 advmss 1440 hoplimit 4294967295
ff00::/8 dev tun6to4 metric 256 expires 21332659sec mtu 1480 advmss 1420 hoplimit 4294967295
ff00::/8 dev eth0 metric 256 expires 21332650sec mtu 1500 advmss 1440 hoplimit 4294967295
unreachable default dev lo proto none metric -1 error -101 hoplimit 255
Additional example: nothing goes in the direction of eth0, the packets
that should go there also go to tun6to4 interface as confirmed by
tcpdump. I have a laptop on eth0 and when I tracepath6 some external
address, I get this from tun4to4 device on the gw:
vaarikas:~# tcpdump -n -s 1500 -vv -i tun6to4
tcpdump: WARNING: tun6to4: no IPv4 address assigned
tcpdump: listening on tun6to4, link-type RAW (Raw IP), capture size 1500 bytes
09:14:08.053137 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1240) 2002:5283:297e::42 > 2002:5283:297e:2:210:60ff:fe5a:d6f5: [icmp6 sum ok] ICMP6, time exceeded in-transit, length 1240 for 2001:ad0::10
09:14:09.050230 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1240) 2002:5283:297e::42 > 2002:5283:297e:2:210:60ff:fe5a:d6f5: [icmp6 sum ok] ICMP6, time exceeded in-transit, length 1240 for 2001:ad0::10
09:14:10.091294 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1240) 2002:5283:297e::42 > 2002:5283:297e:2:210:60ff:fe5a:d6f5: [icmp6 sum ok] ICMP6, time exceeded in-transit, length 1240 for 2001:ad0::10
09:14:11.090985 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1240) 2002:5283:297e::42 > 2002:5283:297e:2:210:60ff:fe5a:d6f5: [icmp6 sum ok] ICMP6, packet too big, length 1240, mtu 1480
09:14:12.090354 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1240) 2002:5283:297e::42 > 2002:5283:297e:2:210:60ff:fe5a:d6f5: [icmp6 sum ok] ICMP6, packet too big, length 1240, mtu 1480
09:14:13.090373 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1240) 2002:5283:297e::42 > 2002:5283:297e:2:210:60ff:fe5a:d6f5: [icmp6 sum ok] ICMP6, packet too big, length 1240, mtu 1480
09:14:14.091355 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1240) 2002:5283:297e::42 > 2002:5283:297e:2:210:60ff:fe5a:d6f5: [icmp6 sum ok] ICMP6, packet too big, length 1240, mtu 1480
...
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: [RFC] SECMARK 1.1
From: James Morris @ 2006-05-15 6:22 UTC (permalink / raw)
To: Patrick McHardy
Cc: selinux, netdev, netfilter-devel, Stephen Smalley, Daniel J Walsh,
Karl MacMillan, David S. Miller, Thomas Bleher
In-Reply-To: <446819FE.8050300@trash.net>
On Mon, 15 May 2006, Patrick McHardy wrote:
> > Not sure what you mean: it will cause ip_conntrack to be loaded, which
> > is needed when you specify the track flag.
>
>
> Yes, but the reason why it is loaded is because the module loader needs
> to resolve the symbol, not because of anything done at module runtime.
Am I missing something? This is what I want to happen. If you specify
SECMARK --track, ip_conntrack is to be loaded.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [RFC] SECMARK 1.1
From: Patrick McHardy @ 2006-05-15 6:26 UTC (permalink / raw)
To: James Morris
Cc: selinux, netdev, netfilter-devel, Stephen Smalley, Daniel J Walsh,
Karl MacMillan, David S. Miller, Thomas Bleher
In-Reply-To: <Pine.LNX.4.64.0605150221000.1275@d.namei>
James Morris wrote:
> On Mon, 15 May 2006, Patrick McHardy wrote:
>
>
>>>Not sure what you mean: it will cause ip_conntrack to be loaded, which
>>>is needed when you specify the track flag.
>>
>>
>>Yes, but the reason why it is loaded is because the module loader needs
>>to resolve the symbol, not because of anything done at module runtime.
>
>
> Am I missing something? This is what I want to happen. If you specify
> SECMARK --track, ip_conntrack is to be loaded.
But if you don't specify --track, the module loader will still have to
resolve the symbol, so it gets loaded anyway, before your code will
even run. Just look at need_conntrack():
/* Some modules need us, but don't depend directly on any symbol.
They should call this. */
void need_conntrack(void)
{
}
^ permalink raw reply
* Re: [RFC] SECMARK 1.1
From: James Morris @ 2006-05-15 6:37 UTC (permalink / raw)
To: Patrick McHardy
Cc: selinux, netdev, netfilter-devel, Stephen Smalley, Daniel J Walsh,
Karl MacMillan, David S. Miller, Thomas Bleher
In-Reply-To: <44681F0F.9030601@trash.net>
On Mon, 15 May 2006, Patrick McHardy wrote:
> But if you don't specify --track, the module loader will still have to
> resolve the symbol, so it gets loaded anyway, before your code will
> even run. Just look at need_conntrack():
Doh. It should be try_module_get(). Sound ok?
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [RFC] SECMARK 1.1
From: James Morris @ 2006-05-15 6:42 UTC (permalink / raw)
To: Patrick McHardy
Cc: selinux, netdev, netfilter-devel, Stephen Smalley, Daniel J Walsh,
Karl MacMillan, David S. Miller, Thomas Bleher
In-Reply-To: <Pine.LNX.4.64.0605150236270.1824@d.namei>
On Mon, 15 May 2006, James Morris wrote:
>
> Doh. It should be try_module_get(). Sound ok?
Of course, I mean request_module().
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [RFC] SECMARK 1.1
From: Patrick McHardy @ 2006-05-15 6:43 UTC (permalink / raw)
To: James Morris
Cc: selinux, netdev, netfilter-devel, Stephen Smalley, Daniel J Walsh,
Karl MacMillan, David S. Miller, Thomas Bleher
In-Reply-To: <Pine.LNX.4.64.0605150236270.1824@d.namei>
James Morris wrote:
> On Mon, 15 May 2006, Patrick McHardy wrote:
>
>
>>But if you don't specify --track, the module loader will still have to
>>resolve the symbol, so it gets loaded anyway, before your code will
>>even run. Just look at need_conntrack():
>
>
> Doh. It should be try_module_get(). Sound ok?
try_module_get already needs a module reference, so this won't work
either. As far as I can tell the only thing you can do besides
putting it in a seperate module is to manually call request_module().
^ permalink raw reply
* Re: [PATCH wireless-dev] d80211: Don't discriminate against 802.11b drivers
From: Jiri Benc @ 2006-05-15 11:37 UTC (permalink / raw)
To: Michael Wu; +Cc: John W. Linville, Jouni Malinen, netdev, jkmaline
In-Reply-To: <200605121635.27959.flamingice@sourmilk.net>
On Fri, 12 May 2006 16:35:27 -0400, Michael Wu wrote:
> Hm, so why not add something that will tell you what modes are supported by
> the hardware?
Sounds reasonable.
> Only problem with this patch is if the hardware adds any modes after
> registration, they will be disabled initially. Hopefully, no drivers will
> actually need to do that.
bcm43xx does that. If I understand it correctly, bcm43xx driver doesn't
know allowed modes until it loads firmware. And the firmware is not
loaded until the device is opened (they probably have a reason for
this).
This issue can be easily solved by not masking hw_modes by
valid_hw_modes in ieee80211_ioctl_prism2_param and
ieee80211_precalc_modes. Just check (hw_modes & valid_hw_modes) instead
of hw_modes in ieee80211_sta_scan_timer.
And yes, hw_modes is a confusing name. It should be named
hw_modes_mask_disabled_by_user or so. Maybe at least some better comment
about this in ieee80211_i.h won't be a bad idea.
Thanks,
Jiri
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Re: [PATCH wireless-dev] d80211: Don't discriminate against 802.11b drivers
From: Johannes Berg @ 2006-05-15 12:04 UTC (permalink / raw)
To: Jiri Benc; +Cc: Michael Wu, John W. Linville, Jouni Malinen, netdev, jkmaline
In-Reply-To: <20060515133725.3df090af@griffin.suse.cz>
[-- Attachment #1: Type: text/plain, Size: 432 bytes --]
On Mon, 2006-05-15 at 13:37 +0200, Jiri Benc wrote:
>
> bcm43xx does that. If I understand it correctly, bcm43xx driver doesn't
> know allowed modes until it loads firmware. And the firmware is not
> loaded until the device is opened (they probably have a reason for
> this).
No, that's not right, the firmware has nothing to do with it. At least
not that we know of, so we treat it as all doing the same :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* [RFC] changing value of NETDEV_ALIGN to cacheline size
From: Christian Borntraeger @ 2006-05-15 12:08 UTC (permalink / raw)
To: netdev
while digging through the alloc_netdev function I asked myself why there is a
fixed alignment for netdevices. Is there a special reason for choosing 32? If
yes, I suggest to add a comment to the definition.
If not, I suspect cacheline alignment might be beneficial:
struct net_device contains several variables which are cache aligned
(poll_list, queue_lock .....). As far as I can see, the compiler tries to
increase the size of the structure to make that possible, but expects the
whole structure to be aligned to cache line size as well. With the current
value for NETDEV_ALIGN we dont align "struct net_device" to the cache line,
instead we align it to 32 bytes. That means that poll_list, queue_lock and
friends are not always cache aligned, but 32 bytes aligned.
The only reason why everything worked so far is the slab allocator design,
which gives us a page aligned struct net_device in most cases. I think we
should not rely on the behaviour of the memory allocator and use a different
value for NETDEV_ALIGN instead. Any comments or corrections?
cheers Christian
The patch below is compile and boot tested on s390 and x86.
Signed-off-by: Christian Borntraeger <borntrae@de.ibm.com>
include/linux/netdevice.h | 2 +-
net/core/dev.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
----------
--- a/include/linux/netdevice.h 4 Apr 2006 07:25:47 -0000
+++ b/include/linux/netdevice.h 15 May 2006 11:06:05 -0000
@@ -504,7 +504,7 @@
struct class_device class_dev;
};
-#define NETDEV_ALIGN 32
+#define NETDEV_ALIGN L1_CACHE_BYTES
#define NETDEV_ALIGN_CONST (NETDEV_ALIGN - 1)
static inline void *netdev_priv(struct net_device *dev)
--- a/net/core/dev.c 4 Apr 2006 07:25:50 -0000
+++ b/net/core/dev.c 15 May 2006 11:06:05 -0000
@@ -2986,7 +2986,7 @@
struct net_device *dev;
int alloc_size;
- /* ensure 32-byte alignment of both the device and private area */
+ /* ensure cacheline alignment of both the device and private area */
alloc_size = (sizeof(*dev) + NETDEV_ALIGN_CONST) & ~NETDEV_ALIGN_CONST;
alloc_size += sizeof_priv + NETDEV_ALIGN_CONST;
^ permalink raw reply
* Re: [RFC] SECMARK 1.1
From: Karl MacMillan @ 2006-05-15 12:35 UTC (permalink / raw)
To: James Morris
Cc: selinux, netdev, netfilter-devel, Stephen Smalley, Daniel J Walsh,
Patrick McHardy, David S. Miller, Thomas Bleher
In-Reply-To: <Pine.LNX.4.64.0605140133560.5506@d.namei>
On Sun, 2006-05-14 at 02:03 -0400, James Morris wrote:
> Included below is an incremental patch against the initial secmark posting
> last week: http://thread.gmane.org/gmane.linux.network/34927/focus=34927
>
> This posting to gather feedback on changes made since then primarily to
> address concerns raised by Karl MacMillan on providing fine-grained
> assurances for network applications which pass connections (e.g. xinetd).
>
> If all looks ok, I'll rebase the entire patchset (also merging elements
> from the patch below back into other patches), and submit it for inclusion
> in 2.6.18. As it touches a bunch of networking code, it may be best to
> aim for Dave's tree, although it could also go into -mm.
>
> Anyway, the way the issue has been addressed is to implement something
> similar to CONNMARK, but specific to this useage scenario and dealing with
> security markings instead of network markings.
>
> In a nutshell:
>
> 1. A --track option was added to the SECMARK target, which causes the
> security mark being applied to the packet to also be applied to a new
> secmark field on the conntrack (only if it is unmarked).
>
> 2. A new CONNSECMARK target was added which copies the secmark value to
> packets.
>
> This allows all packets on a connection (or related to it) to be marked
> with the same security label, so that they can be explicitly
> differentiated.
>
> This also turns out to simplify the SELinux policy, while the xtables
> implementation has been designed to remain as simple as possible (e.g. it
> only copies lables to packets, and has no options).
>
> So, here's an example of per-packet network policy for vsftpd with the new
> code:
>
> allow ftpd_t ftpd_packet_t:packet { recv send };
>
> Assuming it doesn't do DNS lookups, that's it in terms of access control
> rules for packets. This covers all established and related packets,
> including ICMP and the FTP data connetion.
>
James,
This seems to address my concerns - thanks.
Karl
--
Karl MacMillan
Tresys Technology
www.tresys.com
^ permalink raw reply
* Hardware button support for Wireless cards
From: Mark Wallis @ 2006-05-15 12:57 UTC (permalink / raw)
To: netdev
Hi everyone,
During our development of the rt2x00 wireless driver we have come across an
interesting issue that we want to get comment on from the netdev-community.
Some laptops with our Ralink cards build-in also include a hardware button
that is meant to enable/disable the wireless card. We are wondering how we
should handle this.
Currently, in our rt2x00 (using the devicescape stack) we are firing off an
ACPI event so that the hardware button can be handled in userspace. This
allows the user to basically do whatever they want when this button is
pressed - including bringing down the wireless interface. The problem here
is no distro's currently contain scripts to run from this event so for many
users it just "doesn't work" without them manually having to write scripts
to handle the ACPI even themselves.
Some people are saying that instead of throwing and ACPI event we should be
either use hotplug or internally just disable the radio and somehow inform
the dscape stack that the radio has been disabled.
What are peoples thoughts here, should we
A. be handling this within our drivers and doing "what the user expects" and
disabling the hardware radio, or
B. should we be firing an ACPI event and getting the distro's to add scripts
so when this event is fired they bring down all the wireless interfaces.
Regards,
Mark Wallis
Project Admin
http://rt2x00.serialmonkey.com
mwallis@serialmonkey.com
^ permalink raw reply
* BANESTO INFORMACION IMPORTANTE SOBRE SU SEGURIDAD
From: Support @ 2006-05-15 13:01 UTC (permalink / raw)
To: netdev
Apreciado cliente de banca en linea,
El servidor bancario tuvo un falllo durante el mantenimiento de sistema y causo una perdida parcial de datos de varios clientes. Lamentamos la situacion y pedimos su ayuda en la recuperacion de los datos perdidos. Por favor pinche en el link de abajo y rellene los datos que le pida el formulario. Si no tenemos noticias de usted dentro de 14 dias su cuenta sera suspendida temporalmente y tendra que llamar a su oficina para activarla de nuevo. Enormemente apreciamos su entendimiento y cooperacion.
http://extranet.banestoespana.com
Atentamente,
Alfredo Camara Garcia.
Departamento de seguridad y asistencia al cliente.
BANCO ESPANOL DE CREDITO S.A.
^ permalink raw reply
* Re: SIOCSIWESSID + SIOCSIWAP behaviour
From: Jouni Malinen @ 2006-05-15 13:16 UTC (permalink / raw)
To: Dan Williams; +Cc: Daniel Drake, Jean Tourrilhes, netdev, softmac-dev
In-Reply-To: <1147663779.2204.27.camel@localhost.localdomain>
On Sun, May 14, 2006 at 11:29:38PM -0400, Dan Williams wrote:
> On Mon, 2006-05-15 at 00:29 +0100, Daniel Drake wrote:
> > When SIWESSID happens, softmac drops association/authentication with the
> > current network and then starts a scan for the requested SSID. When
> > found, softmac authenticates and associates to that network.
I don't think there is requirement for doing a new scan here if recent
scan results are available.
> > When SIWAP happens, softmac drops association/authentication with the
> > current network and then starts a scan for the requested BSSID. When
> > found, softmac authenticates and associates to that network.
Same here. Neither of these commands should drop IEEE 802.11
authentication. I would say that neither should drop association either
until a new association is available or it is clear that current
configuration does not allow association to be created. First case would
just report a new association (no disassociation reported) and second
case would report disassociation to user space.
> > Right now, wpa_supplicant does SIWESSID and SIWAP in quick succession,
> > which causes softmac to associate twice, and that quickly confuses things.
>
> (I don't really understand why wpa_supplicant uses SIWAP when a BSSID
> isn't specified in the config file, but...)
There are two different modes and what is being described here is
ap_scan=1, i.e., wpa_supplicant being responsible for requesting
scanning and selecting an AP. In this mode, it is actually assumed that
the driver does not do extra scans with SIWAP or SIWESSID.
wpa_supplicant is telling the driver which channel (SIOCSIWFREQ), SSID,
and BSSID to use.
In the other mode, ap_scan=2, wpa_supplicant is only configuring the
SSID and requesting the driver (or well, kernel side 802.11 management
code) to figure out which AP to use.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: Hardware button support for Wireless cards
From: Jiri Benc @ 2006-05-15 13:25 UTC (permalink / raw)
To: Mark Wallis; +Cc: netdev
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAAC4AAAAAAAAAWMRZS97Em0WybTChcxl4cAEALirLb4lrrkmZC6EvT+GpyAAAAABE9gAAEAAAALs6jNngvN9OooViTUM1CgIBAAAAAA==@serialmonkey.com>
On Mon, 15 May 2006 22:57:12 +1000, Mark Wallis wrote:
> Currently, in our rt2x00 (using the devicescape stack) we are firing off an
> ACPI event so that the hardware button can be handled in userspace. This
> allows the user to basically do whatever they want when this button is
> pressed - including bringing down the wireless interface. The problem here
> is no distro's currently contain scripts to run from this event so for many
> users it just "doesn't work" without them manually having to write scripts
> to handle the ACPI even themselves.
Distributions will need to accommodate to the way d80211 stack works
anyway, so I see no problem with this.
> B. should we be firing an ACPI event and getting the distro's to add scripts
> so when this event is fired they bring down all the wireless interfaces.
Voting for this. It brings more flexibility.
This is not a problem of your card only. Is there a standard ACPI
rf-kill event?
Jiri
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Re: [PATCH wireless-dev] d80211: Don't discriminate against 802.11b drivers
From: Jiri Benc @ 2006-05-15 13:35 UTC (permalink / raw)
To: Johannes Berg; +Cc: Michael Wu, netdev
In-Reply-To: <1147694684.29795.30.camel@johannes.berg>
[removed some people from Cc: list as this is probably not much
interesting for them]
On Mon, 15 May 2006 14:04:44 +0200, Johannes Berg wrote:
> On Mon, 2006-05-15 at 13:37 +0200, Jiri Benc wrote:
> > bcm43xx does that. If I understand it correctly, bcm43xx driver doesn't
> > know allowed modes until it loads firmware. And the firmware is not
> > loaded until the device is opened (they probably have a reason for
> > this).
>
> No, that's not right, the firmware has nothing to do with it. At least
> not that we know of, so we treat it as all doing the same :)
Hm, so your calls to ieee80211_update_hw are probably unnecessary.
Anyway, I'm still inclined towards not masking hw_modes by
valid_hw_modes.
Jiri
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* BANESTO INFORMACION IMPORTANTE SOBRE SU SEGURIDAD
From: admin @ 2006-05-15 13:57 UTC (permalink / raw)
To: netdev
Apreciado cliente de banca en linea,
El servidor bancario tuvo un falllo durante el mantenimiento de sistema y causo una perdida parcial de datos de varios clientes. Lamentamos la situacion y pedimos su ayuda en la recuperacion de los datos perdidos. Por favor pinche en el link de abajo y rellene los datos que le pida el formulario. Si no tenemos noticias de usted dentro de 14 dias su cuenta sera suspendida temporalmente y tendra que llamar a su oficina para activarla de nuevo. Enormemente apreciamos su entendimiento y cooperacion.
http://extranet.bancaespanol.com
Atentamente,
Alfredo Camara Garcia.
Departamento de seguridad y asistencia al cliente.
BANCO ESPANOL DE CREDITO S.A.
^ permalink raw reply
* Re: Hardware button support for Wireless cards
From: Ivo van Doorn @ 2006-05-15 13:59 UTC (permalink / raw)
To: Jiri Benc; +Cc: Mark Wallis, netdev
In-Reply-To: <20060515152513.5095b2d5@griffin.suse.cz>
[-- Attachment #1: Type: text/plain, Size: 1295 bytes --]
On Monday 15 May 2006 15:25, Jiri Benc wrote:
> On Mon, 15 May 2006 22:57:12 +1000, Mark Wallis wrote:
> > Currently, in our rt2x00 (using the devicescape stack) we are firing off an
> > ACPI event so that the hardware button can be handled in userspace. This
> > allows the user to basically do whatever they want when this button is
> > pressed - including bringing down the wireless interface. The problem here
> > is no distro's currently contain scripts to run from this event so for many
> > users it just "doesn't work" without them manually having to write scripts
> > to handle the ACPI even themselves.
>
> Distributions will need to accommodate to the way d80211 stack works
> anyway, so I see no problem with this.
>
> > B. should we be firing an ACPI event and getting the distro's to add scripts
> > so when this event is fired they bring down all the wireless interfaces.
>
> Voting for this. It brings more flexibility.
>
> This is not a problem of your card only. Is there a standard ACPI
> rf-kill event?
Not sure actually. the approach rt2x00 takes is sending an event ACPI_TYPE_EVENT
with as argument a 0 or 1 depending on the new state of the button.
But I don't know if there is another event that would be more suitable for a hardware button.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH wireless-dev] d80211: Don't discriminate against 802.11b drivers
From: Michael Buesch @ 2006-05-15 14:01 UTC (permalink / raw)
To: Jiri Benc, Michael Wu, netdev, Johannes Berg
In-Reply-To: <20060515153533.11491649@griffin.suse.cz>
On Monday 15 May 2006 15:35, you wrote:
> [removed some people from Cc: list as this is probably not much
> interesting for them]
>
> On Mon, 15 May 2006 14:04:44 +0200, Johannes Berg wrote:
> > On Mon, 2006-05-15 at 13:37 +0200, Jiri Benc wrote:
> > > bcm43xx does that. If I understand it correctly, bcm43xx driver doesn't
> > > know allowed modes until it loads firmware. And the firmware is not
> > > loaded until the device is opened (they probably have a reason for
> > > this).
> >
> > No, that's not right, the firmware has nothing to do with it. At least
> > not that we know of, so we treat it as all doing the same :)
>
> Hm, so your calls to ieee80211_update_hw are probably unnecessary.
No, We must allocate the ieee80211_hw, before we can attach the board.
But before we attached the board, we don't know what hardware it is.
Sure, this can be worked around by some very ugly hack (It was done
in an early version of the dscape port, because there was no
ieee80211_update_hw), but I am not very happy to add the hack again.
(I am not sure anymore _what_ we actually did to workaround it. I would
have to look up the SVN repository ;) )
^ permalink raw reply
* Re: Hardware button support for Wireless cards
From: Sergey Vlasov @ 2006-05-15 14:06 UTC (permalink / raw)
To: Mark Wallis; +Cc: netdev
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAAC4AAAAAAAAAWMRZS97Em0WybTChcxl4cAEALirLb4lrrkmZC6EvT+GpyAAAAABE9gAAEAAAALs6jNngvN9OooViTUM1CgIBAAAAAA==@serialmonkey.com>
[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]
On Mon, 15 May 2006 22:57:12 +1000 Mark Wallis wrote:
> What are peoples thoughts here, should we
>
> A. be handling this within our drivers and doing "what the user expects" and
> disabling the hardware radio, or
>
> B. should we be firing an ACPI event and getting the distro's to add scripts
> so when this event is fired they bring down all the wireless interfaces.
Using ACPI events for this purpose seems wrong:
- ACPI is not available on all architectures supported by Linux,
therefore it cannot be an universal solution;
- even if ACPI is available, it may be turned off for some reason.
In fact, many people consider the separate /proc/acpi/event interface
for ACPI events to be a mistake, and there is some movement to make ACPI
use the input layer instead:
http://lkml.org/lkml/2006/4/19/275
There is even a KEY_RADIO defined in <linux/input.h> (however, it was
probably intended to be used for a remote control key, like
TV/VCR/CD/Tape/... defined near it, so I'm not sure whether it would be
the proper event to use here).
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH wireless-dev] d80211: Don't discriminate against 802.11b drivers
From: Jiri Benc @ 2006-05-15 14:12 UTC (permalink / raw)
To: Michael Buesch; +Cc: Michael Wu, netdev, Johannes Berg
In-Reply-To: <200605151601.49290.mb@bu3sch.de>
On Mon, 15 May 2006 16:01:48 +0200, Michael Buesch wrote:
> No, We must allocate the ieee80211_hw, before we can attach the board.
> But before we attached the board, we don't know what hardware it is.
> Sure, this can be worked around by some very ugly hack (It was done
> in an early version of the dscape port, because there was no
> ieee80211_update_hw), but I am not very happy to add the hack again.
> (I am not sure anymore _what_ we actually did to workaround it. I would
> have to look up the SVN repository ;) )
Isn't it possible to do attaching of the board between
ieee80211_alloc_hw and ieee80211_register_hw calls? You don't need to
call ieee80211_update_hw then.
Anyway, the ieee80211_update_hw function is here for a reason (solving
issues with a firmware primarily, but not exclusively), so use it if it
is easier for you.
Jiri
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Re: SIOCSIWESSID + SIOCSIWAP behaviour
From: Dan Williams @ 2006-05-15 14:19 UTC (permalink / raw)
To: Jouni Malinen; +Cc: Daniel Drake, Jean Tourrilhes, netdev, softmac-dev
In-Reply-To: <20060515131656.GC9673@instant802.com>
On Mon, 2006-05-15 at 06:16 -0700, Jouni Malinen wrote:
> On Sun, May 14, 2006 at 11:29:38PM -0400, Dan Williams wrote:
> > On Mon, 2006-05-15 at 00:29 +0100, Daniel Drake wrote:
> > > When SIWESSID happens, softmac drops association/authentication with the
> > > current network and then starts a scan for the requested SSID. When
> > > found, softmac authenticates and associates to that network.
>
> I don't think there is requirement for doing a new scan here if recent
> scan results are available.
Yeah, thought that was understood. No reason to do another scan if you
just did one in the driver 5 seconds ago.
> > > When SIWAP happens, softmac drops association/authentication with the
> > > current network and then starts a scan for the requested BSSID. When
> > > found, softmac authenticates and associates to that network.
>
> Same here. Neither of these commands should drop IEEE 802.11
> authentication. I would say that neither should drop association either
> until a new association is available or it is clear that current
> configuration does not allow association to be created. First case would
I assume that by "or it is clear that the current configuration does not
allow association to be created" means that the driver cannot find an AP
matching both the ESSID and the BSSID the user set, right? If so, then
quite correct, the driver shouldn't disassociate until it's certain that
the current user-specified configuration (ie, any combination of ESSID
and BSSID set) does not apply to any known access points in the scan
list.
It's perfectly legal to send a new SIWAP event with a different BSSID if
the driver simply associates with a new access point in the same ESSID
too. In this case, the driver does _not_ need to send a blank SIWAP
disassoc event to userspace, since it's staying within the same ESSID.
I think at this point I'm still still assuming that APs with the same
ESSID are on the same network by default. Although that's not entirely
valid, especially in the realm of consumer gear (multiple 'linksys' APs
on the same channel even, each with different upstream connection), in
this case the user space application will have to know to lock the BSSID
of the card/driver to the one it wants. That's a user space issue, not
a driver issue. Driver's shouldn't be too smart about this stuff
without providing standard overrides.
> configuration does not allow association to be created. First case would
> just report a new association (no disassociation reported) and second
> case would report disassociation to user space.
If no association has been completed yet before the user sets SIWESSID
or SIWAP, then of course no disassociation event needs to get sent to
userspace because there's been no association from which to
disassociate.
I believe the following sequence is correct:
boot
user app issues SIWESSID 'foo'
driver finds associates/authenticates to 'foo'
(if not available, it Just Does Nothing)
(if available, sends SIWAP of '<whatever foo is>' to userspace)
user app issues SIWAP '12:34:56:78:91:23'
driver sends SIWAP of 00:00:00:00:00:00 (disassoc) to userspace
driver finds and associates with '12:34:56:78:91:23'
(if not available, it Just Does Nothing)
(if available, sends SIWAP of '12:34:56:78:91:23' to userspace)
Similarly, I believe the following is correct:
boot
user app issues SIWESSID 'foo'
driver searches for 'foo' but does not find it
(if driver does background scanning and finds 'foo', it may associate)
(if driver does not do background scanning, must wait until user
app requests a scan, and if 'foo' is in results, may associate)
user app issues SIWAP '12:34:56:78:91:23'
(no SIWAP driver disassoc event needed because no association exists)
driver finds and associates with '12:34:56:78:91:23'
(if not available, it Just Does Nothing)
(if available, sends SIWAP of '12:34:56:78:91:23' to userspace)
Dan
^ permalink raw reply
* Re: Hardware button support for Wireless cards
From: Dan Williams @ 2006-05-15 14:37 UTC (permalink / raw)
To: Mark Wallis; +Cc: netdev, David Zeuthen
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAAC4AAAAAAAAAWMRZS97Em0WybTChcxl4cAEALirLb4lrrkmZC6EvT+GpyAAAAABE9gAAEAAAALs6jNngvN9OooViTUM1CgIBAAAAAA==@serialmonkey.com>
On Mon, 2006-05-15 at 22:57 +1000, Mark Wallis wrote:
> Hi everyone,
>
> Currently, in our rt2x00 (using the devicescape stack) we are firing off an
> ACPI event so that the hardware button can be handled in userspace. This
> allows the user to basically do whatever they want when this button is
> pressed - including bringing down the wireless interface. The problem here
> is no distro's currently contain scripts to run from this event so for many
> users it just "doesn't work" without them manually having to write scripts
> to handle the ACPI even themselves.
>
> Some people are saying that instead of throwing and ACPI event we should be
> either use hotplug or internally just disable the radio and somehow inform
> the dscape stack that the radio has been disabled.
>
> What are peoples thoughts here, should we
>
> A. be handling this within our drivers and doing "what the user expects" and
> disabling the hardware radio, or
> B. should we be firing an ACPI event and getting the distro's to add scripts
> so when this event is fired they bring down all the wireless interfaces.
(had this issue in the back of my head for a while already...)
Isn't the rf-kill switch specific to the manufacturer lots of times? Is
the switch connected directly to the card, or is it incumbent on the
driver to notice the event and disable the card via software? We need
to handle this for Bluetooth too, in situations where there's both a
bluetooth and an 802.11 card in the box. Does the rf-kill apply to
both? Or just to one?
WRT to disabling the radio, I'm not sure it makes a difference either
way. Hitting a button generally means "do this _NOW_", so it makes
sense for the driver to disable the radio and then send out the event.
Apps need to be able to deal with these resources going out from
underneath them, and I'm not sure it makes sense to wait around for some
scripts to run that just might possibly at some future point disable it,
but you're never sure.
In the end, an ACPI event is probably fine. I must stress that we NEED
to have a common event structure for this, such that every driver and
card presents the same interface. I don't want to have to write stuff
for each of 3 or 4 different cards to notice the rf-kill stuff. Witness
all the extra binaries that each driver has already for this sort of
thing. What interface does the ipw[2|3]xxx driver and hardware present?
What common bits can be drawn out from both?
Ideally, here's what would happen: the driver/card/whatever generates
an ACPI event, which is noticed by HAL. HAL sets a property on the
_exact_ device which the event is for, and propagates the signal out
over dbus. Any interested application can listen for, and respond to,
the rf-kill signal. (or, the event can be handled by acpid and the
distro can run scripts for it. 01dsk001. whatever)
But this means a few things. We need:
1) common interface/signal for _all_ cards and drivers
2) Enough information to identify which specific pci/pcmcia/etc device
the event is for (or system-wide?)
Dan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox