On Fri, 02.09.05 10:34, Jean Tourrilhes ([EMAIL PROTECTED]) wrote:
Lennart Poettering wrote :
It is simply not true that all current
network drivers set IFF_RUNNING correctly. ifplugd does the best it
can to detect the carrier, but is still incompatible out of the box
with some
This how I think ifplugd should work, it should not poll it
should just use libnetlink and read for the next message.
The RUNNING flag works for wireless and non-wireless devices.
If there is a driver it doesn't work on than that is a bug in
the device driver and should be fixed ASAP, not worked
On Wed, 2005-09-07 at 11:15 -0700, Stephen Hemminger wrote:
This how I think ifplugd should work, it should not poll it
should just use libnetlink and read for the next message.
Incidentally, this is what netplugd already does, for people using
Fedora, Red Hat or Mandriva systems.
b
-
On Thu, 01 Sep 2005 19:16:05 +0100, Pedro Ramalhais wrote:
Of
course you may sometimes want to force reassociation manually - and
there should be some call available for this. (Maybe setting BSSID while
the card is running should force reassociation?)
That's the kind of hackish
James Ketrenos wrote:
Jeff Garzik wrote:
Jiri Benc wrote:
Our patches against latest ieee80211 branch can be found at
http://kernel.org/pub/linux/kernel/people/jbenc/
Thanks for your patience.
To answer Pavel's question from the other email:
I was hoping that Intel would resend their
Jeff Garzik wrote:
It seems like some of this overlaps changes already in upstream.
What's the best way to start this process? I would prefer to receive
patches rather than 'git pull' at the present time.
Understood.
Should I Lindent the files first?
Probably cleanest that way. I've
Hi,
Pedro Ramalhais wrote:
Yes, i might want to bring the card UP so that it can scan, but don't
want to associate. Or bring the card UP and configure the card in
Monitor mode. Or bring the card UP and configure the card in Master
mode. Maybe ad-hoc too, not sure.
Yes, that sounds useful.
Hi!
I noticed that wireless patches are now in the mainline. That is good,
patches are getting smaller, but it is going to make future user
interface changes harder; and thats very bad.
There are good reasons to have wireless interfaces as wlanX, with
tcpdump showing wireless packetes, etc; but
Hi!
I noticed that wireless patches are now in the mainline. That is good,
patches are getting smaller, but it is going to make future user
interface changes harder; and thats very bad.
Hi,
I'm also happy that these are in mainline now.
There are good reasons to have wireless interfaces
Hi!
There are good reasons to have wireless interfaces as wlanX, with
tcpdump showing wireless packetes, etc; but current patches name it
ethX, and you get plain ethernet packets on tcpdump. Are we going to
keep showing wireless interfaces as ethernet ones forever, or do we
plan to
On Mon, 2005-09-05 at 15:37 +0200, Pavel Machek wrote:
I noticed that wireless patches are now in the mainline. That is good,
patches are getting smaller, but it is going to make future user
interface changes harder; and thats very bad.
Only a very early version of the ieee80211 header was
Pavel Machek wrote:
Hi!
I noticed that wireless patches are now in the mainline. That is good,
patches are getting smaller, but it is going to make future user
interface changes harder; and thats very bad.
There are good reasons to have wireless interfaces as wlanX, with
tcpdump showing
On Fri, 02.09.05 11:40, Jiri Benc ([EMAIL PROTECTED]) wrote:
On Thu, 1 Sep 2005 10:04:22 -0700, Stephen Hemminger wrote:
By the way, last time I looked at the ifplugd source it was using
outdated and incorrect ways to detect carrier. It should just
open a netlink socket and wait for
Lennart Poettering wrote :
It is simply not true that all current
network drivers set IFF_RUNNING correctly. ifplugd does the best it
can to detect the carrier, but is still incompatible out of the box
with some drivers. To write carrier detection code that works reliably
on most drivers
On Fri, Sep 02, 2005 at 10:34:03AM -0700, Jean Tourrilhes wrote:
Another part of the problem is that the notion of carrier
detection only apply to some technology (mostly Ethernet). With
Wireless, there is no notion of carrier. You can somewhat *emulate* it
using the association, but
Jiri Benc wrote:
On Sat, 27 Aug 2005 11:21:37 -0500, James Ketrenos wrote:
The order required of user space is:
kernel hotplug hotplug script
--------
1. module load
2. netdev device registered
On Wed, 31 Aug 2005 10:52:54 -0700, Jean Tourrilhes wrote:
I personally consider that a bug in ifplugd. For example, the
hp100 Ethernet driver will start media sensing only in the open()
call, which means that ifplugd won't work on the hp100 driver.
It would be trivial to fix
On Wed, 31 Aug 2005 17:06:19 -0400, Peter Jones wrote:
Not necessarily started by hotplug, but started by something like
ifplugd or NetworkManager. And that class of programs is already
responsible for things like choosing what AP to associate, so it's an
extra degree of control for them, but
On Wed, 31 Aug 2005 22:40:00 +0200, Pavel Machek wrote:
AFAICS, with your patches ifconfig shows counts of wifi packets. How
do I get ethernet packet counts? Will tcpdump wlan0 work on ethernet
or wifi level?
Ethernet corresponds to 802.3, wifi is 802.11. These are different
standards
On Thu, Sep 01, 2005 at 02:13:21PM +0200, Jiri Benc wrote:
On Wed, 31 Aug 2005 10:52:54 -0700, Jean Tourrilhes wrote:
I personally consider that a bug in ifplugd. For example, the
hp100 Ethernet driver will start media sensing only in the open()
call, which means that ifplugd won't work
By the way, last time I looked at the ifplugd source it was using
outdated and incorrect ways to detect carrier. It should just
open a netlink socket and wait for carrier event. Instead it seems
to muck around looking at MII, wireless API and other ways
that only work on some devices. In current
On Thu, Sep 01, 2005 at 07:36:34PM +0100, Pedro Ramalhais wrote:
Oops, my brain had censored that part of the iwconfig manual.
Yeah, it come at the end of a long page ;-)
Reading that, and since i imagine that few people use it,
Not explicitely, but it's used internally.
On Thu, Sep 01, 2005 at 05:26:07PM +0200, Jiri Benc wrote:
The current implementation of ieee80211 as is in ieee80211 branch
contains ugly hack so it works with ethernet frames externally (which
are internally converted to and from 802.11 frames). Because 802.3 and
802.11 have the same format
On Wed, 31 Aug 2005 11:57:15 -0400, Peter Jones wrote:
I don't think that's really right either. For one thing, things like
DHCP's timeout start counting at about the same time as ifconfig up,
and association can take some time.
You're right, thanks for pointing this out.
But why don't we
Hi!
What other changes are required in userspace after your patches are
applied?
AFAIK none.
Really?
AFAICS, with your patches ifconfig shows counts of wifi packets. How
do I get ethernet packet counts? Will tcpdump wlan0 work on ethernet
or wifi level?
I agree. Don't know who
On Wed, 2005-08-31 at 19:08 +0200, Jiri Benc wrote:
But is it really needed? Imagine the situation when computer is started
with unplugged ethernet cable which is plugged in later. I know, this is
rare, but - shouldn't be the right approach that DHCP is started by
hotplug when the carrier is
On Wed, 2005-08-31 at 10:52 -0700, Jean Tourrilhes wrote:
Peter Jones [EMAIL PROTECTED] wrote :
I don't think that's really right either. For one thing, things like
DHCP's timeout start counting at about the same time as ifconfig up,
and association can take some time.
That's
On Wed, Aug 31, 2005 at 05:43:32PM -0400, Peter Jones wrote:
On Wed, 2005-08-31 at 10:52 -0700, Jean Tourrilhes wrote:
Peter Jones [EMAIL PROTECTED] wrote :
I don't think that's really right either. For one thing, things like
DHCP's timeout start counting at about the same time as
Hi,
+/* wrappers of WE functions that don't check for errors */
+static inline int _iwe_stream_add_point(struct translate_scan *data,
You may wonder why the original API of iwe_stream_add_point(()
is the way it is rather than the way you expect. I'll explain :
working closely with
Hi!
Anyway, our rebasing from ieee80211 up to the latest development tip is
done across 29 commits, with a series size of 225k.
Are there any plans to fix compiled into kernel case? It works okay
when modular, but when compiled into kernel, it fails to load
firmware
Hi!
Looks nice.. why is ieee-seq_number += 0x10; increased by 0x10?
Sequence number is stored in bits 4 to 15 of the Sequence Control field
in 802.11 header. Lower 4 bits are used for fragment number.
Comment would be nice.
separate-from-ethernet.patch
Okay, here it starts to be
Pavel Machek wrote:
Hi!
Anyway, our rebasing from ieee80211 up to the latest development tip is
done across 29 commits, with a series size of 225k.
Are there any plans to fix compiled into kernel case? It works okay
when modular, but when compiled into kernel, it fails to load
firmware
I
Hi!
Anyway, our rebasing from ieee80211 up to the latest development tip is
done across 29 commits, with a series size of 225k.
Are there any plans to fix compiled into kernel case? It works okay
when modular, but when compiled into kernel, it fails to load
firmware
I assume you
Hi,
Am Freitag 26 August 2005 02:49 schrieb Michael Wu:
I hope to submit the adm8211 driver for review soon, but there's a bunch of
code in the driver which probably belong in the ieee80211 code:
[...]
- AVS capture header in monitor mode
there has been a discussion about AVS or radiotap
On Thu, 25 Aug 2005 20:30:26 -0400, Jeff Garzik wrote:
add-seq-number.patch
Adds sequence numbers to transmitted frames.
any security implications here, as with TCP sequence numbers?
802.11 sequence numbers are intended solely for duplicate frame
filtering (chapter 9.2.9 in IEEE 802.11
On Thu, 25 Aug 2005 20:49:52 -0400, Michael Wu wrote:
I hope to submit the adm8211 driver for review soon, but there's a bunch of
code in the driver which probably belong in the ieee80211 code:
- Duplicate frame removal
- Definitions for all management payloads
- SIOCSIWENCODEEXT and
On Fri, 26 Aug 2005 11:04:15 +0200, Stefan Rompf wrote:
there has been a discussion about AVS or radiotap header on the ipw list
Does it have an archive on web? If so, could you post an address of that
thread?
Thanks,
--
Jiri Benc
SUSE Labs
-
To unsubscribe from this list: send the line
On Fri, Aug 26, 2005 at 02:11:07PM +0200, Jiri Benc wrote:
On Fri, 26 Aug 2005 11:04:15 +0200, Stefan Rompf wrote:
there has been a discussion about AVS or radiotap header on the ipw list
Does it have an archive on web? If so, could you post an address of that
thread?
It's archived off the
On Friday 26 August 2005 05:04, Stefan Rompf wrote:
- AVS capture header in monitor mode
there has been a discussion about AVS or radiotap header on the ipw list
that resulted in the inclusion of radiotap definitions in James' latest
patches for ieee80211. Radiotap requires a libpcap
On Fri, 26 Aug 2005 11:07:07 -0400, Michael Wu wrote:
http://aluminum.sourmilk.net/adm8211/index.php?path=netdev/
Looks good for the first view. Unfortunately I won't have enough time to
look closely until next week.
- adm8211 supports shared key authentication, rtl8180-sa2400 only supports
On Fri, 26 Aug 2005 09:10:45 -0400, Mike Kershaw wrote:
It's archived off the sourceforge page (http://ipw2200.sourceforge.net
or http://sourceforge.net/mailarchive/forum.php?forum_id=38938)
I've found two threads regarding this; if anybody else is interested and
doesn't want to spend ages
On Friday 26 August 2005 12:13, Jiri Benc wrote:
You mentioned problem with hooks in scanning/association/etc. Probably
everybody involved in this discussion knows it but I think it is worth
saying it: This is one of the most important things in a new ieee80211
layer. Unfortunately, it seems
Our patches against latest ieee80211 branch can be found at
http://kernel.org/pub/linux/kernel/people/jbenc/
Patches have to be applied in this order (also specified in 'series'
file):
debug-macros-cleanup.patch
ipw2100-cleanup-prefixes.patch
ipw2100-cleanup-debug-prints.patch
Hi!
Our patches against latest ieee80211 branch can be found at
http://kernel.org/pub/linux/kernel/people/jbenc/
Patches have to be applied in this order (also specified in 'series'
file):
debug-macros-cleanup.patch
ipw2100-cleanup-prefixes.patch
ipw2100-cleanup-debug-prints.patch
Jiri Benc wrote:
Our patches against latest ieee80211 branch can be found at
http://kernel.org/pub/linux/kernel/people/jbenc/
Thanks for your patience.
To answer Pavel's question from the other email:
I was hoping that Intel would resend their patches, rediffed to the
latest ieee80211
On Thursday 25 August 2005 13:31, Jiri Benc wrote:
Our patches against latest ieee80211 branch can be found at
http://kernel.org/pub/linux/kernel/people/jbenc/
I hope to submit the adm8211 driver for review soon, but there's a bunch of
code in the driver which probably belong in the ieee80211
Hi,
I don't want to disturb the good work you guys are doing, but
I had a few comments on your patch regarding the WE APIs.
In particular :
--
+struct translate_scan {
+ char *start;
+ char *stop;
+ int count;
Jeff Garzik wrote:
Jiri Benc wrote:
Our patches against latest ieee80211 branch can be found at
http://kernel.org/pub/linux/kernel/people/jbenc/
Thanks for your patience.
To answer Pavel's question from the other email:
I was hoping that Intel would resend their patches, rediffed to the
48 matches
Mail list logo
