* Re: [net-next 10/10] i825xx: Move the Intel 82586/82593/82596 based drivers
From: Phil Blundell @ 2011-08-11 11:04 UTC (permalink / raw)
To: Jeff Kirsher
Cc: davem, netdev, gospo, sassmann, Russell King, aris, Donald Becker,
Chris Beauregard, Richard Procter, Andries Brouwer, M.Hipp,
Richard Hirst, Sam Creasey, Thomas Bogendoerfer
In-Reply-To: <1313033278-7337-11-git-send-email-jeffrey.t.kirsher@intel.com>
On Wed, 2011-08-10 at 20:27 -0700, Jeff Kirsher wrote:
> Move the drivers that use the i82586/i82593/i82596 chipsets into
> drivers/net/ethernet/i825xx/ and make the necessary Kconfig and
> Makefile changes. There were 4 3Com drivers which were initially
> moved into 3com/, which now reside in i825xx since they all used
> the i82586 chip.
Actually, I think 3c505 was better in 3com/ where you had it before.
Although the card does use an i82586, it's front-ended by an 80186
microcontroller and that's what the driver talks to. So there is no
meaningful code commonality with the other '586 drivers.
That said, I don't think it's a massive deal either way and if you have
a strong preference for putting it in i825xx then that's probably fine.
p.
^ permalink raw reply
* [PATCH] net/bridge/netfilter/ebtables.c: use available error handling code
From: Julia Lawall @ 2011-08-11 11:59 UTC (permalink / raw)
To: Bart De Schuymer
Cc: kernel-janitors, Patrick McHardy, Stephen Hemminger, davem,
netfilter-devel, netfilter, coreteam, bridge, netdev,
linux-kernel
From: Julia Lawall <julia@diku.dk>
Free the locally allocated table and newinfo as done in adjacent error
handling code.
Signed-off-by: Julia Lawall <julia@diku.dk>
---
net/bridge/netfilter/ebtables.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
index 2b5ca1a..5864cc4 100644
--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridge/netfilter/ebtables.c
@@ -1198,7 +1198,8 @@ ebt_register_table(struct net *net, const struct ebt_table *input_table)
if (table->check && table->check(newinfo, table->valid_hooks)) {
BUGPRINT("The table doesn't like its own initial data, lol\n");
- return ERR_PTR(-EINVAL);
+ ret = -EINVAL;
+ goto free_chainstack;
}
table->private = newinfo;
^ permalink raw reply related
* 2.6.35.11 bridge drops fragmented packets
From: Andrei Popa @ 2011-08-11 12:43 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 1115 bytes --]
Hello,
We've got a problem with kernel 2.6.35.11 as it does not forward
fragmented packets on a bridge.
I've seen this thread
http://lkml.indiana.edu/hypermail/linux/kernel/0604.0/0201.html and I
thought to email you.
The command "echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables"
fixes the problem.
The config from the kernel is attached.
The network configuration is as follows:
cisco, interace in mode trunk with allowed vlan 1501,299 -> linux ->
cisco, interface in mode trunk with allowed vlan 1501
The MTU on cisco and on linux interfaces is set to 1500.
Packets with size 1500 and no fragments are forwarded succesfully,
packets with size 1500 and fragments are not forwaded.
On linux it's a bond comprised of eth1.1501 and eth0.1501.
root@shaper_b2b_bucuresti:~# brctl show
bridge name bridge id STP enabled interfaces
br1501 8000.0015170ae7b8 no eth0.1501
eth1.1501
I cand see the fragmented packets arriving on eth0 and eth0.1501 but I
don't see them leaving on eth1 or eth1.1501.
Andrei
[-- Attachment #2: config --]
[-- Type: text/x-patch, Size: 5579 bytes --]
*** General ***
owner = itelecom
contact = support@i-neo.ro
mailhost = mail.itelecom.ro
sendmail = /usr/lib/sendmail
imgcache = /var/lib/smokeping/.simg
imgurl = ../.simg
datadir = /var/lib/smokeping
piddir = /var/lib/smokeping
cgiurl = http://89.39.188.34/cgi-perl/smokeping.pl
smokemail = /etc/smokemail.dist
# specify this to get syslog logging
syslogfacility = local0
# each probe is now run in its own process
# disable this to revert to the old behaviour
# concurrentprobes = no
#owner = ineo
#contact = support@i-neo.ro
#mailhost = mail.itelecom.ro
# NOTE: do not put the Image Cache below cgi-bin
# since all files under cgi-bin will be executed ... this is not
# good for images.
#imgcache = /var/lib/smokeping/.simg
#imgurl = ../.simg
#datadir = /var/lib/smokeping
#piddir = /var/run/smokeping
#cgiurl = http://89.39.188.34/cgi-perl/smokeping.pl
#smokemail = /etc/smokeping/smokemail
#tmail = /etc/smokeping/tmail
#sendmail = /usr/lib/sendmail
# specify this to get syslog logging
#syslogfacility = local0
# each probe is now run in its own process
# disable this to revert to the old behaviour
# concurrentprobes = no
*** Alerts ***
to = alert@i-neo.ro
from = smokeping@itelecom.ro
+someloss
type = loss
# in percent
pattern = >0%,*12*,>0%,*12*,>0%
comment = loss 3 times in a row
+rtt_dns
type = rtt
# in milliseconds
pattern = >1
comment = dns rtt up
+startloss
type = loss
# in percent
pattern = ==S,>0%,>0%,>0%
comment = loss at startup
*** Database ***
step = 300
pings = 20
# consfn mrhb steps total
AVERAGE 0.5 1 1008
AVERAGE 0.5 12 4320
MIN 0.5 12 4320
MAX 0.5 12 4320
AVERAGE 0.5 144 720
MAX 0.5 144 720
MIN 0.5 144 720
*** Presentation ***
template = /etc/smokeping/basepage.html
+ overview
width = 600
height = 50
range = 10h
+ detail
width = 600
height = 200
unison_tolerance = 2
"Last 3 Hours" 3h
"Last 30 Hours" 30h
"Last 10 Days" 10d
"Last 400 Days" 400d
#+ hierarchies
#++ owner
#title = Host Owner
#++ location
#title = Location
*** Probes ***
+ FPing
binary = /usr/sbin/fping
+ DNS
binary = /usr/bin/dig
lookup = yahoo.com
pings = 5
step = 180
*** Slaves ***
secrets= /etc/smokeping/smokeping_secrets
+boomer
display_name=boomer
color=0000ff
+slave2
display_name=another
color=00ff00
*** Targets ***
probe = FPing
menu = Top
title = Network Latency Grapher
remark = Welcome to the SmokePing website of xxx Company. \
Here you will learn all about the latency of our network.
menuextra = <a target='_blank' href='http://89.39.188.34/smokeping/tr.html{HOST}' class='{CLASS}' \
onclick="window.open(this.href,this.target, \
'width=800,height=500,toolbar=no,location=no,status=no,scrollbars=no'); \
return false;">[Trace]</a>
+ services
menu = Service Latency
title = Service Latency (DNS, HTTP)
++ DNS
probe = DNS
menu = DNS Latency
title = DNS Latency
+++ ns1
host = ns1.itelecom.ro
alerts = rtt_dns,someloss
+ Extern
menu = Extern
title = Extern
++ NTT
menu = NTT
title = NTT(213.198.82.177)
host = 213.198.82.177
++ NTT_test1
menu = NTT_test1
title = NTT_test1(213.198.76.29)
host = 213.198.76.29
alerts = someloss
++ NTT_test2
menu = NTT_test2
title = NTT_test2(62.73.178.85)
host = 62.73.178.85
alerts = someloss
++ LEVEL3_interconect
menu = LEVEL3_interconect
title = LEVEL3(212.162.45.133)
host = 212.162.45.133
alerts = someloss
++ WWWLEVEL3
menu = WWWLEVEL3
title = WWWLEVEL3(4.68.95.11)
host = 4.68.95.11
alerts = someloss
++ GTSCE
menu = GTSCE
title = GTSCE(195.39.208.77)
host = 195.39.208.77
alerts = someloss
++ GBLX
menu = GBLX
title = GBLX(207.218.55.80)
host = 207.218.55.80
alerts = someloss
++ wwwyahoo
menu =wwwYahoo
title = www.yahoo.com
host = 87.248.122.122
alerts = someloss
++ yahoo
menu =Yahoo
title = yahoo.com
host = 67.195.160.76
alerts = someloss
++ www_yahoo
menu =www_Yahoo
title = www.yahoo.com
host = 87.248.122.122
alerts = someloss
++ kernel
menu = ftp.kernel.org
title = ftp.kernel.org
host = 130.239.17.4
alerts = someloss
++ google
menu = www.google.com
title = www.google.com
host = 209.85.135.103
alerts = someloss
++ facebook
menu = www.facebook.com
title = www.facebook.com
host = 69.63.189.11
alerts = someloss
+ Metro
menu = Metro
title = Metro
++ interlan
menu = www.interlan.ro
title = www.interlan.ro
host = 86.104.125.235
alerts = someloss
++ k
menu = www.k.ro
title = www.k.ro
host = 194.102.255.23
alerts = someloss
++ astral
menu = astral.ro
title = astral.ro
host = 193.230.240.28
alerts = someloss
++ lgastralnet
menu = lg.astralnet.ro
title = lg.astralnet.ro
host = 194.102.255.35
alerts = someloss
++ ilink
menu = www.ilink.ro
title = www.ilink.ro
host = 86.55.0.10
alerts = someloss
++ rdsnet
menu = www.rdsnet.ro
title = www.rdsnet.ro
host = 81.196.12.33
alerts = someloss
++ rds1_bucuresti
menu = www.home.ro
title = www.home.ro
host = 81.196.20.130
alerts = someloss
++ rds2_oradea
menu = www.rdsor.ro
title = www.rdsor.ro
host = 193.231.238.4
++ rds3_constanta
menu = CaffeDelMar.ro
title = CaffeDelMar.ro
host = 86.122.57.68
++ romtelecom
menu = www.romtelecom.ro
title = www.romtelecom.ro
host = 86.35.15.233
++ mediasat
menu = www.mediasat.ro
title = www.mediasat.ro
host = 81.180.226.176
++ ines
menu = www.ines.ro
title = www.ines.ro
host = 80.86.96.15
++ newcom
menu = www.newcom.ro
title = www.newcom.ro
host = 89.165.199.15
alerts = someloss
+ Clienti
menu = Clienti
title = Clienti
++ PCPLANET_client
menu = PCPLANET_client
title = PCPLANET_client
host = 93.115.98.30
^ permalink raw reply
* RE: [linux-firmware v2 1/2] rtl_nic: update firmware forRTL8111E-VL
From: Ben Hutchings @ 2011-08-11 12:46 UTC (permalink / raw)
To: hayeswang; +Cc: dwmw2, romieu, netdev
In-Reply-To: <9DEF5678E5044F80AEBAD3FE738EA980@realtek.com.tw>
[-- Attachment #1: Type: text/plain, Size: 984 bytes --]
On Thu, 2011-08-11 at 11:41 +0800, hayeswang wrote:
>
> > -----Original Message-----
> > From: Ben Hutchings [mailto:ben@decadent.org.uk]
> > > +File: rtl_nic/rtl8168e-3.fw (Version: rtl8168e-3_0.0.1)
> > [...]
> >
> > Please don't write the version in yet another way. It should be:
> >
>
> I just think if someone replaces the firmware with another one, I could check
> the firmware through the information without checking the ram data.
> For example, someone renames the rtl8168f-1.fw to rtl8168e-3.fw and replaces the
> original rtl8168e-3.fw. Through ethtool to show the version of the firmware, I
> could know the firmware is invalid. If the version only contain the value 0.0.1,
> I must compare the binary file to find out the result.
[...]
You're talking about the version string inside the firmware file. I see
the value of including the name there. However, in the WHENCE file it
is redundant.
But I really don't care that much.
Ben.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [Patch] scm: Capture the full credentials of the scm sender
From: David Miller @ 2011-08-11 12:51 UTC (permalink / raw)
To: tim.c.chen; +Cc: eric.dumazet, ebiederm, viro, ak, linux-kernel, netdev
In-Reply-To: <1312908512.2576.97.camel@schen9-DESK>
From: Tim Chen <tim.c.chen@linux.intel.com>
Date: Tue, 09 Aug 2011 09:48:32 -0700
> This patch corrects an erroneous update of credential's gid with uid
> introduced in commit 257b5358b32f17 since 2.6.36.
>
> Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net/bridge/netfilter/ebtables.c: use available error handling code
From: David Miller @ 2011-08-11 12:53 UTC (permalink / raw)
To: julia
Cc: bart.de.schuymer, kernel-janitors, kaber, shemminger,
netfilter-devel, netfilter, coreteam, bridge, netdev,
linux-kernel
In-Reply-To: <1313063978-29400-1-git-send-email-julia@diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Thu, 11 Aug 2011 13:59:38 +0200
> From: Julia Lawall <julia@diku.dk>
>
> Free the locally allocated table and newinfo as done in adjacent error
> handling code.
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
Applied.
^ permalink raw reply
* Re: [PATCH] net/netlabel/netlabel_kapi.c: add missing cleanup code
From: David Miller @ 2011-08-11 12:53 UTC (permalink / raw)
To: julia; +Cc: error27, paul, kernel-janitors, netdev, linux-kernel
In-Reply-To: <Pine.LNX.4.64.1108111205450.18938@ask.diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Thu, 11 Aug 2011 12:06:04 +0200 (CEST)
> From: Julia Lawall <julia@diku.dk>
>
> Call cipso_v4_doi_putdef in the case of the failure of the allocation of
> entry. Reverse the order of the error handling code at the end of the
> function and insert more labels in order to reduce the number of
> unnecessary calls to kfree.
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
Applied.
^ permalink raw reply
* Re: [PATCH 1/3 v2] net/irda: sh_irda: add missing header
From: David Miller @ 2011-08-11 12:53 UTC (permalink / raw)
To: kuninori.morimoto.gx; +Cc: kuninori.morimoto.gx, netdev
In-Reply-To: <8762m4wb8t.wl%kuninori.morimoto.gx@renesas.com>
From: kuninori.morimoto.gx@gmail.com
Date: Thu, 11 Aug 2011 02:25:42 -0700 (PDT)
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> This patch fixup below build error on sh_irda
>
> sh_irda.c: In function 'sh_irda_write':
> sh_irda.c:174: error: implicit declaration of function 'iowrite16'
> sh_irda.c: In function 'sh_irda_read':
> sh_irda.c:184: error: implicit declaration of function 'ioread16'
> sh_irda.c: At top level:
> sh_irda.c:492: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'sh_irda_irq'
> sh_irda.c: In function 'sh_irda_probe':
> sh_irda.c:776: error: implicit declaration of function 'ioremap_nocache'
> sh_irda.c:776: warning: assignment makes pointer from integer without a cast
> sh_irda.c:811: error: implicit declaration of function 'request_irq'
> sh_irda.c:811: error: 'sh_irda_irq' undeclared (first use in this function)
> sh_irda.c:811: error: (Each undeclared identifier is reported only once
> sh_irda.c:811: error: for each function it appears in.)
> sh_irda.c:811: error: 'IRQF_DISABLED' undeclared (first use in this function)
> sh_irda.c:825: error: implicit declaration of function 'iounmap'
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3 v2] net/irda: sh_sir: add missing header
From: David Miller @ 2011-08-11 12:53 UTC (permalink / raw)
To: kuninori.morimoto.gx; +Cc: kuninori.morimoto.gx, netdev
In-Reply-To: <874o1owb82.wl%kuninori.morimoto.gx@renesas.com>
From: kuninori.morimoto.gx@gmail.com
Date: Thu, 11 Aug 2011 02:26:09 -0700 (PDT)
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> This patch fixup below build error on sh_sir
>
> sh_sir.c: In function 'sh_sir_write':
> sh_sir.c:127:2: error: implicit declaration of function 'iowrite16'
> sh_sir.c: In function 'sh_sir_read':
> sh_sir.c:132:2: error: implicit declaration of function 'ioread16'
> sh_sir.c: At top level:
> sh_sir.c:561:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'sh_sir_irq'
> sh_sir.c: In function 'sh_sir_probe':
> sh_sir.c:727:2: error: implicit declaration of function 'ioremap_nocache'
> sh_sir.c:727:16: warning: assignment makes pointer from integer without a cast
> sh_sir.c:762:2: error: implicit declaration of function 'request_irq'
> sh_sir.c:762:23: error: 'sh_sir_irq' undeclared (first use in this function)
> sh_sir.c:762:23: note: each undeclared identifier is reported only once for each function it appears in
> sh_sir.c:762:35: error: 'IRQF_DISABLED' undeclared (first use in this function)
> sh_sir.c:776:2: error: implicit declaration of function 'iounmap'
> sh_sir.c: At top level:
> sh_sir.c:436:13: warning: 'sh_sir_clear_all_err' defined but not used
> sh_sir.c:474:12: warning: 'sh_sir_is_which_phase' defined but not used
> sh_sir.c:490:13: warning: 'sh_sir_tx' defined but not used
> sh_sir.c:540:13: warning: 'sh_sir_rx' defined but not used
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Applied.
^ permalink raw reply
* Re: [PATCH 3/3] net/irda: sh_sir: tidyup compile warning
From: David Miller @ 2011-08-11 12:54 UTC (permalink / raw)
To: kuninori.morimoto.gx; +Cc: kuninori.morimoto.gx, netdev
In-Reply-To: <8739h8wb79.wl%kuninori.morimoto.gx@renesas.com>
From: kuninori.morimoto.gx@gmail.com
Date: Thu, 11 Aug 2011 02:26:37 -0700 (PDT)
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> This patch tidyup below warning
>
> ${LINUX}/drivers/net/irda/sh_sir.c:514:6: warning:
> 'val' may be used uninitialized in this function
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Applied.
^ permalink raw reply
* Re: [PATCH] slcan: ldisc generated skbs are received in softirq context
From: David Miller @ 2011-08-11 12:56 UTC (permalink / raw)
To: socketcan; +Cc: netdev, matvejchikov, alan
In-Reply-To: <4E42A163.5030208@hartkopp.net>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Wed, 10 Aug 2011 17:18:59 +0200
> As this discussion pointed out
>
> http://marc.info/?l=linux-netdev&m=131257225602375
>
> netdevices that are based on serial line disciplines should use netif_rx_ni()
> when pushing received socketbuffers into the netdev rx queue.
>
> Following commit 614851601c121b1320a35757ab88292d6272f906 ("slip: fix NOHZ
> local_softirq_pending 08 warning") this patch updates the slcan driver
> accordingly.
>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
> CC: Matvejchikov Ilya <matvejchikov@gmail.com>
> CC: Alan Cox <alan@lxorguk.ukuu.org.uk>
Applied.
^ permalink raw reply
* Re: return of ip_rt_bug()
From: David Miller @ 2011-08-11 13:00 UTC (permalink / raw)
To: ja; +Cc: selinux, davej, netdev
In-Reply-To: <alpine.LFD.2.00.1108091645351.1527@ja.ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Tue, 9 Aug 2011 16:51:26 +0300 (EEST)
> There are other places that used fl.iif (0 for output
> routes) but are now using rt_iif instead of rt_route_iif,
> not sure if this change is fatal for them because:
>
> - net/sched/cls_route.c, route4_classify() gets optional
> iif, so it can be 0, may be to match output route? And
> later route4_classify does exact match for rt_iif. Does
> it mean that now we can not match output packets without
> providing "fromif OUTDEV" ?
>
> - net/sched/em_meta.c: now int_rtiif (being rt_iif) is
> always != 0, may be not good to match output routes?
>
> In short, the fl.iif -> rt_iif conversion is risky
> at some places.
If we convert em_meta.c and cls_route.c to use rt_route_iif
we should be OK right? Please patches to do this if so.
Thanks.
^ permalink raw reply
* Re: [PATCH] ipv4: some rt_iif -> rt_route_iif conversions
From: David Miller @ 2011-08-11 13:01 UTC (permalink / raw)
To: ja; +Cc: netdev
In-Reply-To: <alpine.LFD.2.00.1108091651290.1527@ja.ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Tue, 9 Aug 2011 17:01:16 +0300 (EEST)
>
> As rt_iif represents input device even for packets
> coming from loopback with output route, it is not an unique
> key specific to input routes. Now rt_route_iif has such role,
> it was fl.iif in 2.6.38, so better to change the checks at
> some places to save CPU cycles and to restore 2.6.38 semantics.
>
> compare_keys:
> - input routes: only rt_route_iif matters, rt_iif is same
> - output routes: only rt_oif matters, rt_iif is not
> used for matching in __ip_route_output_key
> - now we are back to 2.6.38 state
>
> ip_route_input_common:
> - matching rt_route_iif implies input route
> - compared to 2.6.38 we eliminated one rth->fl.oif check
> because it was not needed even for 2.6.38
>
> compare_hash_inputs:
> Only the change here is not an optimization, it has
> effect only for output routes. I assume I'm restoring
> the original intention to ignore oif, it was using fl.iif
> - now we are back to 2.6.38 state
>
> Signed-off-by: Julian Anastasov <ja@ssi.bg>
Applied, thanks a lot for doing these audits.
^ permalink raw reply
* Re: [net-next 04/10] 8390: Move the 8390 related drivers
From: Ben Hutchings @ 2011-08-11 13:07 UTC (permalink / raw)
To: Jeff Kirsher
Cc: davem, netdev, gospo, sassmann, Donald Becker, Paul Gortmaker,
Alain Malek, Peter De Schrijver, David Huggins-Daines, Wim Dumon,
Yoshinori Sato, David Hinds, Russell King
In-Reply-To: <1313033278-7337-5-git-send-email-jeffrey.t.kirsher@intel.com>
On Wed, 2011-08-10 at 20:27 -0700, Jeff Kirsher wrote:
> Moves the drivers for the National Semi-conductor 8390 chipset into
> drivers/net/ethernet/8390/ and the necessary Kconfig and Makefile
> changes.
[...]
> --- /dev/null
> +++ b/drivers/net/ethernet/8390/Kconfig
[...]
> +config EL2
> + tristate "3c503 \"EtherLink II\" support"
> + depends on ISA
> + select CRC32
> + ---help---
> + If you have a network (Ethernet) card of this type, say Y and read
> + the Ethernet-HOWTO, available from
> + <http://www.tldp.org/docs.html#howto>.
> +
> + To compile this driver as a module, choose M here. The module
> + will be called 3c503.
[...]
Minor issue: you add the EL2 config here correctly, but don't remove it
from drivers/net/Kconfig until patch 10.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: 2.6.35.11 bridge drops fragmented packets
From: Eric Dumazet @ 2011-08-11 13:39 UTC (permalink / raw)
To: ierdnah; +Cc: netdev
In-Reply-To: <1313066585.14145.18.camel@ierdnac-hp>
Le jeudi 11 août 2011 à 15:43 +0300, Andrei Popa a écrit :
> Hello,
>
> We've got a problem with kernel 2.6.35.11 as it does not forward
> fragmented packets on a bridge.
> I've seen this thread
> http://lkml.indiana.edu/hypermail/linux/kernel/0604.0/0201.html and I
> thought to email you.
>
> The command "echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables"
> fixes the problem.
>
> The config from the kernel is attached.
> The network configuration is as follows:
> cisco, interace in mode trunk with allowed vlan 1501,299 -> linux ->
> cisco, interface in mode trunk with allowed vlan 1501
>
> The MTU on cisco and on linux interfaces is set to 1500.
> Packets with size 1500 and no fragments are forwarded succesfully,
> packets with size 1500 and fragments are not forwaded.
> On linux it's a bond comprised of eth1.1501 and eth0.1501.
> root@shaper_b2b_bucuresti:~# brctl show
> bridge name bridge id STP enabled interfaces
> br1501 8000.0015170ae7b8 no eth0.1501
> eth1.1501
> I cand see the fragmented packets arriving on eth0 and eth0.1501 but I
> don't see them leaving on eth1 or eth1.1501.
>
> Andrei
>
Could you give us output of 'netstat -s' to check if IP defrag drops
some packets ?
^ permalink raw reply
* Re: 2.6.35.11 bridge drops fragmented packets
From: Andrei Popa @ 2011-08-11 13:44 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1313069946.3261.1.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Thu, 2011-08-11 at 15:39 +0200, Eric Dumazet wrote:
> Le jeudi 11 août 2011 à 15:43 +0300, Andrei Popa a écrit :
> > Hello,
> >
> > We've got a problem with kernel 2.6.35.11 as it does not forward
> > fragmented packets on a bridge.
> > I've seen this thread
> > http://lkml.indiana.edu/hypermail/linux/kernel/0604.0/0201.html and I
> > thought to email you.
> >
> > The command "echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables"
> > fixes the problem.
> >
> > The config from the kernel is attached.
> > The network configuration is as follows:
> > cisco, interace in mode trunk with allowed vlan 1501,299 -> linux ->
> > cisco, interface in mode trunk with allowed vlan 1501
> >
> > The MTU on cisco and on linux interfaces is set to 1500.
> > Packets with size 1500 and no fragments are forwarded succesfully,
> > packets with size 1500 and fragments are not forwaded.
> > On linux it's a bond comprised of eth1.1501 and eth0.1501.
> > root@shaper_b2b_bucuresti:~# brctl show
> > bridge name bridge id STP enabled interfaces
> > br1501 8000.0015170ae7b8 no eth0.1501
> > eth1.1501
> > I cand see the fragmented packets arriving on eth0 and eth0.1501 but I
> > don't see them leaving on eth1 or eth1.1501.
> >
> > Andrei
> >
>
> Could you give us output of 'netstat -s' to check if IP defrag drops
> some packets ?
root@shaper_b2b_bucuresti:~# echo 1
> /proc/sys/net/bridge/bridge-nf-call-iptables
On a server behind the shaper:
nl2 ~ # ping -s 65000 lg.telia.net
PING juniperlg1-sn4.m-sp.skanova.net (81.228.10.74) 65000(65028) bytes
of data.
^C
--- juniperlg1-sn4.m-sp.skanova.net ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 8021ms
nl2 ~ #
root@shaper_b2b_bucuresti:~# netstat -s
Ip:
12783151 total packets received
10960 with invalid addresses
0 forwarded
0 incoming packets discarded
2738144 incoming packets delivered
2224918 requests sent out
20 dropped because of missing route
2380122 fragments dropped after timeout
1502102174 reassemblies required
662730406 packets reassembled ok
3060985 packet reassembles failed
5 fragments received ok
10 fragments created
Icmp:
352 ICMP messages received
0 input ICMP message failed.
ICMP input histogram:
destination unreachable: 327
echo requests: 9
echo replies: 16
340 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 304
echo request: 27
echo replies: 9
IcmpMsg:
InType0: 16
InType3: 327
InType8: 9
OutType0: 9
OutType3: 304
OutType8: 27
Tcp:
193 active connections openings
14926 passive connection openings
8 failed connection attempts
17 connection resets received
2 connections established
1603905 segments received
1248972 segments send out
1140 segments retransmited
0 bad segments received.
19 resets sent
Udp:
991041 packets received
2 packets to unknown port received.
0 packet receive errors
991110 packets sent
UdpLite:
TcpExt:
8 resets received for embryonic SYN_RECV sockets
16113 delayed acks sent
1 delayed acks further delayed because of locked socket
Quick ack mode was activated 46 times
27639 packets directly queued to recvmsg prequeue.
1894178 bytes directly in process context from backlog
18824 bytes directly received in process context from prequeue
380110 packet headers predicted
1356 packets header predicted and directly queued to user
160586 acknowledgments not containing data payload received
730360 predicted acknowledgments
10 times recovered from packet loss by selective acknowledgements
Detected reordering 7 times using time stamp
4 congestion windows fully recovered without slow start
9 congestion windows partially recovered using Hoe heuristic
4 congestion windows recovered without slow start by DSACK
16 fast retransmits
7 forward retransmits
21 retransmits in slow start
229 other TCP timeouts
46 DSACKs sent for old packets
24 DSACKs received
13 connections reset due to early user close
4 connections aborted due to timeout
TCPDSACKIgnoredOld: 12
TCPDSACKIgnoredNoUndo: 3
TCPSackMerged: 2
TCPSackShiftFallback: 30
IpExt:
InMcastPkts: 12981
InBcastPkts: 129863
InOctets: 1509979125
OutOctets: 551230551
InMcastOctets: 363468
InBcastOctets: 8832164
^ permalink raw reply
* Re: 2.6.35.11 bridge drops fragmented packets
From: Eric Dumazet @ 2011-08-11 14:17 UTC (permalink / raw)
To: ierdnah; +Cc: netdev
In-Reply-To: <1313070275.814.2.camel@ierdnac-hp>
Le jeudi 11 août 2011 à 16:44 +0300, Andrei Popa a écrit :
> On Thu, 2011-08-11 at 15:39 +0200, Eric Dumazet wrote:
> > Le jeudi 11 août 2011 à 15:43 +0300, Andrei Popa a écrit :
> > > Hello,
> > >
> > > We've got a problem with kernel 2.6.35.11 as it does not forward
> > > fragmented packets on a bridge.
> > > I've seen this thread
> > > http://lkml.indiana.edu/hypermail/linux/kernel/0604.0/0201.html and I
> > > thought to email you.
> > >
> > > The command "echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables"
> > > fixes the problem.
> > >
> > > The config from the kernel is attached.
> > > The network configuration is as follows:
> > > cisco, interace in mode trunk with allowed vlan 1501,299 -> linux ->
> > > cisco, interface in mode trunk with allowed vlan 1501
> > >
> > > The MTU on cisco and on linux interfaces is set to 1500.
> > > Packets with size 1500 and no fragments are forwarded succesfully,
> > > packets with size 1500 and fragments are not forwaded.
> > > On linux it's a bond comprised of eth1.1501 and eth0.1501.
> > > root@shaper_b2b_bucuresti:~# brctl show
> > > bridge name bridge id STP enabled interfaces
> > > br1501 8000.0015170ae7b8 no eth0.1501
> > > eth1.1501
> > > I cand see the fragmented packets arriving on eth0 and eth0.1501 but I
> > > don't see them leaving on eth1 or eth1.1501.
> > >
> > > Andrei
> > >
> >
> > Could you give us output of 'netstat -s' to check if IP defrag drops
> > some packets ?
> root@shaper_b2b_bucuresti:~# echo 1
> > /proc/sys/net/bridge/bridge-nf-call-iptables
>
> On a server behind the shaper:
>
> nl2 ~ # ping -s 65000 lg.telia.net
> PING juniperlg1-sn4.m-sp.skanova.net (81.228.10.74) 65000(65028) bytes
> of data.
> ^C
> ---
65000 bytes means 43 frames, and your network seems a bit busy.
If _one_ frame is lost (becasue of shaping for example), IP
fragmentation in bridge will fail -> all frames are discarded.
Could you try with "-s 2000" ?
I could not reproduce your problem on my dev machine (admitidly using a
more recent kernel)
^ permalink raw reply
* Re: [PATCH v11 4/5] powerpc: Add flexcan device support for p1010rdb.
From: Kumar Gala @ 2011-08-11 14:17 UTC (permalink / raw)
To: Robin Holt
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300, PPC list,
Wolfgang Grandegger
In-Reply-To: <20110811104252.GC4926-sJ/iWh9BUns@public.gmane.org>
On Aug 11, 2011, at 5:42 AM, Robin Holt wrote:
> On Wed, Aug 10, 2011 at 11:46:27PM -0500, Kumar Gala wrote:
>>
>> On Aug 10, 2011, at 1:16 PM, Wolfgang Grandegger wrote:
>>
>>> On 08/10/2011 07:01 PM, Kumar Gala wrote:
>>>>
>>>> On Aug 10, 2011, at 11:27 AM, Robin Holt wrote:
>>>>
>>>>> I added a simple clock source for the p1010rdb so the flexcan driver
>>>>> could determine a clock frequency. The p1010 flexcan device only has
>>>>> an oscillator of system bus frequency divided by 2.
>>>>>
>>>>> Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
>>>>> Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
>>>>> Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>,
>>>>> Cc: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
>>>>> Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
>>>>> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
>>>>> Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
>>>>> Cc: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
>>>>> ---
>>>>> arch/powerpc/platforms/85xx/Kconfig | 2 +
>>>>> arch/powerpc/platforms/85xx/Makefile | 2 +
>>>>> arch/powerpc/platforms/85xx/clock.c | 52 ++++++++++++++++++++++++++++++++
>>>>> arch/powerpc/platforms/85xx/p1010rdb.c | 8 +++++
>>>>> 4 files changed, 64 insertions(+), 0 deletions(-)
>>>>> create mode 100644 arch/powerpc/platforms/85xx/clock.c
>>>>
>>>> I dont understand how mpc85xx_clk_functions() ends up being associated with the frequency the flexcan is running at.
>>>
>>> The function mpc85xx_clk_get_rate() returns "fsl_get_sys_freq() / 2" for
>>> Flexcan devices.
>>>
>>>> This either seems to global or I'm missing something.
>>>
>>> This patch extends the existing Flexcan platform driver for ARM for the
>>> PowerPC using the device tree. Due to the nice integration of the device
>>> tree (of-platform) into the platform driver and devices, the difference
>>> are quite small (see patches 1..3). Apart from the endianess issue, only
>>> the clock needs to be handled in a common way. As ARM already uses the
>>> clk interface, we found it straight-forward to implement it for the
>>> P1010, or more general for the 85xx, as well, instead of using an
>>> additional helper function.
>>
>> I see, that. What concerns me is there are numerous clocks /
>> frequencies that exist inside a MPC85xx/P1010 SOC. The code I'm seeing
>> does NOT seem to do anything to relate this clock JUST to the flexcan.
>
> if (!dev->of_node ||
> !of_device_is_compatible(dev->of_node, "fsl,flexcan"))
> return ERR_PTR(-ENOENT);
>
> That should relate it just to flexcan, right? Plus it has the added
> benefit of being a baby-step in the direction of implementing a clkdev
> type thing for powerpc which did look fairly slick to me, but I may
> be confused.
>
> It sounds like Wolfgang is defering to you. Give it an honest evaluation
> and tell me which direction you would like me to go. I don't have a
> strong preference either way. The alternative I gave to Wolfgang of
> using a flexcan property to avoid needing any clk_get_rate seems fairly
> hackish at this point, but I have had more time to get used to the
> 'hack in a 85xx clock' method.
For some time we've been adding 'clock-frequency' nodes in the device tree to abstract having to know this headache in the kernel and adding a bunch of SoC specific code all the time. So pushing this to the firmware is exactly where we want it for FSL PPC SoCs.
We need to make sure the device tree binding has details on a 'clock-frequency' property.
- k
^ permalink raw reply
* Influencing triggering of xfrm acquire messages?
From: David Martin @ 2011-08-11 14:21 UTC (permalink / raw)
To: netdev
Hi,
I have got a question regarding the triggering of xfrm acquire messages.
The setup is the following:
I'm using HIPL (https://launchpad.net/hipl) which implements the
Host Identity Protocol (HIP) and provides a control channel for the mutual peer
authentication and the generation of keying material. In the end of the initial
handshake, HIPL sets up the Linux Kernel IPsec implementation for the protection
of payload data.
The initial exchange is triggered by the following policy for outgoing traffic.
Note that 2001:10::/28 is the prefix for HIP addresses.
> martin@pisa1:~$ sudo ip xfrm policy
> src 2001:10::/28 dst 2001:10::/28
> dir out priority 0
> tmpl src :: dst ::
> proto 0 reqid 0 mode transport
Anything matching the policy (eg. a ping matching the address prefix) triggers
an acquire message, so far so good. Everytime an acquire is triggered the kernel
sets up a SA looking like this:
> martin@pisa1:~$ sudo ip xfrm state
> src 2001:1a:a148:104c:92bb:671e:8100:9354 dst 2001:1c:5000:45b6:2d33:2c10:2726:a043
> proto 0 reqid 0 mode transport
> replay-window 0
> sel src 2001:1a:a148:104c:92bb:671e:8100:9354/128 dst 2001:1c:5000:45b6:2d33:2c10:2726:a043/128 proto udp sport 49024 dport 1025
As long as it exists no additional acquire will be triggered which is a problem,
for example when shortly after an exchange the daemon is restarted and needs to
start another exchange with the same peer host.
Is this state supposed to be set up? Is it supposed to be removed automatically
once we set up our own SA? Is there a way to remove it manually to
trigger another acquire? Any input is welcome, thanks a lot in advance.
Greetings, David
^ permalink raw reply
* Re: [PATCH net 2/5] bnx2x: fix select_queue when FCoE is disabled
From: David Miller @ 2011-08-11 14:26 UTC (permalink / raw)
To: dmitry; +Cc: netdev, vladz, eilong
In-Reply-To: <1312895335.21856.1.camel@lb-tlvb-dmitry>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Tue, 9 Aug 2011 16:08:55 +0300
> From: Vladislav Zolotarov <vladz@broadcom.com>
>
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 1/5] bnx2x: init FCOE FP only once
From: David Miller @ 2011-08-11 14:26 UTC (permalink / raw)
To: dmitry; +Cc: netdev, eilong, vladz
In-Reply-To: <1312895290.21856.0.camel@lb-tlvb-dmitry>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Tue, 9 Aug 2011 16:08:09 +0300
> From: Vladislav Zolotarov <vladz@broadcom.com>
>
>
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 3/5] bnx2x: prevent race between undi_unload and load flows
From: David Miller @ 2011-08-11 14:26 UTC (permalink / raw)
To: dmitry; +Cc: netdev, vladz, eilong
In-Reply-To: <1312895392.21856.2.camel@lb-tlvb-dmitry>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Tue, 9 Aug 2011 16:09:52 +0300
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2] net: add Documentation/networking/scaling.txt
From: Will de Bruijn @ 2011-08-11 14:26 UTC (permalink / raw)
To: Rick Jones; +Cc: rdunlap, linux-doc, davem, netdev, therbert
In-Reply-To: <4E418030.2010102@hp.com>
> Any other worries I have a probably a matter of opinion or ignorance on my
> part.
I'll be happy to revise it once more. This version also lacks the
required one-line description in Documentation/networking/00-INDEX, so
I will have to resubmit, either way.
The 'suggested configuration' heuristics are certainly debatable, so
any questionable statements there can just be dropped. If the
technical description of the mechanisms is contentious, that would be
a more serious error.
willem
^ permalink raw reply
* Re: [PATCH net 4/5] bnx2x: properly clean indirect addresses
From: David Miller @ 2011-08-11 14:26 UTC (permalink / raw)
To: dmitry; +Cc: netdev, vladz, eilong
In-Reply-To: <1312895429.21856.3.camel@lb-tlvb-dmitry>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Tue, 9 Aug 2011 16:10:29 +0300
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 5/5] bnx2x: disable dcb on 578xx since not supported yet
From: David Miller @ 2011-08-11 14:27 UTC (permalink / raw)
To: dmitry; +Cc: netdev, vladz, eilong
In-Reply-To: <1312895473.21856.4.camel@lb-tlvb-dmitry>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Tue, 9 Aug 2011 16:11:13 +0300
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ 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