On Mon, Jan 16, 2006 at 08:08:19AM +0100, Patrick McHardy wrote:
>
> I can't figure out how this can happen. If a local outgoing multicast
> packet would have been SNATed to a non-local IP, ip_route_input would
> have been used by ip_route_me_harder. In that case we should see
> ip_output instead
Herbert Xu wrote:
Andi Kleen <[EMAIL PROTECTED]> wrote:
Badness in ip_finish_output2 at /home/lsrc/quilt/linux/net/ipv4/ip_output.c:203
Call Trace: {ip_finish_output2+419}
{ip_fragment+1512}
{ip_finish_output2+0}
{ip_mc_output+521}
{ip_push_pending_frames+877}
{udp_push_pendin
Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Friday 13 January 2006 11:45, Patrick McHardy wrote:
>
>> I'm going to look into this. Andi, do you have any SNAT rules?
>
> Yes, a single one. I disabled it now and let's see what will happen.
BTW, here is a related discussion:
http://www.ussg.iu.edu/
On Sunday 15 January 2006 20:29, Carlos Martín wrote:
> On Sunday 15 January 2006 12:52, Denis Vlasenko wrote:
> > Hi,
> >
> > http://195.66.192.167/linux/acx_patches/acxsm-20060115.tar.bz2
>
> I've mirrored it at http://www.cmartin.tk/acx/ and will sync
In article <[EMAIL PROTECTED]> (at Mon, 16 Jan 2006 16:59:20 +1100), Shaun
Pereira <[EMAIL PROTECTED]> says:
> If I understand correctly from your comments (thanks for that, they are
> helpful)
> copy_to_user acts like a memcopy for an 'array' of bytes and should not
> be used to copy the timeval
John Que wrote:
Hello,
I wonder if can anybody can say what is the advantages/disadvantages
of the linux networking kernel layer comapred to STREAMS network layer
(of Solaris for examples).
From my experience up to day , I am used to it that the Linux took the best
of all worlds. I don't k
Hi Arnd
I have made the changes suggested, and attached it below. I think it
should be good now.
Just a couple of questions if I may.
If I understand correctly from your comments (thanks for that, they are
helpful)
copy_to_user acts like a memcopy for an 'array' of bytes and should not
be used
jamal wrote:
On Mon, 2006-16-01 at 05:56 +0100, Patrick McHardy wrote:
This is a dead horse since I ACKed the patch, but that patch
is _wrong_ without the user space fix.
What's wrong with this:
tc qdisc add dev dummy0 root handle 1: prio bands 5
for i in $(seq 1 5); do
tc filter add dev du
To fake ethernet or not?
There is a similar problem in the VLAN code - do you expect the rest of
the network stack to be able to interpret VLAN tagged frames? This was
the original state of the VLAN code - this caused problems since many
apps and modules did not understand
On Mon, 2006-16-01 at 05:56 +0100, Patrick McHardy wrote:
> jamal wrote:
> > Indeed this is where we disagree.
> > It is also not necessary to assume that all bands are fifo ;->
>
> I don't see how this is related.
>
When you initialize a band that is not specified in the priomap, you
make the
On Mon, 2006-16-01 at 05:46 +0100, Patrick McHardy wrote:
> So as you can see it is perfectly fine to classify to any band without
> even using priomap.
I dont think there is any arguement about that (eventually you have to
fall to priomap though). I could also specify with filters or eventually
On Mon, 2006-16-01 at 00:05 +0100, Willem de Bruijn wrote:
> > Well, if you are doing research you need to know whats out there so
> > you can a) learn from it b) avoid reinventing the wheel
>
> That speaks for itself. I'm not completely ignorant and have read most that
> has been published at de
Dmitry Torokhov wrote:
Hi,
I am getting the following warning with the latest pull from Linus:
CC [M] net/ipv4/netfilter/ipt_policy.o
net/ipv4/netfilter/ipt_policy.c:156: warning: initialization from incompatible
pointer type
It looks like arguments of match() and checkentry() methods have
jamal wrote:
On Mon, 2006-16-01 at 05:35 +0100, Patrick McHardy wrote:
2) If i specify 4 queues, without this, i get a priomap which says how
to map to 3 queues. I really should specify mapping to 4 queues.
This is where we disagree. Prio includes a mechanism for classification
without prioma
jamal wrote:
On Mon, 2006-16-01 at 05:24 +0100, Patrick McHardy wrote:
If I say I want n bands, I don't want half of them initialized and
the other half not. That's just confusing.
Thats where we disagree - The kernel should not be making such
decisions.
Corrolary: If i wanted to have the b
On Mon, 2006-16-01 at 05:35 +0100, Patrick McHardy wrote:
> jamal wrote:
> > On Mon, 2006-16-01 at 01:23 +0100, Patrick McHardy wrote:
> >
> >
> > 1) If i specify no bands i get 3 bands and a priomap which says how you
> > map packets to 3 queues.
> >
> > 2) If i specify 4 queues, without this,
jamal wrote:
On Mon, 2006-16-01 at 01:23 +0100, Patrick McHardy wrote:
jamal wrote:
the prio qdisc assumes a default priomap which is suited for
3 bands when you configure > 3 bands but not specify the
priomap. This forces the user to specify the priomap when bands >3
This doesn't fix an
On Mon, 2006-16-01 at 05:24 +0100, Patrick McHardy wrote:
> jamal wrote:
> > On Mon, 2006-16-01 at 01:21 +0100, Patrick McHardy wrote:
> >
> >>
> >>Well, part of the mechanism is manuall classification without
> >>the priomap using filters or skb->priority. So I disagree with
> >>this statement.
>
On Mon, 2006-16-01 at 01:23 +0100, Patrick McHardy wrote:
> jamal wrote:
> >>the prio qdisc assumes a default priomap which is suited for
> >>3 bands when you configure > 3 bands but not specify the
> >>priomap. This forces the user to specify the priomap when bands >3
> >>
>
> This doesn't fix a
jamal wrote:
On Mon, 2006-16-01 at 01:21 +0100, Patrick McHardy wrote:
Well, part of the mechanism is manuall classification without
the priomap using filters or skb->priority. So I disagree with
this statement.
So lets agree to disagree then.
If i create a policy which specifies what pack
On Mon, 2006-16-01 at 01:21 +0100, Patrick McHardy wrote:
> jamal wrote:
> > The policy comes from user space. The kernel is supposed to be dumb,
> > it just implements the mechanisms. If you tell the kernel
> > "here are 4 queues but i only want you to send packets to the
> > first 3" and then so
Hi All,
This is my first post to this mailing list.
I am writing a new network protocol in the form of a module. I
finished writing it in kernel 2.6.9 on Fedora Core 3 distribution. It
is working great.
However my implementation is not working on newer kernels like 2.6.12
etc. On doing some rese
This replaces some tests with is_zero_ether_addr(), memcmp(one, two, 6) with
compare_ether_addr(one, two), and 6 with ETH_ALEN where appropriate.
Signed-off-by: Kris Katterjohn <[EMAIL PROTECTED]>
Thanks!
--- x/net/core/pktgen.c 2006-01-15 21:29:21.0 -0600
+++ y/net/core/pktgen.c 2006-01
This should have been forwaded to netdev I think (forwading there)
El Sun, 15 Jan 2006 23:41:48 +0300,
Serge Belyshev <[EMAIL PROTECTED]> escribió:
Diego Calleja <[EMAIL PROTECTED]> writes:
> > El Sun, 15 Jan 2006 21:48:38 +0200,
> > "Vitaly V. Bursov" <[EMAIL PROTECTED]> escribió:
> ...
> >> PP
From: Stefan Rompf <[EMAIL PROTECTED]>
Date: Sun, 15 Jan 2006 13:52:32 +0100
> Davem? (And frankly, if the RFC2863 and user/kernel operstate interaction
> stuff is so unintersting for you that you don't plan looking at it anyway,
> you should have told earlier. That could have saved us weeks of
Hello james,
Thank you for your review.
I'll check your mails and fix my patch.
James Morris wrote:
On Fri, 13 Jan 2006, Kazunori Miyazawa wrote:
[it's better to send patches inline, so they can be reviewed inline with
proper quoting etc.]
I'm sorry and I agree. But my MUA changes a signl
Hello Herbert,
Thank you for your comments.
Herbert Xu wrote:
On Fri, Jan 13, 2006 at 08:17:49PM +0900, Kazunori Miyazawa wrote:
Anyway this is for 2.6.15. please review and apply it.
Signed-off-by: Kazunori MIYAZAWA <[EMAIL PROTECTED]>
Thanks for the patch Miyazawa-san!
Just a quick tho
David S. Miller wrote:
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Fri, 13 Jan 2006 00:01:34 +0100
It seems to be a common mistake to use jiffies as clocksource, which
gives very bad results in most cases. This patch changes the default
to gettimeofday.
Applied, this is definitely an im
jamal wrote:
the prio qdisc assumes a default priomap which is suited for
3 bands when you configure > 3 bands but not specify the
priomap. This forces the user to specify the priomap when bands >3
This doesn't fix anything, it just makes it harder to use if you
don't care about priomap but
jamal wrote:
On Fri, 2006-13-01 at 18:16 +0100, Thomas Graf wrote:
* Patrick McHardy <[EMAIL PROTECTED]> 2006-01-12 06:25
In the last case in prio_classify (band < q->bands) the band
is returned directly. This could come from attached filters
or from skb->priority. Its still not a fix since
On Sun, Jan 15, 2006 at 04:19:58PM +0300, Vitaly Bordug wrote:
> On Thu, 5 Jan 2006 19:18:26 +0100
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > This patch removes the obsolete drivers/net/eepro100.c driver.
> >
> > Is there any known problem in e100 still preventing us from removing
> > this d
On Sun, Jan 15, 2006 at 11:39:41AM -0800, Sam Leffler wrote:
> The big stumbling block I found to going with virtual devices is that it
> affects user apps. I looked at doing things like auto-create a station
> device for backwards compatibility but decided against it. If you
> really want thi
On Sun, 15 Jan 2006 16:19:58 +0300
Vitaly Bordug <[EMAIL PROTECTED]> wrote:
> On Thu, 5 Jan 2006 19:18:26 +0100
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > This patch removes the obsolete drivers/net/eepro100.c driver.
> >
> > Is there any known problem in e100 still preventing us from removi
> Well, if you are doing research you need to know whats out there so
> you can a) learn from it b) avoid reinventing the wheel
That speaks for itself. I'm not completely ignorant and have read most that
has been published at decent venues. Thing is, I don't find such publications
about innovati
Ok, it is really attached now ;->
cheers,
jamal
On Sun, 2006-15-01 at 16:37 -0500, jamal wrote:
> Stephen,
>
> This is against the latest iproute2
>
> cheers,
> jamal
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [EMAIL PROTECTED]
> Mor
On Sun, 2006-15-01 at 21:21 +0100, Willem de Bruijn wrote:
> > Your lack of knowledge about netfilter shows very clearly here.
>
> Again, I never stated that netfilter is a purely functional framework.
> Although my lack of netfilter indeed is unfortunate, it is of no direct
> concern.
>
> > H
Stephen,
This is against the latest iproute2
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 15 Jan 2006, ext Stuffed Crust wrote:
> * Knowing the hardware frequency capabilities, the 802.11 stack applies
>802.11d and regdomain rules to the available frequency set, and
Regarding 802.11d and regulatory domains, the stack should also be able to
stick to one regulatory domain if
On Fri, 2006-13-01 at 18:16 +0100, Thomas Graf wrote:
> * Patrick McHardy <[EMAIL PROTECTED]> 2006-01-12 06:25
> >
> > In the last case in prio_classify (band < q->bands) the band
> > is returned directly. This could come from attached filters
> > or from skb->priority. Its still not a fix since
> Linux TCP/IP doesn't work like this.
I never said it did, I said that *functional frameworks* worked like this. For
the most part I believe Linux TCP/IP does work like this, though. I'll skip
routing when making this point.
Although Linux has indirect function calls to choose between a TCP a
On Sun, 2006-01-15 at 12:08 -0800, Sam Leffler wrote:
> To do what you describe I would create a monitor mode device, switch
> channel, then destroy it. All the time you leave the station device
> unchanged, though you probably need to disable it. This may not be
> possible with all devices--
Stefan Rompf wrote:
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()
ini
Stuffed Crust wrote:
On Sat, Jan 14, 2006 at 05:07:01PM -0500, Jeff Garzik wrote:
This can be accomplished by passing a static table to the
register_wiphy_device() call (or perhaps via a struct wiphy_dev
parameter) or through a more explicit, dynamic interface like:
wiphy_register_supported_
Stefan Rompf wrote:
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 b
Stefan Rompf wrote:
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
On Sunday 15 January 2006 12:50, Willem de Bruijn wrote:
> int tcp(char * pkt, int plen){
> if (!ip(pkt, plen))
> return -1;
> //[... process tcp stuff ..]
> return 0;
> }
Linux TCP/IP doesn't work like this.
> Why do people keep developing stream-like architectur
On Sunday 15 January 2006 13:52, Stefan Rompf wrote:
> 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.
Merging of new feature
On Sunday 15 January 2006 12:52, Denis Vlasenko wrote:
> Hi,
>
> http://195.66.192.167/linux/acx_patches/acxsm-20060115.tar.bz2
I've mirrored it at http://www.cmartin.tk/acx/ and will sync as with the
'normal' tarballs.
>
> README says:
> ==
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 acti
On Sat, Jan 14, 2006 at 06:41:56PM -0500, Dan Williams wrote:
> One other thing: capability. It's not enough to be able to configure
> the device, user-space tools also have to know what the device is
> capable of before they try touching it. Ie, which ciphers, protocols,
> channels, etc. Simila
Stefan Rompf wrote:
> Even though it is a bit more work on kernel side, we should allow changing
> the
> mode of virtual devices. Let's face it, even though we find multi-BSS
> capabilities very interesting, 999 of 1000 users won't care due to the two
> facts that IPW firmware IMHO doesn't allow i
On Sat, Jan 14, 2006 at 05:09:23PM -0500, Jeff Garzik wrote:
> A big open issue: should you fake ethernet, or represent 802.11
> natively throughout the rest of the net stack?
>
> The former causes various and sundry hacks, and the latter requires that
> you touch a bunch of non-802.11 code to
On Sat, Jan 14, 2006 at 05:07:01PM -0500, Jeff Garzik wrote:
> >This can be accomplished by passing a static table to the
> >register_wiphy_device() call (or perhaps via a struct wiphy_dev
> >parameter) or through a more explicit, dynamic interface like:
> >
> > wiphy_register_supported_frequenc
On Thu, 5 Jan 2006 19:18:26 +0100
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> This patch removes the obsolete drivers/net/eepro100.c driver.
>
> Is there any known problem in e100 still preventing us from removing
> this driver (it seems noone was able anymore to verify the ARM problem)?
>
I think
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 serialize
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 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 th
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 thinkin
Ulrich Kunitz wrote:
How can I find out which RF chip I have in my device? This is an area where I
lack knowledge - why are there so many different chips? Is it one per region?
Or maybe ZyDAS sell the ZD1211 but it has to be combined by other vendors with
a RF chip for it to become useful?
It i
On Sun, Jan 15, 2006 at 12:50:38PM +0100, Willem de Bruijn ([EMAIL PROTECTED])
wrote:
> >I wonder if can anybody can say what is the advantages/disadvantages
> > of the linux networking kernel layer comapred to STREAMS network layer
> > (of Solaris for examples).
>
> hi John,
>
> I'll take a
On Sunday 15 January 2006 12:06, Denis Vlasenko wrote:
> On Sunday 15 January 2006 01:43, Carlos Martín wrote:
> > Attached patch does a s/netdevice_t/struct net_device/g on all the files
that
> > required it. It's against 20060114
>
> Too late :)
> acx-200601
Hi,
http://195.66.192.167/linux/acx_patches/acxsm-20060115.tar.bz2
README says:
==
*** Not run tested. Almost certainly won't work. Lots of things are TODO. ***
This tarball contains a port of acx driver to ieee80211softmac
stack. Broadcom 43xx driver was used as an example
>I wonder if can anybody can say what is the advantages/disadvantages
> of the linux networking kernel layer comapred to STREAMS network layer
> (of Solaris for examples).
hi John,
I'll take a stab at this question, since I'm working on a stream-like
framework in/op top of Linux anyway. Firs
On 1/14/06, David S. Miller <[EMAIL PROTECTED]> wrote:
> From: Jeff Garzik <[EMAIL PROTECTED]>
> Date: Sat, 14 Jan 2006 17:09:23 -0500
>
> > A big open issue: should you fake ethernet, or represent 802.11
> > natively throughout the rest of the net stack?
> >
> > The former causes various and sund
that
> required it. It's against 20060114
Too late :)
acx-20060115 already has no netdevice_t.
--
vda
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, 14 Jan 2006, Pete Zaitcev wrote:
> On Sat, 14 Jan 2006 15:13:39 +0100 (CET), Ulrich Kunitz <[EMAIL PROTECTED]>
> wrote:
>
> > [...] Register accesses in USB devices should be
> > able to sleep. However the 80211 stacks I've seen so far have a
> > fixed set of capabilities and do also ass
Hello,
I wonder if can anybody can say what is the advantages/disadvantages
of the linux networking kernel layer comapred to STREAMS network layer
(of Solaris for examples).
>From my experience up to day , I am used to it that the Linux took the best
of all worlds. I don't know very much about
John W. Linville wrote:
> Configuration seems to be coalescing around netlink. Among other
> things, this technology provides for muliticast requests and
> asynchronous event notification.
On the other hand, the tree structure of sysfs can handle the
resource exclusivity and sharing naturaly.
A
68 matches
Mail list logo
