* Re: Weak host model vs .interface down
From: Joakim Tjernlund @ 2010-06-11 20:46 UTC (permalink / raw)
To: Mitchell Erblich; +Cc: netdev, Rick Jones
In-Reply-To: <2297DADB-883E-4156-998A-854BE6CAC079@earthlink.net>
Mitchell Erblich <erblichs@earthlink.net> wrote on 2010/06/11 21:50:14:
>
>
> On Jun 11, 2010, at 10:06 AM, Joakim Tjernlund wrote:
>
> > Rick Jones <rick.jones2@hp.com> wrote on 2010/06/11 18:32:20:
> >> Joakim Tjernlund wrote:
> >>> Linux uses the weak host model which makes the IP addresses part of the system
> >>> rather than the interface. However consider this:
> >>>
> >>> System A, eth0 connected to the network
> >>> # > ifconfig eth0 192.168.1.16
> >>> # > ifconfig eth1 192.168.1.17 down
> >>>
> >>> System B
> >>> # > ping 192.168.1.17
> >>> PING 192.168.1.17 (192.168.1.17) 56(84) bytes of data.
> >>> 64 bytes from 192.168.1.17: icmp_seq=1 ttl=64 time=0.618 ms
> >>>
> >>> Isn't it a bit much to respond on 192.168.1.17 when its interface is down?
> >>
> >> As you said at the beginning, the weak end system model presumes the IP address
> >> is part of the system. Seems to me that means unless one removes the IP address
> >> from the system it is reasonable for the system to continue to respond to that
> >> IP address. Regardless of what happens to any individual interface.
> >
> > The weak model doesn't go into such detail, it is assumption/impl. detail
> > to assume that the ip address still is part of the system even when the interface
> > is down. One could just as well define interface down as temporarly removing
> > the IP address from the system too. This makes make much more sense to me and
> > if you always want the system to answer on a IP adress you make it an IP alias.
> >
> > Since the current behaviour is a problem to me and routers in general, can
> > we change this? What is the current usage model which needs it to stay as is?
> >
> >>
> >> Now, I wouldn't expect it to continue to respond to 192.168.1.17 through eth1,
> >> but if eth0 is indeed connected to the same broadcast domain, given the
> >> following of the weak end-system model, continuing to respond seems consistent
> >> with enthusiasticaly following the weak end-system model.
> >
> > Dosnt matter if it is in the same broadcast domain, you can use a bridge
> > interface or dummy interface too. It will still respond to 192.168.1.17
> > I can't find a way disable this behaviour, can you?
> >
> > --
>
> Guys
>
> Isn't this the diff between models of a host/end system and a
> router/intermediate system?
Not sure what you mean here, but there is no such assumtion in
the models.
>
> Can you verify that xmit capability on the intf is disabled with the
> down arg?
umm, isn't that true by definition? if an I/F is put into down state, it
cannot xmit nor receive.
>
> IMO, One possible behaviour is to allow the receipt of a magic
> packet to bring up a down system for the "energy star protocol".
isn't that something totally different? I cannot se how that relates
to the matter at hand.
Jocke
^ permalink raw reply
* Re: [PATCH 1/4][RFC] Introduction to sk_buff state checking
From: Randy Dunlap @ 2010-06-11 20:46 UTC (permalink / raw)
To: David Miller; +Cc: dvomlehn, to, linux-kernel, akpm, netdev
In-Reply-To: <20100611.133811.52184181.davem@davemloft.net>
On Fri, 11 Jun 2010 13:38:11 -0700 (PDT) David Miller wrote:
>
> This is the second time you've submitted this patch set,
> it is also the second time that:
>
> 1) Your email client has emitted these strange
> "linux-kernel@vger.kernel.org"@cisco.com
> addresses.
>
> I saw that you were specifically notified about this
> problem during the previous submission.
>
> What did you do to try and correct it?
>
> 2) You are not CC:'ing the networking developer mailing
> list "netdev@vger.kernel.org" Many networking developers
> do not read linux-kernel, so by not CC:'ing that list
> you are not reaching the folks most capable of reviewing
> your patches.
>
> Please fix this up.
> --
Ack. Also this one:
----- The following addresses had permanent fatal errors -----
<to@dvomlehn-lnx2.corp.sa.net>
(reason: 550 Host unknown)
----- Transcript of session follows -----
550 5.1.2 <to@dvomlehn-lnx2.corp.sa.net>... Host unknown (Name server: dvomlehn-lnx2.corp.sa.net: host not found)
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH 1/4][RFC] Introduction to sk_buff state checking
From: David Miller @ 2010-06-11 20:38 UTC (permalink / raw)
To: dvomlehn; +Cc: to, linux-kernel, akpm, netdev
In-Reply-To: <20100611203350.GA28383@dvomlehn-lnx2.corp.sa.net>
This is the second time you've submitted this patch set,
it is also the second time that:
1) Your email client has emitted these strange
"linux-kernel@vger.kernel.org"@cisco.com
addresses.
I saw that you were specifically notified about this
problem during the previous submission.
What did you do to try and correct it?
2) You are not CC:'ing the networking developer mailing
list "netdev@vger.kernel.org" Many networking developers
do not read linux-kernel, so by not CC:'ing that list
you are not reaching the folks most capable of reviewing
your patches.
Please fix this up.
^ permalink raw reply
* Re: [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: Johannes Berg @ 2010-06-11 20:29 UTC (permalink / raw)
To: Dmytro Milinevskyy
Cc: Valo, GeunSik Lim, Kroah-Hartman, Jiri Slaby, Jiri Kosina,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
ath5k-devel-xDcbHBWguxEUs3QNXV6qNA, John W. Linville, Keng-Yu Lin,
Greg-juf53994utBLZpfksSYvnA, netdev-u79uwXL29TY76Z2rM5mHXA,
Kalle-juf53994utBLZpfksSYvnA, Shahar Or,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Luca Verdesca
In-Reply-To: <AANLkTim90VBfWjp2YPYeYN6ImjIyZzcJ_XnpT5cdgCt4-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, 2010-06-11 at 23:26 +0300, Dmytro Milinevskyy wrote:
> Generic LED class is not disabled so it's possible to control leds in sysfs.
But if you turn off ATH5K_LEDS??
johannes
^ permalink raw reply
* Re: [PATCH 1/7] ethoc: calculate number of buffers in ethoc_probe
From: David Miller @ 2010-06-11 20:29 UTC (permalink / raw)
To: jonas; +Cc: netdev
In-Reply-To: <1276260460-14531-1-git-send-email-jonas@southpole.se>
I've applied all 7 patches to net-next-2.6, thanks Jonas.
^ permalink raw reply
* Re: [ath5k-devel] [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: Dmytro Milinevskyy @ 2010-06-11 20:26 UTC (permalink / raw)
To: Johannes Berg
Cc: Bob Copeland, ath5k-devel-xDcbHBWguxEUs3QNXV6qNA, Kalle Valo,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, GeunSik Lim, Jiri Slaby,
Greg Kroah-Hartman, John W. Linville, Keng-Yu Lin,
netdev-u79uwXL29TY76Z2rM5mHXA, Jiri Kosina, Shahar Or,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Luca Verdesca
In-Reply-To: <1276286993.3918.0.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
Generic LED class is not disabled so it's possible to control leds in sysfs.
-- Dima
On Fri, Jun 11, 2010 at 11:09 PM, Johannes Berg
<johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> On Wed, 2010-06-09 at 17:43 +0300, Dmytro Milinevskyy wrote:
>> Hi, Bob.
>>
>> For instance I don't use 802.11 leds layer and trigger leds from
>> userspace according to my purposes.
>
> Without the LED stuff in sysfs, how do you do that?
>
> johannes
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: Johannes Berg @ 2010-06-11 20:09 UTC (permalink / raw)
To: Dmytro Milinevskyy
Cc: Valo, GeunSik Lim, Kroah-Hartman, Jiri Slaby, Jiri Kosina,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
ath5k-devel-xDcbHBWguxEUs3QNXV6qNA, John W. Linville, Keng-Yu Lin,
Greg-juf53994utBLZpfksSYvnA, netdev-u79uwXL29TY76Z2rM5mHXA,
Kalle-juf53994utBLZpfksSYvnA, Shahar Or,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Luca Verdesca
In-Reply-To: <AANLkTimXqdkQxv_Y1JaleTTWNsDIQHQaPn8HR7efOupb-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, 2010-06-09 at 17:43 +0300, Dmytro Milinevskyy wrote:
> Hi, Bob.
>
> For instance I don't use 802.11 leds layer and trigger leds from
> userspace according to my purposes.
Without the LED stuff in sysfs, how do you do that?
johannes
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2010-06-11 20:05 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) As alluded to in the previous networking pull, for correct
operation r8169 needs a post-mdio-read delay just as it needs one
for post-mdio-write. From Timo Teräs.
2) 8139 driver's NAPI completion is racy, the sequence for completing
a NAPI poll should be:
napi_complete()
reenable_interrupts(dev);
But these driver bits had the ordering reversed. If the race is
triggered, NAPI can be left disabled forever and therefore no
more RX packets will be received until a down/up of the device.
3) When a multiqueue device is plumbed into a non-multiqueue-capable
SW layer (bonding, bridging, etc.) we print a warning about the RX
queue selection being "out of range", which is not very useful
since we are aware of this issue. All it does is spam the log and
make life difficult for the user. Only print the message in cases
where there is real trouble.
From Tim Gardner.
4) LXT973 phy support from Richard Cochran.
5) CAIF protocol has tests like:
if (!x > y)
which are clearly bogus, fixes from Dan Carpenter.
6) HW timestamping support broke RX on some gianfar chips, turn the
feature off for now until we can understand the issue better. From
Anton Vorontsov.
7) IPV6 icmp bumps wrong stat counters due to typos in a 2.6.35 change,
fix from Eric Dumazet.
8) When a hw accelerated VLAN interface is hooked up to a bond, the
packet dropping behavior for inactive bonding slaves erroneously
changes compared to what happens with all other kinds of devices.
Fix by tracking whether the packet should be dropped inside of the
SKB so layers can communicate that they've done the bonding check
already. Fix from John Fastabend.
9) Packet rate estimator lacks sufficient SMP locking. The basic
assumption was that the RTNL would be held when estimators are
created or destroyed, but that doesn't happen in some cases, in
particular the xt_RATEEST netfilter module does not do this.
Adding RTNL to those spots is non-trivial and would actually cause
more problems than it would fix. So add a new spinlock to protect
the critical insert/delete/search operations.
Fix from Eric Dumazet.
10) pktgen miscalculates inter-packet delays, basically the old calculation
was:
wait_until(next_time);
now = get_time();
state->next_time = now + state->delay;
we fix it to be:
wait_until(next_time);
state->next_time = next_time + state->delay;
From Daniel Turull.
11) Missing endianness conversion in firmware header field in wimax driver,
from Inaky Perez-Gonzalez.
Please pull, thanks a lot!
The following changes since commit 7908a9e5fc3f9a679b1777ed231a03636c068446:
Linus Torvalds (1):
Merge branch 'kvm-updates/2.6.35' of git://git.kernel.org/pub/scm/virt/kvm/kvm
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Anton Vorontsov (1):
gianfar: Revive the driver for eTSEC devices (disable timestamping)
Dan Carpenter (1):
caif: fix a couple range checks
Daniel Turull (1):
pktgen: Fix accuracy of inter-packet delay.
David S. Miller (2):
Merge branch 'num_rx_queues' of git://kernel.ubuntu.com/rtg/net-2.6
Merge branch 'wimax-2.6.35.y' of git://git.kernel.org/.../inaky/wimax
Eric Dumazet (2):
ipv6: fix ICMP6_MIB_OUTERRORS
pkt_sched: gen_estimator: add a new lock
Figo.zhang (1):
net8139: fix a race at the end of NAPI
Inaky Perez-Gonzalez (1):
wimax/i2400m: fix missing endian correction read in fw loader
John Fastabend (1):
net: deliver skbs on inactive slaves to exact matches
Richard Cochran (1):
phylib: Add support for the LXT973 phy.
Tim Gardner (1):
net: Print num_rx_queues imbalance warning only when there are allocated queues
Timo Teräs (1):
r8169: fix mdio_read and update mdio_write according to hw specs
drivers/net/8139cp.c | 2 +-
drivers/net/8139too.c | 2 +-
drivers/net/gianfar.c | 3 +-
drivers/net/phy/lxt.c | 51 ++++++++++++++++++++++++++++++++++++++++-
drivers/net/r8169.c | 12 +++++++--
drivers/net/wimax/i2400m/fw.c | 2 +-
include/linux/skbuff.h | 5 +++-
net/8021q/vlan_core.c | 4 +-
net/caif/cfrfml.c | 2 +-
net/caif/cfveil.c | 2 +-
net/core/dev.c | 25 +++++++++++++------
net/core/gen_estimator.c | 15 +++++++++--
net/core/pktgen.c | 2 +-
net/ipv6/icmp.c | 4 +-
14 files changed, 103 insertions(+), 28 deletions(-)
^ permalink raw reply
* Re: [0/8] netpoll/bridge fixes
From: Matt Mackall @ 2010-06-11 20:03 UTC (permalink / raw)
To: Herbert Xu
Cc: Stephen Hemminger, Michael S. Tsirkin, Qianfeng Zhang,
David S. Miller, netdev, WANG Cong
In-Reply-To: <20100611021142.GA24490@gondor.apana.org.au>
On Fri, 2010-06-11 at 12:11 +1000, Herbert Xu wrote:
> On Fri, Jun 11, 2010 at 08:48:39AM +1000, Herbert Xu wrote:
> > On Thu, Jun 10, 2010 at 02:59:15PM -0700, Stephen Hemminger wrote:
> > >
> > > Okay, then add a comment where in_irq is used?
> >
> > Actually let me put it into a wrapper. I'll respin the patches.
>
> OK here is a repost. And this time it really is 8 patches :)
> I've tested it lightly.
These all look very nice to me, thanks for digging into this.
Acked-by: Matt Mackall <mpm@selenic.com>
Hopefully we'll also get an ack from Wang Cong on them and another test
result.
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: [ath5k-devel] [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: Dmytro Milinevskyy @ 2010-06-11 19:52 UTC (permalink / raw)
To: Bob Copeland
Cc: Kalle Valo, GeunSik Lim, Greg Kroah-Hartman, Jiri Slaby, netdev,
ath5k-devel, linux-wireless, John W. Linville, Keng-Yu Lin,
Jiri Kosina, Shahar Or, linux-kernel, Luca Verdesca
In-Reply-To: <AANLkTimUW58T19GOkRk3oCC9huLDQLgLj4W3RjiQ9n53@mail.gmail.com>
I didn't know. Thank you for noting that.
However I think it's better to give a chance to disable 802.11 leds.
-- Dima
On Fri, Jun 11, 2010 at 8:07 PM, Bob Copeland <me@bobcopeland.com> wrote:
> On Wed, Jun 9, 2010 at 10:43 AM, Dmytro Milinevskyy
> <milinevskyy@gmail.com> wrote:
>> Hi, Bob.
>>
>> For instance I don't use 802.11 leds layer and trigger leds from
>> userspace according to my purposes.
>
> FWIW you can disable mac80211 triggers from userspace as well.
> But, I guess hooking up null triggers will work too.
>
> --
> Bob Copeland %% www.bobcopeland.com
>
^ permalink raw reply
* Re: Weak host model vs .interface down
From: Mitchell Erblich @ 2010-06-11 19:50 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Rick Jones, netdev
In-Reply-To: <OFE6F71D1A.A94BE06C-ONC125773F.005C80CF-C125773F.005DF884@transmode.se>
On Jun 11, 2010, at 10:06 AM, Joakim Tjernlund wrote:
> Rick Jones <rick.jones2@hp.com> wrote on 2010/06/11 18:32:20:
>> Joakim Tjernlund wrote:
>>> Linux uses the weak host model which makes the IP addresses part of the system
>>> rather than the interface. However consider this:
>>>
>>> System A, eth0 connected to the network
>>> # > ifconfig eth0 192.168.1.16
>>> # > ifconfig eth1 192.168.1.17 down
>>>
>>> System B
>>> # > ping 192.168.1.17
>>> PING 192.168.1.17 (192.168.1.17) 56(84) bytes of data.
>>> 64 bytes from 192.168.1.17: icmp_seq=1 ttl=64 time=0.618 ms
>>>
>>> Isn't it a bit much to respond on 192.168.1.17 when its interface is down?
>>
>> As you said at the beginning, the weak end system model presumes the IP address
>> is part of the system. Seems to me that means unless one removes the IP address
>> from the system it is reasonable for the system to continue to respond to that
>> IP address. Regardless of what happens to any individual interface.
>
> The weak model doesn't go into such detail, it is assumption/impl. detail
> to assume that the ip address still is part of the system even when the interface
> is down. One could just as well define interface down as temporarly removing
> the IP address from the system too. This makes make much more sense to me and
> if you always want the system to answer on a IP adress you make it an IP alias.
>
> Since the current behaviour is a problem to me and routers in general, can
> we change this? What is the current usage model which needs it to stay as is?
>
>>
>> Now, I wouldn't expect it to continue to respond to 192.168.1.17 through eth1,
>> but if eth0 is indeed connected to the same broadcast domain, given the
>> following of the weak end-system model, continuing to respond seems consistent
>> with enthusiasticaly following the weak end-system model.
>
> Dosnt matter if it is in the same broadcast domain, you can use a bridge
> interface or dummy interface too. It will still respond to 192.168.1.17
> I can't find a way disable this behaviour, can you?
>
> --
Guys
Isn't this the diff between models of a host/end system and a
router/intermediate system?
Can you verify that xmit capability on the intf is disabled with the
down arg?
IMO, One possible behaviour is to allow the receipt of a magic
packet to bring up a down system for the "energy star protocol".
Mitchell Erblich
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] drivers/net/e1000/e1000_main.c: Fix message logging defect
From: Jeff Kirsher @ 2010-06-11 19:46 UTC (permalink / raw)
To: Joe Perches; +Cc: Emil Tantilov, netdev, e1000-devel, LKML
In-Reply-To: <1276237773.1556.507.camel@Joe-Laptop.home>
On Thu, Jun 10, 2010 at 23:29, Joe Perches <joe@perches.com> wrote:
> commit 675ad47375c76a7c3be4ace9554d92cd55518ced
> removed the capability to use ethtool.set_msglevel to
> control the types of messages emitted by the driver.
>
> That commit should probably be reverted.
>
> If not, then this patch fixes a message logging defect
> introduced by converting a printk without KERN_<level>
> to e_info.
>
> This also reduces text by about 200 bytes.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
Thanks Joe. I have added the patch to my queue.
^ permalink raw reply
* Re: Weak host model vs .interface down
From: Joakim Tjernlund @ 2010-06-11 19:41 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <4C126EC6.9000506@hp.com>
Rick Jones <rick.jones2@hp.com> wrote on 2010/06/11 19:13:42:
>
> > The weak model doesn't go into such detail, it is assumption/impl. detail
> > to assume that the ip address still is part of the system even when the interface
> > is down. One could just as well define interface down as temporarly removing
> > the IP address from the system too. This makes make much more sense to me and
> > if you always want the system to answer on a IP adress you make it an IP alias.
> >
> > Since the current behaviour is a problem to me and routers in general, can
> > we change this? What is the current usage model which needs it to stay as is?
>
> Router != end-system so I wouldn't think the weak or strong end-system model
> would apply to a router. I think Stephen already posted a patch to allow that
> for when one's box was a router rather than an end-system.
Not really an anwser to what I was asking but I choose to read that as
you agree with me. The rest is an impl. detail. :)
Stephen's patch is good but I would not mind making I/F down removing the
IP address from the system unconditionally.
Jocke
^ permalink raw reply
* Re: [patch 2.6.35] WiMAX pull request
From: David Miller @ 2010-06-11 19:39 UTC (permalink / raw)
To: inaky; +Cc: netdev, wimax, inaky.perez-gonzalez
In-Reply-To: <cover.1276282933.git.inaky.perez-gonzalez@intel.com>
From: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Date: Fri, 11 Jun 2010 12:03:05 -0700
> From: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
>
> The following changes since commit 3a24934f065d23145f1c9c70da9f630c7a37795f:
> Inaky Perez-Gonzalez (1):
> wimax/i2400m: fix bad race condition check in RX path
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/inaky/wimax.git wimax-2.6.35.y
Pulled, thanks a lot.
^ permalink raw reply
* [patch 2.6.35] WiMAX pull request
From: Inaky Perez-Gonzalez @ 2010-06-11 19:03 UTC (permalink / raw)
To: netdev, wimax; +Cc: Inaky Perez-Gonzalez
From: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
The following changes since commit 3a24934f065d23145f1c9c70da9f630c7a37795f:
Inaky Perez-Gonzalez (1):
wimax/i2400m: fix bad race condition check in RX path
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/inaky/wimax.git wimax-2.6.35.y
Patches follow for reviewing convenience.
Inaky Perez-Gonzalez (1):
wimax/i2400m: fix missing endian correction read in fw loader
drivers/net/wimax/i2400m/fw.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
^ permalink raw reply
* [patch 2.6.35] wimax/i2400m: fix missing endian correction read in fw loader
From: Inaky Perez-Gonzalez @ 2010-06-11 19:03 UTC (permalink / raw)
To: netdev, wimax
In-Reply-To: <cover.1276282933.git.inaky.perez-gonzalez@intel.com>
From: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
i2400m_fw_hdr_check() was accessing hardware field
bcf_hdr->module_type (little endian 32) without converting to host
byte sex.
Reported-by: Данилин Михаил <mdanilin@nsg.net.ru>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
drivers/net/wimax/i2400m/fw.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wimax/i2400m/fw.c b/drivers/net/wimax/i2400m/fw.c
index 3f283bf..1149135 100644
--- a/drivers/net/wimax/i2400m/fw.c
+++ b/drivers/net/wimax/i2400m/fw.c
@@ -1192,7 +1192,7 @@ int i2400m_fw_hdr_check(struct i2400m *i2400m,
unsigned module_type, header_len, major_version, minor_version,
module_id, module_vendor, date, size;
- module_type = bcf_hdr->module_type;
+ module_type = le32_to_cpu(bcf_hdr->module_type);
header_len = sizeof(u32) * le32_to_cpu(bcf_hdr->header_len);
major_version = (le32_to_cpu(bcf_hdr->header_version) & 0xffff0000)
>> 16;
--
1.6.6.1
_______________________________________________
wimax mailing list
wimax@linuxwimax.org
http://lists.linuxwimax.org/listinfo/wimax
^ permalink raw reply related
* Re: pull request: wireless-next-2.6 2010-06-09
From: David Miller @ 2010-06-11 18:34 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100609211251.GC2452-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Wed, 9 Jun 2010 17:12:51 -0400
> Dave,
>
> Here is the usual, frightening, monstrous post-window pull request...
> Along with the usual batch of driver updates, there are also some DMA
> state API conversions from FUJITA Tomonori, some cleanups from Julia
> Lawall and Joe Perches, some SSB changes from Larry Finger and Rafał
> Miłecki, and a number of mac80211 changes from Johannes Berg. All of it
> has had at least one cycle through linux-next and most of it has been
> there for several days. This also includes the same wireless-2.6 pull I
> sent you previously so as to resolve some merge conflicts.
>
> Please let me know if there are problems!
Pulled, thanks JOhn.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Fw: [Bug 16183] New: sch_teql no longer works post 2.6.30
From: Eric Dumazet @ 2010-06-11 17:43 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20100611090835.31b8436c@nehalam>
Le vendredi 11 juin 2010 à 09:08 -0700, Stephen Hemminger a écrit :
>
> Begin forwarded message:
>
> Date: Fri, 11 Jun 2010 15:56:44 GMT
> From: bugzilla-daemon@bugzilla.kernel.org
> To: shemminger@linux-foundation.org
> Subject: [Bug 16183] New: sch_teql no longer works post 2.6.30
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=16183
>
> Summary: sch_teql no longer works post 2.6.30
> Product: Networking
> Version: 2.5
> Kernel Version: 2.6.31 through 2.6.34
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: IPV4
> AssignedTo: shemminger@linux-foundation.org
> ReportedBy: tom@compton.nu
> Regression: Yes
>
>
> Created an attachment (id=26729)
> --> (https://bugzilla.kernel.org/attachment.cgi?id=26729)
> Patch to fix sch_teql
>
> The sch_teql module, which can be used to load balance over a set of underlying
> interfaces, stopped working after 2.6.30 and has been broken in all kernels
> since then.
>
> The problem is that the transmit routine relies on being able to access the
> destination address in the skb in order to do ARP resolution once it has
> decided which underlying interface it is going to transmit through.
>
> In 2.6.31 the IFF_XMIT_DST_RELEASE flag was introduced, and set by default for
> all interfaces, which causes the destination address to be release before the
> transmit routine for the interface is called.
>
> The solution (implemented in the attached patch) is to clear that flag for teql
> interfaces.
>
> --
> Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug.
>
>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Please note my old email address no longer works ;)
Thanks
^ permalink raw reply
* Re: Weak host model vs .interface down
From: Rick Jones @ 2010-06-11 17:13 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev
In-Reply-To: <OFE6F71D1A.A94BE06C-ONC125773F.005C80CF-C125773F.005DF884@transmode.se>
> The weak model doesn't go into such detail, it is assumption/impl. detail
> to assume that the ip address still is part of the system even when the interface
> is down. One could just as well define interface down as temporarly removing
> the IP address from the system too. This makes make much more sense to me and
> if you always want the system to answer on a IP adress you make it an IP alias.
>
> Since the current behaviour is a problem to me and routers in general, can
> we change this? What is the current usage model which needs it to stay as is?
Router != end-system so I wouldn't think the weak or strong end-system model
would apply to a router. I think Stephen already posted a patch to allow that
for when one's box was a router rather than an end-system.
rick jones
It's a router!
No, it's an end-system!
...
http://snltranscripts.jt.org/75/75ishimmer.phtml
^ permalink raw reply
* Re: Weak host model vs .interface down
From: Joakim Tjernlund @ 2010-06-11 17:06 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <4C126514.30905@hp.com>
Rick Jones <rick.jones2@hp.com> wrote on 2010/06/11 18:32:20:
> Joakim Tjernlund wrote:
> > Linux uses the weak host model which makes the IP addresses part of the system
> > rather than the interface. However consider this:
> >
> > System A, eth0 connected to the network
> > # > ifconfig eth0 192.168.1.16
> > # > ifconfig eth1 192.168.1.17 down
> >
> > System B
> > # > ping 192.168.1.17
> > PING 192.168.1.17 (192.168.1.17) 56(84) bytes of data.
> > 64 bytes from 192.168.1.17: icmp_seq=1 ttl=64 time=0.618 ms
> >
> > Isn't it a bit much to respond on 192.168.1.17 when its interface is down?
>
> As you said at the beginning, the weak end system model presumes the IP address
> is part of the system. Seems to me that means unless one removes the IP address
> from the system it is reasonable for the system to continue to respond to that
> IP address. Regardless of what happens to any individual interface.
The weak model doesn't go into such detail, it is assumption/impl. detail
to assume that the ip address still is part of the system even when the interface
is down. One could just as well define interface down as temporarly removing
the IP address from the system too. This makes make much more sense to me and
if you always want the system to answer on a IP adress you make it an IP alias.
Since the current behaviour is a problem to me and routers in general, can
we change this? What is the current usage model which needs it to stay as is?
>
> Now, I wouldn't expect it to continue to respond to 192.168.1.17 through eth1,
> but if eth0 is indeed connected to the same broadcast domain, given the
> following of the weak end-system model, continuing to respond seems consistent
> with enthusiasticaly following the weak end-system model.
Dosnt matter if it is in the same broadcast domain, you can use a bridge
interface or dummy interface too. It will still respond to 192.168.1.17
I can't find a way disable this behaviour, can you?
^ permalink raw reply
* Re: [ath5k-devel] [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: Bob Copeland @ 2010-06-11 17:07 UTC (permalink / raw)
To: Dmytro Milinevskyy
Cc: Kalle Valo, GeunSik Lim, Greg Kroah-Hartman, Jiri Slaby,
netdev-u79uwXL29TY76Z2rM5mHXA, ath5k-devel-xDcbHBWguxEUs3QNXV6qNA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, John W. Linville,
Keng-Yu Lin, Jiri Kosina, Shahar Or,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Luca Verdesca
In-Reply-To: <AANLkTimXqdkQxv_Y1JaleTTWNsDIQHQaPn8HR7efOupb-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Jun 9, 2010 at 10:43 AM, Dmytro Milinevskyy
<milinevskyy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi, Bob.
>
> For instance I don't use 802.11 leds layer and trigger leds from
> userspace according to my purposes.
FWIW you can disable mac80211 triggers from userspace as well.
But, I guess hooking up null triggers will work too.
--
Bob Copeland %% www.bobcopeland.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Weak host model vs .interface down
From: Rick Jones @ 2010-06-11 16:32 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev
In-Reply-To: <OF1D06F11A.44DE8C5A-ONC125773F.00437856-C125773F.004425B9@transmode.se>
Joakim Tjernlund wrote:
> Linux uses the weak host model which makes the IP addresses part of the system
> rather than the interface. However consider this:
>
> System A, eth0 connected to the network
> # > ifconfig eth0 192.168.1.16
> # > ifconfig eth1 192.168.1.17 down
>
> System B
> # > ping 192.168.1.17
> PING 192.168.1.17 (192.168.1.17) 56(84) bytes of data.
> 64 bytes from 192.168.1.17: icmp_seq=1 ttl=64 time=0.618 ms
>
> Isn't it a bit much to respond on 192.168.1.17 when its interface is down?
As you said at the beginning, the weak end system model presumes the IP address
is part of the system. Seems to me that means unless one removes the IP address
from the system it is reasonable for the system to continue to respond to that
IP address. Regardless of what happens to any individual interface.
Now, I wouldn't expect it to continue to respond to 192.168.1.17 through eth1,
but if eth0 is indeed connected to the same broadcast domain, given the
following of the weak end-system model, continuing to respond seems consistent
with enthusiasticaly following the weak end-system model.
rick jones
^ permalink raw reply
* Fw: [Bug 16183] New: sch_teql no longer works post 2.6.30
From: Stephen Hemminger @ 2010-06-11 16:08 UTC (permalink / raw)
To: Eric Dumazet, David Miller; +Cc: netdev
Begin forwarded message:
Date: Fri, 11 Jun 2010 15:56:44 GMT
From: bugzilla-daemon@bugzilla.kernel.org
To: shemminger@linux-foundation.org
Subject: [Bug 16183] New: sch_teql no longer works post 2.6.30
https://bugzilla.kernel.org/show_bug.cgi?id=16183
Summary: sch_teql no longer works post 2.6.30
Product: Networking
Version: 2.5
Kernel Version: 2.6.31 through 2.6.34
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
AssignedTo: shemminger@linux-foundation.org
ReportedBy: tom@compton.nu
Regression: Yes
Created an attachment (id=26729)
--> (https://bugzilla.kernel.org/attachment.cgi?id=26729)
Patch to fix sch_teql
The sch_teql module, which can be used to load balance over a set of underlying
interfaces, stopped working after 2.6.30 and has been broken in all kernels
since then.
The problem is that the transmit routine relies on being able to access the
destination address in the skb in order to do ARP resolution once it has
decided which underlying interface it is going to transmit through.
In 2.6.31 the IFF_XMIT_DST_RELEASE flag was introduced, and set by default for
all interfaces, which causes the destination address to be release before the
transmit routine for the interface is called.
The solution (implemented in the attached patch) is to clear that flag for teql
interfaces.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
--
^ permalink raw reply
* [PATCH net-next-2.6] ipv4: sysctl to block responding on down interface
From: Stephen Hemminger @ 2010-06-11 15:48 UTC (permalink / raw)
To: Joakim Tjernlund, David Miller; +Cc: netdev
In-Reply-To: <OF1D06F11A.44DE8C5A-ONC125773F.00437856-C125773F.004425B9@transmode.se>
When Linux is used as a router, it is undesirable for the kernel to process
incoming packets when the address assigned to the interface is down.
The initial problem report was for a management application that used ICMP
to check link availability.
The default is disabled to maintain compatibility with previous behavior.
This is not recommended for server systems because it makes fail over more
difficult, and does not account for configurations where multiple interfaces
have the same IP address.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
Documentation/networking/ip-sysctl.txt | 10 ++++++++++
include/linux/inetdevice.h | 2 ++
net/ipv4/devinet.c | 1 +
net/ipv4/route.c | 7 +++++++
4 files changed, 20 insertions(+)
--- a/include/linux/inetdevice.h 2010-05-28 08:35:11.000000000 -0700
+++ b/include/linux/inetdevice.h 2010-06-11 08:35:55.237028136 -0700
@@ -37,6 +37,7 @@ enum
IPV4_DEVCONF_ACCEPT_LOCAL,
IPV4_DEVCONF_SRC_VMARK,
IPV4_DEVCONF_PROXY_ARP_PVLAN,
+ IPV4_DEVCONF_LINKFILTER,
__IPV4_DEVCONF_MAX
};
@@ -140,6 +141,7 @@ static inline void ipv4_devconf_setall(s
#define IN_DEV_ARP_ANNOUNCE(in_dev) IN_DEV_MAXCONF((in_dev), ARP_ANNOUNCE)
#define IN_DEV_ARP_IGNORE(in_dev) IN_DEV_MAXCONF((in_dev), ARP_IGNORE)
#define IN_DEV_ARP_NOTIFY(in_dev) IN_DEV_MAXCONF((in_dev), ARP_NOTIFY)
+#define IN_DEV_LINKFILTER(in_dev) IN_DEV_MAXCONF((in_dev), LINKFILTER)
struct in_ifaddr {
struct in_ifaddr *ifa_next;
--- a/net/ipv4/devinet.c 2010-06-01 08:39:12.000000000 -0700
+++ b/net/ipv4/devinet.c 2010-06-11 08:37:03.921248294 -0700
@@ -1416,6 +1416,7 @@ static struct devinet_sysctl_table {
DEVINET_SYSCTL_RW_ENTRY(ARP_ACCEPT, "arp_accept"),
DEVINET_SYSCTL_RW_ENTRY(ARP_NOTIFY, "arp_notify"),
DEVINET_SYSCTL_RW_ENTRY(PROXY_ARP_PVLAN, "proxy_arp_pvlan"),
+ DEVINET_SYSCTL_RW_ENTRY(LINKFILTER, "link_filter"),
DEVINET_SYSCTL_FLUSHING_ENTRY(NOXFRM, "disable_xfrm"),
DEVINET_SYSCTL_FLUSHING_ENTRY(NOPOLICY, "disable_policy"),
--- a/net/ipv4/route.c 2010-06-11 08:13:13.000000000 -0700
+++ b/net/ipv4/route.c 2010-06-11 08:14:28.486271886 -0700
@@ -2152,6 +2152,13 @@ static int ip_route_input_slow(struct sk
goto brd_input;
if (res.type == RTN_LOCAL) {
+ int linkf = IN_DEV_LINKFILTER(in_dev);
+
+ if (linkf && !netif_running(res.fi->fib_dev))
+ goto no_route;
+ if (linkf > 1 && !netif_carrier_ok(res.fi->fib_dev))
+ goto no_route;
+
err = fib_validate_source(saddr, daddr, tos,
net->loopback_dev->ifindex,
dev, &spec_dst, &itag, skb->mark);
--- a/Documentation/networking/ip-sysctl.txt 2010-06-11 08:14:46.889751310 -0700
+++ b/Documentation/networking/ip-sysctl.txt 2010-06-11 08:15:35.508471622 -0700
@@ -832,6 +832,16 @@ rp_filter - INTEGER
Default value is 0. Note that some distributions enable it
in startup scripts.
+link_filter - INTEGER
+ 0 - Allow packets to be received for the address on this interface
+ even if interface is disabled or no carrier.
+
+ 1 - Ignore packets received if interface associated with the incoming
+ address is down.
+
+ 2 - Ignore packets received if interface associated with the incoming
+ address is down or has no carrier.
+
arp_filter - BOOLEAN
1 - Allows you to have multiple network interfaces on the same
subnet, and have the ARPs for each interface be answered
^ permalink raw reply
* [PATCH 3/4] pcmcia: dev_node removal bugfix
From: Dominik Brodowski @ 2010-06-11 14:44 UTC (permalink / raw)
To: linux-pcmcia; +Cc: Dominik Brodowski, netdev, linux-wireless
In-Reply-To: <20100611144359.GA9572@comet.dominikbrodowski.net>
Patch c7c2fa07 removed one line too much from smc91c92_cs.c.
Reported-by: Komuro <komurojun-mbn@nifty.com>
CC: netdev@vger.kernel.org
CC: linux-wireless@vger.kernel.org
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
---
drivers/net/pcmcia/smc91c92_cs.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/pcmcia/smc91c92_cs.c b/drivers/net/pcmcia/smc91c92_cs.c
index 7b6fe89..64e6a84 100644
--- a/drivers/net/pcmcia/smc91c92_cs.c
+++ b/drivers/net/pcmcia/smc91c92_cs.c
@@ -322,6 +322,7 @@ static int smc91c92_probe(struct pcmcia_device *link)
return -ENOMEM;
smc = netdev_priv(dev);
smc->p_dev = link;
+ link->priv = dev;
spin_lock_init(&smc->lock);
link->io.NumPorts1 = 16;
--
1.7.0.4
^ permalink raw reply related
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