* Re: NULL pointer dereference at __ip_route_output_key
From: Dave Jones @ 2012-04-03 0:22 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kernel-team
In-Reply-To: <20120402.200711.2234324385609269937.davem@davemloft.net>
On Mon, Apr 02, 2012 at 08:07:11PM -0400, David Miller wrote:
> > We just had this reported. Look familiar to anyone ?
>
> If you could unravel the source file and line the OOPS occurs at, I
> can look at these kinds of reports much faster. As it stands, when I
> see a Fedora OOPS, it's a long process for me:
Ok, I'll try and pull these apart for you in future, as I usually
have the bits for the most recent builds around.
> Anyways in this case dev_out is NULL when we read it around line
> 2798 of net/ipv4/route.c:
>
> dev_out = FIB_RES_DEV(res);
> fl4->flowi4_oif = dev_out->ifindex;
>
> and we are thus OOPS'ing on the dev_out->ifindex.
>
> Unfortunately I've never seen a report like this. If the reporter can
> reproduce, you can try to extract more information by doing something
> like this right after the dev_out assignment:
>
> if (!dev_out) {
> pr_crit("ipv4: FIB_RES_DEV() is NULL, nh_sel=%d\n",
> res.nh_sel);
> rth = ERR_PTR(-EINVAL);
> goto out;
> }
>
> This debugging will also avoid the NULL pointer crash at least for
> that particular invocation.
ok, I'll do a test build with this change for the user to try out.
Hopefully he can retrigger it.
thanks,
Dave
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2012-04-03 0:34 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Provide device string properly for USB i2400m wimax devices, also don't
OOPS when providing firmware string. From Phil Sutter.
2) Add support for sh_eth SH7734 chips, from Nobuhiro Iwamatsu.
3) Add another device ID to USB zaurus driver, from Guan Xin.
4) Loop index start in pool vector iterator is wrong causing MAC to
not get configured in bnx2x driver, fix from Dmitry Kravkov.
5) EQL driver assumes HZ=100, fix from Eric Dumazet.
6) Now that skb_add_rx_frag() can specify the truesize increment
separately, do so in f_phonet and cdc_phonet, also from Eric
Dumazet.
7) virtio_net accidently uses net_ratelimit() not only on the kernel
warning but also the statistic bump, fix from Rick Jones.
8) ip_route_input_mc() uses fixed init_net namespace, oops, use
dev_net(dev) instead. Fix from Benjamin LaHaise.
9) dev_forward_skb() needs to clear the incoming interface index of
the SKB so that it looks like a new incoming packet, also from
Benjamin LaHaise.
10) iwlwifi mistakenly initializes a channel entry as 2GHZ instead
of 5GHZ, fix from Stanislav Yakovlev.
11) Missing kmalloc() return value checks in orinoco, from Santosh
Nayak.
12) ath9k doesn't check for HT capabilities in the right way, it
is checking ht_supported instead of the ATH9K_HW_CAP_HT flag.
Fix from Sujith Manoharan.
13) Fix x86 BPF JIT emission of 16-bit immediate field of AND
instructions, from Feiran Zhuang.
14) Avoid infinite loop in GARP code when registering sysfs entries.
From David Ward.
15) rose protocol uses memcpy instead of memcmp in a device address
comparison, oops. Fix from Daniel Borkmann.
16) Fix build of lpc_eth due to dev_hw_addr_rancom() interface being
renamed to eth_hw_addr_random(). From Roland Stigge.
17) Make ipv6 RTM_GETROUTE interpret RTA_IIF attribute the same way
that ipv4 does. Fix from Shmulik Ladkani.
18) via-rhine has an inverted bit test, causing suspend/resume regressions.
Fix from Andreas Mohr.
19) RIONET assumes 4K page size, fix from Akinobu Mita.
20) Initialization of imask register in sky2 is buggy, because
bits are "or'd" into an uninitialized local variable. Fix
from Lino Sanfilippo.
21) Fix FCOE checksum offload handling, from Yi Zou.
22) Fix VLAN processing regression in e1000, from Jiri Pirko.
Please pull, thanks a lot!
The following changes since commit b1a808ff436343956a6ae63178ea1810c5e5a3a1:
Merge branch 'for-next' of git://gitorious.org/kernel-hsi/kernel-hsi (2012-04-02 09:50:40 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
Akinobu Mita (1):
rionet: fix page allocation order of rionet_active
Alexander Duyck (1):
ixgbe: Fix issues with SR-IOV loopback when flow control is disabled
Andreas Mohr (1):
via-rhine: fix wait-bit inversion.
Andrew Morton (1):
net/netfilter/nfnetlink_acct.c: use linux/atomic.h
Benjamin LaHaise (2):
net/ipv4: fix IPv4 multicast over network namespaces
net/core: dev_forward_skb() should clear skb_iif
Bob Copeland (1):
ath5k: drop self from MAINTAINERS
Dan Carpenter (1):
mISDN: array underflow in open_bchannel()
David S. Miller (3):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless
Merge branch 'master' of git://git.kernel.org/.../jkirsher/net
Merge branch 'master' of git://git.kernel.org/.../linville/wireless
David Ward (1):
net/garp: avoid infinite loop if attribute already exists
Dmitry Kravkov (1):
bnx2x: fix vector traveling while looking for an empty entry
Don Skidmore (2):
ixgbe: fix typo in enumeration name
ixgbe: update version number
Eliad Peller (1):
mac80211: remove outdated comment
Eric Dumazet (4):
ath9k: fix a memory leak in ath_rx_tasklet()
eql: dont rely on HZ=100
f_phonet: fix skb truesize underestimation
cdc-phonet: fix skb truesize underestimation
Guan Xin (1):
USB: Add Motorola Rokr E6 Id to the USBNet driver "zaurus"
Jeff Kirsher (3):
Merge branch 'master' of git://git.kernel.org/.../davem/net
Merge branch 'master' of git://git.kernel.org/.../davem/net
Merge branch 'master' of git://git.kernel.org/.../davem/net
Jiri Pirko (1):
e1000: fix vlan processing regression
John W. Linville (1):
cfg80211: allow CFG80211_SIGNAL_TYPE_UNSPEC in station_info
Kenth Eriksson (1):
Fix non TBI PHY access; a bad merge undid bug fix in a previous commit.
Larry Finger (1):
rtlwifi: rtl8192ce: rtl8192cu: rtl8192de: Fix low-gain setting when scanning
Lino Sanfilippo (1):
sky2: dont overwrite settings for PHY Quick link
Matt Carlson (1):
tg3: Fix 5717 serdes powerdown problem
Nobuhiro Iwamatsu (1):
net: sh_eth: Add support SH7734
Phil Sutter (2):
wimax: i2400m - prevent a possible kernel bug due to missing fw_name string
wimax: i2400m-usb - use a private struct ethtool_ops
Rabin Vincent (1):
net: usb: cdc_eem: fix mtu
Rajkumar Manoharan (3):
ath9k: fix max noise floor threshold
ath9k: reduce listen time period
mac80211: fix oper channel timestamp updation
Rick Jones (1):
virtio_net: do not rate limit counter increments
Santosh Nayak (1):
net: orinoco: add error handling for failed kmalloc().
Shmulik Ladkani (1):
ipv6: Fix RTM_GETROUTE's interpretation of RTA_IIF to be consistent with ipv4
Stanislav Yakovlev (2):
net/wireless: ipw2x00: fix a typo in wiphy struct initilization
MAINTAINERS: adding maintainer for ipw2x00
Stanislaw Gruszka (5):
iwlegacy: do not nulify il->vif on reset
iwlegacy: fix BSSID setting
rt2x00: rt2800usb: schedule txdone work on timeout
rt2x00: rt2800usb: fix status register reread logic
mac80211: fix possible tid_rx->reorder_timer use after free
Sujith Manoharan (1):
ath9k: Use HW HT capabilites properly
Weiping Pan (1):
bonding: emit event when bonding changes MAC
Yi Zou (2):
net: do not do gso for CHECKSUM_UNNECESSARY in netif_needs_gso
fcoe: use CHECKSUM_UNNECESSARY instead of CHECKSUM_PARTIAL on tx
Yoshihiro Shimoda (1):
net: sh_eth: fix endian check for architecture independent
Yuval Mintz (1):
bnx2x: previous driver unload revised
danborkmann@iogearbox.net (1):
rose_dev: fix memcpy-bug in rose_set_mac_address
huajun li (1):
usb/rtl8150 : Remove duplicated definitions
stephen hemminger (1):
intel: make wired ethernet driver message level consistent (rev2)
stigge@antcom.de (1):
net: lpc_eth: Fix rename of dev_hw_addr_random
zhuangfeiran@ict.ac.cn (1):
x86 bpf_jit: fix a bug in emitting the 16-bit immediate operand of AND
MAINTAINERS | 13 +-
arch/x86/net/bpf_jit_comp.c | 2 +-
drivers/isdn/hardware/mISDN/avmfritz.c | 2 +-
drivers/isdn/hardware/mISDN/hfcpci.c | 2 +-
drivers/isdn/hardware/mISDN/hfcsusb.c | 2 +-
drivers/isdn/hardware/mISDN/mISDNipac.c | 2 +-
drivers/isdn/hardware/mISDN/mISDNisar.c | 2 +-
drivers/isdn/hardware/mISDN/netjet.c | 2 +-
drivers/isdn/hardware/mISDN/w6692.c | 2 +-
drivers/net/bonding/bond_main.c | 8 +-
drivers/net/eql.c | 7 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 7 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 40 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h | 3 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h | 3 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c | 1 -
drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.h | 2 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 464 ++++++++++++++++----
drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h | 4 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c | 2 +-
drivers/net/ethernet/broadcom/tg3.c | 4 +-
drivers/net/ethernet/freescale/fsl_pq_mdio.c | 12 +-
drivers/net/ethernet/intel/e1000/e1000_main.c | 40 +-
drivers/net/ethernet/intel/e1000e/netdev.c | 7 +-
drivers/net/ethernet/intel/igb/igb_main.c | 7 +-
drivers/net/ethernet/intel/igbvf/netdev.c | 7 +-
drivers/net/ethernet/intel/ixgb/ixgb_main.c | 6 +-
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 2 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 13 +-
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 7 +-
drivers/net/ethernet/marvell/sky2.c | 5 +-
drivers/net/ethernet/nxp/lpc_eth.c | 2 +-
drivers/net/ethernet/renesas/Kconfig | 5 +-
drivers/net/ethernet/renesas/sh_eth.c | 22 +-
drivers/net/ethernet/renesas/sh_eth.h | 15 +-
drivers/net/ethernet/via/via-rhine.c | 12 +-
drivers/net/rionet.c | 11 +-
drivers/net/usb/cdc-phonet.c | 4 +-
drivers/net/usb/cdc_eem.c | 1 +
drivers/net/usb/rtl8150.c | 26 --
drivers/net/usb/zaurus.c | 5 +
drivers/net/virtio_net.c | 7 +-
drivers/net/wimax/i2400m/netdev.c | 3 +-
drivers/net/wimax/i2400m/usb.c | 18 +
drivers/net/wireless/ath/ath9k/calib.c | 5 +-
drivers/net/wireless/ath/ath9k/init.c | 2 +-
drivers/net/wireless/ath/ath9k/main.c | 4 +-
drivers/net/wireless/ath/ath9k/recv.c | 4 +-
drivers/net/wireless/ipw2x00/ipw2200.c | 4 +-
drivers/net/wireless/iwlegacy/3945-mac.c | 2 -
drivers/net/wireless/iwlegacy/4965-mac.c | 2 -
drivers/net/wireless/iwlegacy/common.c | 31 +-
drivers/net/wireless/orinoco/main.c | 8 +
drivers/net/wireless/rt2x00/rt2800usb.c | 10 +-
drivers/net/wireless/rtlwifi/rtl8192c/phy_common.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8192de/phy.c | 2 +-
drivers/usb/gadget/f_phonet.c | 2 +-
include/linux/if_eql.h | 2 +-
include/net/cfg80211.h | 6 +-
net/802/garp.c | 22 +-
net/core/dev.c | 1 +
net/ipv4/route.c | 2 +-
net/ipv6/route.c | 34 ++-
net/mac80211/agg-rx.c | 3 +-
net/mac80211/main.c | 3 -
net/mac80211/scan.c | 2 +-
net/netfilter/nfnetlink_acct.c | 2 +-
net/rose/rose_dev.c | 4 +-
net/wireless/nl80211.c | 29 +-
69 files changed, 705 insertions(+), 294 deletions(-)
^ permalink raw reply
* Re: NULL pointer dereference at __ip_route_output_key
From: David Miller @ 2012-04-03 0:34 UTC (permalink / raw)
To: davej; +Cc: netdev, kernel-team
In-Reply-To: <20120403002200.GA21262@redhat.com>
From: Dave Jones <davej@redhat.com>
Date: Mon, 2 Apr 2012 20:22:00 -0400
> On Mon, Apr 02, 2012 at 08:07:11PM -0400, David Miller wrote:
>
> > > We just had this reported. Look familiar to anyone ?
> >
> > If you could unravel the source file and line the OOPS occurs at, I
> > can look at these kinds of reports much faster. As it stands, when I
> > see a Fedora OOPS, it's a long process for me:
>
> Ok, I'll try and pull these apart for you in future, as I usually
> have the bits for the most recent builds around.
Thanks a lot Dave.
^ permalink raw reply
* Re: [PATCH] ipv6: fix array index in ip6_mc_add_src()
From: RongQing Li @ 2012-04-03 0:58 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120402.161950.1558486977364492163.davem@davemloft.net>
OK, I see, thanks
BR
-Roy
2012/4/3, David Miller <davem@davemloft.net>:
> From: RongQing Li <roy.qing.li@gmail.com>
> Date: Mon, 2 Apr 2012 18:16:14 +0800
>
>> 2012/4/2 David Miller <davem@davemloft.net>:
>>> From: roy.qing.li@gmail.com
>>> Date: Sun, 1 Apr 2012 16:45:26 +0800
>>>
>>>> From: RongQing.Li <roy.qing.li@gmail.com>
>>>>
>>>> Convert array index from the loop bound to the loop index.
>>>>
>>>> Signed-off-by: RongQing.Li <roy.qing.li@gmail.com>
>>>
>>> That's not all you are doing:
>>>
>>>> - (void) ip6_mc_del1_src(pmc, sfmode, &psfsrc[i]);
>>>> + ip6_mc_del1_src(pmc, sfmode, &psfsrc[j]);
>>>
>>> You absolutely MUST mention and explain this (void) removal.
>>> It's probably there to elide an unchecked return value
>>> warning from the compiler.
>>
>> since ip6_mc_del1_src() does not use __must_check likely attribute.
>> I try to compile with several gcc warning options, but do not
>> find which options can report the unchecked return value.
>
> I said "probably", I didn't check myself.
>
> The issue I had was that you didn't mention the void removal in the
> commit message.
>
^ permalink raw reply
* [PATCH 2/2] TCP: Use 32768-65535 outgoing port range by default
From: fernando @ 2012-04-03 0:50 UTC (permalink / raw)
To: David Miller, Stephen Hemminger; +Cc: netdev@vger.kernel.org
In-Reply-To: <20120403094840.ftxlwztl40gwcg4s@webmail.int.intellilink.co.jp>
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: sysctl-ip_local_port_range-change-default.patch --]
[-- Type: text/plain, Size: 2055 bytes --]
Subject: [PATCH] TCP: Use 32768-65535 outgoing port range by default
From: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
There was a time when the ip masquerading code reserved the 61000-65095
port range, which is the reason why the current default upper limit in
ip_local_port_range is 61000. However, the current iptables-based
masquerading and SNAT implementation does not have that restriction;
ipchains and the compatibilty mode that used the range over 61000
exclusively is lone gone.
Bump up the last local port number used by default to the maximum, i.e.
65535, so that we can have more connections in the system without
eating deeper into IANA assigned range.
Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
---
diff -urNp linux-3.4-rc1-orig/Documentation/networking/ip-sysctl.txt linux-3.4-rc1/Documentation/networking/ip-sysctl.txt
--- linux-3.4-rc1-orig/Documentation/networking/ip-sysctl.txt 2012-04-03 08:51:37.325983165 +0900
+++ linux-3.4-rc1/Documentation/networking/ip-sysctl.txt 2012-04-03 08:53:52.282652377 +0900
@@ -605,7 +605,7 @@ ip_local_port_range - 2 INTEGERS
Defines the local port range that is used by TCP and UDP to
choose the local port. The first number is the first, the
second the last local port number. The default values are
- 32768 and 61000 respectively.
+ 32768 and 65535 respectively.
These two numbers determine the number of active connections
which this system can issue simultaneously to systems not
diff -urNp linux-3.4-rc1-orig/net/ipv4/inet_connection_sock.c linux-3.4-rc1/net/ipv4/inet_connection_sock.c
--- linux-3.4-rc1-orig/net/ipv4/inet_connection_sock.c 2012-03-19 08:15:34.000000000 +0900
+++ linux-3.4-rc1/net/ipv4/inet_connection_sock.c 2012-04-03 08:52:15.350171717 +0900
@@ -34,7 +34,7 @@ EXPORT_SYMBOL(inet_csk_timer_bug_msg);
*/
struct local_ports sysctl_local_ports __read_mostly = {
.lock = __SEQLOCK_UNLOCKED(sysctl_local_ports.lock),
- .range = { 32768, 61000 },
+ .range = { 32768, 65535 },
};
unsigned long *sysctl_local_reserved_ports;
^ permalink raw reply
* [PATCH 1/2] TCP: update ip_local_port_range documentation
From: fernando @ 2012-04-03 0:48 UTC (permalink / raw)
To: David Miller, Stephen Hemminger; +Cc: netdev@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: sysctl-ip_local_port_range-documentation.patch --]
[-- Type: text/plain, Size: 1867 bytes --]
Subject: [PATCH] TCP: update ip_local_port_range documentation
From: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
The explanation of ip_local_port_range in Documentation/networking/ip-sysctl.txt
contains several factual errors:
- The default value of ip_local_port_range does not depend on the amount of
memory available in the system.
- tcp_tw_recycle is not enabled by default.
- 1024-4999 is not the default value.
Fix them.
Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
---
diff -urNp linux-3.4-rc1-orig/Documentation/networking/ip-sysctl.txt linux-3.4-rc1/Documentation/networking/ip-sysctl.txt
--- linux-3.4-rc1-orig/Documentation/networking/ip-sysctl.txt 2012-03-19 08:15:34.000000000 +0900
+++ linux-3.4-rc1/Documentation/networking/ip-sysctl.txt 2012-04-03 07:42:56.793550547 +0900
@@ -604,15 +604,12 @@ IP Variables:
ip_local_port_range - 2 INTEGERS
Defines the local port range that is used by TCP and UDP to
choose the local port. The first number is the first, the
- second the last local port number. Default value depends on
- amount of memory available on the system:
- > 128Mb 32768-61000
- < 128Mb 1024-4999 or even less.
- This number defines number of active connections, which this
- system can issue simultaneously to systems not supporting
- TCP extensions (timestamps). With tcp_tw_recycle enabled
- (i.e. by default) range 1024-4999 is enough to issue up to
- 2000 connections per second to systems supporting timestamps.
+ second the last local port number. The default values are
+ 32768 and 61000 respectively.
+
+ These two numbers determine the number of active connections
+ which this system can issue simultaneously to systems not
+ supporting TCP extensions (timestamps).
ip_local_reserved_ports - list of comma separated ranges
Specify the ports which are reserved for known third-party
^ permalink raw reply
* Re: [PATCH] phonet: Check input from user before allocating
From: Eric Dumazet @ 2012-04-03 1:53 UTC (permalink / raw)
To: David Miller
Cc: remi, levinsasha928, remi.denis-courmont, davej, netdev,
linux-kernel
In-Reply-To: <20120402.174006.70116829696492189.davem@davemloft.net>
On Mon, 2012-04-02 at 17:40 -0400, David Miller wrote:
> From: "Rémi Denis-Courmont" <remi@remlab.net>
> Date: Mon, 2 Apr 2012 22:01:40 +0300
>
> > Le lundi 2 avril 2012 23:31:00 Sasha Levin, vous avez écrit :
> >> A phonet packet is limited to USHRT_MAX bytes, this is never checked during
> >> tx which means that the user can specify any size he wishes, and the kernel
> >> will attempt to allocate that size.
> >
> > Does this really solve the problem? I guess 128kb is still possible with
> > USHRT_MAX plus skbuff overhead, which might still trigger OOM relatively
> > easily once the memory gets sufficiently fragmented.
> >
> > How does UDP deal with this?
>
> UDP generates a fragment list of MTU sized SKBs.
>
> Phonet could avoid the large allocations by building page based
> SKBs.
Not that AF_UNIX does nothing in this respect, it can use order-XX pages
for large datagrams.
(I beleve I sent a patch some time ago to address this point)
^ permalink raw reply
* Re: [PATCH] phonet: Check input from user before allocating
From: David Miller @ 2012-04-03 1:59 UTC (permalink / raw)
To: eric.dumazet
Cc: remi, levinsasha928, remi.denis-courmont, davej, netdev,
linux-kernel
In-Reply-To: <1333417997.18626.1.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 03 Apr 2012 03:53:17 +0200
> Not that AF_UNIX does nothing in this respect, it can use order-XX pages
> for large datagrams.
>
> (I beleve I sent a patch some time ago to address this point)
Yes, on the datagram side it's a problem.
For stream AF_UNIX sockets the allocation is capped at SKB_MAX_ALLOC
which evaluates to an order 2 page.
Overall, AF_UNIX ought to be easy to deal with since all of the
routines that copy data between userspace and SKBs can handle
segmented SKBs and thus most of the work is converting over to
sock_alloc_send_pskb() and setting data_len how we set the normal
length of sock_alloc_skb_skb() currently.
Anyways, feel free to resubmit your patch.
^ permalink raw reply
* [RFC] net:phy:phylib: phy shares the same interrupt with mac
From: Jason Lin @ 2012-04-03 2:11 UTC (permalink / raw)
To: netdev
1) Add a new definition PHY_MAC if phy shares the same
interrupt with mac.
2) Add do_phy_workqueue(), that mac can invoke this function
in its ISR when link status changed or other conditions.
Does this seems reasonable?
---------------------------
drivers/net/phy/phy.c | 27 +++++++++++++++++++++++++++
drivers/net/phy/phy_device.c | 4 ++--
include/linux/phy.h | 3 +++
3 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 7670aac..c8009e9 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -527,6 +527,28 @@ static irqreturn_t phy_interrupt(int irq, void *phy_dat)
return IRQ_HANDLED;
}
+/*
+ * do_phy_workqueue - PHY interrupt handler used by MAC
+ * @irq: interrupt line
+ * @phydev: phy_device pointer
+ *
+ * Description: When a PHY use the same interrupt with MAC,
+ * the handler is invoked by MAC, and schedules a work task
+ * to clear the PHY's interrupt.
+ * This handler is invoked only in MAC's ISR.
+ */
+irqreturn_t do_phy_workqueue(int irq, struct phy_device *phydev) {
+
+ BUG_ON(!in_interrupt());
+
+ if (PHY_HALTED == phydev->state)
+ return IRQ_NONE;
+
+ schedule_work(&phydev->phy_queue);
+ return IRQ_HANDLED;
+}
+EXPORT_SYMBOL(do_phy_workqueue);
+
/**
* phy_enable_interrupts - Enable the interrupts from the PHY side
* @phydev: target phy_device struct
@@ -589,6 +611,11 @@ int phy_start_interrupts(struct phy_device *phydev)
INIT_WORK(&phydev->phy_queue, phy_change);
+ if (phydev->irq == PHY_MAC) {
+ err = phy_enable_interrupts(phydev);
+ return err;
+ }
+
atomic_set(&phydev->irq_disable, 0);
if (request_irq(phydev->irq, phy_interrupt,
IRQF_SHARED,
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 993c52c..1857097 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -345,7 +345,7 @@ int phy_connect_direct(struct net_device *dev,
struct phy_device *phydev,
phy_prepare_link(phydev, handler);
phy_start_machine(phydev, NULL);
- if (phydev->irq > 0)
+ if ((phydev->irq > 0) || (phydev->irq == PHY_MAC))
phy_start_interrupts(phydev);
return 0;
@@ -399,7 +399,7 @@ EXPORT_SYMBOL(phy_connect);
*/
void phy_disconnect(struct phy_device *phydev)
{
- if (phydev->irq > 0)
+ if ((phydev->irq > 0) || (phydev->irq == PHY_MAC))
phy_stop_interrupts(phydev);
phy_stop_machine(phydev);
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 7da5fa8..155822c 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -44,9 +44,11 @@
* Set phydev->irq to PHY_POLL if interrupts are not supported,
* or not desired for this PHY. Set to PHY_IGNORE_INTERRUPT if
* the attached driver handles the interrupt
+ * Set to PHY_MAC if using the same interrupt with MAC
*/
#define PHY_POLL -1
#define PHY_IGNORE_INTERRUPT -2
+#define PHY_MAC -3
#define PHY_HAS_INTERRUPT 0x00000001
#define PHY_HAS_MAGICANEG 0x00000002
@@ -510,6 +512,7 @@ int phy_ethtool_sset(struct phy_device *phydev,
struct ethtool_cmd *cmd);
int phy_ethtool_gset(struct phy_device *phydev, struct ethtool_cmd *cmd);
int phy_mii_ioctl(struct phy_device *phydev,
struct ifreq *ifr, int cmd);
+irqreturn_t do_phy_workqueue(int irq, struct phy_device *phydev);
int phy_start_interrupts(struct phy_device *phydev);
void phy_print_status(struct phy_device *phydev);
void phy_device_free(struct phy_device *phydev);
^ permalink raw reply related
* Re: [PATCH] phonet: Check input from user before allocating
From: Eric Dumazet @ 2012-04-03 2:15 UTC (permalink / raw)
To: David Miller
Cc: remi, levinsasha928, remi.denis-courmont, davej, netdev,
linux-kernel
In-Reply-To: <20120402.215911.1929019308299701014.davem@davemloft.net>
On Mon, 2012-04-02 at 21:59 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 03 Apr 2012 03:53:17 +0200
>
> > Not that AF_UNIX does nothing in this respect, it can use order-XX pages
> > for large datagrams.
> >
> > (I beleve I sent a patch some time ago to address this point)
>
> Yes, on the datagram side it's a problem.
>
> For stream AF_UNIX sockets the allocation is capped at SKB_MAX_ALLOC
> which evaluates to an order 2 page.
>
> Overall, AF_UNIX ought to be easy to deal with since all of the
> routines that copy data between userspace and SKBs can handle
> segmented SKBs and thus most of the work is converting over to
> sock_alloc_send_pskb() and setting data_len how we set the normal
> length of sock_alloc_skb_skb() currently.
>
> Anyways, feel free to resubmit your patch.
This was indeed a basic patch, but it probably can lower raw performance
on some apps, (if memory frag is not an issue) so I need to bench it.
Any idea of a representative benchmark in dgram af_unix ?
http://patchwork.ozlabs.org/patch/114103/
I'll respin it with proper performance resuts.
^ permalink raw reply
* Re: [PATCH] phonet: Check input from user before allocating
From: David Miller @ 2012-04-03 2:23 UTC (permalink / raw)
To: eric.dumazet
Cc: remi, levinsasha928, remi.denis-courmont, davej, netdev,
linux-kernel
In-Reply-To: <1333419304.18626.5.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 03 Apr 2012 04:15:04 +0200
> Any idea of a representative benchmark in dgram af_unix ?
Maybe you could try to make bw_unix from lmbench use
SOCK_DGRAM? :-)
^ permalink raw reply
* Re: [PATCH] phonet: Check input from user before allocating
From: Eric Dumazet @ 2012-04-03 2:29 UTC (permalink / raw)
To: David Miller
Cc: remi, levinsasha928, remi.denis-courmont, davej, netdev,
linux-kernel
In-Reply-To: <20120402.222300.1137842205135530387.davem@davemloft.net>
On Mon, 2012-04-02 at 22:23 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 03 Apr 2012 04:15:04 +0200
>
> > Any idea of a representative benchmark in dgram af_unix ?
>
> Maybe you could try to make bw_unix from lmbench use
> SOCK_DGRAM? :-)
>
Yes, I also converted hackbench to SOCK_DGRAM and change its DATASIZE
from 100 to 10000 bytes per message.
Thanks
^ permalink raw reply
* Re: [PATCH] phonet: Check input from user before allocating
From: Rick Jones @ 2012-04-03 2:29 UTC (permalink / raw)
To: David Miller
Cc: eric.dumazet, remi, levinsasha928, remi.denis-courmont, davej,
netdev, linux-kernel
In-Reply-To: <20120402.222300.1137842205135530387.davem@davemloft.net>
On 04/02/2012 07:23 PM, David Miller wrote:
> From: Eric Dumazet<eric.dumazet@gmail.com>
> Date: Tue, 03 Apr 2012 04:15:04 +0200
>
>> Any idea of a representative benchmark in dgram af_unix ?
>
> Maybe you could try to make bw_unix from lmbench use
> SOCK_DGRAM? :-)
I don't know it isn't entirely bitrotted, but there are streaming and
datagram AF_UNIX tests in netperf - they require conditional inclusion
via ./configure --enable-unixdomain:
http://www.netperf.org/svn/netperf2/trunk/doc/netperf.html#DG_005fSTREAM
happy benchmarking,
rick jones
^ permalink raw reply
* Re: [PATCH] phonet: Check input from user before allocating
From: Eric Dumazet @ 2012-04-03 2:34 UTC (permalink / raw)
To: Rick Jones
Cc: David Miller, remi, levinsasha928, remi.denis-courmont, davej,
netdev, linux-kernel
In-Reply-To: <4F7A60A4.5040600@hp.com>
On Mon, 2012-04-02 at 19:29 -0700, Rick Jones wrote:
> On 04/02/2012 07:23 PM, David Miller wrote:
> > From: Eric Dumazet<eric.dumazet@gmail.com>
> > Date: Tue, 03 Apr 2012 04:15:04 +0200
> >
> >> Any idea of a representative benchmark in dgram af_unix ?
> >
> > Maybe you could try to make bw_unix from lmbench use
> > SOCK_DGRAM? :-)
>
> I don't know it isn't entirely bitrotted, but there are streaming and
> datagram AF_UNIX tests in netperf - they require conditional inclusion
> via ./configure --enable-unixdomain:
>
> http://www.netperf.org/svn/netperf2/trunk/doc/netperf.html#DG_005fSTREAM
>
Ah yes of course, I'll try that.
BTW, do you have plans to support vmsplice()/splice() as a way to
provide 0-copy to TCP_STREAM ?
I ask this because I am currently working on fixing splice(pipe ->
socket) performance problem and need a standard benchmark to publish
performance results.
Thanks
^ permalink raw reply
* Re: [PATCH] phonet: Check input from user before allocating
From: Rick Jones @ 2012-04-03 2:39 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, remi, levinsasha928, remi.denis-courmont, davej,
netdev, linux-kernel
In-Reply-To: <1333420452.18626.11.camel@edumazet-glaptop>
On 04/02/2012 07:34 PM, Eric Dumazet wrote:
> On Mon, 2012-04-02 at 19:29 -0700, Rick Jones wrote:
>> I don't know it isn't entirely bitrotted, but there are streaming and
>> datagram AF_UNIX tests in netperf - they require conditional inclusion
>> via ./configure --enable-unixdomain:
>>
>> http://www.netperf.org/svn/netperf2/trunk/doc/netperf.html#DG_005fSTREAM
>>
>
> Ah yes of course, I'll try that.
>
> BTW, do you have plans to support vmsplice()/splice() as a way to
> provide 0-copy to TCP_STREAM ?
I'd probably plead "too platform specific" but I've already got some
platform-specific stuff in there like TCP_INFO so I probably cannot hide
behind that. Particularly if I ever do make "native" WSA calls for
Windows...
Until now I'd not thought of vmsplice/splice though - only sendfile for
zero copy, which should be there for TCP in the form of the TCP_SENDFILE
test (unmigrated, so none of the omni output selection is available)
> I ask this because I am currently working on fixing splice(pipe ->
> socket) performance problem and need a standard benchmark to publish
> performance results.
I'll start to ponder, without promises.
rick
^ permalink raw reply
* Re: [PATCH] phonet: Check input from user before allocating
From: Eric Dumazet @ 2012-04-03 3:14 UTC (permalink / raw)
To: Rick Jones
Cc: David Miller, remi, levinsasha928, remi.denis-courmont, davej,
netdev, linux-kernel
In-Reply-To: <4F7A62FE.2050103@hp.com>
On Mon, 2012-04-02 at 19:39 -0700, Rick Jones wrote:
> On 04/02/2012 07:34 PM, Eric Dumazet wrote:
> > On Mon, 2012-04-02 at 19:29 -0700, Rick Jones wrote:
> >> I don't know it isn't entirely bitrotted, but there are streaming and
> >> datagram AF_UNIX tests in netperf - they require conditional inclusion
> >> via ./configure --enable-unixdomain:
> >>
> >> http://www.netperf.org/svn/netperf2/trunk/doc/netperf.html#DG_005fSTREAM
> >>
> >
> > Ah yes of course, I'll try that.
> >
It seems netperf has some problems zith AF_UNIX dgram :
socket(PF_FILE, SOCK_DGRAM, 0) = 4
setsockopt(4, SOL_SOCKET, SO_SNDBUF, [0], 4) = 0
getsockopt(4, SOL_SOCKET, SO_SNDBUF, [2048], [4]) = 0
setsockopt(4, SOL_SOCKET, SO_RCVBUF, [0], 4) = 0
getsockopt(4, SOL_SOCKET, SO_RCVBUF, [2288], [4]) = 0
sendto(3, "\0\0\0+\377\377\377\377\0\0\0\0\0\0\10\0\0\0\0\10\0\0\0\0\0\0\0\0\0\0\0\0"..., 256, 0, NULL, 0) = 256
select(1024, [3], NULL, NULL, {120, 0}) = 1 (in [3], left {119, 979635})
recvfrom(3, "\0\0\0,\0\0\0\0\0\0\10\360\0\0\10\0\0\0\0\0\0\0\0\n\0\0\0\0\0\0\0\0"..., 256, 0, NULL, NULL) = 256
connect(4, {sa_family=AF_FILE, path="/tmp/netpe62HGNM"}, 110) = 0
rt_sigaction(SIGALRM, {0x403171, [ALRM], SA_RESTORER|SA_INTERRUPT, 0x7f691f026af0}, NULL, 8) = 0
alarm(10) = 0
sendto(4, "netperf\0netperf\0netperf\0netperf\0"..., 2048, 0, NULL, 0) = -1 EMSGSIZE (Message too long)
dup(2) = 5
fcntl(5, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat(5, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 3), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f691fa18000
lseek(5, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(5, "dg_send: data send error: Messag"..., 43dg_send: data send error: Message too long
) = 43
close(5) = 0
munmap(0x7f691fa18000, 4096) = 0
exit_group(1) = ?
I guess the SO_SNDBUF/SO_RCVBUF limits are a bit too low ?
Tried this on an old kernel as well.
Linux edumazet-glaptop 2.6.38-13-generic #57~lucid1-Ubuntu SMP Tue Mar 6 20:05:46 UTC 2012 x86_64 GNU/Linux
^ permalink raw reply
* [PATCH] netfilter: xt_CT: remove a compile warning
From: Eric Dumazet @ 2012-04-03 3:48 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Pablo Neira Ayuso
If CONFIG_NF_CONNTRACK_TIMEOUT=n we have following warning :
CC [M] net/netfilter/xt_CT.o
net/netfilter/xt_CT.c: In function ‘xt_ct_tg_check_v1’:
net/netfilter/xt_CT.c:284: warning: label ‘err4’ defined but not used
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/xt_CT.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/netfilter/xt_CT.c b/net/netfilter/xt_CT.c
index 0c8e438..6d4ca2f 100644
--- a/net/netfilter/xt_CT.c
+++ b/net/netfilter/xt_CT.c
@@ -269,7 +269,9 @@ static int xt_ct_tg_check_v1(const struct xt_tgchk_param *par)
} else {
ret = -ENOENT;
pr_info("Timeout policy base is empty\n");
- goto err4;
+err4:
+ rcu_read_unlock();
+ goto err3;
}
rcu_read_unlock();
}
@@ -281,8 +283,6 @@ out:
info->ct = ct;
return 0;
-err4:
- rcu_read_unlock();
err3:
nf_conntrack_free(ct);
err2:
^ permalink raw reply related
* /proc/net/dev is funky in 3.3.0
From: Ben Greear @ 2012-04-03 4:29 UTC (permalink / raw)
To: NetDev
Not all entries are shown!
[root@lanner-i7 lanforge]# cat /proc/net/dev|grep sta59
[root@lanner-i7 lanforge]# ifconfig sta59
sta59 Link encap:Ethernet HWaddr 00:95:95:00:00:3C
inet addr:10.111.9.39 Bcast:10.111.255.255 Mask:255.255.0.0
inet6 addr: fe80::295:95ff:fe00:3c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:58103 errors:0 dropped:0 overruns:0 frame:0
TX packets:26167 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:39494634 (37.6 MiB) TX bytes:37095540 (35.3 MiB)
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 2/2] TCP: Use 32768-65535 outgoing port range by default
From: David Miller @ 2012-04-03 4:50 UTC (permalink / raw)
To: fernando; +Cc: shemminger, netdev
In-Reply-To: <20120403095018.rm7gil9xz0gsgccs@webmail.int.intellilink.co.jp>
From: fernando@intellilink.co.jp
Date: Tue, 3 Apr 2012 09:50:18 +0900
> There was a time when the ip masquerading code reserved the
> 61000-65095 port range, which is the reason why the current default
> upper limit in ip_local_port_range is 61000. However, the current
> iptables-based masquerading and SNAT implementation does not have
> that restriction; ipchains and the compatibilty mode that used the
> range over 61000 exclusively is lone gone.
I don't think so, anyone out there using "--to-port 61000-65095"
or similar in their firewall setup will suddenly break with
your change.
I'm not applying this patch.
^ permalink raw reply
* Re: [PATCH 1/2] TCP: update ip_local_port_range documentation
From: David Miller @ 2012-04-03 4:54 UTC (permalink / raw)
To: fernando; +Cc: shemminger, netdev
In-Reply-To: <20120403094840.ftxlwztl40gwcg4s@webmail.int.intellilink.co.jp>
From: fernando@intellilink.co.jp
Date: Tue, 3 Apr 2012 09:48:40 +0900
> + These two numbers determine the number of active connections
> + which this system can issue simultaneously to systems not
> + supporting TCP extensions (timestamps).
This paragraph is false altogether, it's only true if we have
one configured IP address.
I'd remove it entirely, it doesn't help anyone and just adds
confusion.
^ permalink raw reply
* Re: [PATCH 1/2] TCP: update ip_local_port_range documentation
From: fernando @ 2012-04-03 4:59 UTC (permalink / raw)
To: David Miller; +Cc: shemminger@vyatta.com, netdev@vger.kernel.org
In-Reply-To: <20120403.005428.1951197638640326467.davem@davemloft.net>
Quoting David Miller <davem@davemloft.net>:
> From: fernando@intellilink.co.jp
> Date: Tue, 3 Apr 2012 09:48:40 +0900
>
>> + These two numbers determine the number of active connections
>> + which this system can issue simultaneously to systems not
>> + supporting TCP extensions (timestamps).
>
> This paragraph is false altogether, it's only true if we have
> one configured IP address.
>
> I'd remove it entirely, it doesn't help anyone and just adds
> confusion.
I agree. I will remove that part too and resubmit.
^ permalink raw reply
* Re: [PATCH 2/2] TCP: Use 32768-65535 outgoing port range by default
From: fernando @ 2012-04-03 5:18 UTC (permalink / raw)
To: David Miller; +Cc: shemminger@vyatta.com, netdev@vger.kernel.org
In-Reply-To: <20120403.005027.988304181797945160.davem@davemloft.net>
Quoting David Miller <davem@davemloft.net>:
> From: fernando@intellilink.co.jp
> Date: Tue, 3 Apr 2012 09:50:18 +0900
>
>> There was a time when the ip masquerading code reserved the
>> 61000-65095 port range, which is the reason why the current default
>> upper limit in ip_local_port_range is 61000. However, the current
>> iptables-based masquerading and SNAT implementation does not have
>> that restriction; ipchains and the compatibilty mode that used the
>> range over 61000 exclusively is lone gone.
>
> I don't think so, anyone out there using "--to-port 61000-65095"
> or similar in their firewall setup will suddenly break with
> your change.
Yes, I considered that. The thing is that certain non-linux hosts
already use a superset of the 61000-65095 range and 61000 looks like a
magic number to most users. I just thought that anyone using --to-ports
would set ip_local_port_range accordingly. Do you want me to document
where 61000 comes from instead?
^ permalink raw reply
* Re: [PATCH ethtool] Add the command to show the time stamping capabilities.
From: Richard Cochran @ 2012-04-03 5:37 UTC (permalink / raw)
To: Ben Hutchings
Cc: e1000-devel, netdev, Martin Porter, John Ronciak, Jacob Keller,
David Miller
In-Reply-To: <1333394758.5356.28.camel@bwh-desktop.uk.solarflarecom.com>
On Mon, Apr 02, 2012 at 08:25:58PM +0100, Ben Hutchings wrote:
> On Sun, 2012-04-01 at 17:23 +0200, Richard Cochran wrote:
> > + if (info->tx_types & (1 << HWTSTAMP_TX_OFF))
> > + fprintf(stdout, "HWTSTAMP_TX_OFF\n");
> > +
> > + if (info->tx_types & (1 << HWTSTAMP_TX_ON))
> > + fprintf(stdout, "HWTSTAMP_TX_ON\n");
> > +
> > + if (info->tx_types & (1 << HWTSTAMP_TX_ONESTEP_SYNC))
> > + fprintf(stdout, "HWTSTAMP_TX_ONESTEP_SYNC\n");
>
> If there is no hardware timestamping available then shouldn't we see
> HWTSTAMP_TX_OFF reported here? But that's going to be the case. Not
> sure whether the kernel or the ethtool utility should deal with that,
> but don't assume the ethtool utility is the only consumer.
Actually, if the device does not support hardware time stamping at
all, then ioctl SIOCSHWTSTAMP returns EOPNOTSUPP. So, HWTSTAMP_TX_ON
means you can turn Tx time stamping on, and HWTSTAMP_TX_OFF means you
can turn it off again. It might not seem too logical, but that is how
the interface works.
So (tx_types == 0) means no hardware timestamping available. We can
print that as a special case, if you think it best.
> Hardware Receive Filter Modes:
> none (HWTSTAMP_FILTER_NONE)
> ptpv2-l4-event (HWTSTAMP_FILTER_PTP_V2_L4_EVENT)
> ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC)
>
> (Maybe you can think of better names.)
Okay, I get the idea.
Thanks,
Richard
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: /proc/net/dev is funky in 3.3.0
From: Eric Dumazet @ 2012-04-03 5:43 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev
In-Reply-To: <4F7A7C98.1030103@candelatech.com>
On Mon, 2012-04-02 at 21:29 -0700, Ben Greear wrote:
> Not all entries are shown!
>
> [root@lanner-i7 lanforge]# cat /proc/net/dev|grep sta59
> [root@lanner-i7 lanforge]# ifconfig sta59
> sta59 Link encap:Ethernet HWaddr 00:95:95:00:00:3C
> inet addr:10.111.9.39 Bcast:10.111.255.255 Mask:255.255.0.0
> inet6 addr: fe80::295:95ff:fe00:3c/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:58103 errors:0 dropped:0 overruns:0 frame:0
> TX packets:26167 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:39494634 (37.6 MiB) TX bytes:37095540 (35.3 MiB)
>
> Thanks,
> Ben
>
Could you post "ip link" result ?
^ permalink raw reply
* set route
From: Jean-Jacques Sarton @ 2012-04-03 5:47 UTC (permalink / raw)
To: netdev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
I think there is a little bug within the portion of code
for setting the network routing.
If I issue the following
ip li se dev x down; ip li se dev x up;\
ip ad ad 2001:db8:1:1::2/64 dev X;\
ip ro ad 2001:db8:1:1::/64 via 2001:db8:1:1::2 dev X
All id OK. If I insert a sleep 2 between set addr
and set route, I will get the error message:
RTNETLINK answers: No route to host
This seem, for me to be a BUG. The address is known
and therefore there is a route.
If the addresse for the gateway is outside, this
may make sense, but for a static route I expect
that the route is set regardless of the knowledge
of the addresse.
Do you have an explanation for the problem and if
this is a bug, will it be fixed ?
Regards,
Jean-Jacques Sarton
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAk96jvkACgkQM9JbiR3CwQskpACeMj0S6q5IYD9FhwGLOZZjWeKr
A3sAn1s99YK7aacxQ+Eiqb9MI4CaWDs+
=yLUY
-----END PGP SIGNATURE-----
^ 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