* [PATCH] Add support for iPhone 5, iPad 2 GSM/CDMA, iPad 3 GSM/CDMA to ipheth.
From: Jay Purohit @ 2012-10-11 22:32 UTC (permalink / raw)
To: netdev
This patch introduces support for all devices which
officially/unofficially support
tethering over the USB connection.
This is a revision of the iPhone 5 ipheth support patch.
Signed-off-by: Jay Purohit <jspurohit@velocitylimitless.com>
diff -uprN ../old/linux-3.6.1/drivers/net/usb/ipheth.c
./drivers/net/usb/ipheth.c
--- ../old/linux-3.6.1/drivers/net/usb/ipheth.c 2012-10-07
10:41:28.000000000 -0500
+++ ./drivers/net/usb/ipheth.c 2012-10-11 17:28:39.862329304 -0500
@@ -55,13 +55,28 @@
#include <linux/workqueue.h>
#define USB_VENDOR_APPLE 0x05ac
+
+/*
+ * Please add the supported VID/PID for devices that support tethering here.
+ *
+ * Note: iPod touches starting with the 3G do actually support USB ethernet,
+ * however implementing support for it in this driver would be useless,
+ * as there is no external interface for it to bridge with on device.
+ */
+
#define USB_PRODUCT_IPHONE 0x1290
#define USB_PRODUCT_IPHONE_3G 0x1292
#define USB_PRODUCT_IPHONE_3GS 0x1294
#define USB_PRODUCT_IPHONE_4 0x1297
-#define USB_PRODUCT_IPAD 0x129a
#define USB_PRODUCT_IPHONE_4_VZW 0x129c
#define USB_PRODUCT_IPHONE_4S 0x12a0
+#define USB_PRODUCT_IPHONE_5 0x12a8
+
+#define USB_PRODUCT_IPAD 0x129a
+#define USB_PRODUCT_IPAD_2_GSM 0x12a2
+#define USB_PRODUCT_IPAD_2_CDMA 0x12a3
+#define USB_PRODUCT_IPAD_3_GSM 0x12a4
+#define USB_PRODUCT_IPAD_3_CDMA 0x12a5
#define IPHETH_USBINTF_CLASS 255
#define IPHETH_USBINTF_SUBCLASS 253
@@ -106,6 +121,22 @@ static struct usb_device_id ipheth_table
IPHETH_USBINTF_CLASS, IPHETH_USBINTF_SUBCLASS,
IPHETH_USBINTF_PROTO) },
{ USB_DEVICE_AND_INTERFACE_INFO(
+ USB_VENDOR_APPLE, USB_PRODUCT_IPAD_2_GSM,
+ IPHETH_USBINTF_CLASS, IPHETH_USBINTF_SUBCLASS,
+ IPHETH_USBINTF_PROTO) },
+ { USB_DEVICE_AND_INTERFACE_INFO(
+ USB_VENDOR_APPLE, USB_PRODUCT_IPAD_2_CDMA,
+ IPHETH_USBINTF_CLASS, IPHETH_USBINTF_SUBCLASS,
+ IPHETH_USBINTF_PROTO) },
+ { USB_DEVICE_AND_INTERFACE_INFO(
+ USB_VENDOR_APPLE, USB_PRODUCT_IPAD_3_GSM,
+ IPHETH_USBINTF_CLASS, IPHETH_USBINTF_SUBCLASS,
+ IPHETH_USBINTF_PROTO) },
+ { USB_DEVICE_AND_INTERFACE_INFO(
+ USB_VENDOR_APPLE, USB_PRODUCT_IPAD_3_CDMA,
+ IPHETH_USBINTF_CLASS, IPHETH_USBINTF_SUBCLASS,
+ IPHETH_USBINTF_PROTO) },
+ { USB_DEVICE_AND_INTERFACE_INFO(
USB_VENDOR_APPLE, USB_PRODUCT_IPHONE_4_VZW,
IPHETH_USBINTF_CLASS, IPHETH_USBINTF_SUBCLASS,
IPHETH_USBINTF_PROTO) },
@@ -113,6 +144,10 @@ static struct usb_device_id ipheth_table
USB_VENDOR_APPLE, USB_PRODUCT_IPHONE_4S,
IPHETH_USBINTF_CLASS, IPHETH_USBINTF_SUBCLASS,
IPHETH_USBINTF_PROTO) },
+ { USB_DEVICE_AND_INTERFACE_INFO(
+ USB_VENDOR_APPLE, USB_PRODUCT_IPHONE_5,
+ IPHETH_USBINTF_CLASS, IPHETH_USBINTF_SUBCLASS,
+ IPHETH_USBINTF_PROTO) },
{ }
};
MODULE_DEVICE_TABLE(usb, ipheth_table);
^ permalink raw reply
* Re: [PATCH 0/3] virtio-net: inline header support
From: Rusty Russell @ 2012-10-11 22:37 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: kvm, netdev, linux-kernel, virtualization, Sasha Levin,
Paolo Bonzini, avi, Thomas Lendacky
In-Reply-To: <20121011110430.GF5552@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
> On Thu, Oct 11, 2012 at 10:33:31AM +1030, Rusty Russell wrote:
>> OK. Well, Anthony wants qemu to be robust in this regard, so I am
>> tempted to rework all the qemu drivers to handle arbitrary layouts.
>> They could use a good audit anyway.
>
> I agree here. Still trying to understand whether we can agree to use
> a feature bit for this, or not.
I'd *like* to imply it by the new PCI layout, but if it doesn't work
we'll add a new feature bit.
I'm resisting a feature bit, since it constrains future implementations
which could otherwise assume it.
>> This would become a glaring exception, but I'm tempted to fix it to 32
>> bytes at the same time as we get the new pci layout (ie. for the virtio
>> 1.0 spec).
>
> But this isn't a virtio-pci only issue, is it?
> qemu has s390 bus with same limmitation.
> How can we tie it to pci layout?
They can use a transport feature if they need to, of course. But
perhaps the timing with ccw will coincide with the fix, in which they
don't need to, but it might be a bit late.
Cornelia?
Cheers,
Rusty.
^ permalink raw reply
* [PATCH] vti: fix sparse bit endian warnings
From: Stephen Hemminger @ 2012-10-11 22:51 UTC (permalink / raw)
To: David Miller, Saurabh Mohan; +Cc: netdev
Use be32_to_cpu instead of htonl to keep sparse happy.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.org>
--- a/net/ipv4/ip_vti.c 2012-10-10 11:54:57.165566432 -0700
+++ b/net/ipv4/ip_vti.c 2012-10-11 11:06:35.696333265 -0700
@@ -374,7 +374,7 @@ static netdev_tx_t vti_tunnel_xmit(struc
memset(&fl4, 0, sizeof(fl4));
flowi4_init_output(&fl4, tunnel->parms.link,
- htonl(tunnel->parms.i_key), RT_TOS(tos),
+ be32_to_cpu(tunnel->parms.i_key), RT_TOS(tos),
RT_SCOPE_UNIVERSE,
IPPROTO_IPIP, 0,
dst, tiph->saddr, 0, 0);
@@ -441,7 +441,7 @@ static int vti_tunnel_bind_dev(struct ne
struct flowi4 fl4;
memset(&fl4, 0, sizeof(fl4));
flowi4_init_output(&fl4, tunnel->parms.link,
- htonl(tunnel->parms.i_key),
+ be32_to_cpu(tunnel->parms.i_key),
RT_TOS(iph->tos), RT_SCOPE_UNIVERSE,
IPPROTO_IPIP, 0,
iph->daddr, iph->saddr, 0, 0);
^ permalink raw reply
* Re: amd64, v3.6.0: Kernel panic + BUG at net/netfilter/nf_conntrack_core.c:220!
From: Pablo Neira Ayuso @ 2012-10-11 23:32 UTC (permalink / raw)
To: Borislav Petkov, Ian Applegate, linux-kernel, netfilter-devel,
netfilter, coreteam, netdev
In-Reply-To: <20121011212733.GB26025@liondog.tnic>
On Thu, Oct 11, 2012 at 11:27:33PM +0200, Borislav Petkov wrote:
> On Thu, Oct 11, 2012 at 12:13:33PM -0700, Ian Applegate wrote:
> > On machines serving mainly http traffic we are seeing the following
> > panic, which is not yet reproducible.
>
> Must be this BUG_ON:
>
> if (!nf_ct_is_confirmed(ct)) {
> BUG_ON(hlist_nulls_unhashed(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode));
> hlist_nulls_del_rcu(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode);
> }
At quick glance, I think we're hitting a memory corruption, I don't
see by now any sane code path to reach that bugtrap.
More comments below:
> Spamming some more lists and leaving the rest for reference.
>
> >
> >
> > [180926.566743] ------------[ cut here ]------------
> > [180926.572034] kernel BUG at net/netfilter/nf_conntrack_core.c:220!
> > [180926.578873] invalid opcode: 0000 [#1] SMP
> > [180926.583594] Modules linked in: xfs exportfs ipmi_devintf ipmi_si
> > ipmi_msghandler dm_mod md_mod nf_conntr
> > ack_ipv6 nf_defrag_ipv6 ip6table_filter ip6table_raw ip6_tables
> > nf_conntrack_ipv4 nf_defrag_ipv4 xt_tcpudp x
> > t_conntrack xt_multiport iptable_filter xt_NOTRACK nf_conntrack
> > iptable_raw ip_tables x_tables nfsv4 auth_rp
> > cgss fuse nfsv3 nfs_acl nfs fscache lockd sunrpc sfc mtd i2c_algo_bit
> > i2c_core mdio igb dca uhci_hcd coretem
> > p acpi_cpufreq kvm_intel kvm crc32c_intel aesni_intel ablk_helper
> > cryptd aes_x86_64 aes_generic evdev sd_mod
> > crc_t10dif mperf snd_pcm ahci snd_timer tpm_tis microcode snd tpm
> > libahci tpm_bios soundcore libata snd_pag
> > e_alloc pcspkr ehci_hcd lpc_ich usbcore mfd_core hpsa scsi_mod
> > usb_common button processor thermal_sys
> > [180926.657762] CPU 12
> > [180926.660008] Pid: 5948, comm: nginx-fl Not tainted 3.6.0-cloudflare
> > #1 HP ProLiant DL180 G6
> > [180926.669820] RIP: 0010:[<ffffffffa02ccdd1>] [<ffffffffa02ccdd1>]
> > destroy_conntrack+0x55/0xa9 [nf_conntrack]
> > [180926.680871] RSP: 0018:ffff8805bd73fbb8 EFLAGS: 00010246
> > [180926.686930] RAX: 0000000000000000 RBX: ffff8806b6f56c30 RCX:
> > ffff8805bd73fc48
> > [180926.695055] RDX: 0000000000000000 RSI: 0000000000000006 RDI:
> > ffff8806b6f56c30
> > [180926.703179] RBP: ffffffff81651780 R08: 00000000000172e0 R09:
> > ffffffff812cef91
> > [180926.711304] R10: dead000000200200 R11: dead000000100100 R12:
> > ffff8806b6f56c30
> > [180926.727451] R13: 0000000000000000 R14: ffffffffa02d6030 R15:
> > 0000000000000000
> > [180926.735575] FS: 00007f382cdb2710(0000) GS:ffff880627cc0000(0000)
> > knlGS:0000000000000000
> > [180926.744766] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [180926.751312] CR2: ffffffffff600400 CR3: 00000005bd8d3000 CR4:
> > 00000000000007e0
> > [180926.759436] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> > 0000000000000000
> > [180926.767560] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> > 0000000000000400
> > [180926.775686] Process nginx-fl (pid: 5948, threadinfo
> > ffff8805bd73e000, task ffff8805c9755960)
> > [180926.785265] Stack:
> > [180926.787634] 0000000000000000 ffffffff81651780 ffff8802720c2900
> > ffffffffa02cde78
> > [180926.796087] ffffffff81651ec0 ffffffffa02d6030 00000000bff0efab
> > ffff8805ffffffff
> > [180926.804532] 0002880500000002 0000000300000014 0000001400000003
> > 06ff880600000002
> > [180926.812985] Call Trace:
> > [180926.815845] [<ffffffffa02cde78>] ? nf_conntrack_in+0x4ed/0x5bc
> > [nf_conntrack]
Here below the trace shows the output path to close a tcp socket. But
the line above refers to a conntrack function that is called in the
input path.
If this process is just acting as plain http server, this backtrace
doesn't seem consistent to me.
> > [180926.824069] [<ffffffff812ac195>] ? nf_iterate+0x41/0x77
> > [180926.830131] [<ffffffff812b3820>] ? ip_options_echo+0x2ed/0x2ed
> > [180926.836873] [<ffffffff812ac2ee>] ? nf_hook_slow+0x68/0xfd
> > [180926.843127] [<ffffffff812b3820>] ? ip_options_echo+0x2ed/0x2ed
> > [180926.849866] [<ffffffff812b55a8>] ? __ip_local_out+0x98/0x9d
> > [180926.856315] [<ffffffff812b55b6>] ? ip_local_out+0x9/0x19
> > [180926.862465] [<ffffffff812c7582>] ? tcp_transmit_skb+0x7ae/0x7f1
> > [180926.869305] [<ffffffff810fff4c>] ? virt_to_head_page+0x9/0x2c
> > [180926.875949] [<ffffffff812c78a6>] ? tcp_send_active_reset+0xd5/0x101
> > [180926.883175] [<ffffffff812bc38f>] ? tcp_close+0x118/0x354
> > [180926.889334] [<ffffffff812dbdc2>] ? inet_release+0x75/0x7b
> > [180926.895591] [<ffffffff81278bff>] ? sock_release+0x19/0x73
> > [180926.901845] [<ffffffff81278c7b>] ? sock_close+0x22/0x27
> > [180926.907906] [<ffffffff81109de8>] ? __fput+0xe9/0x1ae
> > [180926.913677] [<ffffffff81057157>] ? task_work_run+0x53/0x67
> > [180926.920031] [<ffffffff8100e50c>] ? do_notify_resume+0x79/0x8d
> > [180926.926673] [<ffffffff8134e5b2>] ? int_signal+0x12/0x17
> > [180926.932732] Code: 05 48 89 df ff d0 48 c7 c7 30 66 2d a0 e8 11 b0
> > 07 e1 48 89 df e8 72 25 00 00 48 8b 43
> > 78 a8 08 75 2a 48 8b 53 10 48 85 d2 75 04 <0f> 0b eb fe 48 8b 43 08
> > 48 89 02 a8 01 75 04 48 89 50 08 48 be
> > [180926.954788] RIP [<ffffffffa02ccdd1>] destroy_conntrack+0x55/0xa9
> > [nf_conntrack]
> > [180926.963217] RSP <ffff8805bd73fbb8>
> > [180926.967700] ---[ end trace 54a660a52afd5820 ]---
> > [180926.973038] Kernel panic - not syncing: Fatal exception in interrupt
> >
> > ---
> > Ian Applegate
> > CloudFlare
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
> --
> Regards/Gruss,
> Boris.
^ permalink raw reply
* Re: Fwd: [Bug 1063038] Re: Broadcom BCM57780 Cannot Connect at Gigabit Speed using tg3 module.
From: Nithin Nayak Sujir @ 2012-10-11 20:25 UTC (permalink / raw)
To: Justin Chudgar; +Cc: netdev, 1063038
In-Reply-To: <50756903.1030709@justinzane.com>
On 10/10/2012 05:24 AM, Justin Chudgar wrote:
> I've got a device with a Broadcom 57780 ethernet NIC. It uses the tg3.ko
> driver module. The problem is that this NIC cannot connect at gigabit
> (1000MBps) speed. In all cases connection works well at 100MBps. I
> reported this to Ubuntu as noted below and was directed here.
> [https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1063038] Following
> are the tests I've completed:
I don't see a problem linking up with 57780 at gigabit. I tested the latest net kernel (3.6.0) and
to make sure it's not ubuntu specific, tested ubuntu 12.04 as well (3.2.0.23-generic). Everything
works fine here on my setup.
> sudo ethtool -i eth7
driver: tg3
version: 3.121
firmware-version: 57780-v3.15
bus-info: 0000:43:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
> sudo ethtool eth7
Settings for eth7:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: external
Auto-negotiation: on
Supports Wake-on: g
Wake-on: d
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes
> ifconfig eth7
eth7 Link encap:Ethernet HWaddr 00:10:18:2a:18:cd
inet addr:3.3.3.1 Bcast:3.3.3.255 Mask:255.255.255.0
inet6 addr: fe80::210:18ff:fe2a:18cd/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1224 errors:0 dropped:0 overruns:0 frame:0
TX packets:1114 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:115500 (115.5 KB) TX bytes:146587 (146.5 KB)
Interrupt:80
> ping 3.3.3.2 -c 1
PING 3.3.3.2 (3.3.3.2) 56(84) bytes of data.
64 bytes from 3.3.3.2: icmp_req=1 ttl=64 time=0.185 ms
--- 3.3.3.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.185/0.185/0.185/0.000 ms
Nithin.
> - Cables tested with cable tester
> - Cables tested to work at gigabit speed with Realtek and Intel gigabit
> NICs.
> - All unmanaged switch ports tested at gigabit speed with other NICs.
> - Tried to connect with NetworkManager enabled and disabled.
> - Tried both dhcp and static connections.
> - Tried to renegotiate connection with `ethtool -r` both with TSO
> enabled and disabled.
> - Tried 3.2.0-23-generic 3.5.0-15-generic3.5.0-17-generic
> 3.6.0-999-generic kernels from main, xorg-edgers and mainline repos.
> - Used 'tg3_debug=1' kernel option in grub with the following output:
>
> [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.5.0-17-generic
> root=UUID=eccabacd-efb2-45b4-b7a6-2f530d50afd3 ro rootflags=subvol=@
> tg3_debug=1 i915_enable_rc6=7 i915_enable_fbc=1 lvds_downclock=1
> [ 0.000000] Kernel command line:
> BOOT_IMAGE=/vmlinuz-3.5.0-17-generic
> root=UUID=eccabacd-efb2-45b4-b7a6-2f530d50afd3 ro rootflags=subvol=@
> tg3_debug=1 i915_enable_rc6=7 i915_enable_fbc=1 lvds_downclock=1
> [ 5.963136] tg3.c:v3.123 (March 21, 2012)
> [ 5.995781] tg3 mdio bus: probed
> [ 6.005583] tg3 0000:01:00.0: >eth0: Tigon3 [partno(BCM57780) rev
> 57780001] (PCI Express) MAC address dc:0e:a1:ac:38:d5
> [ 6.005687] tg3 0000:01:00.0: >eth0: attached PHY driver [Broadcom
> BCM57780] (mii_bus:phy_addr=100:01)
> [ 6.005790] tg3 0000:01:00.0: >eth0: RXcsums[1] LinkChgREG[0]
> MIirq[0] ASF[0] TSOcap[1]
> [ 6.005887] tg3 0000:01:00.0: >eth0: dma_rwctrl[76180000]
> dma_mask[64-bit]
> [ 294.987653] tg3 0000:01:00.0: >irq 44 for MSI/MSI-X
> [ 295.893224] tg3 0000:01:00.0: >eth0: Link is down
> [ 309.887879] tg3 0000:01:00.0: >eth0: Link is up at 100 Mbps, full
> duplex
> [ 309.887886] tg3 0000:01:00.0: >eth0: Flow control is on for TX and
> on for RX
>
> Other distros' forums suggest loading broadcom.ko first; however, this
> module is no present. Any suggestions would be much appreciated.
>
> lspci -vv:
> 01:00.0 Ethernet controller: Broadcom Corporation NetLink BCM57780
> Gigabit Ethernet PCIe (rev 01)
> Subsystem: Acer Incorporated [ALI] Device 0601
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 44
> Region 0: Memory at d3400000 (64-bit, non-prefetchable) [size=64K]
> Capabilities: [48] Power Management version 3
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot+,D3cold+)
>
> Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-
> Capabilities: [60] Vendor Specific Information: Len=6c <?>
> Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Address: 00000000fee0100c Data: 4189
> Capabilities: [cc] Express (v2) Endpoint, MSI 00
> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
> <4us, L1 unlimited
> ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
> DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> Unsupported-
> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
> MaxPayload 128 bytes, MaxReadReq 512 bytes
> DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+
> TransPend+
> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
> Latency L0 <1us, L1 <32us
> ClockPM+ Surprise- LLActRep- BwNot-
> LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled-
> Retrain- CommClk+
> ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
> DLActive- BWMgmt- ABWMgmt-
> DevCap2: Completion Timeout: Range ABCD, TimeoutDis+
> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
> LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance-
> SpeedDis-, Selectable De-emphasis: -6dB
> Transmit Margin: Normal Operating Range,
> EnterModifiedCompliance- ComplianceSOS-
> Compliance De-emphasis: -6dB
> LnkSta2: Current De-emphasis Level: -6dB
> Capabilities: [100 v1] Advanced Error Reporting
> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
> UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
> UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt-
> UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
> CESta: RxErr+ BadTLP- BadDLLP- Rollover- Timeout-
> NonFatalErr-
> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
> NonFatalErr+
> AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+
> ChkEn-
> Capabilities: [13c v1] Virtual Channel
> Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
> Arb: Fixed- WRR32- WRR64- WRR128-
> Ctrl: ArbSelect=Fixed
> Status: InProgress-
> VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
> Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
> Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
> Status: NegoPending- InProgress-
> Capabilities: [160 v1] Device Serial Number dc-0e-a1-ff-fe-ac-38-d5
> Capabilities: [16c v1] Power Budgeting <?>
> Kernel driver in use: tg3
> Kernel modules: tg3
> ---
>
>
> Justin Chudgar | Weed, CA 96094 | 530 921 0738 | http://www.justinzane.com/
>
> -------- Original Message --------
> Subject: [Bug 1063038] Re: Broadcom BCM57780 Cannot Connect at Gigabit
> Speed using tg3 module.
> Date: Tue, 09 Oct 2012 14:38:45 -0000
> From: Joseph Salisbury <joseph.salisbury@canonical.com>
> Reply-To: Bug 1063038 <1063038@bugs.launchpad.net>
> To: justin@justinzane.com
>
>
>
> This issue appears to be an upstream bug, since you tested the latest
> upstream kernel. Would it be possible for you to open an upstream bug
> report[0]? That will allow the upstream Developers to examine the
> issue, and may provide a quicker resolution to the bug.
>
> Please follow the instructions on the wiki page[0]. The first step is
> to email the appropriate mailing list. If no response is received, then
> a bug may be opened on bugzilla.kernel.org.
>
> [0] https://wiki.ubuntu.com/Bugs/Upstream/kernel
>
>
> ** Changed in: linux (Ubuntu)
> Status: Confirmed => Triaged
>
> ** Changed in: linux (Ubuntu)
> Importance: Undecided => Medium
>
> ** Tags added: kernel-bug-exists-upstream
>
^ permalink raw reply
* Re: unresponsive vlan on top of bond with fail_over_mac=active
From: Jay Vosburgh @ 2012-10-12 0:33 UTC (permalink / raw)
To: Michal Kubecek; +Cc: netdev, Andy Gospodarek
In-Reply-To: <20121011103757.GA13873@unicorn.suse.cz>
Michal Kubecek <mkubecek@suse.cz> wrote:
>On Wed, Oct 10, 2012 at 08:34:31PM -0700, Jay Vosburgh wrote:
>> Michal Kubecek <mkubecek@suse.cz> wrote:
>> What network device are they using that requires fail_over_mac
>> to be set to active?
>
>I would have to ask for exact configuration, all I know for sure is that
>the problem was reported for s390x (S390-64) architecture. I reproduced
>it with VMware Workstation virtual devices which emulate Intel e1000.
Have you tried the "follow" setting to fail_over_mac?
I looked into this very topic (VLAN address propagation on s390)
earlier this year. The eventual solution for that case was to use the
"follow" fail_over_mac option, which resolved the problem for the OSA
device (qeth).
I did submit a patch to do MAC address propagation to VLANs, but
then withdrew it after I figured out that "follow" would also resolve
the problem without code changes.
http://patchwork.ozlabs.org/patch/153551/
>> I tested some of this out earlier this year, and I don't recall
>> having problems (although I'm not sure I did this exact test). The
>> dev_uc_add() logic (in __dev_set_rx_mode) would put the underlying
>> device into promiscuous mode if the hardware didn't support multiple
>> unicast MAC addresses. dev_uc_add() was invoked by vlan_sync_address(),
>> which is called by the vlan NETDEV_CHANGEADDR notifier callback.
>
>Yes, this part works fine, I checked uc list with live crash session.
>But as bonding driver doesn't set its ndo_set_rx_mode method, the
>iformation about second MAC address doesn't propagate down to the
>slaves.
What kernel are you looking at? In current mainline, bonding
does have bond_set_multicast_list as ndo_set_rx_mode, although it
doesn't propagate unicast address information, only multicast. I
believe this has been the case for a long time.
>> Bonding does propagate promisc to its slaves, but (as you point
>> out) not the uc lists; is the hardware in question something that
>> supports multiple unicast addresses (IFF_UNICAST_FLT)? The device I
>> tested with does not support IFF_UNICAST_FLT, and (as I recall) would
>> end up in promisc mode.
>
>My tests were done with (emulated) e1000 which supports unicast
>filtering (up to 14 addresses, according to what I've seen in the
>driver). I'm not sure about the devices on s390x.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* [PATCH] bridge: don't flood multicast packets if no snooping entry
From: Lin Ming @ 2012-10-12 1:17 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
From: Lin Ming <mlin@ss.pku.edu.cn>
Currently, multicast packets will be flood even if there is no
mutlicast snooping entry attached to port.
With IGMP snooping enabled, we should stop sending multicast packets
if there is no member joined.
Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
---
net/bridge/br_input.c | 2 ++
net/bridge/br_private.h | 2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index 76f15fd..2821085 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -90,6 +90,8 @@ int br_handle_frame_finish(struct sk_buff *skb)
skb = NULL;
if (!skb2)
goto out;
+ } else if (!mdst && BR_INPUT_SKB_CB_NOT_IGMP(skb)) {
+ skb = NULL;
} else
skb2 = skb;
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 9b278c4..e2c894d 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -268,8 +268,10 @@ struct br_input_skb_cb {
#ifdef CONFIG_BRIDGE_IGMP_SNOOPING
# define BR_INPUT_SKB_CB_MROUTERS_ONLY(__skb) (BR_INPUT_SKB_CB(__skb)->mrouters_only)
+# define BR_INPUT_SKB_CB_NOT_IGMP(__skb) (!BR_INPUT_SKB_CB(__skb)->igmp)
#else
# define BR_INPUT_SKB_CB_MROUTERS_ONLY(__skb) (0)
+# define BR_INPUT_SKB_CB_NOT_IGMP(__skb) (0)
#endif
#define br_printk(level, br, format, args...) \
--
1.7.2.5
^ permalink raw reply related
* Re: BUG: unable to handle kernel NULL pointer dereference in qfq_dequeue()
From: Cong Wang @ 2012-10-12 1:25 UTC (permalink / raw)
To: Eric Dumazet
Cc: stephen hemminger, David S. Miller, netdev, Thomas Graf, rizzo
In-Reply-To: <1349968843.21172.9508.camel@edumazet-glaptop>
On Thu, 2012-10-11 at 17:20 +0200, Eric Dumazet wrote:
>
> I just realize its a 2.6.32 redhat kernel, while QFQ is a 3.0 addition.
>
> Can you reproduce the bug on current kernel (3.6 or git tree)
>
Sure, the gdb backtrace is from the latest -net kernel.
^ permalink raw reply
* Re: [PATCH 01/12] usbnet: introduce usbnet 3 command helpers
From: Ming Lei @ 2012-10-12 1:43 UTC (permalink / raw)
To: Alan Stern
Cc: Oliver Neukum, David S. Miller, Greg Kroah-Hartman, netdev,
linux-usb
In-Reply-To: <Pine.LNX.4.44L0.1210111030570.1170-100000@iolanthe.rowland.org>
On Thu, Oct 11, 2012 at 10:36 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
>
> It's worse than you may realize. When a SCSI disk is suspended, all of
> its ancestor devices may be suspended too. Pages can't be read in from
> the drive until all those ancestors are resumed. This means that all
> runtime resume code paths for all drivers that could be bound to an
> ancestor of a block device must avoid GFP_KERNEL. In practice it's
Exactly, so several subsystems(for example, pci, usb, scsi) will be involved,
and converting GFP_KERNEL in runtime PM path to GFP_NOIO becomes
more difficult.
> probably easiest for the runtime PM core to use tsk_set_allowd_gfp()
> before calling any runtime_resume method.
Yes, it might be done in usb runtime resume context because all
usb device might include a mass storage interface. But, in fact,
we can find if there is one mass storage interface on the current
configuration easily inside usb_runtime_resume().
Also, we can loose the constraint in runtime PM core, before calling
runtime_resume callback for one device, the current context is marked
as ~GFP_IOFS only if it is a block device or there is one block device
descendant. But the approach becomes a bit complicated because
device tree traversing is involved.
Thanks,
--
Ming Lei
^ permalink raw reply
* Re: [PATCH] bridge: don't flood multicast packets if no snooping entry
From: Herbert Xu @ 2012-10-12 1:48 UTC (permalink / raw)
To: Lin Ming; +Cc: netdev
In-Reply-To: <1350004643-3786-1-git-send-email-minggr@gmail.com>
On Fri, Oct 12, 2012 at 09:17:23AM +0800, Lin Ming wrote:
> From: Lin Ming <mlin@ss.pku.edu.cn>
>
> Currently, multicast packets will be flood even if there is no
> mutlicast snooping entry attached to port.
>
> With IGMP snooping enabled, we should stop sending multicast packets
> if there is no member joined.
Hmm, the default is deliberately this way so that we don't disrupt
traffic when we boot up. If you want to stop flooding unknown groups
by default you have to make it an option.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] bridge: don't flood multicast packets if no snooping entry
From: Lin Ming @ 2012-10-12 2:14 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20121012014852.GA17025@gondor.apana.org.au>
On Fri, Oct 12, 2012 at 9:48 AM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Fri, Oct 12, 2012 at 09:17:23AM +0800, Lin Ming wrote:
>> From: Lin Ming <mlin@ss.pku.edu.cn>
>>
>> Currently, multicast packets will be flood even if there is no
>> mutlicast snooping entry attached to port.
>>
>> With IGMP snooping enabled, we should stop sending multicast packets
>> if there is no member joined.
>
> Hmm, the default is deliberately this way so that we don't disrupt
> traffic when we boot up. If you want to stop flooding unknown groups
> by default you have to make it an option.
Do you mean adding a sysfs entry, for example
/sys/class/net/br0/bridge/multicast_no_flood ?
Thanks.
>
> Cheers,
^ permalink raw reply
* Re: [PATCH] bridge: don't flood multicast packets if no snooping entry
From: Herbert Xu @ 2012-10-12 2:27 UTC (permalink / raw)
To: Lin Ming; +Cc: netdev
In-Reply-To: <CAF1ivSbpwJqauL+S7FeozrkjkMcUyuOivv_Qk68Hme4uipq-yw@mail.gmail.com>
On Fri, Oct 12, 2012 at 10:14:00AM +0800, Lin Ming wrote:
>
> Do you mean adding a sysfs entry, for example
> /sys/class/net/br0/bridge/multicast_no_flood ?
Yes something like that.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: conntrack, NAT and icmp echo reply
From: Vigneswaran R @ 2012-10-12 5:13 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: Eric Dumazet, netdev, netfilter
In-Reply-To: <10293136eb284457b47cbffd6c91d1ef@visp.net.lb>
On Thursday 11 October 2012 03:32 PM, Denys Fedoryshchenko wrote:
> On 2012-10-11 12:57, Eric Dumazet wrote:
>> On Thu, 2012-10-11 at 12:41 +0300, Denys Fedoryshchenko wrote:
>>> Hi all
>>>
>>> I have NAT box, with very simple rule
>>> iptables -t nat -I POSTROUTING -s 10.0.0.0/8 -j MASQUERADE
>>> It can be SNAT also, and it works fine, as NAT.
>>>
>>> When i generate icmp _reply_ packet, to some host
>>> hping -I ppp0 -1 --icmptype 0 8.8.8.8
>>>
>>> It will pass the box, and will exit it without NAT, e.g. with original
>>> IP 10.x.x.x
>>> on outgoing interface, which is not expected behavior IMHO.
>>> Is it a bug or feature?
>>>
>>
>> It depends, -s 10.0.0.0/8 wont match the rule if the source address
>> should be 198.23.44.55 I guess ?
>>
>> I would try the more obvious
>>
>> iptables -t nat -I POSTROUTING -o device -j MASQUERADE
> Source is correct, it is 10.0.0.0/8 range. I tested also ICMP code 3,
> it wont be NATed also.
> But ICMP echo passing OK.
> Also TCP RST generated same way, (i guess that don't have any match in
> conntrack table), won't be NATed too.
> hping -I ppp0 -R 8.8.8.8
> 13:01:07.074134 IP 10.0.0.142.2106 > 8.8.8.8.0: Flags [R], seq
> 510333079, win 512, length 0
> 13:01:08.074239 IP 10.0.0.142.2107 > 8.8.8.8.0: Flags [R], seq
> 1169580528, win 512, length 0
> 13:01:09.074253 IP 10.0.0.142.2108 > 8.8.8.8.0: Flags [R], seq
> 186548661, win 512, length 0
> 13:01:10.074376 IP 10.0.0.142.2109 > 8.8.8.8.0: Flags [R], seq
> 2135508128, win 512, length 0
> 13:01:11.074553 IP 10.0.0.142.2110 > 8.8.8.8.0: Flags [R], seq
> 1507433100, win 512, length 0
>
> And ICMP here you can see correct behavior with icmp echo request:
>
> 12:58:22.917458 IP 10.0.0.142 > 8.8.8.8: ICMP echo reply, id 62548,
> seq 0, length 8
> 12:58:23.917543 IP 10.0.0.142 > 8.8.8.8: ICMP echo reply, id 62548,
> seq 256, length 8
> 12:58:24.917657 IP 10.0.0.142 > 8.8.8.8: ICMP echo reply, id 62548,
> seq 512, length 8
> 12:58:31.047475 IP 10.0.0.142 > 8.8.8.8: ICMP net 5.6.7.8 unreachable,
> length 36
> 12:58:32.047562 IP 10.0.0.142 > 8.8.8.8: ICMP net 5.6.7.8 unreachable,
> length 36
> 12:58:33.047734 IP 10.0.0.142 > 8.8.8.8: ICMP net 5.6.7.8 unreachable,
> length 36
> 12:58:54.014601 IP X.146.153.X > 8.8.8.8: ICMP echo request, id 10462,
> seq 0, length 8
> 12:58:54.081897 IP 8.8.8.8 > X.146.153.X: ICMP echo reply, id 10462,
> seq 0, length 8
I think, the following may be the reason for the behaviour you observed.
(I may be wrong, I am not an expert in iptables.)
"nat" table only consulted for "NEW" connections. ref:
<http://inai.de/images/nf-packet-flow.svg>
The ICMP echo _reply_ may not be considered as part of a "NEW"
connection, as it must be a _reply_ to some already received _request_.
So _request_ is new and _reply_ is not.
Regards,
Vignesh
^ permalink raw reply
* Re: [PATCH] bridge: don't flood multicast packets if no snooping entry
From: Lin Ming @ 2012-10-12 5:19 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20121012022708.GA17230@gondor.apana.org.au>
On Fri, Oct 12, 2012 at 10:27 AM, Herbert Xu
<herbert@gondor.apana.org.au> wrote:
> On Fri, Oct 12, 2012 at 10:14:00AM +0800, Lin Ming wrote:
>>
>> Do you mean adding a sysfs entry, for example
>> /sys/class/net/br0/bridge/multicast_no_flood ?
>
> Yes something like that.
Or a better name: multicast_fast_leave
Quote from Internet:
"
IGMP Fast Leave enhances your control over router or switch bandwidth.
Enabling Fast Leave tells IGMP snooping to stop the transmission of a
group multicast stream to a port as soon as it receives a Leave message
on that port. No timeouts are observed.
Ordinarily, when IGMP snooping sees a Leave message, it waits for a
Membership Query message before setting the entry timeout to 2 seconds.
Fast Leave tells IGMP to drop the entry from the port as soon as the
Leave message is seen. For this reason, Fast Leave should only be
configured on interfaces that have one client per port.
"
I'm going to add fast leave support. It would need other changes in
addition to this patch.
Thanks.
>
> Cheers,
^ permalink raw reply
* [PATCH] Ip6{In,Out}BcastPkts statistics missing from /proc/net/snmp6
From: Niels Baggesen @ 2012-10-12 5:57 UTC (permalink / raw)
To: netdev
The subject line says it all:
Ip6{In,Out}BcastPkts statistics missing from /proc/net/snmp6
Signed-off-by: Niels Baggesen <nba@users.sourceforge.net>
--- net/ipv6/proc.c.orig 2012-10-01 12:52:09.452543199 +0200
+++ net/ipv6/proc.c 2012-10-01 12:53:19.794660628 +0200
@@ -90,6 +90,8 @@
SNMP_MIB_ITEM("Ip6OutMcastOctets", IPSTATS_MIB_OUTMCASTOCTETS),
SNMP_MIB_ITEM("Ip6InBcastOctets", IPSTATS_MIB_INBCASTOCTETS),
SNMP_MIB_ITEM("Ip6OutBcastOctets", IPSTATS_MIB_OUTBCASTOCTETS),
+ SNMP_MIB_ITEM("Ip6InBcastPkts", IPSTATS_MIB_INBCASTPKTS),
+ SNMP_MIB_ITEM("Ip6OutBcastPkts", IPSTATS_MIB_OUTBCASTPKTS),
SNMP_MIB_SENTINEL
};
/Niels
--
Niels Baggesen - @home - Århus - Denmark - nba@users.sourceforge.net
The purpose of computing is insight, not numbers --- R W Hamming
^ permalink raw reply
* Re: [PATCH] Ip6{In,Out}BcastPkts statistics missing from /proc/net/snmp6
From: David Miller @ 2012-10-12 6:26 UTC (permalink / raw)
To: nba; +Cc: netdev
In-Reply-To: <S1754219Ab2JLF5l/20121012055742Z+351@vger.kernel.org>
From: Niels Baggesen <nba@users.sourceforge.net>
Date: Fri, 12 Oct 2012 01:57:41 -0400
> The subject line says it all:
Your email client corrupted your patch.
Fix this, and email yourself the patch validating that what you
receive you can apply successfully.
Only after you can do this should you resubmit your patch here.
^ permalink raw reply
* Re: [PATCH] Ip6{In,Out}BcastPkts statistics missing from /proc/net/snmp6
From: Eric Dumazet @ 2012-10-12 6:30 UTC (permalink / raw)
To: Niels Baggesen; +Cc: netdev
In-Reply-To: <S1754091Ab2JLF5l/20121012055741Z+350@vger.kernel.org>
On Fri, 2012-10-12 at 01:57 -0400, Niels Baggesen wrote:
> The subject line says it all:
>
> Ip6{In,Out}BcastPkts statistics missing from /proc/net/snmp6
>
> Signed-off-by: Niels Baggesen <nba@users.sourceforge.net>
>
>
> --- net/ipv6/proc.c.orig 2012-10-01 12:52:09.452543199 +0200
> +++ net/ipv6/proc.c 2012-10-01 12:53:19.794660628 +0200
> @@ -90,6 +90,8 @@
> SNMP_MIB_ITEM("Ip6OutMcastOctets", IPSTATS_MIB_OUTMCASTOCTETS),
> SNMP_MIB_ITEM("Ip6InBcastOctets", IPSTATS_MIB_INBCASTOCTETS),
> SNMP_MIB_ITEM("Ip6OutBcastOctets", IPSTATS_MIB_OUTBCASTOCTETS),
> + SNMP_MIB_ITEM("Ip6InBcastPkts", IPSTATS_MIB_INBCASTPKTS),
> + SNMP_MIB_ITEM("Ip6OutBcastPkts", IPSTATS_MIB_OUTBCASTPKTS),
> SNMP_MIB_SENTINEL
> };
>
> /Niels
>
And does it give useful information ?
As far as I know, IPv6 doesnt increment these counters, but I might be
wrong.
^ permalink raw reply
* Re: conntrack, NAT and icmp echo reply
From: Denys Fedoryshchenko @ 2012-10-12 6:59 UTC (permalink / raw)
To: Vigneswaran R; +Cc: Eric Dumazet, netdev, netfilter
In-Reply-To: <5077A707.1030709@atc.tcs.com>
On 2012-10-12 09:13, Vigneswaran R wrote:
> On Thursday 11 October 2012 03:32 PM, Denys Fedoryshchenko wrote:
>> On 2012-10-11 12:57, Eric Dumazet wrote:
>>> On Thu, 2012-10-11 at 12:41 +0300, Denys Fedoryshchenko wrote:
>>>> Hi all
>>>>
>>>> I have NAT box, with very simple rule
>>>> iptables -t nat -I POSTROUTING -s 10.0.0.0/8 -j MASQUERADE
>>>> It can be SNAT also, and it works fine, as NAT.
>>>>
>>>> When i generate icmp _reply_ packet, to some host
>>>> hping -I ppp0 -1 --icmptype 0 8.8.8.8
>>>>
>>>> It will pass the box, and will exit it without NAT, e.g. with
>>>> original
>>>> IP 10.x.x.x
>>>> on outgoing interface, which is not expected behavior IMHO.
>>>> Is it a bug or feature?
>>>>
>>>
>>> It depends, -s 10.0.0.0/8 wont match the rule if the source address
>>> should be 198.23.44.55 I guess ?
>>>
>>> I would try the more obvious
>>>
>>> iptables -t nat -I POSTROUTING -o device -j MASQUERADE
>> Source is correct, it is 10.0.0.0/8 range. I tested also ICMP code
>> 3, it wont be NATed also.
>> But ICMP echo passing OK.
>> Also TCP RST generated same way, (i guess that don't have any match
>> in conntrack table), won't be NATed too.
>> hping -I ppp0 -R 8.8.8.8
>> 13:01:07.074134 IP 10.0.0.142.2106 > 8.8.8.8.0: Flags [R], seq
>> 510333079, win 512, length 0
>> 13:01:08.074239 IP 10.0.0.142.2107 > 8.8.8.8.0: Flags [R], seq
>> 1169580528, win 512, length 0
>> 13:01:09.074253 IP 10.0.0.142.2108 > 8.8.8.8.0: Flags [R], seq
>> 186548661, win 512, length 0
>> 13:01:10.074376 IP 10.0.0.142.2109 > 8.8.8.8.0: Flags [R], seq
>> 2135508128, win 512, length 0
>> 13:01:11.074553 IP 10.0.0.142.2110 > 8.8.8.8.0: Flags [R], seq
>> 1507433100, win 512, length 0
>>
>> And ICMP here you can see correct behavior with icmp echo request:
>>
>> 12:58:22.917458 IP 10.0.0.142 > 8.8.8.8: ICMP echo reply, id 62548,
>> seq 0, length 8
>> 12:58:23.917543 IP 10.0.0.142 > 8.8.8.8: ICMP echo reply, id 62548,
>> seq 256, length 8
>> 12:58:24.917657 IP 10.0.0.142 > 8.8.8.8: ICMP echo reply, id 62548,
>> seq 512, length 8
>> 12:58:31.047475 IP 10.0.0.142 > 8.8.8.8: ICMP net 5.6.7.8
>> unreachable, length 36
>> 12:58:32.047562 IP 10.0.0.142 > 8.8.8.8: ICMP net 5.6.7.8
>> unreachable, length 36
>> 12:58:33.047734 IP 10.0.0.142 > 8.8.8.8: ICMP net 5.6.7.8
>> unreachable, length 36
>> 12:58:54.014601 IP X.146.153.X > 8.8.8.8: ICMP echo request, id
>> 10462, seq 0, length 8
>> 12:58:54.081897 IP 8.8.8.8 > X.146.153.X: ICMP echo reply, id 10462,
>> seq 0, length 8
>
> I think, the following may be the reason for the behaviour you
> observed. (I may be wrong, I am not an expert in iptables.)
>
> "nat" table only consulted for "NEW" connections. ref:
> <http://inai.de/images/nf-packet-flow.svg>
>
> The ICMP echo _reply_ may not be considered as part of a "NEW"
> connection, as it must be a _reply_ to some already received
> _request_. So _request_ is new and _reply_ is not.
>
>
> Regards,
> Vignesh
Yes, they are not related to existing and it is not new connection, but
there is similar issues related to TCP, and it is handled differently.
For example if nf_conntrack_tcp_loose is set to 0 - it will not pickup
already established connections, and just they will have INVALID state.
If set to 1 (and it is default value) - it will pickup the connection,
even it is established state. I was expecting ICMP and especially RST
can be consistent with that.
---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
^ permalink raw reply
* [PATCH 1/2] net: add doc for in6_pton()
From: Cong Wang @ 2012-10-12 7:06 UTC (permalink / raw)
To: netdev; +Cc: Cong Wang, David S. Miller
It is not easy to use in6_pton() correctly without reading
its definition, so add some doc for it.
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
net/core/utils.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/net/core/utils.c b/net/core/utils.c
index f5613d5..30f3879 100644
--- a/net/core/utils.c
+++ b/net/core/utils.c
@@ -161,6 +161,18 @@ out:
}
EXPORT_SYMBOL(in4_pton);
+/**
+ * in6_pton - convert an IPv6 address from literal to binary representation
+ * @src: the start of the IPv6 address string
+ * @srclen: the length of the string, -1 means strlen(src)
+ * @dst: the binary (u8[16] array) representation of the IPv6 address
+ * @delim: the delimiter of the IPv6 address in @src, -1 means no delimiter
+ * @end: A pointer to the end of the parsed string will be placed here
+ *
+ * Return one on success, return zero when any error occurs
+ * and @end will point to the end of the parsed string.
+ *
+ */
int in6_pton(const char *src, int srclen,
u8 *dst,
int delim, const char **end)
--
1.7.7.6
^ permalink raw reply related
* [PATCH 2/2] net: add doc for in4_pton()
From: Cong Wang @ 2012-10-12 7:06 UTC (permalink / raw)
To: netdev; +Cc: Cong Wang, David S. Miller
In-Reply-To: <1350025577-792-1-git-send-email-amwang@redhat.com>
It is not easy to use in4_pton() correctly without reading
its definition, so add some doc for it.
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
net/core/utils.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/net/core/utils.c b/net/core/utils.c
index 30f3879..e3487e46 100644
--- a/net/core/utils.c
+++ b/net/core/utils.c
@@ -107,6 +107,18 @@ static inline int xdigit2bin(char c, int delim)
return IN6PTON_UNKNOWN;
}
+/**
+ * in4_pton - convert an IPv4 address from literal to binary representation
+ * @src: the start of the IPv4 address string
+ * @srclen: the length of the string, -1 means strlen(src)
+ * @dst: the binary (u8[4] array) representation of the IPv4 address
+ * @delim: the delimiter of the IPv4 address in @src, -1 means no delimiter
+ * @end: A pointer to the end of the parsed string will be placed here
+ *
+ * Return one on success, return zero when any error occurs
+ * and @end will point to the end of the parsed string.
+ *
+ */
int in4_pton(const char *src, int srclen,
u8 *dst,
int delim, const char **end)
--
1.7.7.6
^ permalink raw reply related
* [patch] RDS: fix an integer overflow check
From: Dan Carpenter @ 2012-10-12 7:31 UTC (permalink / raw)
To: Venkat Venkatsubra; +Cc: David S. Miller, rds-devel, netdev, kernel-janitors
"len" is an int. We verified that len was postive already. Since
PAGE_SIZE is specified as an unsigned long, the type it promoted to
unsigned and the condition is never true.
I'm not sure this check is actually needed. It might be that we could
just remove it?
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/net/rds/info.c b/net/rds/info.c
index 9a6b4f6..4d62618 100644
--- a/net/rds/info.c
+++ b/net/rds/info.c
@@ -176,7 +176,7 @@ int rds_info_getsockopt(struct socket *sock, int optname, char __user *optval,
/* check for all kinds of wrapping and the like */
start = (unsigned long)optval;
- if (len < 0 || len + PAGE_SIZE - 1 < len || start + len < start) {
+ if (len < 0 || len > INT_MAX - (PAGE_SIZE - 1) || start + len < start) {
ret = -EINVAL;
goto out;
}
^ permalink raw reply related
* Re: [PATCH 0/3] virtio-net: inline header support
From: Paolo Bonzini @ 2012-10-12 7:38 UTC (permalink / raw)
To: Rusty Russell
Cc: kvm, Michael S. Tsirkin, netdev, linux-kernel, virtualization,
Sasha Levin, avi, Thomas Lendacky
In-Reply-To: <87wqyw63et.fsf@rustcorp.com.au>
Il 12/10/2012 00:37, Rusty Russell ha scritto:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
>> On Thu, Oct 11, 2012 at 10:33:31AM +1030, Rusty Russell wrote:
>>> OK. Well, Anthony wants qemu to be robust in this regard, so I am
>>> tempted to rework all the qemu drivers to handle arbitrary layouts.
>>> They could use a good audit anyway.
>>
>> I agree here. Still trying to understand whether we can agree to use
>> a feature bit for this, or not.
>
> I'd *like* to imply it by the new PCI layout, but if it doesn't work
> we'll add a new feature bit.
>
> I'm resisting a feature bit, since it constrains future implementations
> which could otherwise assume it.
Future implementations may certainly refuse to start if the feature is
not there. Whether it's a good idea or not, well, that depends on how
much future they are.
Paolo
>>> This would become a glaring exception, but I'm tempted to fix it to 32
>>> bytes at the same time as we get the new pci layout (ie. for the virtio
>>> 1.0 spec).
>>
>> But this isn't a virtio-pci only issue, is it?
>> qemu has s390 bus with same limmitation.
>> How can we tie it to pci layout?
>
> They can use a transport feature if they need to, of course. But
> perhaps the timing with ccw will coincide with the fix, in which they
> don't need to, but it might be a bit late.
>
> Cornelia?
>
> Cheers,
> Rusty.
>
^ permalink raw reply
* Re: [patch] isdn: fix a wrapping bug in isdn_ppp_ioctl()
From: Karsten Keil @ 2012-10-12 7:49 UTC (permalink / raw)
To: Joe Perches
Cc: David Laight, Andreas Schwab, Dan Carpenter, Karsten Keil,
David S. Miller, Masanari Iida, netdev, kernel-janitors
In-Reply-To: <1349884342.2035.1.camel@joe-AO722>
Hi,
Am 10.10.2012 17:52, schrieb Joe Perches:
> On Wed, 2012-10-10 at 16:44 +0100, David Laight wrote:
>>> On Wed, 2012-10-10 at 15:59 +0100, David Laight wrote:
>>>> Seems to me the code is expecting 256 bits of data, not any multiple of int,
>>>> long or anything else.
>>>
>>> include/linux/isdn_ppp.h:#define PPPIOCGCOMPRESSORS _IOR('t',134,unsigned long [8])
>>
>> That doesn't mean the whole thing makes any sense on 64bit systems.
>> A whole load of historic code used 'long' to ensure 32bit.
>> Some of that might have crept into Linux sources.
>
> Very true, but it's exported via copy_to_user.
>
>> Since I suspect there are a maximum of 256 bits on both 32 and 64bit
>> systems, I wouldn't like to guess exactly how any particular 64bit
>> application chooses to check the bitmap.
>>
>> The ioctl constant may be wrong on 64 bit systems.
>
> shrug. Not much to do about it now.
> isdn isn't very active.
>
> Karsten? What do you think?
>
I use ipppd as testbench to test remote connections via different PPP
clients running on a 64 bit system without problems so far - but I did
not use any compressions for some years, so maybe this code was never
tested on 64 bit and at least not on mixed 32/64 bit systems.
If I will find some time, I will check if the compression works.
I did not wrote this part, so I cannot say how the code should work
correctly out of the box, I need to analyze this first by myself.
Karsten
^ permalink raw reply
* Re: Fw: [Bug 48701] New: Kernel OOPS when transmitting packets using OVS and DSA
From: Pravin Shelar @ 2012-10-12 8:07 UTC (permalink / raw)
To: barry-RiHDFbPRhGT6V6G2DxALlg
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
Stephen Hemminger
In-Reply-To: <20121011093217.44ec3c44-We1ePj4FEcvRI77zikRAJc56i+j3xesD0e7PPNI6Mm0@public.gmane.org>
I could not reproduce it on x86_64 arch and I do not have access to PPC or DSA,
now I am looking at code. meanwhile can you try to reproduce it only with PPC
without DSA, so that we can narrow it down?
one more thing, Are you using any openflow rule for this network or
are there any vlan configured?
Thanks,
Pravin.
On Thu, Oct 11, 2012 at 9:32 AM, Stephen Hemminger
<shemminger-ZtmgI6mnKB3QT0dZR+AlfA@public.gmane.org> wrote:
>
>
> Begin forwarded message:
>
> Date: Thu, 11 Oct 2012 16:13:39 +0000 (UTC)
> From: bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.org
> To: shemminger-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org
> Subject: [Bug 48701] New: Kernel OOPS when transmitting packets using OVS and DSA
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=48701
>
> Summary: Kernel OOPS when transmitting packets using OVS and
> DSA
> Product: Networking
> Version: 2.5
> Kernel Version: 3.6.1
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Other
> AssignedTo: shemminger-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org
> ReportedBy: barry-RiHDFbPRhGT6V6G2DxALlg@public.gmane.org
> CC: jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org
> Regression: No
>
>
> When I compiled the kernel (3.6.1 mainline) with distributed switch
> architectural (DSA) and OVS (OpenvSwich), I can pass ping traffic fine, but
> larger packets cause an oops.
>
> This is on a Freescale 83XX Processor:
> # uname -a
> Linux PPCTEST 3.6.1+ #1 PREEMPT Thu Oct 11 08:36:35 PDT 2012 ppc GNU/Linux
> # Unable to handle kernel paging request for data at address 0x12000007
> Faulting instruction address: 0xc008b5ec
> Oops: Kernel access of bad area, sig: 11 [#1]
> PREEMPT SEL B1305
> Modules linked in:
> NIP: c008b5ec LR: c008b5e0 CTR: c0041a68
> REGS: dfffbb30 TRAP: 0300 Not tainted (3.6.1+)
> MSR: 00001032 <ME,IR,DR,RI> CR: 22048024 XER: 00000000
> DAR: 12000007, DSISR: 20000000
> TASK = c0407368[0] 'swapper' THREAD: c0424000
> GPR00: c008b5e0 dfffbbe0 c0407368 00100100 00000001 dfb91720 000000c3 c040ae80
> GPR08: 00000000 00000000 c0440d30 c07fd000 24048022 101810a0 c03a79b8 c03abacc
> GPR16: c042e474 00200000 dfffbc1c c034be84 c034be6c dfffbc18 00000000 00008100
> GPR24: 00000000 dfabc000 00000000 df9b8384 00009032 dfb91720 00100100 12000007
> NIP [c008b5ec] kfree+0x64/0xd4
> LR [c008b5e0] kfree+0x58/0xd4
> Call Trace:
> [dfffbbe0] [c008b5e0] kfree+0x58/0xd4 (unreliable)
> [dfffbbf8] [c0217300] skb_free_head+0x4c/0x5c
> [dfffbc00] [c0217bbc] __kfree_skb+0x18/0xbc
> [dfffbc10] [c0314c94] do_execute_actions+0x5f8/0x650
> [dfffbc78] [c0316158] ovs_dp_process_received_packet+0xbc/0xe8
> [dfffbd18] [c0319900] ovs_vport_receive+0x64/0x78
> [dfffbd30] [c031a30c] netdev_frame_hook+0xa0/0xb8
> [dfffbd48] [c021ff68] __netif_receive_skb+0x50c/0x6d0
> [dfffbdb0] [c02f1e1c] dsa_rcv+0x228/0x24c
> [dfffbde0] [c02200b8] __netif_receive_skb+0x65c/0x6d0
> [dfffbe48] [c0221668] napi_skb_finish+0x38/0x88
> [dfffbe58] [c01f5a14] gfar_clean_rx_ring+0x3a4/0x4b0
> [dfffbeb8] [c01f87ac] gfar_poll+0x4c0/0x5dc
> [dfffbf78] [c0225040] net_rx_action+0x74/0x180
> [dfffbfa8] [c001d144] __do_softirq+0xac/0x13c
> [dfffbff0] [c000bd20] call_do_softirq+0x14/0x24
> [c0425e80] [c000500c] do_softirq+0x70/0xb0
> [c0425ea0] [c001d220] irq_exit+0x4c/0x80
> [c0425ea8] [c0005158] do_IRQ+0x10c/0x128
> [c0425ed0] [c000dce0] ret_from_except+0x0/0x14
> --- Exception: 501 at cpu_idle+0x98/0xec
> LR = cpu_idle+0x98/0xec
> [c0425f90] [c0007f08] cpu_idle+0x54/0xec (unreliable)
> [c0425fa8] [c0003d58] rest_init+0x78/0xa0
> [c0425fc0] [c03dc934] start_kernel+0x288/0x29c
> [c0425ff0] [00003438] 0x3438
> Instruction dump:
> 5529c9f4 7c09582e 7c695a14 70098000 41a20008 8063001c 83c30014 7cbd2b78
> 480fec99 5463103a 7c63f214 83e30058 <813f0000> 801f0004 7f890040 41bc0010
> ---[ end trace ffca2b34cb60156e ]---
>
> Kernel panic - not syncing: Fatal exception in interrupt
> Rebooting in 10 seconds..
>
> This is 100% repeatable.
>
> I had to do some small kernel tweaks to get the DSA drivers to find the
> hardware, so it is possible I broke something, but unlikely since my changes
> were not in this area at all.
>
> Barry
>
> --
> Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug.
> _______________________________________________
> dev mailing list
> dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org
> http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: alignment faults in 3.6
From: Arnd Bergmann @ 2012-10-12 8:11 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Måns Rullgård, David Laight, Russell King - ARM Linux,
Eric Dumazet, netdev, Jon Masters
In-Reply-To: <yw1xtxu1nfsn.fsf@unicorn.mansr.com>
On Thursday 11 October 2012, Måns Rullgård wrote:
> > But, the IP header is expected to be aligned.
>
> Everything tells the compiler the struct is perfectly aligned. When the
> buggy driver passes a misaligned pointer, bad things happen.
Would it be appropriate to add a WARN_ON_ONCE() in the alignment fault path
then? If all alignment faults in the kernel are caused by broken drivers,
that would at least give us some hope of finding those drivers while at the
same time not causing much overhead in the case where we need to do the
fixup in the meantime.
Arnd
^ 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