* [RFC] remove netpoll receive code
From: Stephen Hemminger @ 2007-10-17 20:21 UTC (permalink / raw)
To: David S. Miller, Andrew Morton; +Cc: netdev, linux-kernel
The netpoll receive code is:
1. Not used by any in-tree features, it is used by kgdb-over-ether.
2. A nice hook for people doing nasty things like private binary network stacks or rootkits.
3. Unsecured by any of the normal firewalling code.
Hopefully all distro's are smart enough to turn it off in their default config *nudge, nudge*.
Doubly true for any distribution that claims to be secure or enterprise ready.
I propose that we take out all the whole netpoll rx path. If/when kgdb gets submitted
a better and alternative receive path can be added.
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: multicast: bug or "feature"
From: Vlad Yasevich @ 2007-10-17 20:23 UTC (permalink / raw)
To: David Stevens; +Cc: Brian Haley, netdev
In-Reply-To: <OF5E5E93CF.68389D89-ON88257377.006E39CF-88257377.006EB529@us.ibm.com>
David Stevens wrote:
> I'm not clear on your configuration.
>
> Are the sender and receiver running on the same machine? Are
> you saying eth0 and eth1 are connected on the same link?
Yes and Yes.
I know it's a strange config, but it works with IPv6.
Here is the info off the reproducing system:
# ifconfig
eth0 Link encap:Ethernet HWaddr 00:17:08:7D:47:18
inet addr:10.202.1.23 Bcast:10.202.255.255 Mask:255.255.0.0
inet6 addr: 2001:1890:1109:a10:217:8ff:fe7d:4718/64 Scope:Global
inet6 addr: fe80::217:8ff:fe7d:4718/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1094 errors:0 dropped:0 overruns:0 frame:0
TX packets:669 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:107776 (105.2 KiB) TX bytes:109874 (107.2 KiB)
Base address:0x4000 Memory:f9de0000-f9e00000
eth1 Link encap:Ethernet HWaddr 00:18:FE:7F:49:C8
inet addr:10.202.1.26 Bcast:10.202.255.255 Mask:255.255.0.0
inet6 addr: 2001:1890:1109:a10:218:feff:fe7f:49c8/64 Scope:Global
inet6 addr: fe80::218:feff:fe7f:49c8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:479 errors:0 dropped:0 overruns:0 frame:0
TX packets:35 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:52236 (51.0 KiB) TX bytes:4467 (4.3 KiB)
Interrupt:41 Memory:f6000000-f6012100
# ip r l
10.202.0.0/16 dev eth0 proto kernel scope link src 10.202.1.23
10.202.0.0/16 dev eth1 proto kernel scope link src 10.202.1.26
default via 10.202.1.1 dev eth0
-vlad
^ permalink raw reply
* Re: [Bugme-new] [Bug 9179] New: 2.6.23.1 / USB_ZD1201: Kernel panic with zd1201 driver
From: Andrew Morton @ 2007-10-17 20:27 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo; +Cc: bugme-daemon, netdev, linux-wireless, zairasai
In-Reply-To: <bug-9179-10286@http.bugzilla.kernel.org/>
On Wed, 17 Oct 2007 11:34:57 -0700 (PDT)
bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9179
>
> Summary: 2.6.23.1 / USB_ZD1201: Kernel panic with zd1201 driver
> Product: Drivers
> Version: 2.5
> KernelVersion: 2.6.23.1
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: network-wireless
> AssignedTo: drivers_network-wireless@kernel-bugs.osdl.org
> ReportedBy: zairasai@googlemail.com
>
>
> [1.] One line summary of the problem:
>
> 2.6.23.1 / USB_ZD1201: Kernel panic with zd1201 driver
>
>
>
>
> [2.] Full description of the problem:
>
> The zd1201-driver (symbol: USB_ZD1201) triggers a kernel panic during
> initialization of the WLAN device, showing the following message:
>
> EIP: [<e095e1d1>] zd1201_usbrx+0x6e1/0xbb0 [zd1201] SS:ESP 0068:c0469d7c
> Kernel panic - not syncing: Fatal exception in interrupt
>
> According to the init output during bootup, the panic seems to occur right when
> the WLAN device receives an IP address from the DHCP-Server of the
> WLAN/DSL-Router. The WLAN device is (in my case) a 'Belkin F5D6051' based on
> the ZyDAS 1201 chip.
>
> As far as i know, the only recent change in 'drivers/net/wireless/zd1201.c' was
> done in patch-2.6.22, so the bug probably affects all kernel versions later
> than 2.6.21.7, but at least the ones i've tested (which are listed in the
> summary below). It also recently came up in some different
> distribution-specific forums/bugtrackers, so it does not seem to be specific to
> my machine/setup. A link to another report on this problem is included at the
> end of this report.
>
> Below is an extract of patch-2.6.22, showing that the lines 330 and 388 have
> been removed from 'drivers/net/wireless/zd1201.c'. I put those two lines back,
> which made things work as expected again; however, that is only meant as a
> hint, since i don't know why they were taken out or what other implications my
> change might have.
>
> patch-2.6.22, lines 586509-586528:
> {{{
> diff --git a/drivers/net/wireless/zd1201.c b/drivers/net/wireless/zd1201.c
> index 6cb66a3..935b144 100644
> --- a/drivers/net/wireless/zd1201.c
> +++ b/drivers/net/wireless/zd1201.c
> @@ -327,7 +327,6 @@ static void zd1201_usbrx(struct urb *urb)
> memcpy(skb_put(skb, 6), &data[datalen-8], 6);
> memcpy(skb_put(skb, 2), &data[datalen-24], 2);
> memcpy(skb_put(skb, len), data, len);
> - skb->dev = zd->dev;
> skb->dev->last_rx = jiffies;
> skb->protocol = eth_type_trans(skb, zd->dev);
> zd->stats.rx_packets++;
> @@ -385,7 +384,6 @@ static void zd1201_usbrx(struct urb *urb)
> memcpy(skb_put(skb, 2), &data[6], 2);
> memcpy(skb_put(skb, len), data+8, len);
> }
> - skb->dev = zd->dev;
> skb->dev->last_rx = jiffies;
> skb->protocol = eth_type_trans(skb, zd->dev);
> zd->stats.rx_packets++;
> }}}
>
Arnaldo, we have a pretty solid report here that your
4c13eb6657fe9ef7b4dc8f1a405c902e9e5234e0 made this driver go crash.
^ permalink raw reply
* [PATCH 1/2] napi_synchronize: waiting for NAPI
From: Stephen Hemminger @ 2007-10-17 20:26 UTC (permalink / raw)
To: David S. Miller, Jeff Garzik; +Cc: netdev
In-Reply-To: <20071017202640.171902388@linux-foundation.org>
[-- Attachment #1: napi-synchronize.patch --]
[-- Type: text/plain, Size: 1039 bytes --]
Some drivers with shared NAPI need a synchronization barrier.
Also suggested by Benjamin Herrenschmidt for EMAC.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
--- a/include/linux/netdevice.h 2007-10-17 08:45:32.000000000 -0700
+++ b/include/linux/netdevice.h 2007-10-17 08:47:54.000000000 -0700
@@ -407,6 +407,24 @@ static inline void napi_enable(struct na
clear_bit(NAPI_STATE_SCHED, &n->state);
}
+#ifdef CONFIG_SMP
+/**
+ * napi_synchronize - wait until NAPI is not running
+ * @n: napi context
+ *
+ * Wait until NAPI is done being scheduled on this context.
+ * Waits till any outstanding processing completes but
+ * does not disable future activations.
+ */
+static inline void napi_synchronize(const struct napi_struct *n)
+{
+ while (test_bit(NAPI_STATE_SCHED, &n->state))
+ msleep(1);
+}
+#else
+# define napi_synchronize(n) barrier()
+#endif
+
/*
* The DEVICE structure.
* Actually, this whole structure is a big mistake. It mixes I/O
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* [PATCH 2/2] sky2: shutdown cleanup
From: Stephen Hemminger @ 2007-10-17 20:26 UTC (permalink / raw)
To: David S. Miller, Jeff Garzik; +Cc: netdev
In-Reply-To: <20071017202640.171902388@linux-foundation.org>
[-- Attachment #1: sky2-shutdown-cleanup.patch --]
[-- Type: text/plain, Size: 4485 bytes --]
Solve issues with dual port devices due to shared NAPI.
* shutting down one device shouldn't kill other one.
* suspend shouldn't hang.
Also fix potential race between restart and shutdown.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
--- a/drivers/net/sky2.c 2007-10-17 10:17:56.000000000 -0700
+++ b/drivers/net/sky2.c 2007-10-17 13:12:06.000000000 -0700
@@ -1384,13 +1384,9 @@ static int sky2_up(struct net_device *de
sky2_prefetch_init(hw, txqaddr[port], sky2->tx_le_map,
TX_RING_SIZE - 1);
- napi_enable(&hw->napi);
-
err = sky2_rx_start(sky2);
- if (err) {
- napi_disable(&hw->napi);
+ if (err)
goto err_out;
- }
/* Enable interrupts from phy/mac for port */
imask = sky2_read32(hw, B0_IMSK);
@@ -1679,13 +1675,13 @@ static int sky2_down(struct net_device *
/* Stop more packets from being queued */
netif_stop_queue(dev);
- napi_disable(&hw->napi);
-
/* Disable port IRQ */
imask = sky2_read32(hw, B0_IMSK);
imask &= ~portirq_msk[port];
sky2_write32(hw, B0_IMSK, imask);
+ synchronize_irq(hw->pdev->irq);
+
sky2_gmac_reset(hw, port);
/* Stop transmitter */
@@ -1699,6 +1695,9 @@ static int sky2_down(struct net_device *
ctrl &= ~(GM_GPCR_TX_ENA | GM_GPCR_RX_ENA);
gma_write16(hw, port, GM_GP_CTRL, ctrl);
+ /* Make sure no packets are pending */
+ napi_synchronize(&hw->napi);
+
sky2_write8(hw, SK_REG(port, GPHY_CTRL), GPC_RST_SET);
/* Workaround shared GMAC reset */
@@ -1736,8 +1735,6 @@ static int sky2_down(struct net_device *
/* turn off LED's */
sky2_write16(hw, B0_Y2LED, LED_STAT_OFF);
- synchronize_irq(hw->pdev->irq);
-
sky2_tx_clean(dev);
sky2_rx_clean(sky2);
@@ -2048,9 +2045,6 @@ static int sky2_change_mtu(struct net_de
err = sky2_rx_start(sky2);
sky2_write32(hw, B0_IMSK, imask);
- /* Unconditionally re-enable NAPI because even if we
- * call dev_close() that will do a napi_disable().
- */
napi_enable(&hw->napi);
if (err)
@@ -2915,6 +2909,7 @@ static void sky2_restart(struct work_str
rtnl_lock();
sky2_write32(hw, B0_IMSK, 0);
sky2_read32(hw, B0_IMSK);
+ napi_disable(&hw->napi);
for (i = 0; i < hw->ports; i++) {
dev = hw->dev[i];
@@ -2924,6 +2919,7 @@ static void sky2_restart(struct work_str
sky2_reset(hw);
sky2_write32(hw, B0_IMSK, Y2_IS_BASE);
+ napi_enable(&hw->napi);
for (i = 0; i < hw->ports; i++) {
dev = hw->dev[i];
@@ -4191,7 +4187,6 @@ static int __devinit sky2_probe(struct p
err = -ENOMEM;
goto err_out_free_pci;
}
- netif_napi_add(dev, &hw->napi, sky2_poll, NAPI_WEIGHT);
if (!disable_msi && pci_enable_msi(pdev) == 0) {
err = sky2_test_msi(hw);
@@ -4207,6 +4202,8 @@ static int __devinit sky2_probe(struct p
goto err_out_free_netdev;
}
+ netif_napi_add(dev, &hw->napi, sky2_poll, NAPI_WEIGHT);
+
err = request_irq(pdev->irq, sky2_intr,
(hw->flags & SKY2_HW_USE_MSI) ? 0 : IRQF_SHARED,
dev->name, hw);
@@ -4215,6 +4212,7 @@ static int __devinit sky2_probe(struct p
goto err_out_unregister;
}
sky2_write32(hw, B0_IMSK, Y2_IS_BASE);
+ napi_enable(&hw->napi);
sky2_show_addr(dev);
@@ -4265,23 +4263,18 @@ err_out:
static void __devexit sky2_remove(struct pci_dev *pdev)
{
struct sky2_hw *hw = pci_get_drvdata(pdev);
- struct net_device *dev0, *dev1;
+ int i;
if (!hw)
return;
del_timer_sync(&hw->watchdog_timer);
+ cancel_work_sync(&hw->restart_work);
- flush_scheduled_work();
+ for (i = hw->ports; i >= 0; --i)
+ unregister_netdev(hw->dev[i]);
sky2_write32(hw, B0_IMSK, 0);
- synchronize_irq(hw->pdev->irq);
-
- dev0 = hw->dev[0];
- dev1 = hw->dev[1];
- if (dev1)
- unregister_netdev(dev1);
- unregister_netdev(dev0);
sky2_power_aux(hw);
@@ -4296,9 +4289,9 @@ static void __devexit sky2_remove(struct
pci_release_regions(pdev);
pci_disable_device(pdev);
- if (dev1)
- free_netdev(dev1);
- free_netdev(dev0);
+ for (i = hw->ports; i >= 0; --i)
+ free_netdev(hw->dev[i]);
+
iounmap(hw->regs);
kfree(hw);
@@ -4328,6 +4321,7 @@ static int sky2_suspend(struct pci_dev *
}
sky2_write32(hw, B0_IMSK, 0);
+ napi_disable(&hw->napi);
sky2_power_aux(hw);
pci_save_state(pdev);
@@ -4362,8 +4356,8 @@ static int sky2_resume(struct pci_dev *p
pci_write_config_dword(pdev, PCI_DEV_REG3, 0);
sky2_reset(hw);
-
sky2_write32(hw, B0_IMSK, Y2_IS_BASE);
+ napi_enable(&hw->napi);
for (i = 0; i < hw->ports; i++) {
struct net_device *dev = hw->dev[i];
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: multicast: bug or "feature"
From: David Stevens @ 2007-10-17 20:29 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: Brian Haley, netdev
In-Reply-To: <47166F2B.5010706@hp.com>
Can you send the contents of /proc/net/igmp and the packet trace,
also? And the code?
+-DLS
^ permalink raw reply
* Re: [RFC] remove netpoll receive code
From: Andrew Morton @ 2007-10-17 20:41 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, netdev, linux-kernel, Jason Wessel
In-Reply-To: <20071017132131.1992bedd@freepuppy.rosehill>
On Wed, 17 Oct 2007 13:21:31 -0700
Stephen Hemminger <shemminger@linux-foundation.org> wrote:
> The netpoll receive code is:
> 1. Not used by any in-tree features, it is used by kgdb-over-ether.
> 2. A nice hook for people doing nasty things like private binary network stacks or rootkits.
> 3. Unsecured by any of the normal firewalling code.
>
> Hopefully all distro's are smart enough to turn it off in their default config *nudge, nudge*.
> Doubly true for any distribution that claims to be secure or enterprise ready.
>
> I propose that we take out all the whole netpoll rx path. If/when kgdb gets submitted
> a better and alternative receive path can be added.
>
umm, let's cc the kgdb maintainer.
^ permalink raw reply
* Re: [Bugme-new] [Bug 9179] New: 2.6.23.1 / USB_ZD1201: Kernel panic with zd1201 driver
From: Dan Williams @ 2007-10-17 20:46 UTC (permalink / raw)
To: Andrew Morton
Cc: Arnaldo Carvalho de Melo,
bugme-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
zairasai-gM/Ye1E23mwN+BqQ9rBEUg
In-Reply-To: <20071017132740.eebaed9d.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
On Wed, 2007-10-17 at 13:27 -0700, Andrew Morton wrote:
> On Wed, 17 Oct 2007 11:34:57 -0700 (PDT)
> bugme-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.org wrote:
>
> > http://bugzilla.kernel.org/show_bug.cgi?id=9179
> >
> > Summary: 2.6.23.1 / USB_ZD1201: Kernel panic with zd1201 driver
> > Product: Drivers
> > Version: 2.5
> > KernelVersion: 2.6.23.1
> > Platform: All
> > OS/Version: Linux
> > Tree: Mainline
> > Status: NEW
> > Severity: normal
> > Priority: P1
> > Component: network-wireless
> > AssignedTo: drivers_network-wireless-ztI5WcYan/vQLgFONoPN62D2FQJk+8+b@public.gmane.org
> > ReportedBy: zairasai-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org
> >
> >
> > [1.] One line summary of the problem:
> >
> > 2.6.23.1 / USB_ZD1201: Kernel panic with zd1201 driver
> >
> >
> >
> >
> > [2.] Full description of the problem:
> >
> > The zd1201-driver (symbol: USB_ZD1201) triggers a kernel panic during
> > initialization of the WLAN device, showing the following message:
> >
> > EIP: [<e095e1d1>] zd1201_usbrx+0x6e1/0xbb0 [zd1201] SS:ESP 0068:c0469d7c
> > Kernel panic - not syncing: Fatal exception in interrupt
> >
> > According to the init output during bootup, the panic seems to occur right when
> > the WLAN device receives an IP address from the DHCP-Server of the
> > WLAN/DSL-Router. The WLAN device is (in my case) a 'Belkin F5D6051' based on
> > the ZyDAS 1201 chip.
> >
> > As far as i know, the only recent change in 'drivers/net/wireless/zd1201.c' was
> > done in patch-2.6.22, so the bug probably affects all kernel versions later
> > than 2.6.21.7, but at least the ones i've tested (which are listed in the
> > summary below). It also recently came up in some different
> > distribution-specific forums/bugtrackers, so it does not seem to be specific to
> > my machine/setup. A link to another report on this problem is included at the
> > end of this report.
> >
> > Below is an extract of patch-2.6.22, showing that the lines 330 and 388 have
> > been removed from 'drivers/net/wireless/zd1201.c'. I put those two lines back,
> > which made things work as expected again; however, that is only meant as a
> > hint, since i don't know why they were taken out or what other implications my
> > change might have.
> >
> > patch-2.6.22, lines 586509-586528:
> > {{{
> > diff --git a/drivers/net/wireless/zd1201.c b/drivers/net/wireless/zd1201.c
> > index 6cb66a3..935b144 100644
> > --- a/drivers/net/wireless/zd1201.c
> > +++ b/drivers/net/wireless/zd1201.c
> > @@ -327,7 +327,6 @@ static void zd1201_usbrx(struct urb *urb)
> > memcpy(skb_put(skb, 6), &data[datalen-8], 6);
> > memcpy(skb_put(skb, 2), &data[datalen-24], 2);
> > memcpy(skb_put(skb, len), data, len);
> > - skb->dev = zd->dev;
> > skb->dev->last_rx = jiffies;
> > skb->protocol = eth_type_trans(skb, zd->dev);
> > zd->stats.rx_packets++;
> > @@ -385,7 +384,6 @@ static void zd1201_usbrx(struct urb *urb)
> > memcpy(skb_put(skb, 2), &data[6], 2);
> > memcpy(skb_put(skb, len), data+8, len);
> > }
> > - skb->dev = zd->dev;
> > skb->dev->last_rx = jiffies;
> > skb->protocol = eth_type_trans(skb, zd->dev);
> > zd->stats.rx_packets++;
> > }}}
> >
>
> Arnaldo, we have a pretty solid report here that your
> 4c13eb6657fe9ef7b4dc8f1a405c902e9e5234e0 made this driver go crash.
In 2.6.22 and later, eth_type_trans() sets skb->dev. It looks like the
lines tha tset last_rx in the patch above should be moved below the
eth_type_trans() lines, otherwise they'll likely oops.
Something like this is probably in order?
diff --git a/drivers/net/wireless/zd1201.c b/drivers/net/wireless/zd1201.c
index 6cb66a3..935b144 100644
--- a/drivers/net/wireless/zd1201.c
+++ b/drivers/net/wireless/zd1201.c
@@ -327,7 +327,6 @@ static void zd1201_usbrx(struct urb *urb)
memcpy(skb_put(skb, 6), &data[datalen-8], 6);
memcpy(skb_put(skb, 2), &data[datalen-24], 2);
memcpy(skb_put(skb, len), data, len);
- skb->dev = zd->dev;
- skb->dev->last_rx = jiffies;
skb->protocol = eth_type_trans(skb, zd->dev);
+ skb->dev->last_rx = jiffies;
zd->stats.rx_packets++;
@@ -385,7 +384,6 @@ static void zd1201_usbrx(struct urb *urb)
memcpy(skb_put(skb, 2), &data[6], 2);
memcpy(skb_put(skb, len), data+8, len);
}
- skb->dev = zd->dev;
- skb->dev->last_rx = jiffies;
skb->protocol = eth_type_trans(skb, zd->dev);
+ skb->dev->last_rx = jiffies;
zd->stats.rx_packets++;
Dan
^ permalink raw reply related
* Re: stateless 1:1 NAT
From: Florin Andrei @ 2007-10-17 21:03 UTC (permalink / raw)
To: netdev
In-Reply-To: <4716661B.3020301@trash.net>
Patrick McHardy wrote:
>
> And Linux 2.6.23? :)
Alright, I get it. :-) Building kernel 2.6.23.1 as we speak.
--
Florin Andrei
http://florin.myip.org/
^ permalink raw reply
* TCP port randomization
From: Krzysztof Oledzki @ 2007-10-17 21:15 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1251 bytes --]
Hello,
Is it normal that TCP port randomization (tested with 2.6.22) works only
when explicitly binding to a IP address:
--- cut here ---
root@fw1:~# nc 192.168.129.28 11
(UNKNOWN) [192.168.129.28] 11 (systat) : Connection refused
root@fw1:~# nc 192.168.129.28 11
(UNKNOWN) [192.168.129.28] 11 (systat) : Connection refused
root@fw1:~# nc 192.168.129.28 11
(UNKNOWN) [192.168.129.28] 11 (systat) : Connection refused
23:11:11.896126 IP 192.168.129.2.37839 > 192.168.129.28.11: S
23:11:12.146573 IP 192.168.129.2.37840 > 192.168.129.28.11: S
23:11:12.396488 IP 192.168.129.2.37841 > 192.168.129.28.11: S
--- cut here ---
--- cut here ---
root@fw1:~# nc -s 192.168.129.2 192.168.129.28 11
(UNKNOWN) [192.168.129.28] 11 (systat) : Connection refused
root@fw1:~# nc -s 192.168.129.2 192.168.129.28 11
(UNKNOWN) [192.168.129.28] 11 (systat) : Connection refused
root@fw1:~# nc -s 192.168.129.2 192.168.129.28 11
(UNKNOWN) [192.168.129.28] 11 (systat) : Connection refused
23:11:31.704391 IP 192.168.129.2.57204 > 192.168.129.28.11: S
23:11:34.400048 IP 192.168.129.2.14512 > 192.168.129.28.11: S
23:11:34.606707 IP 192.168.129.2.20117 > 192.168.129.28.11: S
--- cut here ---
Best regards,
Krzysztof Olędzki
^ permalink raw reply
* Re: bizarre network timing problem
From: Chuck Ebbert @ 2007-10-17 21:17 UTC (permalink / raw)
To: Felix von Leitner; +Cc: linux-kernel, Netdev
In-Reply-To: <20071017205127.GA21334@codeblau.de>
On 10/17/2007 04:51 PM, Felix von Leitner wrote:
> I wrote a small read-only SMB server, and wanted to see how fast it was.
> So I used smbget to download a moderately large file from it via localhost.
> smbget only got ~70 KB/sec.
>
> This is what the view from strace -tt on the server is:
>
> 22:44:58.812467 read(8, "\0\0\0007\377SMB.\0\0\0\0\10\1\310\0\0\0\0\0\0\0\0\0\0\0\0\0\0\232\3"..., 8192) = 59
> 22:44:58.812619 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b46b8e5e000
> 22:44:58.812729 fcntl(9, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE)
> 22:44:58.812847 epoll_ctl(7, EPOLL_CTL_DEL, 8, {0, {u32=8, u64=13323248792850399240}}) = 0
> 22:44:58.812946 epoll_ctl(7, EPOLL_CTL_ADD, 8, {EPOLLOUT, {u32=8, u64=18251433459580936}}) = 0
> 22:44:58.813039 epoll_wait(7, {{EPOLLOUT, {u32=8, u64=18251433459580936}}}, 100, 442) = 1
> 22:44:58.813132 setsockopt(8, SOL_TCP, TCP_CORK, [1], 4) = 0
> 22:44:58.813215 write(8, "\0\0\372<\377SMB.\0\0\0\0\200A\300\0\0\0\0\0\0\0\0\0\0\0\0\0\0\232\3"..., 64) = 64
> 22:44:58.813323 sendfile(8, 9, [128000], 64000) = 64000
> 22:44:58.813430 setsockopt(8, SOL_TCP, TCP_CORK, [0], 4) = 0
> 22:44:58.813511 munmap(0x2b46b8e5e000, 8192) = 0
> 22:44:58.813600 epoll_wait(7, {{EPOLLOUT, {u32=8, u64=18251433459580936}}}, 100, 442) = 1
> 22:44:58.813693 epoll_ctl(7, EPOLL_CTL_DEL, 8, {0, {u32=8, u64=8}}) = 0
> 22:44:58.813778 epoll_ctl(7, EPOLL_CTL_ADD, 8, {EPOLLIN, {u32=8, u64=18252000395264008}}) = 0
> 22:44:58.813869 epoll_wait(7, {}, 100, 441) = 0
> 22:44:59.255789 epoll_wait(7, {{EPOLLIN, {u32=8, u64=18252000395264008}}}, 100, 999) = 1
> 22:44:59.688519 read(8, "\0\0\0007\377SMB.\0\0\0\0\10\1\310\0\0\0\0\0\0\0\0\0\0\0\0\0\0\232\3"..., 8192) = 59
>
>
> As you can see, the time difference between reading the query and writing the
> result is very small, but there is a big delay before receiving the next request.
>
> This is the view from a sniffer on the lo interface:
>
> 1192653899.688385 127.0.0.1 -> 127.0.0.1 SMB Read AndX Request, FID: 0x0001, 64000 bytes at offset 192000
> 1192653899.688399 127.0.0.1 -> 127.0.0.1 TCP 445 > 42990 [ACK] Seq=192660 Ack=779 Win=33920 Len=0 TSV=359208 TSER=359208
> 1192653899.895725 127.0.0.1 -> 127.0.0.1 SMB [TCP Window Full] Read AndX Response, FID: 0x0001, 64000 bytes
> 1192653899.895793 127.0.0.1 -> 127.0.0.1 TCP 42990 > 445 [ACK] Seq=779 Ack=204948 Win=12288 Len=0 TSV=359260 TSER=359260
> 1192653899.895805 127.0.0.1 -> 127.0.0.1 NBSS NBSS Continuation Message
> 1192653899.935725 127.0.0.1 -> 127.0.0.1 TCP 42990 > 445 [ACK] Seq=779 Ack=209044 Win=12288 Len=0 TSV=359270 TSER=359260
> 1192653900.147739 127.0.0.1 -> 127.0.0.1 NBSS [TCP Window Full] NBSS Continuation Message
> 1192653900.147767 127.0.0.1 -> 127.0.0.1 TCP [TCP ZeroWindow] 42990 > 445 [ACK] Seq=779 Ack=221332 Win=0 Len=0 TSV=359323 TSER=359323
> 1192653900.147807 127.0.0.1 -> 127.0.0.1 TCP [TCP Window Update] 42990 > 445 [ACK] Seq=779 Ack=221332 Win=12288 Len=0 TSV=359323 TSER=359323
> 1192653900.147815 127.0.0.1 -> 127.0.0.1 NBSS NBSS Continuation Message
> 1192653900.147837 127.0.0.1 -> 127.0.0.1 TCP 42990 > 445 [ACK] Seq=779 Ack=225428 Win=12288 Len=0 TSV=359323 TSER=359323
> 1192653900.355754 127.0.0.1 -> 127.0.0.1 NBSS [TCP Window Full] NBSS Continuation Message
> 1192653900.355782 127.0.0.1 -> 127.0.0.1 TCP [TCP ZeroWindow] 42990 > 445 [ACK] Seq=779 Ack=237716 Win=0 Len=0 TSV=359375 TSER=359375
> 1192653900.355820 127.0.0.1 -> 127.0.0.1 TCP [TCP Window Update] 42990 > 445 [ACK] Seq=779 Ack=237716 Win=12288 Len=0 TSV=359375 TSER=359375
> 1192653900.355829 127.0.0.1 -> 127.0.0.1 NBSS NBSS Continuation Message
> 1192653900.355849 127.0.0.1 -> 127.0.0.1 TCP 42990 > 445 [ACK] Seq=779 Ack=241812 Win=12288 Len=0 TSV=359375 TSER=359375
> 1192653900.563766 127.0.0.1 -> 127.0.0.1 NBSS [TCP Window Full] NBSS Continuation Message
> 1192653900.563794 127.0.0.1 -> 127.0.0.1 TCP [TCP ZeroWindow] 42990 > 445 [ACK] Seq=779 Ack=254100 Win=0 Len=0 TSV=359427 TSER=359427
> 1192653900.563831 127.0.0.1 -> 127.0.0.1 TCP [TCP Window Update] 42990 > 445 [ACK] Seq=779 Ack=254100 Win=12288 Len=0 TSV=359427 TSER=359427
> 1192653900.563839 127.0.0.1 -> 127.0.0.1 NBSS NBSS Continuation Message
> 1192653900.563858 127.0.0.1 -> 127.0.0.1 TCP 42990 > 445 [ACK] Seq=779 Ack=256724 Win=12288 Len=0 TSV=359427 TSER=359427
> 1192653900.564444 127.0.0.1 -> 127.0.0.1 SMB Read AndX Request, FID: 0x0001, 64000 bytes at offset 256000
>
>
> Note the delay between sending the response and getting the reply.
> Also note that there is almost no delay between getting the reply and sending
> the next request.
>
> My understanding of TCP_CORK from the tcp(7) man page is that it should flush
> out the data immediately, but the network trace seems to suggest that there is
> a 200 ms delay between the request and the outgoing data. tcp(7) says there is
> a 200 ms delay for sending out data when the socket is in corked mode, so
> uncorking does not appear to work.
>
>
> Now for the strange part: the same code works without a 200 ms delay
> over ethernet. The delay only appears on the loopback interface.
>
> Also, on my home desktop, which is also running 2.6.22, there is no
> delay even on loopback.
>
> I tried 2.6.23 on my notebook, but the effect is the same.
>
> Any ideas what could cause this?
>
(cc: netdev)
^ permalink raw reply
* Re: multicast: bug or "feature"
From: Vlad Yasevich @ 2007-10-17 21:25 UTC (permalink / raw)
To: David Stevens; +Cc: Brian Haley, netdev
In-Reply-To: <OF8C1D2DD7.B02D8047-ON88257377.00705A00-88257377.00707296@us.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 782 bytes --]
David Stevens wrote:
> Can you send the contents of /proc/net/igmp and the packet trace,
> also? And the code?
>
> +-DLS
>
# cat /proc/net/igmp
Idx Device : Count Querier Group Users Timer Reporter
1 lo : 0 V3
010000E0 1 0:00000000 0
2 eth0 : 3 V2
010000E0 1 0:00000000 0
3 eth1 : 4 V2
030100E0 1 0:00000000 1
010000E0 1 0:00000000 0
Source attached. The trace only shows a single udp packet and you can
re-create it with the attached small apps.
-vlad
[-- Attachment #2: client.c --]
[-- Type: text/x-csrc, Size: 984 bytes --]
#include <stdio.h>
#include <string.h>
#include <netinet/in.h>
int main(int argc, char **argv)
{
struct sockaddr_storage dest;
struct sockaddr_storage src;
struct sockaddr_in *s = (struct sockaddr_in*) &src;
struct sockaddr_in *d = (struct sockaddr_in *)&dest;
int sock;
char msg[] = "Hello Multicast";
int off = 0;
memset(&dest, 0, sizeof(dest));
memset(&src, 0, sizeof(src));
if (argc < 3) {
printf("Usage: <src ip> <mcast dest>\n");
return 1;
}
d->sin_family = s->sin_family = AF_INET;
d->sin_port = htons(2000);
inet_aton(argv[1], &s->sin_addr);
inet_aton(argv[2], &d->sin_addr);
sock = socket(AF_INET, SOCK_DGRAM, 0);
if (setsockopt(sock, IPPROTO_IP, IP_MULTICAST_LOOP, &off,
sizeof(off))) {
perror("setsockopt");
return 1;
}
if (setsockopt(sock, IPPROTO_IP, IP_MULTICAST_IF, s, sizeof(*s))) {
perror("setsockopt");
return 1;
}
sendto(sock, msg, sizeof(msg), 0, (struct sockaddr *)d, sizeof(*d));
close (socket);
return 0;
}
[-- Attachment #3: server.c --]
[-- Type: text/x-csrc, Size: 852 bytes --]
#include <stdio.h>
#include <string.h>
#include <netinet/in.h>
int main(int argc, char **argv)
{
struct sockaddr_in addr;
int addr_len;
struct ip_mreq req;
int sock;
char msg[256];
memset(&addr, 0, sizeof(addr));
if (argc < 3) {
printf("Usage: <interface ip> <mcast group>\n");
return 1;
}
sock = socket(AF_INET, SOCK_DGRAM, 0);
addr.sin_family = AF_INET;
addr.sin_port = htons(2000);
if (bind(sock, (struct sockaddr *)&addr, sizeof(addr))) {
perror("bind");
return 1;
}
inet_aton(argv[1], &req.imr_interface);
inet_aton(argv[2], &req.imr_multiaddr);
if (setsockopt(sock, IPPROTO_IP, IP_ADD_MEMBERSHIP, &req,
sizeof(req))) {
perror("setsockopt");
return 1;
}
recvfrom(sock, msg, sizeof(msg), 0, (struct sockaddr *)&addr, &addr_len);
printf("Message recieved: %s", msg);
close (socket);
return 0;
}
^ permalink raw reply
* [PATCH] zd1201: avoid null ptr access of skb->dev
From: John W. Linville @ 2007-10-17 21:10 UTC (permalink / raw)
To: Andrew Morton
Cc: Arnaldo Carvalho de Melo, netdev, linux-wireless, zairasai,
John W. Linville
In-Reply-To: <20071017132740.eebaed9d.akpm@linux-foundation.org>
skb->dev is not set until eth_type_trans is called...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/zd1201.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/zd1201.c b/drivers/net/wireless/zd1201.c
index 935b144..d5c0c66 100644
--- a/drivers/net/wireless/zd1201.c
+++ b/drivers/net/wireless/zd1201.c
@@ -327,8 +327,8 @@ static void zd1201_usbrx(struct urb *urb)
memcpy(skb_put(skb, 6), &data[datalen-8], 6);
memcpy(skb_put(skb, 2), &data[datalen-24], 2);
memcpy(skb_put(skb, len), data, len);
- skb->dev->last_rx = jiffies;
skb->protocol = eth_type_trans(skb, zd->dev);
+ skb->dev->last_rx = jiffies;
zd->stats.rx_packets++;
zd->stats.rx_bytes += skb->len;
netif_rx(skb);
@@ -384,8 +384,8 @@ static void zd1201_usbrx(struct urb *urb)
memcpy(skb_put(skb, 2), &data[6], 2);
memcpy(skb_put(skb, len), data+8, len);
}
- skb->dev->last_rx = jiffies;
skb->protocol = eth_type_trans(skb, zd->dev);
+ skb->dev->last_rx = jiffies;
zd->stats.rx_packets++;
zd->stats.rx_bytes += skb->len;
netif_rx(skb);
--
1.5.2.4
^ permalink raw reply related
* [PATCH] pfkey: sending an SADB_GET responds with an SADB_GET
From: Charles Hardin @ 2007-10-17 21:36 UTC (permalink / raw)
To: netdev, linux-kernel
Kernel needs to respond to an SADB_GET with the same message type to conform
to the RFC 2367 Section 3.1.5
diff --git a/net/key/af_key.c b/net/key/af_key.c
index 7969f8a..fb4fee1 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -1552,7 +1552,7 @@ static int pfkey_get(struct sock *sk, struct sk_buff
*skb,
out_hdr = (struct sadb_msg *) out_skb->data;
out_hdr->sadb_msg_version = hdr->sadb_msg_version;
- out_hdr->sadb_msg_type = SADB_DUMP;
+ out_hdr->sadb_msg_type = SADB_GET;
out_hdr->sadb_msg_satype = pfkey_proto2satype(proto);
out_hdr->sadb_msg_errno = 0;
out_hdr->sadb_msg_reserved = 0;
^ permalink raw reply related
* Re: [PATCH/RFC] net: Add __napi_sycnhronize() to sync with napi poll
From: Benjamin Herrenschmidt @ 2007-10-17 21:52 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, Roland Dreier, David S. Miller, Jeff Garzik,
linuxppc-dev list
In-Reply-To: <20071017083107.6a1b1bd3@freepuppy.rosehill>
On Wed, 2007-10-17 at 08:31 -0700, Stephen Hemminger wrote:
> Please don't use double underscore, for this function name. There is no
> reason to not make it a normal API call.
>
> The sky2 fix I am working on will use napi_synchronize as well.
Allright. A compiler barrier in the !SMP case makes sense, but I would
still want an smp_mb() before the test_bit. I think it's a bug in
synchronize_irq not to have it.
Cheers,
Ben.
> --- a/include/linux/netdevice.h 2007-10-16 16:48:20.000000000 -0700
> +++ b/include/linux/netdevice.h 2007-10-17 08:29:55.000000000 -0700
> @@ -407,6 +407,24 @@ static inline void napi_enable(struct na
> clear_bit(NAPI_STATE_SCHED, &n->state);
> }
>
> +#ifdef CONFIG_SMP
> +/**
> + * napi_synchronize - wait until NAPI is not running
> + * @n: napi context
> + *
> + * Wait until NAPI is done being scheduled on this context.
> + * Any outstanding processing completes but
> + * does not disable future activations.
> + */
> +static inline void napi_synchronize(const struct napi_struct *n)
> +{
> + while (test_bit(NAPI_STATE_SCHED, &n->state))
> + msleep(1);
> +}
> +#else
> +# define napi_synchronize(n) barrier()
> +#endif
> +
> /*
> * The DEVICE structure.
> * Actually, this whole structure is a big mistake. It mixes I/O
^ permalink raw reply
* Re: bizarre network timing problem
From: Felix von Leitner @ 2007-10-17 22:00 UTC (permalink / raw)
To: Chuck Ebbert; +Cc: linux-kernel, Netdev
In-Reply-To: <47167BDE.4000103@redhat.com>
Thus spake Chuck Ebbert (cebbert@redhat.com):
> > Any ideas what could cause this?
> (cc: netdev)
Maybe I should mention this, too:
accept(5, {sa_family=AF_INET6, sin6_port=htons(59821), inet_pton(AF_INET6, "::ffff:127.0.0.1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [18446744069414584348]) = 8
setsockopt(8, SOL_TCP, TCP_NODELAY, [1], 4) = 0
And if it would be the Nagle algorithm, it should also impact the
ethernet case.
Felix
^ permalink raw reply
* [PATCH] net: Add napi_sycnhronize() to sync with napi poll
From: Benjamin Herrenschmidt @ 2007-10-17 22:04 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Jeff Garzik, netdev, David S. Miller, Roland Dreier,
linuxppc-dev list
In-Reply-To: <20071017083107.6a1b1bd3@freepuppy.rosehill>
net: Add __napi_synchronize() to sync with napi poll
The EMAC driver which needs to handle multiple devices with one
NAPI instance implements its own per-channel disable bit. However,
when setting such a bit, it needs to synchronize with the poller
(that is make sure that any pending poller instance has completed,
or is started late enough to see that disable bit).
This implements a low level __napi_synchronize() function to acheive
that. The underscores are to emphasis the low level aspect of it and
to discourage driver writers who don't know what they are doing to
use it (to please DaveM :-)
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Back to msleep() since it fits my need well and that's what
you used as well. Note that the smp_mb() will turn into barrier()
on non-SMP.
I'll send a separate patch to fix EMAC to use the non __ version.
Index: linux-work/include/linux/netdevice.h
===================================================================
--- linux-work.orig/include/linux/netdevice.h 2007-10-17 13:31:32.000000000 +1000
+++ linux-work/include/linux/netdevice.h 2007-10-18 08:01:05.000000000 +1000
@@ -394,6 +394,23 @@ static inline void napi_disable(struct n
}
/**
+ * napi_synchronize - synchronize with a concurrent poll
+ * @n: napi context
+ *
+ * Synchronizes with a concurrent poll. Not to be used in normal
+ * drivers, mostly useful if you end up with multiple interfaces
+ * on one NAPI instance. This must be called from task context.
+ */
+static inline void napi_synchronize(struct napi_struct *n)
+{
+ smp_mb();
+#ifdef CONFIG_SMP
+ while (test_bit(NAPI_STATE_SCHED, &n->state))
+ msleep(1);
+#endif /* CONFIG_SMP */
+}
+
+/**
* napi_enable - enable NAPI scheduling
* @n: napi context
*
^ permalink raw reply
* Re: TCP port randomization
From: Stephen Hemminger @ 2007-10-17 22:08 UTC (permalink / raw)
To: Krzysztof Oledzki; +Cc: netdev
In-Reply-To: <Pine.LNX.4.64.0710172308140.12701@bizon.gios.gov.pl>
On Wed, 17 Oct 2007 23:15:48 +0200 (CEST)
Krzysztof Oledzki <olel@ans.pl> wrote:
> Hello,
>
> Is it normal that TCP port randomization (tested with 2.6.22) works only
> when explicitly binding to a IP address:
>
>
> --- cut here ---
> root@fw1:~# nc 192.168.129.28 11
> (UNKNOWN) [192.168.129.28] 11 (systat) : Connection refused
> root@fw1:~# nc 192.168.129.28 11
> (UNKNOWN) [192.168.129.28] 11 (systat) : Connection refused
> root@fw1:~# nc 192.168.129.28 11
> (UNKNOWN) [192.168.129.28] 11 (systat) : Connection refused
>
> 23:11:11.896126 IP 192.168.129.2.37839 > 192.168.129.28.11: S
> 23:11:12.146573 IP 192.168.129.2.37840 > 192.168.129.28.11: S
> 23:11:12.396488 IP 192.168.129.2.37841 > 192.168.129.28.11: S
> --- cut here ---
>
>
> --- cut here ---
> root@fw1:~# nc -s 192.168.129.2 192.168.129.28 11
> (UNKNOWN) [192.168.129.28] 11 (systat) : Connection refused
> root@fw1:~# nc -s 192.168.129.2 192.168.129.28 11
> (UNKNOWN) [192.168.129.28] 11 (systat) : Connection refused
> root@fw1:~# nc -s 192.168.129.2 192.168.129.28 11
> (UNKNOWN) [192.168.129.28] 11 (systat) : Connection refused
>
> 23:11:31.704391 IP 192.168.129.2.57204 > 192.168.129.28.11: S
> 23:11:34.400048 IP 192.168.129.2.14512 > 192.168.129.28.11: S
> 23:11:34.606707 IP 192.168.129.2.20117 > 192.168.129.28.11: S
> --- cut here ---
>
> Best regards,
>
> Krzysztof Olędzki
It is a expected side effect. The starting point for the search
is based on hash(srcaddr, dstaddr, dstport, secret).
You are using same source, dest and port so yes it will stay
the same until rekeying occurs.
The secret only changes every 5min same as TCP initial sequence number.
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: bizarre network timing problem
From: Rick Jones @ 2007-10-17 22:16 UTC (permalink / raw)
To: Felix von Leitner; +Cc: Chuck Ebbert, linux-kernel, Netdev
In-Reply-To: <20071017220019.GA22765@codeblau.de>
the packet trace was a bit too cooked perhaps, but there were indications that
at times the TCP window was going to zero - perhaps something with window
updates or persist timers?
rick jones
^ permalink raw reply
* Re: TCP port randomization
From: Krzysztof Oledzki @ 2007-10-17 22:31 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20071017150818.0e878846@freepuppy.rosehill>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2073 bytes --]
On Wed, 17 Oct 2007, Stephen Hemminger wrote:
> On Wed, 17 Oct 2007 23:15:48 +0200 (CEST)
> Krzysztof Oledzki <olel@ans.pl> wrote:
>
>> Hello,
>>
>> Is it normal that TCP port randomization (tested with 2.6.22) works only
>> when explicitly binding to a IP address:
>>
>>
>> --- cut here ---
>> root@fw1:~# nc 192.168.129.28 11
>> (UNKNOWN) [192.168.129.28] 11 (systat) : Connection refused
>> root@fw1:~# nc 192.168.129.28 11
>> (UNKNOWN) [192.168.129.28] 11 (systat) : Connection refused
>> root@fw1:~# nc 192.168.129.28 11
>> (UNKNOWN) [192.168.129.28] 11 (systat) : Connection refused
>>
>> 23:11:11.896126 IP 192.168.129.2.37839 > 192.168.129.28.11: S
>> 23:11:12.146573 IP 192.168.129.2.37840 > 192.168.129.28.11: S
>> 23:11:12.396488 IP 192.168.129.2.37841 > 192.168.129.28.11: S
>> --- cut here ---
>>
>>
>> --- cut here ---
>> root@fw1:~# nc -s 192.168.129.2 192.168.129.28 11
>> (UNKNOWN) [192.168.129.28] 11 (systat) : Connection refused
>> root@fw1:~# nc -s 192.168.129.2 192.168.129.28 11
>> (UNKNOWN) [192.168.129.28] 11 (systat) : Connection refused
>> root@fw1:~# nc -s 192.168.129.2 192.168.129.28 11
>> (UNKNOWN) [192.168.129.28] 11 (systat) : Connection refused
>>
>> 23:11:31.704391 IP 192.168.129.2.57204 > 192.168.129.28.11: S
>> 23:11:34.400048 IP 192.168.129.2.14512 > 192.168.129.28.11: S
>> 23:11:34.606707 IP 192.168.129.2.20117 > 192.168.129.28.11: S
>> --- cut here ---
>>
>> Best regards,
>>
>> Krzysztof Olędzki
>
> It is a expected side effect.
So it is not possible to use randomization without binding to a specific
srcip?
> The starting point for the search
> is based on hash(srcaddr, dstaddr, dstport, secret).
> You are using same source, dest and port so yes it will stay
> the same until rekeying occurs.
> The secret only changes every 5min same as TCP initial sequence number.
If I get it right, even with explicitly selected constant srcaddr port
numbers should simply increase? This is not what I observed.
Thanks.
Best regards,
Krzysztof Olędzki
^ permalink raw reply
* Re: TCP port randomization
From: Stephen Hemminger @ 2007-10-17 22:34 UTC (permalink / raw)
To: Krzysztof Oledzki; +Cc: netdev
In-Reply-To: <Pine.LNX.4.64.0710180026020.12701@bizon.gios.gov.pl>
On Thu, 18 Oct 2007 00:31:13 +0200 (CEST)
Krzysztof Oledzki <olel@ans.pl> wrote:
>
>
> On Wed, 17 Oct 2007, Stephen Hemminger wrote:
>
> > On Wed, 17 Oct 2007 23:15:48 +0200 (CEST)
> > Krzysztof Oledzki <olel@ans.pl> wrote:
> >
> >> Hello,
> >>
> >> Is it normal that TCP port randomization (tested with 2.6.22) works only
> >> when explicitly binding to a IP address:
> >>
> >>
> >> --- cut here ---
> >> root@fw1:~# nc 192.168.129.28 11
> >> (UNKNOWN) [192.168.129.28] 11 (systat) : Connection refused
> >> root@fw1:~# nc 192.168.129.28 11
> >> (UNKNOWN) [192.168.129.28] 11 (systat) : Connection refused
> >> root@fw1:~# nc 192.168.129.28 11
> >> (UNKNOWN) [192.168.129.28] 11 (systat) : Connection refused
> >>
> >> 23:11:11.896126 IP 192.168.129.2.37839 > 192.168.129.28.11: S
> >> 23:11:12.146573 IP 192.168.129.2.37840 > 192.168.129.28.11: S
> >> 23:11:12.396488 IP 192.168.129.2.37841 > 192.168.129.28.11: S
> >> --- cut here ---
> >>
> >>
> >> --- cut here ---
> >> root@fw1:~# nc -s 192.168.129.2 192.168.129.28 11
> >> (UNKNOWN) [192.168.129.28] 11 (systat) : Connection refused
> >> root@fw1:~# nc -s 192.168.129.2 192.168.129.28 11
> >> (UNKNOWN) [192.168.129.28] 11 (systat) : Connection refused
> >> root@fw1:~# nc -s 192.168.129.2 192.168.129.28 11
> >> (UNKNOWN) [192.168.129.28] 11 (systat) : Connection refused
> >>
> >> 23:11:31.704391 IP 192.168.129.2.57204 > 192.168.129.28.11: S
> >> 23:11:34.400048 IP 192.168.129.2.14512 > 192.168.129.28.11: S
> >> 23:11:34.606707 IP 192.168.129.2.20117 > 192.168.129.28.11: S
> >> --- cut here ---
> >>
> >> Best regards,
> >>
> >> Krzysztof Olędzki
> >
> > It is a expected side effect.
>
> So it is not possible to use randomization without binding to a specific
> srcip?
>
> > The starting point for the search
> > is based on hash(srcaddr, dstaddr, dstport, secret).
> > You are using same source, dest and port so yes it will stay
> > the same until rekeying occurs.
> > The secret only changes every 5min same as TCP initial sequence number.
>
> If I get it right, even with explicitly selected constant srcaddr port
> numbers should simply increase? This is not what I observed.
>
>
When you set srcaddr, it calls bind, and bind does randomization always
independent of address.
This existing behavior may seem odd, but it shouldn't present a security
problem.
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: [RFD] iptables: mangle table obsoletes filter table
From: Bill Davidsen @ 2007-10-17 22:37 UTC (permalink / raw)
To: Al Boldi
Cc: Patrick McHardy, netfilter-devel, netdev, linux-net, linux-kernel
In-Reply-To: <200710120837.18152.a1426z@gawab.com>
Al Boldi wrote:
> Patrick McHardy wrote:
>> Please send mails discussing netfilter to netfilter-devel.
>
> Ok. I just found out this changed to vger. But
> netfilter-devel@vger.kernel.org is bouncing me.
>
>> Al Boldi wrote:
>>> With the existence of the mangle table, how useful is the filter table?
>>>
>>> Other than requiring the REJECT target to be ported to the mangle table,
>>> is the filter table faster than the mangle table?
>> There are some minor differences in ordering (mangle comes before
>> DNAT, filter afterwards), but for most rulesets thats completely
>> irrelevant. The only difference that really matters is that mangle
>> performs rerouting in LOCAL_OUT for packets that had their routing
>> key changed, so its really a superset of the filter table. If you
>> want to use REJECT in the mangle table, you just need to remove the
>> restriction to filter, it works fine. I would prefer to also remove
>> the restriction of MARK, CONNMARK etc. to mangle, they're used for
>> more than just routing today so that restriction also doesn't make
>> much sense. Patches for this are welcome.
>
> Something like this (untested):
>
> --- ipt_REJECT.bak.c 2007-10-12 08:25:17.000000000 +0300
> +++ ipt_REJECT.c 2007-10-12 08:31:44.000000000 +0300
> @@ -165,6 +165,7 @@ static void send_reset(struct sk_buff *o
>
> static inline void send_unreach(struct sk_buff *skb_in, int code)
> {
> + if (!skb_in->dst) ip_route_me_harder(&skb_in, RTN_UNSPEC);
> icmp_send(skb_in, ICMP_DEST_UNREACH, code, 0);
> }
>
> @@ -245,9 +246,6 @@ static struct xt_target ipt_reject_reg =
> .family = AF_INET,
> .target = reject,
> .targetsize = sizeof(struct ipt_reject_info),
> - .table = "filter",
> - .hooks = (1 << NF_IP_LOCAL_IN) | (1 << NF_IP_FORWARD) |
> - (1 << NF_IP_LOCAL_OUT),
> .checkentry = check,
> .me = THIS_MODULE,
> };
>
>>> If not, then shouldn't the filter table be obsoleted to avoid confusion?
>> That would probably confuse people. Just don't use it if you don't
>> need to.
>
That is a most practical suggestion.
> The problem is that people think they are safe with the filter table, when in
> fact they need the prerouting chain to seal things. Right now this is only
> possible in the mangle table.
>
I'm not sure what you think is unsafe about using the filter table, and
the order of evaluation issues certainly seem to suggest that some
actions would take a major rethink at least. Perhaps you could avoid
breaking all of the setups which currently work, rather than force
everyone to do things differently because you feel that your way is better.
--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
^ permalink raw reply
* Re: [PATCH] fs_enet: Update for API changes
From: Vitaly Bordug @ 2007-10-17 22:40 UTC (permalink / raw)
To: Scott Wood; +Cc: Jeff Garzik, netdev, linuxppc-dev
In-Reply-To: <20071017174243.GA4462@loki.buserror.net>
Hello Scott,
On Wed, 17 Oct 2007 12:42:43 -0500
Scott Wood wrote:
> This driver was recently broken by several changes for which this
> driver was not (or was improperly) updated:
>
> 1. SET_MODULE_OWNER() was removed.
> 2. netif_napi_add() was only being called when building with
> the old CPM binding.
> 3. The received/budget test was backwards.
> 4. to_net_dev() was wrong -- the device struct embedded in
> the net_device struct is not the same as the of_platform
> device in the private struct.
> 5. napi_disable/napi_enable was being called even when napi
> was not being used.
>
Good cleanup, thanks!
Jeff: this is important fix, and should be applied if possible.
> These changes have been fixed, and napi is now on by default.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
Acked-by: Vitaly Bordug <vitb@kernel.crashing.org>
> ---
> drivers/net/fs_enet/fs_enet-main.c | 28 ++++++++++++++++------------
> drivers/net/fs_enet/fs_enet.h | 1 +
> 2 files changed, 17 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
> index 04c6fae..f2a4d39 100644
> --- a/drivers/net/fs_enet/fs_enet-main.c
> +++ b/drivers/net/fs_enet/fs_enet-main.c
> @@ -88,7 +88,7 @@ static void skb_align(struct sk_buff *skb, int align)
> static int fs_enet_rx_napi(struct napi_struct *napi, int budget)
> {
> struct fs_enet_private *fep = container_of(napi, struct fs_enet_private, napi);
> - struct net_device *dev = to_net_dev(fep->dev);
> + struct net_device *dev = fep->ndev;
> const struct fs_platform_info *fpi = fep->fpi;
> cbd_t __iomem *bdp;
> struct sk_buff *skb, *skbn, *skbt;
> @@ -217,7 +217,7 @@ static int fs_enet_rx_napi(struct napi_struct *napi, int budget)
>
> fep->cur_rx = bdp;
>
> - if (received >= budget) {
> + if (received < budget) {
> /* done */
> netif_rx_complete(dev, napi);
> (*fep->ops->napi_enable_rx)(dev);
> @@ -807,20 +807,23 @@ static int fs_enet_open(struct net_device *dev)
> int r;
> int err;
>
> - napi_enable(&fep->napi);
> + if (fep->fpi->use_napi)
> + napi_enable(&fep->napi);
>
> /* Install our interrupt handler. */
> r = fs_request_irq(dev, fep->interrupt, "fs_enet-mac", fs_enet_interrupt);
> if (r != 0) {
> printk(KERN_ERR DRV_MODULE_NAME
> ": %s Could not allocate FS_ENET IRQ!", dev->name);
> - napi_disable(&fep->napi);
> + if (fep->fpi->use_napi)
> + napi_disable(&fep->napi);
> return -EINVAL;
> }
>
> err = fs_init_phy(dev);
> - if(err) {
> - napi_disable(&fep->napi);
> + if (err) {
> + if (fep->fpi->use_napi)
> + napi_disable(&fep->napi);
> return err;
> }
> phy_start(fep->phydev);
> @@ -1232,7 +1235,7 @@ static int __devinit fs_enet_probe(struct of_device *ofdev,
> fpi->rx_ring = 32;
> fpi->tx_ring = 32;
> fpi->rx_copybreak = 240;
> - fpi->use_napi = 0;
> + fpi->use_napi = 1;
> fpi->napi_weight = 17;
>
> ret = find_phy(ofdev->node, fpi);
> @@ -1249,11 +1252,11 @@ static int __devinit fs_enet_probe(struct of_device *ofdev,
> goto out_free_fpi;
> }
>
> - SET_MODULE_OWNER(ndev);
> dev_set_drvdata(&ofdev->dev, ndev);
>
> fep = netdev_priv(ndev);
> fep->dev = &ofdev->dev;
> + fep->ndev = ndev;
> fep->fpi = fpi;
> fep->ops = match->data;
>
> @@ -1288,10 +1291,11 @@ static int __devinit fs_enet_probe(struct of_device *ofdev,
> ndev->stop = fs_enet_close;
> ndev->get_stats = fs_enet_get_stats;
> ndev->set_multicast_list = fs_set_multicast_list;
> - if (fpi->use_napi) {
> - ndev->poll = fs_enet_rx_napi;
> - ndev->weight = fpi->napi_weight;
> - }
> +
> + if (fpi->use_napi)
> + netif_napi_add(ndev, &fep->napi, fs_enet_rx_napi,
> + fpi->napi_weight);
> +
> ndev->ethtool_ops = &fs_ethtool_ops;
> ndev->do_ioctl = fs_ioctl;
>
> diff --git a/drivers/net/fs_enet/fs_enet.h b/drivers/net/fs_enet/fs_enet.h
> index baf6477..c675e29 100644
> --- a/drivers/net/fs_enet/fs_enet.h
> +++ b/drivers/net/fs_enet/fs_enet.h
> @@ -75,6 +75,7 @@ struct phy_info {
> struct fs_enet_private {
> struct napi_struct napi;
> struct device *dev; /* pointer back to the device (must be initialized first) */
> + struct net_device *ndev;
> spinlock_t lock; /* during all ops except TX pckt processing */
> spinlock_t tx_lock; /* during fs_start_xmit and fs_tx */
> struct fs_platform_info *fpi;
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [Bugme-new] [Bug 9179] New: 2.6.23.1 / USB_ZD1201: Kernel panic with zd1201 driver
From: Arnaldo Carvalho de Melo @ 2007-10-17 22:49 UTC (permalink / raw)
To: Dan Williams
Cc: Andrew Morton, bugme-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
zairasai-gM/Ye1E23mwN+BqQ9rBEUg
In-Reply-To: <1192654011.15090.3.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
Em Wed, Oct 17, 2007 at 04:46:51PM -0400, Dan Williams escreveu:
> On Wed, 2007-10-17 at 13:27 -0700, Andrew Morton wrote:
> > On Wed, 17 Oct 2007 11:34:57 -0700 (PDT)
> > bugme-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.org wrote:
> >
> > > http://bugzilla.kernel.org/show_bug.cgi?id=9179
> > >
> > > Summary: 2.6.23.1 / USB_ZD1201: Kernel panic with zd1201 driver
> > > Product: Drivers
> > > Version: 2.5
> > > KernelVersion: 2.6.23.1
> > > Platform: All
> > > OS/Version: Linux
> > > Tree: Mainline
> > > Status: NEW
> > > Severity: normal
> > > Priority: P1
> > > Component: network-wireless
> > > AssignedTo: drivers_network-wireless-ztI5WcYan/vQLgFONoPN62D2FQJk+8+b@public.gmane.org
> > > ReportedBy: zairasai-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org
> > >
> > >
> > > [1.] One line summary of the problem:
> > >
> > > 2.6.23.1 / USB_ZD1201: Kernel panic with zd1201 driver
> > >
> > >
> > >
> > >
> > > [2.] Full description of the problem:
> > >
> > > The zd1201-driver (symbol: USB_ZD1201) triggers a kernel panic during
> > > initialization of the WLAN device, showing the following message:
> > >
> > > EIP: [<e095e1d1>] zd1201_usbrx+0x6e1/0xbb0 [zd1201] SS:ESP 0068:c0469d7c
> > > Kernel panic - not syncing: Fatal exception in interrupt
> > >
> > > According to the init output during bootup, the panic seems to occur right when
> > > the WLAN device receives an IP address from the DHCP-Server of the
> > > WLAN/DSL-Router. The WLAN device is (in my case) a 'Belkin F5D6051' based on
> > > the ZyDAS 1201 chip.
> > >
> > > As far as i know, the only recent change in 'drivers/net/wireless/zd1201.c' was
> > > done in patch-2.6.22, so the bug probably affects all kernel versions later
> > > than 2.6.21.7, but at least the ones i've tested (which are listed in the
> > > summary below). It also recently came up in some different
> > > distribution-specific forums/bugtrackers, so it does not seem to be specific to
> > > my machine/setup. A link to another report on this problem is included at the
> > > end of this report.
> > >
> > > Below is an extract of patch-2.6.22, showing that the lines 330 and 388 have
> > > been removed from 'drivers/net/wireless/zd1201.c'. I put those two lines back,
> > > which made things work as expected again; however, that is only meant as a
> > > hint, since i don't know why they were taken out or what other implications my
> > > change might have.
> > >
> > > patch-2.6.22, lines 586509-586528:
> > > {{{
> > > diff --git a/drivers/net/wireless/zd1201.c b/drivers/net/wireless/zd1201.c
> > > index 6cb66a3..935b144 100644
> > > --- a/drivers/net/wireless/zd1201.c
> > > +++ b/drivers/net/wireless/zd1201.c
> > > @@ -327,7 +327,6 @@ static void zd1201_usbrx(struct urb *urb)
> > > memcpy(skb_put(skb, 6), &data[datalen-8], 6);
> > > memcpy(skb_put(skb, 2), &data[datalen-24], 2);
> > > memcpy(skb_put(skb, len), data, len);
> > > - skb->dev = zd->dev;
> > > skb->dev->last_rx = jiffies;
> > > skb->protocol = eth_type_trans(skb, zd->dev);
> > > zd->stats.rx_packets++;
> > > @@ -385,7 +384,6 @@ static void zd1201_usbrx(struct urb *urb)
> > > memcpy(skb_put(skb, 2), &data[6], 2);
> > > memcpy(skb_put(skb, len), data+8, len);
> > > }
> > > - skb->dev = zd->dev;
> > > skb->dev->last_rx = jiffies;
> > > skb->protocol = eth_type_trans(skb, zd->dev);
> > > zd->stats.rx_packets++;
> > > }}}
> > >
> >
> > Arnaldo, we have a pretty solid report here that your
> > 4c13eb6657fe9ef7b4dc8f1a405c902e9e5234e0 made this driver go crash.
>
> In 2.6.22 and later, eth_type_trans() sets skb->dev. It looks like the
> lines tha tset last_rx in the patch above should be moved below the
> eth_type_trans() lines, otherwise they'll likely oops.
>
> Something like this is probably in order?
I think so, its strange that this bisects to me, but Dan's change should
fix it.
- Arnaldo
^ permalink raw reply
* [PATCH] ip_gra_reasm() should set "err" incase of skb_clone() failure
From: Badari Pulavarty @ 2007-10-17 23:02 UTC (permalink / raw)
To: netdev; +Cc: lkml
Simple error handling fix (against 2.26.23-git12).
Thanks,
Badari
Need to initialize "err" in case of skb_clone() failure.
net/ipv4/ip_fragment.c: In function `ip_defrag':
net/ipv4/ip_fragment.c:540: warning: `err' might be used uninitialized in this function
Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com>
---
net/ipv4/ip_fragment.c | 1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.23/net/ipv4/ip_fragment.c
===================================================================
--- linux-2.6.23.orig/net/ipv4/ip_fragment.c 2007-10-17 15:33:27.000000000 -0700
+++ linux-2.6.23/net/ipv4/ip_fragment.c 2007-10-17 15:50:51.000000000 -0700
@@ -544,6 +544,7 @@ static int ip_frag_reasm(struct ipq *qp,
/* Make the one we just received the head. */
if (prev) {
head = prev->next;
+ err = -ENOMEM;
fp = skb_clone(head, GFP_ATOMIC);
if (!fp)
^ 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