* 3.6.10 tcp crash - net/ipv4/tcp.c:1667 & tcp.c:1655
From: Benjamin LaHaise @ 2012-12-17 17:41 UTC (permalink / raw)
To: netdev
Hi folks,
I just hit the following crash with Fedora's 3.6.10-2.fc17 kernel. I don't
have time to debug this myself at the moment, but can certainly test patches
or provide more info as needed. I wasn't doing anything unusual at the time,
just reading email/web browsing. I believe the network driver in use was
ipheth for tethering to an iPhone 4S over USB (the other driver being used
intermittently on this laptop is iwlwifi). Any ideas?
-ben
--
"Thought is the essence of where you are now."
Dec 17 12:28:40 lappy kernel: [ 4044.846922] ------------[ cut here ]------------
Dec 17 12:28:40 lappy kernel: [ 4044.846931] WARNING: at net/ipv4/tcp.c:1667 tcp_recvmsg+0xc25/0xd80()
Dec 17 12:28:40 lappy kernel: [ 4044.846933] Hardware name: HP Pavilion dv7 Notebook PC
Dec 17 12:28:40 lappy kernel: [ 4044.846935] recvmsg bug 2: copied DE50E114 seq 90D65A21 rcvnxt DE50E114 fl 0
Dec 17 12:28:40 lappy kernel: [ 4044.846936] Modules linked in: fuse lockd sunrpc rfcomm bnep ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack btusb bluetooth snd_hda_codec_hdmi arc4 iwldvm ipheth mac80211 iTCO_wdt iTCO_vendor_support hp_wmi sparse_keymap uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev media coretemp microcode i7core_edac edac_core snd_hda_codec_idt i2c_i801 ir_lirc_codec lirc_dev ir_mce_kbd_decoder ir_sanyo_decoder iwlwifi snd_hda_intel ir_sony_decoder snd_hda_codec cfg80211 snd_hwdep jmb38x_ms snd_seq snd_seq_device ir_jvc_decoder lpc_ich memstick mfd_core ir_rc6_decoder snd_pcm r8169 mii rfkill ir_rc5_decoder ir_nec_decoder snd_page_alloc snd_timer snd soundcore vhost_net t
un macvtap macvlan rc_rc6_mce kvm ene_ir rc_core hp_accel lis3lv02d input_polldev uinput crc32c_intel sdhci_pci firewire_ohci sdhci firewire_core mmc_core crc_itu_t nouveau mxm_wmi wmi video i2c_algo_bit drm_kms_helper ttm drm
Dec 17 12:28:40 lappy kernel: i2c_core
Dec 17 12:28:40 lappy kernel: [ 4044.847025] Pid: 2080, comm: Socket Thread Tainted: G W 3.6.10-2.fc17.x86_64 #1
Dec 17 12:28:40 lappy kernel: [ 4044.847030] Call Trace:
Dec 17 12:28:40 lappy kernel: [ 4044.847035] [<ffffffff8105c8ef>] warn_slowpath_common+0x7f/0xc0
Dec 17 12:28:40 lappy kernel: [ 4044.847038] [<ffffffff8105c9e6>] warn_slowpath_fmt+0x46/0x50
Dec 17 12:28:40 lappy kernel: [ 4044.847040] [<ffffffff815576c5>] tcp_recvmsg+0xc25/0xd80
Dec 17 12:28:40 lappy kernel: [ 4044.847043] [<ffffffff8157cb1b>] inet_recvmsg+0x6b/0x80
Dec 17 12:28:40 lappy kernel: [ 4044.847047] [<ffffffff814fa707>] sock_recvmsg+0xd7/0x110
Dec 17 12:28:40 lappy kernel: [ 4044.847051] [<ffffffff811a2fd0>] ? __pollwait+0xf0/0xf0
Dec 17 12:28:40 lappy kernel: [ 4044.847053] [<ffffffff811a2fd0>] ? __pollwait+0xf0/0xf0
Dec 17 12:28:40 lappy kernel: [ 4044.847055] [<ffffffff814fc11f>] sys_recvfrom+0xef/0x170
Dec 17 12:28:40 lappy kernel: [ 4044.847058] [<ffffffff811a2fd0>] ? __pollwait+0xf0/0xf0
Dec 17 12:28:40 lappy kernel: [ 4044.847062] [<ffffffff810d868c>] ? __audit_syscall_entry+0xcc/0x300
Dec 17 12:28:40 lappy kernel: [ 4044.847064] [<ffffffff810d8cac>] ? __audit_syscall_exit+0x3ec/0x450
Dec 17 12:28:40 lappy kernel: [ 4044.847067] [<ffffffff816270e9>] system_call_fastpath+0x16/0x1b
Dec 17 12:28:40 lappy kernel: [ 4044.847068] ---[ end trace 28d4acf1e1aa598d ]---
Dec 17 12:28:40 lappy kernel: [ 4044.847069] ------------[ cut here ]------------
Dec 17 12:28:40 lappy kernel: [ 4044.847071] WARNING: at net/ipv4/tcp.c:1655 tcp_recvmsg+0x671/0xd80()
Dec 17 12:28:40 lappy kernel: [ 4044.847072] Hardware name: HP Pavilion dv7 Notebook PC
Dec 17 12:28:40 lappy kernel: [ 4044.847073] recvmsg bug: copied DE50E114 seq 0 rcvnxt DE50E114 fl 0
Dec 17 12:28:40 lappy kernel: [ 4044.847074] Modules linked in: fuse lockd sunrpc rfcomm bnep ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack btusb bluetooth snd_hda_codec_hdmi arc4 iwldvm ipheth mac80211 iTCO_wdt iTCO_vendor_support hp_wmi sparse_keymap uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev media coretemp microcode i7core_edac edac_core snd_hda_codec_idt i2c_i801 ir_lirc_codec lirc_dev ir_mce_kbd_decDec 17 12:29:32 lappy kernel: imklog 5.8.10, log source = /proc/kmsg started.
^ permalink raw reply
* [PATCH 1/2 v2] qmi_wwan/cdc_ether: add Dell Wireless 5800 (Novatel E362) USB IDs
From: Dan Williams @ 2012-12-17 18:17 UTC (permalink / raw)
To: Bjørn Mork; +Cc: Aleksander Morgado, netdev
Signed-off-by: Dan Williams <dcbw@redhat.com>
Cc: stable@vger.kernel.org
---
drivers/net/usb/cdc_ether.c | 15 +++++++++++++++
drivers/net/usb/qmi_wwan.c | 14 ++++++++++++++
2 files changed, 29 insertions(+)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index d012982..c4c593d 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -487,6 +487,7 @@ static const struct driver_info wwan_info = {
#define HUAWEI_VENDOR_ID 0x12D1
#define NOVATEL_VENDOR_ID 0x1410
#define ZTE_VENDOR_ID 0x19D2
+#define DELL_VENDOR_ID 0x413C
static const struct usb_device_id products [] = {
/*
@@ -618,6 +619,20 @@ static const struct usb_device_id products [] = {
.driver_info = 0,
},
+/* Dell Wireless 5800 (Novatel E362) - handled by qmi_wwan */
+{
+ USB_DEVICE_AND_INTERFACE_INFO(DELL_VENDOR_ID, 0x8195, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
+ .driver_info = 0,
+},
+
+/* Dell Wireless 5800 (Novatel E362) - handled by qmi_wwan */
+{
+ USB_DEVICE_AND_INTERFACE_INFO(DELL_VENDOR_ID, 0x8196, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
+ .driver_info = 0,
+},
+
/*
* WHITELIST!!!
*
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 1ea91f4..9b950f5 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -383,6 +383,20 @@ static const struct usb_device_id products[] = {
USB_CDC_PROTO_NONE),
.driver_info = (unsigned long)&qmi_wwan_info,
},
+ { /* Dell Wireless 5800 (Novatel E362) */
+ USB_DEVICE_AND_INTERFACE_INFO(0x413C, 0x8195,
+ USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET,
+ USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)&qmi_wwan_info,
+ },
+ { /* Dell Wireless 5800 V2 (Novatel E362) */
+ USB_DEVICE_AND_INTERFACE_INFO(0x413C, 0x8196,
+ USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET,
+ USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)&qmi_wwan_info,
+ },
/* 3. Combined interface devices matching on interface number */
{QMI_FIXED_INTF(0x12d1, 0x140c, 1)}, /* Huawei E173 */
--
1.7.11.7
^ permalink raw reply related
* [PATCH 2/2 v2] cdc_ether: cleanup: use USB_DEVICE_AND_INTERFACE_INFO for Novatel 551/E362
From: Dan Williams @ 2012-12-17 18:19 UTC (permalink / raw)
To: Bjørn Mork; +Cc: Aleksander Morgado, netdev
In-Reply-To: <1355768261.1424.50.camel@dcbw.foobar.com>
Signed-off-by: Dan Williams <dcbw@redhat.com>
---
drivers/net/usb/cdc_ether.c | 20 ++++----------------
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index c4c593d..a74f35f 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -595,27 +595,15 @@ static const struct usb_device_id products [] = {
/* Novatel USB551L and MC551 - handled by qmi_wwan */
{
- .match_flags = USB_DEVICE_ID_MATCH_VENDOR
- | USB_DEVICE_ID_MATCH_PRODUCT
- | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = NOVATEL_VENDOR_ID,
- .idProduct = 0xB001,
- .bInterfaceClass = USB_CLASS_COMM,
- .bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET,
- .bInterfaceProtocol = USB_CDC_PROTO_NONE,
+ USB_DEVICE_AND_INTERFACE_INFO(NOVATEL_VENDOR_ID, 0xB001, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
.driver_info = 0,
},
/* Novatel E362 - handled by qmi_wwan */
{
- .match_flags = USB_DEVICE_ID_MATCH_VENDOR
- | USB_DEVICE_ID_MATCH_PRODUCT
- | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = NOVATEL_VENDOR_ID,
- .idProduct = 0x9010,
- .bInterfaceClass = USB_CLASS_COMM,
- .bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET,
- .bInterfaceProtocol = USB_CDC_PROTO_NONE,
+ USB_DEVICE_AND_INTERFACE_INFO(NOVATEL_VENDOR_ID, 0x9010, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
.driver_info = 0,
},
--
1.7.11.7
^ permalink raw reply related
* Re: 3.6.10: Intel: ixgbe 0000:01:00.0 eth4: Detected Tx Unit Hang
From: devendra.aaru @ 2012-12-17 18:38 UTC (permalink / raw)
To: Justin Piszcz; +Cc: linux-kernel, netdev
In-Reply-To: <004101cddadb$b890e910$29b2bb30$@lucidpixels.com>
Ccing netdev
On Sat, Dec 15, 2012 at 10:49 AM, Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
> Hello,
>
> Kernel 3.6.10, first time I have seen this that I can remember (on 10GbE)
> anyway, is this a known issue with 3.6.10?
>
> When the link went down is when I rebooted/etc the remote host attached on
> the other end.
> I've not changed anything physically with the hardware and have been on
> 3.6.0-3.6.9 and noticed this when I moved to 3.6.10.
>
> [10270.229200] ixgbe 0000:01:00.0 eth4: NIC Link is Down
> [10276.124937] ixgbe 0000:01:00.0 eth4: NIC Link is Up 10 Gbps, Flow
> Control: RX/TX
> [24529.430997] ixgbe 0000:01:00.0 eth4: Detected Tx Unit Hang
> [24529.430997] Tx Queue <10>
> [24529.430997] TDH, TDT <4e>, <51>
> [24529.430997] next_to_use <51>
> [24529.430997] next_to_clean <4e>
> [24529.430997] tx_buffer_info[next_to_clean]
> [24529.430997] time_stamp <10172668f>
> [24529.430997] jiffies <101726ea4>
> [24529.431011] ixgbe 0000:01:00.0 eth4: tx hang 1 detected on queue 10,
> resetting adapter
> [24529.431028] ixgbe 0000:01:00.0 eth4: Reset adapter
>
> Thoughts?
>
> lspci -vvxx
>
> 01:00.0 Ethernet controller: Intel Corporation 82598EB 10-Gigabit AT2 Server
> Adapter (rev 01)
> Subsystem: Intel Corporation 82598EB 10-Gigabit AT2 Server Adapter
> 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 26
> Region 0: Memory at fbe40000 (32-bit, non-prefetchable) [size=128K]
> Region 1: Memory at fbe00000 (32-bit, non-prefetchable) [size=256K]
> Region 2: I/O ports at e000 [size=32]
> Region 3: Memory at fbe60000 (32-bit, non-prefetchable) [size=16K]
> Capabilities: [40] 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: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
> Address: 0000000000000000 Data: 0000
> Capabilities: [60] MSI-X: Enable+ Count=18 Masked-
> Vector table: BAR=3 offset=00000000
> PBA: BAR=3 offset=00002000
> Capabilities: [a0] Express (v2) Endpoint, MSI 00
> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
> ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
> DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
> MaxPayload 256 bytes, MaxReadReq 512 bytes
> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
> LnkCap: Port #0, Speed 2.5GT/s, Width x8, ASPM L0s L1, Latency L0 <4us,
> L1 <64us
> ClockPM- Surprise- LLActRep- BwNot-
> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed 2.5GT/s, Width x8, TrErr- Train- SlotClk+ DLActive-
> BWMgmt- ABWMgmt-
> DevCap2: Completion Timeout: Range ABCD, TimeoutDis+
> DevCtl2: Completion Timeout: 16ms to 55ms, 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, EqualizationComplete-,
> EqualizationPhase1-
> EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
> 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: [140 v1] Device Serial Number XX-XX-XX-XX-XX-XX-XX-XX
> (masked)
> Kernel driver in use: ixgbe
> 00: 86 80 0b 15 07 04 10 00 01 00 00 02 10 00 00 00
> 10: 00 00 e4 fb 00 00 e0 fb 01 e0 00 00 00 00 e6 fb
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 2c a1
> 30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 00 00
>
> Justin.
>
> --
> 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/
^ permalink raw reply
* Re: [PATCH v2 03/44] Add CONFIG_HAVE_64BIT_ALIGNED_STRUCT for taskstats
From: David Miller @ 2012-12-17 19:11 UTC (permalink / raw)
To: james.hogan
Cc: geert, hpa, linux-arch, linux-kernel, arnd, bsingharora, mingo,
akpm, eparis, wad, james.l.morris, netdev
In-Reply-To: <50CEEB08.1080707@imgtec.com>
From: James Hogan <james.hogan@imgtec.com>
Date: Mon, 17 Dec 2012 09:51:04 +0000
> On 10/12/12 12:55, Geert Uytterhoeven wrote:
>> On Mon, Dec 10, 2012 at 11:22 AM, James Hogan <james.hogan@imgtec.com> wrote:
>>> On 08/12/12 03:43, H. Peter Anvin wrote:
>>>> On 12/05/2012 08:08 AM, James Hogan wrote:
>>>>> On 64 bit architectures with no efficient unaligned access, taskstats
>>>>> has to add some padding to a reply to prevent unaligned access warnings.
>>>>> However this also needs to apply to 32 bit architectures with 64 bit
>>>>> struct alignment such as metag (which has 64 bit memory accesses).
>>>>
>>>> Wait... 64-bit struct alignment on structures with only 32-bit members?
>>>> That might be... interesting... in a number of places...
>>>
>>> I'll rewrite the description as it's a bit misleading. On metag 64bit
>>> struct alignment is required when it contains 64bit members, not if it
>>> only contains 32bit members. Although metag is a 32bit arch, it can do
>>> 64bit memory accesses which must be aligned.
>>
>> The C alignment rules should take care of this automatically (struct alignment
>> is the maximum alignment of its members).
>
> Hi Geert,
>
> Please see the comment in mk_reply in kernel/taskstats.c. The structure
> is being serialised after 2 NLA headers and a pid which is why the extra
> padding needs to be added manually.
Please solve netlink attribute 64-bit alignment issues fundamentally
rather on a case-by-case basis.
We were just discussing this very issue on the netdev list recently,
CC:'d
^ permalink raw reply
* Re: [PATCH] bugfix: network namespace & device dummy
From: David Miller @ 2012-12-17 19:13 UTC (permalink / raw)
To: lve; +Cc: netdev
In-Reply-To: <50CF1797.803@guap.ru>
From: "V. Lavrov" <lve@guap.ru>
Date: Mon, 17 Dec 2012 17:01:11 +0400
> If container has a network device dummyX (with lxc.network.type =
> phys), then it disappears from the system after you close the
> container.
> The patch returns the device dummyX to the initial network namespace
> after container is closed.
>
> Signed-off-by: Vitaly Lavrov <lve@guap.ru>
This patch is mangled by your email client.
Do not submit any new patches until you can successfully email
them to yourself, then successfully apply the patch that you
receive in that email.
Because that is exactly what you are asking us to do.
^ permalink raw reply
* Re: 3.6.10 tcp crash - net/ipv4/tcp.c:1667 & tcp.c:1655
From: Eric Dumazet @ 2012-12-17 19:34 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: netdev
In-Reply-To: <20121217174145.GH22452@kvack.org>
On Mon, 2012-12-17 at 12:41 -0500, Benjamin LaHaise wrote:
> Hi folks,
>
> I just hit the following crash with Fedora's 3.6.10-2.fc17 kernel. I don't
> have time to debug this myself at the moment, but can certainly test patches
> or provide more info as needed. I wasn't doing anything unusual at the time,
> just reading email/web browsing. I believe the network driver in use was
> ipheth for tethering to an iPhone 4S over USB (the other driver being used
> intermittently on this laptop is iwlwifi). Any ideas?
I see nothing really wrong on ipheth side.
I would be nice to know which driver is really in use when you have a
panic, as its probably a driver issue.
^ permalink raw reply
* Re: [tcpdump-workers] vlan tagged packets and libpcap breakage
From: Ani Sinha @ 2012-12-17 19:49 UTC (permalink / raw)
To: Guy Harris
Cc: David Laight, Daniel Borkmann, netdev, Michael Richardson,
tcpdump-workers, Francesco Ruggeri
In-Reply-To: <DE6D5B28-FA1E-4F04-9BDF-F6D35878776E@alum.mit.edu>
On Mon, Dec 17, 2012 at 2:35 AM, Guy Harris <guy@alum.mit.edu> wrote:
>
> On Dec 17, 2012, at 1:50 AM, "David Laight" <David.Laight@ACULAB.COM> wrote:
>
>> How are you going to tell whether a feature is present in a non-Linux
>> kernel ?
>
> The Linux memory-mapped capture mechanism is not present in a non-Linux kernel, so all the libpcap work involved here would, if necessary on other platforms, have to be done >differently on those platforms. Those platforms would have to have their own mechanisms to indicate whether any changes to filter code, processing of VLAN tags supplied out of >band, etc. would need to be done.
Actually lib-pcap has these pcap-<platform>.c files that are kind of
like platform specific drivers that plug into platform independent
code like gencode.c or bpf_filter.c. These platform specific drivers
are responsible for getting packets from the kernel and running
filters (kernel or userland) on it. So all linux specific code to get
a packet and packet metadata from the kernel can neatly reside in
pcap-linux.c.
Unfortunately though, in this specific problem involving filtering
with vlan tags, both code generation (gentags.c) and code running the
filter (bpf_filter.c) will have to be aware of linux specific
semantics. Due to the issues that Bill had explained earlier in the
thread, we can not rely on post processing before installing the
kernel filter. Therefore, we need to generate a filter that can be
directly installed in the kernel. For the same reason, bpf_filter()
code also needs to change - be aware of linux specific semantics.
^ permalink raw reply
* Re: 3.6.10 tcp crash - net/ipv4/tcp.c:1667 & tcp.c:1655
From: Benjamin LaHaise @ 2012-12-17 19:52 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1355772853.9380.10.camel@edumazet-glaptop>
On Mon, Dec 17, 2012 at 11:34:13AM -0800, Eric Dumazet wrote:
> On Mon, 2012-12-17 at 12:41 -0500, Benjamin LaHaise wrote:
> > Hi folks,
> >
> > I just hit the following crash with Fedora's 3.6.10-2.fc17 kernel. I don't
> > have time to debug this myself at the moment, but can certainly test patches
> > or provide more info as needed. I wasn't doing anything unusual at the time,
> > just reading email/web browsing. I believe the network driver in use was
> > ipheth for tethering to an iPhone 4S over USB (the other driver being used
> > intermittently on this laptop is iwlwifi). Any ideas?
>
> I see nothing really wrong on ipheth side.
>
> I would be nice to know which driver is really in use when you have a
> panic, as its probably a driver issue.
I double checked the logs, and the wifi was disabled at the time (~30
minutes beforehand), so it had to be ipheth. The warnings were the last
thing that made it to disk before the machine hung hard, so there may have
been a more serious crash after the warning that did not get logged.
One thing I have observed with tethering is that the MTU handling is munged
by the network in interesting ways. Although the device claims to be
ethernet with a 1500 byte MTU, a 'ping -s' works only up to 996 (with no
effect trying the various -M options). A number of website are broken by
this, as the network doesn't seem to send ICMP frag needed errors to my
tethered host (but I haven't traced this behaviour from both ends yet).
Things do work for 1500 byte packets to the gateway IP, but that seems
to be local to the phone.
-ben
--
"Thought is the essence of where you are now."
^ permalink raw reply
* Re: [PATCH 4/4] FEC: Add time stamping code and a PTP hardware clock
From: Sascha Hauer @ 2012-12-17 20:02 UTC (permalink / raw)
To: Shawn Guo
Cc: Frank Li, Frank Li, lznua, richardcochran, linux-arm-kernel,
netdev, davem
In-Reply-To: <20121217151445.GA17907@S2101-09.ap.freescale.net>
On Mon, Dec 17, 2012 at 11:14:46PM +0800, Shawn Guo wrote:
> Hi Sascha,
>
> On Mon, Dec 17, 2012 at 10:48:31PM +0800, Frank Li wrote:
> > > I don't know how to continue from here. Since the whole patch doesn't
> > > seem to reviewed very much I tend to say we should revert it for now and
> > > let Frank redo it for the next merge window.
> > >
> > > Other opinions?
> >
> > Can we just disable CONFIG_FEC_PTP defaut instead of revert whole patch?
> >
> To be clear, the following is what Frank meant. Since Frank is out of
> office for some time, I will send this immediate fix to David, if you
> are fine with it.
This leaves an option in the tree which can be used to break FEC on
i.MX3/5.
depends on !SOC_IMX31 && !SOC_IMX35 && !SOC_IMX5
might be an option, but given that this patch seems to have bypassed any
review I feel more like reverting it.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH] tuntap: reset network header before calling skb_get_rxhash()
From: David Miller @ 2012-12-17 20:33 UTC (permalink / raw)
To: eric.dumazet; +Cc: danborkmann, kirill, maxk, netdev, dwmw2
In-Reply-To: <1355755160.10504.25.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 17 Dec 2012 06:39:20 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Commit 499744209b2c (tuntap: dont use skb after netif_rx_ni(skb))
> introduced another bug.
>
> skb_get_rxhash() needs to access the network header, and it was
> set for us in netif_rx_ni().
>
> We need to reset network header or else skb_flow_dissect() behavior
> is out of control.
>
> Reported-and-tested-by: Kirill A. Shutemov <kirill@shutemov.name>
> Tested-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, hopefully we've really resolved this fully now :)
^ permalink raw reply
* Re: [PATCH 1/2 v2] qmi_wwan/cdc_ether: add Dell Wireless 5800 (Novatel E362) USB IDs
From: Bjørn Mork @ 2012-12-17 20:35 UTC (permalink / raw)
To: Dan Williams; +Cc: Aleksander Morgado, netdev
In-Reply-To: <1355768261.1424.50.camel@dcbw.foobar.com>
Dan Williams <dcbw@redhat.com> writes:
> Signed-off-by: Dan Williams <dcbw@redhat.com>
> Cc: stable@vger.kernel.org
> ---
> drivers/net/usb/cdc_ether.c | 15 +++++++++++++++
> drivers/net/usb/qmi_wwan.c | 14 ++++++++++++++
> 2 files changed, 29 insertions(+)
For the qmi_wwan part:
Acked-by: Bjørn Mork <bjorn@mork.no>
^ permalink raw reply
* [GIT PULL net-next] NDISC Updates (sender-side clean-up)
From: YOSHIFUJI Hideaki @ 2012-12-17 20:46 UTC (permalink / raw)
To: David Miller, 'netdev@vger.kernel.org'; +Cc: YOSHIFUJI Hideaki
Hi,
Please consider pulling
git://git.linux-ipv6.org/gitroot/yoshfuji/linux-2.6-next.git
net-next-20121218_ndisc
for net-next; it mainly cleans up sender side of NDISC subsystem.
--yoshfuji
[CHANGELOG]
YOSHIFUJI Hideaki (17):
ndisc: Fix size calculation for headers.
ipv6: Introduce __ip6_hdr() for setting IPv6 header.
ndisc: Introduce struct red_msg for redirect message.
ndisc: Introduce ndisc_fill_redirect_hdr_option().
ndisc: Rename and break up __ndisc_send().
ndisc: Introduce ndisc_send_skb_alloc() for sk_buff allocation.
ipv6: Move ip6_nd_hdr() to its users' source files.
ndisc: Set skb->dev and skb->protocol inside ndisc_alloc_skb().
ndisc: Defer building IPv6 header.
ndisc: Reset skb->transport_header inside ndisc_alloc_send_skb().
ndisc: Calculate message body length and option length separately.
ndisc: Make ndisc_fill_xxx_option() for sk_buff.
ndisc: Calculate checksum and build IPv6 header in __ndisc_send().
ndisc: Concentrate ndisc_send() on sending message.
ndisc: Break down ndisc_build_skb().
ndisc: Fill in ND message on skb directly.
ndisc: Use return value of __skb_put(), instead of icmp6_hdr().
[DIFFSTAT]
include/net/ipv6.h | 22 ++-
include/net/ndisc.h | 7 +
net/ipv6/ip6_gre.c | 18 +--
net/ipv6/ip6_output.c | 51 +-------
net/ipv6/ip6_tunnel.c | 12 +-
net/ipv6/mcast.c | 24 +++-
net/ipv6/ndisc.c | 326
+++++++++++++++++++++++++------------------------
net/ipv6/route.c | 24 ++--
8 files changed, 234 insertions(+), 250 deletions(-)
^ permalink raw reply
* RE: 3.6.10: Intel: ixgbe 0000:01:00.0 eth4: Detected Tx Unit Hang
From: Justin Piszcz @ 2012-12-17 21:06 UTC (permalink / raw)
To: 'devendra.aaru', 'Tantilov, Emil S'; +Cc: linux-kernel, netdev
In-Reply-To: <CAHdPZaOCKy8Ee17g-sU6YViGdfGPOsV7OLN+w+XA2eUWGmAy_Q@mail.gmail.com>
-----Original Message-----
From: devendra.aaru [mailto:devendra.aaru@gmail.com]
Sent: Monday, December 17, 2012 1:39 PM
To: Justin Piszcz
Cc: linux-kernel@vger.kernel.org; netdev@vger.kernel.org
Subject: Re: 3.6.10: Intel: ixgbe 0000:01:00.0 eth4: Detected Tx Unit Hang
Ccing netdev
On Sat, Dec 15, 2012 at 10:49 AM, Justin Piszcz <jpiszcz@lucidpixels.com>
wrote:
> Hello,
>
> Kernel 3.6.10, first time I have seen this that I can remember (on 10GbE)
> anyway, is this a known issue with 3.6.10?
>
> When the link went down is when I rebooted/etc the remote host attached on
> the other end.
> I've not changed anything physically with the hardware and have been on
> 3.6.0-3.6.9 and noticed this when I moved to 3.6.10.
--
> I don't believe we have seen Tx hangs in validation. If you could narrow
down the conditions that lead to the Tx hang that would help a lot. Also
> the output of ethtool -S eth4 after the Tx hang occurs can be useful to
get an idea of the load on the interface.
> Thanks,
> Emil
--
In this case I only have two servers that mount each other's NFS volumes and
that were idle at the time, I rebooted one of the systems and that is when I
saw this, if I can get something to repeat/pattern and/or the ethtool output
I will update this thread, thank you.
Justin.
^ permalink raw reply
* Whence a description of how to enable TCP FASTOPEN in a net-next kernel?
From: Rick Jones @ 2012-12-17 21:27 UTC (permalink / raw)
To: netdev
Is there a writeup describing the steps needed to enable TCP_FASTOPEN in
a net-next kernel? (pulled earlier today)
I am looking to debug netperf's support for enabling the feature and I
want to make sure I've enabled things correctly in the kernel. Thusfar
I've set the tcp_fastopen sysctl to one, and I see the "client" side of
netperf making the appropriate sendto() call, and I see what appears to
be the correct setsockopt being set on the server side, but my tcpdump
traces of the traffic flowing over loopback in my test setup, while
showing the client including the experimental option, do not show the
server side responding:
13:10:23.870202 IP localhost.5923 > localhost.54363: Flags [S], seq
935361110, win 43690, options [mss 65495,sackOK,TS val 889762 ecr
0,nop,wscale 7,Unknown Option 254f989], length 0
13:10:23.870214 IP localhost.54363 > localhost.5923: Flags [S.], seq
4210640362, ack 935361111, win 43690, options [mss 65495,sackOK,TS val
889762 ecr 889762,nop,wscale 7], length 0
The netserver side strace snippet:
3861 socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 8
3861 getsockopt(8, SOL_SOCKET, SO_SNDBUF, [16384], [4]) = 0
3861 getsockopt(8, SOL_SOCKET, SO_RCVBUF, [87380], [4]) = 0
3861 setsockopt(8, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
3861 bind(8, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
3861 setsockopt(8, SOL_TCP, 0x17 /* TCP_??? */, [5], 4) = 0
3861 listen(8, 5) = 0
...
3861 accept(8, {sa_family=AF_INET, sin_port=htons(5923),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 9
3861 recvfrom(9, "n", 1, 0, NULL, NULL) = 1
3861 sendto(9, "n", 1, 0, NULL, 0) = 1
3861 getsockopt(9, SOL_SOCKET, SO_RCVBUF, [262030], [4]) = 0
3861 getsockopt(9, SOL_SOCKET, SO_SNDBUF, [663750], [4]) = 0
3861 close(9) = 0
lather, rinse, repeat the accept sequence off that listen endpoint.
happy benchmarking,
rick jones
^ permalink raw reply
* RE: Launch Time Support
From: Vick, Matthew @ 2012-12-17 21:44 UTC (permalink / raw)
To: Ulf samuelsson; +Cc: netdev@vger.kernel.org
In-Reply-To: <EC58F455-4B86-48F7-95B7-A15C6FC98024@emagii.com>
> -----Original Message-----
> From: Ulf samuelsson [mailto:netdev@emagii.com]
> Sent: Friday, December 14, 2012 11:35 PM
> To: Vick, Matthew
> Cc: netdev@vger.kernel.org
> Subject: Re: Launch Time Support
>
>
> 15 dec 2012 kl. 01:45 skrev "Vick, Matthew" <matthew.vick@intel.com>:
>
> >> -----Original Message-----
> >> From: netdev-owner@vger.kernel.org [mailto:netdev-
> >> owner@vger.kernel.org] On Behalf Of Ulf Samuelsson
> >> Sent: Wednesday, December 12, 2012 5:04 PM
> >> To: netdev@vger.kernel.org
> >> Subject: RFC: Launch Time Support
> >>
> >> Hi, I am looking for some feedback on how to implement launchtime in
> >> the kernel.
> >>
> >> I.E: You define WHEN you want to send a packet, and the driver will
> >> store the packet in a buffer and will send it out on the net when
> the
> >> internal timestamp counter in the network controller reaches the
> >> specified "launch time".
> >>
> >> Some Ethernet controllers like the new Intel i210 support "launch
> >> time",
> >>
> >> Support for launch time is desirable for any isochronous connection,
> >> but I am currently interested in the NTP protocol to improve the
> >> timing.
> >>
> >> Proposed Changes to the Kernel
> >> ===========================================================
> >> The launchtime support will be dependent on CONFIG_NET_LAUNCHTIME If
> >> this is not set, then the kernel functionality is not changed.
> >>
> >> My current idea is to add a new bit to the "flags" field of
> >> "socket.c:sendto"
> >> #define MSG_LAUNCHTIME 0x?????
> >>
> >> struct msghdr gets an additional launchtime field.
> >>
> >> sendto will check if the flags parameter contains MSG_LAUNCHTIME.
> >> If it does, then the first 64 bit longword of the packet (buff)
> >> contains the launchtime.
> >> The launchtime from the buffer is copied to the msghdr.launchtime
> >> field, and the first 64 bits of the packet is then shaved off,
> before
> >> the address is written to the msghdr.
> >>
> >> Each network controller supporting launchtime needs to have an
> >> alternative call to "send packet with launchtime" . This call adds
> >> the launchtime parameter.
> >> If launchtime is supported the exported "ops" includes the new call.
> >>
> >> The UDP/IP packet send will check the MSG_LAUNCHTIME and if set, it
> >> will check if the "send packet with launchtime" call is available
> for
> >> the driver and if so call it, otherwise it will call the normal send
> >> packet and thus ignore the launchtime.
> >>
> >> Before launchtime is used, the application should send an ioctl to
> >> the driver, making sure that launchtime is configured, and only if
> >> the driver ACKs , the application will use launchtime.
> >>
> >> (Possibly the "ops" field for "send packet with launchtime" should
> be
> >> NULL until that ioctl is complete. Comments?)
> >>
> >> To me, this seems to be transparent for all other network stacks so
> >> protocols and drivers not supporting launchtime should still work.
> >>
> >> As far as I know, drivers do not support launch time today.
> >> The Intel igb driver does not in the latest version on the intel web
> >> site, There are some defines headers in the latest version defining
> >> the registers but so far, the code is not using it.
> >>
> >> There is the linux_igb_avb project on sourceforge which allows use
> >> of launch time for user space applications, but not as part of the
> kernel.
> >>
> >> Maybe there is more work done somewhere else, but i am not aware of
> >> this, so any links to such work is appreciated.
> >>
> >> There are some FPGA based PCIe boards that support launchtime
> (Endace
> >> DAG) using proprietary APIs.
> >> Talked to some vendors providing TCP/IP offload engines for FPGA and
> >> they do not support launchtime and liuke Endace use proprietary APIs
> >> so they are only useable by custom programs. Normal networking
> >> interfaces are not supported.
> >>
> >> Comment on above is appreciated.
> >>
> >> BACKGROUND
> >> For those that do not know how the NTP protocol works:
> >> ===================================================
> >> The client sends an UDP packet to the NTP server using port 123 The
> >> NTP client reads the current systime and puts that in the outgoing
> packet.
> >> There is a delay between the time the systime is read, and the time
> >> the packet actually leaves the Ethernet controller adding jitter to
> >> the NTP algorithm.
> >>
> >> When the server receives the packet, it can be timestamped in H/W
> and
> >> a CMSG is then created by the network stack containing that
> timestamp
> >> for use by the server NTP daemon.
> >>
> >> The server generates a reply, which needs to include the client
> >> transmit time, the servers receive time, and the servers transmit
> time.
> >> Again, the transmit time needs to be written into the NTP packet,
> and
> >> then it needs to be processed through the network stack before it is
> >> leaving the ethernet controller causing more jitter.
> >>
> >> If launch time is supported, then the client NTP daemon would simply
> >> read the systime, add a constant delay to create the transmit
> >> timestamp.
> >> The delay needs to be sufficiently large to ensure that all
> >> processing is done,
> >>
> >> The server will do something similar adding a constant to the server
> >> receive timestamp to create the server transmit timestamp.
> >> If both the client and the server uses H/W timestamping and launch
> >> time, then the the jitter ideally is reduced to zero.
> >>
> >> TRANSMIT TIMESTAMPING
> >> ========================
> >> Support for TX timestamps in H/W is not really useful, since you
> need
> >> to provide the TX timestamp in the packet you measure on, so when
> you
> >> know the timestamp it is too late. Server to server NTP connections
> >> support sending that timestamp in a new packet, but there is no such
> >> support in client server communication.
> >>
> >> The i210 supports putting the timestamp inside the packet as it
> >> leaves the Ethernet controller, but that means that you screw up the
> >> UDP checksum, so the packet will be rejected by the receiving NTP
> daemon.
> >> In addition, the i210 timestamp measures seconds and nanoseconds
> >> which is incompatible with the NTP timestamp which uses seconds and
> a
> >> 32 bit fraction of a second so that does not work either.
> >>
> >> Best Regards
> >> Ulf Samuelsson
> >> eMagii.
> >
> > Ulf,
> >
> > I have been looking into adding launch time support as part of
> enabling some of the I210 functionality you have described (such as in
> linux_igb_avb on SourceForge) upstream--less focused on NTP and more
> focused on AVB, but launch time will be necessary for both. If you
> would like, please feel free to contact me and I would love to work
> with you on this.
> >
> > Reading your proposal, I'm a little confused by which systime you're
> referring to. Do you mean on the host or on the NIC? In the case of
> hardware timestamping today, in igb we set the SYSTIM registers to the
> current system time, but that doesn't mean that the host clock and the
> NIC clock stay synced. You would either need a mechanism such as PPS
> (which igb does not implement today) to sync the host clock to the NIC
> clock or have the NTP daemon account for the discrepancy. Off the top
> of my head, I want to say modern PTP daemons (such as ptp4l) account
> for the discrepancy in the daemon.
> >
> > Cheers,
> > Matthew
>
> We live in luxury, having access to a Cesium Clock ;-) and we define
> the time, beeing a top-level (Stratum 1) server.
>
> There are some I/Os on the i210 that can be used to interface to the
> PPS.
>
> As for reading systime, it is done indirectly as you get the systime as
> part of the NTP incoming packet. (It is timestamped at reception) and
> add the constant to that value.
>
> Best Regards
> Ulf Samuelsson
So your proposal is to use a PPS interface (from some Stratum 1 server) to drive the clock on an I210 so you can use the I210's launch time mechanism to send packets at a certain time--is this correct? Or are you talking more about a software launch time solution?
Forgive my ignorance, but what constant are you referring to in the receive path? Based on your first e-mail, you mention the constant should be added to the transmit path.
Also, how will you account for hardware discrepancies? For example, how far in the future you can schedule a packet will differ from hardware to hardware.
Cheers,
Matthew
^ permalink raw reply
* Re: Whence a description of how to enable TCP FASTOPEN in a net-next kernel?
From: Eric Dumazet @ 2012-12-17 21:56 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <50CF8E2A.5020201@hp.com>
On Mon, 2012-12-17 at 13:27 -0800, Rick Jones wrote:
> Is there a writeup describing the steps needed to enable TCP_FASTOPEN in
> a net-next kernel? (pulled earlier today)
>
> I am looking to debug netperf's support for enabling the feature and I
> want to make sure I've enabled things correctly in the kernel. Thusfar
> I've set the tcp_fastopen sysctl to one, and I see the "client" side of
> netperf making the appropriate sendto() call, and I see what appears to
> be the correct setsockopt being set on the server side, but my tcpdump
> traces of the traffic flowing over loopback in my test setup, while
> showing the client including the experimental option, do not show the
> server side responding:
>
> 13:10:23.870202 IP localhost.5923 > localhost.54363: Flags [S], seq
> 935361110, win 43690, options [mss 65495,sackOK,TS val 889762 ecr
> 0,nop,wscale 7,Unknown Option 254f989], length 0
> 13:10:23.870214 IP localhost.54363 > localhost.5923: Flags [S.], seq
> 4210640362, ack 935361111, win 43690, options [mss 65495,sackOK,TS val
> 889762 ecr 889762,nop,wscale 7], length 0
>
> The netserver side strace snippet:
>
> 3861 socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 8
> 3861 getsockopt(8, SOL_SOCKET, SO_SNDBUF, [16384], [4]) = 0
> 3861 getsockopt(8, SOL_SOCKET, SO_RCVBUF, [87380], [4]) = 0
> 3861 setsockopt(8, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> 3861 bind(8, {sa_family=AF_INET, sin_port=htons(0),
> sin_addr=inet_addr("0.0.0.0")}, 16) = 0
> 3861 setsockopt(8, SOL_TCP, 0x17 /* TCP_??? */, [5], 4) = 0
> 3861 listen(8, 5) = 0
> ...
> 3861 accept(8, {sa_family=AF_INET, sin_port=htons(5923),
> sin_addr=inet_addr("127.0.0.1")}, [16]) = 9
> 3861 recvfrom(9, "n", 1, 0, NULL, NULL) = 1
> 3861 sendto(9, "n", 1, 0, NULL, 0) = 1
> 3861 getsockopt(9, SOL_SOCKET, SO_RCVBUF, [262030], [4]) = 0
> 3861 getsockopt(9, SOL_SOCKET, SO_SNDBUF, [663750], [4]) = 0
> 3861 close(9) = 0
> lather, rinse, repeat the accept sequence off that listen endpoint.
>
> happy benchmarking,
I guess you need to enable fastopen both for client and server :
echo 3 >/proc/sys//net/ipv4/tcp_fastopen
^ permalink raw reply
* Re: Whence a description of how to enable TCP FASTOPEN in a net-next kernel?
From: Eric Dumazet @ 2012-12-17 22:03 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <1355781411.9380.12.camel@edumazet-glaptop>
On Mon, 2012-12-17 at 13:56 -0800, Eric Dumazet wrote:
>
> I guess you need to enable fastopen both for client and server :
>
> echo 3 >/proc/sys//net/ipv4/tcp_fastopen
vi +475 Documentation/networking/ip-sysctl.txt
tcp_fastopen - INTEGER
Enable TCP Fast Open feature (draft-ietf-tcpm-fastopen) to send data
in the opening SYN packet. To use this feature, the client application
must use sendmsg() or sendto() with MSG_FASTOPEN flag rather than
connect() to perform a TCP handshake automatically.
The values (bitmap) are
1: Enables sending data in the opening SYN on the client.
2: Enables TCP Fast Open on the server side, i.e., allowing data in
a SYN packet to be accepted and passed to the application before
3-way hand shake finishes.
4: Send data in the opening SYN regardless of cookie availability and
without a cookie option.
0x100: Accept SYN data w/o validating the cookie.
0x200: Accept data-in-SYN w/o any cookie option present.
0x400/0x800: Enable Fast Open on all listeners regardless of the
TCP_FASTOPEN socket option. The two different flags designate two
different ways of setting max_qlen without the TCP_FASTOPEN socket
option.
Default: 0
Note that the client & server side Fast Open flags (1 and 2
respectively) must be also enabled before the rest of flags can take
effect.
See include/net/tcp.h and the code for more details.
^ permalink raw reply
* Re: [GIT PULL net-next] NDISC Updates (sender-side clean-up)
From: David Miller @ 2012-12-17 22:31 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev
In-Reply-To: <50CF84A5.7030706@linux-ipv6.org>
Sorry, you cannot just send a pull request without posting
the patches as well for people to review.
I'm not pulling from your tree without any posting of the
patches for review.
^ permalink raw reply
* Re: Whence a description of how to enable TCP FASTOPEN in a net-next kernel?
From: Rick Jones @ 2012-12-17 22:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1355781411.9380.12.camel@edumazet-glaptop>
On 12/17/2012 01:56 PM, Eric Dumazet wrote:
> On Mon, 2012-12-17 at 13:27 -0800, Rick Jones wrote:
>> [an explanation of what he'd done that hadn't worked]
>
> I guess you need to enable fastopen both for client and server :
>
> echo 3 >/proc/sys//net/ipv4/tcp_fastopen
Looks like I'm good now:
raj@tardy-ubuntu-1204:~$ cat /proc/sys/net/ipv4/tcp_fastopen
3
raj@tardy-ubuntu-1204:~$ sudo tcpdump -c 30 -i lo 'not port 12865'
[sudo] password for raj:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
14:28:43.536166 IP localhost.29105 > localhost.srvr: Flags [S], seq
378007190, win 43690, options [mss 65495,sackOK,TS val 4294942097 ecr
0,nop,wscale 7,Unknown Option 254f989], length 0
14:28:43.536191 IP localhost.srvr > localhost.29105: Flags [S.], seq
2030806688, ack 378007191, win 43690, options [mss 65495,sackOK,TS val
4294942097 ecr 4294942097,nop,wscale 7,Unknown Option
254f989e73dc061f14d850e], length 0
14:28:43.537421 IP localhost.29105 > localhost.srvr: Flags [P.], seq
1:2, ack 1, win 342, options [nop,nop,TS val 4294942098 ecr 4294942097],
length 1
14:28:43.537445 IP localhost.srvr > localhost.29105: Flags [.], ack 2,
win 342, options [nop,nop,TS val 4294942098 ecr 4294942098], length 0
14:28:43.537525 IP localhost.srvr > localhost.29105: Flags [P.], seq
1:2, ack 2, win 342, options [nop,nop,TS val 4294942098 ecr 4294942098],
length 1
14:28:43.537542 IP localhost.srvr > localhost.29105: Flags [F.], seq 2,
ack 2, win 342, options [nop,nop,TS val 4294942098 ecr 4294942098], length 0
14:28:43.537727 IP localhost.29105 > localhost.srvr: Flags [F.], seq 2,
ack 3, win 342, options [nop,nop,TS val 4294942098 ecr 4294942098], length 0
14:28:43.537741 IP localhost.srvr > localhost.29105: Flags [.], ack 3,
win 342, options [nop,nop,TS val 4294942098 ecr 4294942098], length 0
14:28:43.537895 IP localhost.29106 > localhost.srvr: Flags [S], seq
1735077945:1735077946, win 43690, options [mss 65495,sackOK,TS val
4294942098 ecr 0,nop,wscale 7,Unknown Option 254f989e73dc061f14d850e],
length 1
14:28:43.537909 IP localhost.srvr > localhost.29106: Flags [S.], seq
1983728126, ack 1735077947, win 43690, options [mss 65495,sackOK,TS val
4294942098 ecr 4294942098,nop,wscale 7], length 0
14:28:43.537924 IP localhost.29106 > localhost.srvr: Flags [.], ack 1,
win 342, options [nop,nop,TS val 4294942098 ecr 4294942098], length 0
14:28:43.538014 IP localhost.srvr > localhost.29106: Flags [P.], seq
1:2, ack 1, win 342, options [nop,nop,TS val 4294942098 ecr 4294942098],
length 1
14:28:43.538028 IP localhost.srvr > localhost.29106: Flags [F.], seq 2,
ack 1, win 342, options [nop,nop,TS val 4294942098 ecr 4294942098], length 0
14:28:43.538196 IP localhost.29106 > localhost.srvr: Flags [.], ack 2,
win 342, options [nop,nop,TS val 4294942098 ecr 4294942098], length 0
14:28:43.538288 IP localhost.29106 > localhost.srvr: Flags [F.], seq 1,
ack 3, win 342, options [nop,nop,TS val 4294942098 ecr 4294942098], length 0
14:28:43.538300 IP localhost.srvr > localhost.29106: Flags [.], ack 2,
win 342, options [nop,nop,TS val 4294942098 ecr 4294942098], length 0
14:28:43.538417 IP localhost.29107 > localhost.srvr: Flags [S], seq
3902541042:3902541043, win 43690, options [mss 65495,sackOK,TS val
4294942098 ecr 0,nop,wscale 7,Unknown Option 254f989e73dc061f14d850e],
length 1
14:28:43.538431 IP localhost.srvr > localhost.29107: Flags [S.], seq
941945820, ack 3902541044, win 43690, options [mss 65495,sackOK,TS val
4294942098 ecr 4294942098,nop,wscale 7], length 0
14:28:43.538445 IP localhost.29107 > localhost.srvr: Flags [.], ack 1,
win 342, options [nop,nop,TS val 4294942098 ecr 4294942098], length 0
14:28:43.538518 IP localhost.srvr > localhost.29107: Flags [P.], seq
1:2, ack 1, win 342, options [nop,nop,TS val 4294942098 ecr 4294942098],
length 1
14:28:43.538531 IP localhost.srvr > localhost.29107: Flags [F.], seq 2,
ack 1, win 342, options [nop,nop,TS val 4294942098 ecr 4294942098], length 0
14:28:43.538654 IP localhost.29107 > localhost.srvr: Flags [.], ack 2,
win 342, options [nop,nop,TS val 4294942098 ecr 4294942098], length 0
14:28:43.538730 IP localhost.29107 > localhost.srvr: Flags [F.], seq 1,
ack 3, win 342, options [nop,nop,TS val 4294942098 ecr 4294942098], length 0
14:28:43.538742 IP localhost.srvr > localhost.29107: Flags [.], ack 2,
win 342, options [nop,nop,TS val 4294942098 ecr 4294942098], length 0
in which case I suppose that means that netperf top-of-trunk does indeed
have client and server side support for TCP_FASTOPEN. Enabled via the
test-specific -F option though in the loopback test (in a 1 VCPU VM) I
don't see much of a difference (don't suppose I should really):
raj@tardy-ubuntu-1204:~/netperf2_trunk/src$ ./netperf -t TCP_CRR -l 30
-i 30,3 -- -F -P ,12345
MIGRATED TCP Connect/Request/Response TEST from 0.0.0.0 (0.0.0.0) port 0
AF_INET to localhost () port 12345 AF_INET : +/-2.500% @ 99% conf. : demo
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
16384 87380 1 1 30.00 15909.07
16384 87380
raj@tardy-ubuntu-1204:~/netperf2_trunk/src$ ./netperf -t TCP_CRR -l 30
-i 30,3 -- -P ,12345
MIGRATED TCP Connect/Request/Response TEST from 0.0.0.0 (0.0.0.0) port 0
AF_INET to localhost () port 12345 AF_INET : +/-2.500% @ 99% conf. : demo
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
16384 87380 1 1 30.00 15574.37
16384 87380
happy benchmarking,
rick jones
^ permalink raw reply
* Re: Launch Time Support
From: Ulf samuelsson @ 2012-12-17 22:57 UTC (permalink / raw)
To: Vick, Matthew, netdev@vger.kernel.org
In-Reply-To: <06DFBC1E25D8024DB214DC7F41A3CD344897485E@ORSMSX101.amr.corp.intel.com>
17 dec 2012 kl. 22:44 skrev "Vick, Matthew" <matthew.vick@intel.com>:
>> -----Original Message-----
>> From: Ulf samuelsson [mailto:netdev@emagii.com]
>> Sent: Friday, December 14, 2012 11:35 PM
>> To: Vick, Matthew
>> Cc: netdev@vger.kernel.org
>> Subject: Re: Launch Time Support
>>
>>
>> 15 dec 2012 kl. 01:45 skrev "Vick, Matthew" <matthew.vick@intel.com>:
>>
>>>> -----Original Message-----
>>>> From: netdev-owner@vger.kernel.org [mailto:netdev-
>>>> owner@vger.kernel.org] On Behalf Of Ulf Samuelsson
>>>> Sent: Wednesday, December 12, 2012 5:04 PM
>>>> To: netdev@vger.kernel.org
>>>> Subject: RFC: Launch Time Support
>>>>
>>>> Hi, I am looking for some feedback on how to implement launchtime in
>>>> the kernel.
>>>>
>>>> I.E: You define WHEN you want to send a packet, and the driver will
>>>> store the packet in a buffer and will send it out on the net when
>> the
>>>> internal timestamp counter in the network controller reaches the
>>>> specified "launch time".
>>>>
>>>> Some Ethernet controllers like the new Intel i210 support "launch
>>>> time",
>>>>
>>>> Support for launch time is desirable for any isochronous connection,
>>>> but I am currently interested in the NTP protocol to improve the
>>>> timing.
>>>>
>>>> Proposed Changes to the Kernel
>>>> ===========================================================
>>>> The launchtime support will be dependent on CONFIG_NET_LAUNCHTIME If
>>>> this is not set, then the kernel functionality is not changed.
>>>>
>>>> My current idea is to add a new bit to the "flags" field of
>>>> "socket.c:sendto"
>>>> #define MSG_LAUNCHTIME 0x?????
>>>>
>>>> struct msghdr gets an additional launchtime field.
>>>>
>>>> sendto will check if the flags parameter contains MSG_LAUNCHTIME.
>>>> If it does, then the first 64 bit longword of the packet (buff)
>>>> contains the launchtime.
>>>> The launchtime from the buffer is copied to the msghdr.launchtime
>>>> field, and the first 64 bits of the packet is then shaved off,
>> before
>>>> the address is written to the msghdr.
>>>>
>>>> Each network controller supporting launchtime needs to have an
>>>> alternative call to "send packet with launchtime" . This call adds
>>>> the launchtime parameter.
>>>> If launchtime is supported the exported "ops" includes the new call.
>>>>
>>>> The UDP/IP packet send will check the MSG_LAUNCHTIME and if set, it
>>>> will check if the "send packet with launchtime" call is available
>> for
>>>> the driver and if so call it, otherwise it will call the normal send
>>>> packet and thus ignore the launchtime.
>>>>
>>>> Before launchtime is used, the application should send an ioctl to
>>>> the driver, making sure that launchtime is configured, and only if
>>>> the driver ACKs , the application will use launchtime.
>>>>
>>>> (Possibly the "ops" field for "send packet with launchtime" should
>> be
>>>> NULL until that ioctl is complete. Comments?)
>>>>
>>>> To me, this seems to be transparent for all other network stacks so
>>>> protocols and drivers not supporting launchtime should still work.
>>>>
>>>> As far as I know, drivers do not support launch time today.
>>>> The Intel igb driver does not in the latest version on the intel web
>>>> site, There are some defines headers in the latest version defining
>>>> the registers but so far, the code is not using it.
>>>>
>>>> There is the linux_igb_avb project on sourceforge which allows use
>>>> of launch time for user space applications, but not as part of the
>> kernel.
>>>>
>>>> Maybe there is more work done somewhere else, but i am not aware of
>>>> this, so any links to such work is appreciated.
>>>>
>>>> There are some FPGA based PCIe boards that support launchtime
>> (Endace
>>>> DAG) using proprietary APIs.
>>>> Talked to some vendors providing TCP/IP offload engines for FPGA and
>>>> they do not support launchtime and liuke Endace use proprietary APIs
>>>> so they are only useable by custom programs. Normal networking
>>>> interfaces are not supported.
>>>>
>>>> Comment on above is appreciated.
>>>>
>>>> BACKGROUND
>>>> For those that do not know how the NTP protocol works:
>>>> ===================================================
>>>> The client sends an UDP packet to the NTP server using port 123 The
>>>> NTP client reads the current systime and puts that in the outgoing
>> packet.
>>>> There is a delay between the time the systime is read, and the time
>>>> the packet actually leaves the Ethernet controller adding jitter to
>>>> the NTP algorithm.
>>>>
>>>> When the server receives the packet, it can be timestamped in H/W
>> and
>>>> a CMSG is then created by the network stack containing that
>> timestamp
>>>> for use by the server NTP daemon.
>>>>
>>>> The server generates a reply, which needs to include the client
>>>> transmit time, the servers receive time, and the servers transmit
>> time.
>>>> Again, the transmit time needs to be written into the NTP packet,
>> and
>>>> then it needs to be processed through the network stack before it is
>>>> leaving the ethernet controller causing more jitter.
>>>>
>>>> If launch time is supported, then the client NTP daemon would simply
>>>> read the systime, add a constant delay to create the transmit
>>>> timestamp.
>>>> The delay needs to be sufficiently large to ensure that all
>>>> processing is done,
>>>>
>>>> The server will do something similar adding a constant to the server
>>>> receive timestamp to create the server transmit timestamp.
>>>> If both the client and the server uses H/W timestamping and launch
>>>> time, then the the jitter ideally is reduced to zero.
>>>>
>>>> TRANSMIT TIMESTAMPING
>>>> ========================
>>>> Support for TX timestamps in H/W is not really useful, since you
>> need
>>>> to provide the TX timestamp in the packet you measure on, so when
>> you
>>>> know the timestamp it is too late. Server to server NTP connections
>>>> support sending that timestamp in a new packet, but there is no such
>>>> support in client server communication.
>>>>
>>>> The i210 supports putting the timestamp inside the packet as it
>>>> leaves the Ethernet controller, but that means that you screw up the
>>>> UDP checksum, so the packet will be rejected by the receiving NTP
>> daemon.
>>>> In addition, the i210 timestamp measures seconds and nanoseconds
>>>> which is incompatible with the NTP timestamp which uses seconds and
>> a
>>>> 32 bit fraction of a second so that does not work either.
>>>>
>>>> Best Regards
>>>> Ulf Samuelsson
>>>> eMagii.
>>>
>>> Ulf,
>>>
>>> I have been looking into adding launch time support as part of
>> enabling some of the I210 functionality you have described (such as in
>> linux_igb_avb on SourceForge) upstream--less focused on NTP and more
>> focused on AVB, but launch time will be necessary for both. If you
>> would like, please feel free to contact me and I would love to work
>> with you on this.
>>>
>>> Reading your proposal, I'm a little confused by which systime you're
>> referring to. Do you mean on the host or on the NIC? In the case of
>> hardware timestamping today, in igb we set the SYSTIM registers to the
>> current system time, but that doesn't mean that the host clock and the
>> NIC clock stay synced. You would either need a mechanism such as PPS
>> (which igb does not implement today) to sync the host clock to the NIC
>> clock or have the NTP daemon account for the discrepancy. Off the top
>> of my head, I want to say modern PTP daemons (such as ptp4l) account
>> for the discrepancy in the daemon.
>>>
>>> Cheers,
>>> Matthew
>>
>> We live in luxury, having access to a Cesium Clock ;-) and we define
>> the time, beeing a top-level (Stratum 1) server.
>>
>> There are some I/Os on the i210 that can be used to interface to the
>> PPS.
>>
>> As for reading systime, it is done indirectly as you get the systime as
>> part of the NTP incoming packet. (It is timestamped at reception) and
>> add the constant to that value.
>>
>> Best Regards
>> Ulf Samuelsson
>
> So your proposal is to use a PPS interface (from some Stratum 1 server) to drive the clock on an I210 so you can use the I210's launch time mechanism to send packets at a certain time--is this correct? Or are you talking more about a software launch time solution?
There are 4 I/O pins, and you can capture the timestamp when they change value.
This can be used to calibrate the timestamp vs the 1 PPS clock.
It is far from ideal, but it might just work.
If you can clock the part from a 5 MHz clock from the Cesium clock, that would be even better.
>
> Forgive my ignorance, but what constant are you referring to in the receive path? Based on your first e-mail, you mention the constant should be added to the transmit path.
It is an arbitrary time constant you select in the range of 10s of milliseconds.
The only requirement is that the time from receiving the incoming packet,
to the time when the reply leaves the machine is always shorter than the time constant.
We have seen that this has been implemented on a 10 GbE FPGA card using 50 ms.
There is no requirement for short latency in NTP, only predictable latency.
>
> Also, how will you account for hardware discrepancies? For example, how far in the future you can schedule a packet will differ from hardware to hardware.
We don't have the problem, since it is for internal use, and we will use the same H/W
In all nodes. Possibly you want to be able to query the driver for your use.
Best Regards
Ulf Samuelsson
ulf@emagii.com
>
> Cheers,
> Matthew
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] tuntap: fix sparse warning
From: Jason Wang @ 2012-12-18 3:00 UTC (permalink / raw)
To: davem, netdev, linux-kernel; +Cc: fengguang.wu, Jason Wang
Make tun_enable_queue() static to fix the sparse warning:
drivers/net/tun.c:399:19: sparse: symbol 'tun_enable_queue' was not declared. Should it be static?
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/tun.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 173acf5..504f7f1 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -396,7 +396,7 @@ static void tun_disable_queue(struct tun_struct *tun, struct tun_file *tfile)
++tun->numdisabled;
}
-struct tun_struct *tun_enable_queue(struct tun_file *tfile)
+static struct tun_struct *tun_enable_queue(struct tun_file *tfile)
{
struct tun_struct *tun = tfile->detached;
--
1.7.1
^ permalink raw reply related
* [PATCH v4] netfilter: nf_conntrack_sip: Handle Cisco 7941/7945 IP phones
From: Kevin Cernekee @ 2012-12-18 4:33 UTC (permalink / raw)
To: pablo
Cc: David Woodhouse, Eric Dumazet, Patrick McHardy, David S. Miller,
Alexey Kuznetsov, Pekka Savola (ipv6), James Morris,
Hideaki YOSHIFUJI, Gabor Juhos, netfilter-devel, netfilter,
coreteam, linux-kernel, netdev
Most SIP devices use a source port of 5060/udp on SIP requests, so the
response automatically comes back to port 5060:
phone_ip:5060 -> proxy_ip:5060 REGISTER
proxy_ip:5060 -> phone_ip:5060 100 Trying
The newer Cisco IP phones, however, use a randomly chosen high source
port for the SIP request but expect the response on port 5060:
phone_ip:49173 -> proxy_ip:5060 REGISTER
proxy_ip:5060 -> phone_ip:5060 100 Trying
Standard Linux NAT, with or without nf_nat_sip, will send the reply back
to port 49173, not 5060:
phone_ip:49173 -> proxy_ip:5060 REGISTER
proxy_ip:5060 -> phone_ip:49173 100 Trying
But the phone is not listening on 49173, so it will never see the reply.
This patch modifies nf_*_sip to work around this quirk by extracting
the SIP response port from the Via: header, iff the source IP in the
packet header matches the source IP in the SIP request.
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Patrick McHardy <kaber@trash.net>
---
Baseline: git://1984.lsi.us.es/nf-next
v3->v4 changes:
Fix patch context and APIs to match the current Linux tree. These
changes are from OpenWRT (Gabor?) and David W.
v4 was tested with Cisco 7945 (high UDP destination port) and Snom m9
(normal "symmetric" UDP destination port), both on IPv4 only.
I've been running a recent OpenWRT port of this patch (Attitude Adjustment
release, 3.3 kernel) for ~2mo, with both phones as clients.
include/linux/netfilter/nf_conntrack_sip.h | 3 +++
net/netfilter/nf_conntrack_sip.c | 17 +++++++++++++++++
net/netfilter/nf_nat_sip.c | 27 ++++++++++++++++++++++++---
3 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/include/linux/netfilter/nf_conntrack_sip.h b/include/linux/netfilter/nf_conntrack_sip.h
index 387bdd0..ba7f571 100644
--- a/include/linux/netfilter/nf_conntrack_sip.h
+++ b/include/linux/netfilter/nf_conntrack_sip.h
@@ -4,12 +4,15 @@
#include <net/netfilter/nf_conntrack_expect.h>
+#include <linux/types.h>
+
#define SIP_PORT 5060
#define SIP_TIMEOUT 3600
struct nf_ct_sip_master {
unsigned int register_cseq;
unsigned int invite_cseq;
+ __be16 forced_dport;
};
enum sip_expectation_classes {
diff --git a/net/netfilter/nf_conntrack_sip.c b/net/netfilter/nf_conntrack_sip.c
index df8f4f2..72a67bb 100644
--- a/net/netfilter/nf_conntrack_sip.c
+++ b/net/netfilter/nf_conntrack_sip.c
@@ -1440,8 +1440,25 @@ static int process_sip_request(struct sk_buff *skb, unsigned int protoff,
{
enum ip_conntrack_info ctinfo;
struct nf_conn *ct = nf_ct_get(skb, &ctinfo);
+ struct nf_ct_sip_master *ct_sip_info = nfct_help_data(ct);
+ enum ip_conntrack_dir dir = CTINFO2DIR(ctinfo);
unsigned int matchoff, matchlen;
unsigned int cseq, i;
+ union nf_inet_addr addr;
+ __be16 port;
+
+ /* Many Cisco IP phones use a high source port for SIP requests, but
+ * listen for the response on port 5060. If we are the local
+ * router for one of these phones, save the port number from the
+ * Via: header so that nf_nat_sip can redirect the responses to
+ * the correct port.
+ */
+ if (ct_sip_parse_header_uri(ct, *dptr, NULL, *datalen,
+ SIP_HDR_VIA_UDP, NULL, &matchoff,
+ &matchlen, &addr, &port) > 0 &&
+ port != ct->tuplehash[dir].tuple.src.u.udp.port &&
+ nf_inet_addr_cmp(&addr, &ct->tuplehash[dir].tuple.src.u3))
+ ct_sip_info->forced_dport = port;
for (i = 0; i < ARRAY_SIZE(sip_handlers); i++) {
const struct sip_handler *handler;
diff --git a/net/netfilter/nf_nat_sip.c b/net/netfilter/nf_nat_sip.c
index 16303c7..5951146e 100644
--- a/net/netfilter/nf_nat_sip.c
+++ b/net/netfilter/nf_nat_sip.c
@@ -95,6 +95,7 @@ static int map_addr(struct sk_buff *skb, unsigned int protoff,
enum ip_conntrack_info ctinfo;
struct nf_conn *ct = nf_ct_get(skb, &ctinfo);
enum ip_conntrack_dir dir = CTINFO2DIR(ctinfo);
+ struct nf_ct_sip_master *ct_sip_info = nfct_help_data(ct);
char buffer[INET6_ADDRSTRLEN + sizeof("[]:nnnnn")];
unsigned int buflen;
union nf_inet_addr newaddr;
@@ -107,7 +108,8 @@ static int map_addr(struct sk_buff *skb, unsigned int protoff,
} else if (nf_inet_addr_cmp(&ct->tuplehash[dir].tuple.dst.u3, addr) &&
ct->tuplehash[dir].tuple.dst.u.udp.port == port) {
newaddr = ct->tuplehash[!dir].tuple.src.u3;
- newport = ct->tuplehash[!dir].tuple.src.u.udp.port;
+ newport = ct_sip_info->forced_dport ? :
+ ct->tuplehash[!dir].tuple.src.u.udp.port;
} else
return 1;
@@ -144,6 +146,7 @@ static unsigned int nf_nat_sip(struct sk_buff *skb, unsigned int protoff,
enum ip_conntrack_info ctinfo;
struct nf_conn *ct = nf_ct_get(skb, &ctinfo);
enum ip_conntrack_dir dir = CTINFO2DIR(ctinfo);
+ struct nf_ct_sip_master *ct_sip_info = nfct_help_data(ct);
unsigned int coff, matchoff, matchlen;
enum sip_header_types hdr;
union nf_inet_addr addr;
@@ -258,6 +261,21 @@ next:
!map_sip_addr(skb, protoff, dataoff, dptr, datalen, SIP_HDR_TO))
return NF_DROP;
+ /* Mangle destination port for Cisco phones, then fix up checksums */
+ if (dir == IP_CT_DIR_REPLY && ct_sip_info->forced_dport) {
+ struct udphdr *uh;
+
+ if (!skb_make_writable(skb, skb->len))
+ return NF_DROP;
+
+ uh = (void *)skb->data + protoff;
+ uh->dest = ct_sip_info->forced_dport;
+
+ if (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff,
+ 0, 0, NULL, 0))
+ return NF_DROP;
+ }
+
return NF_ACCEPT;
}
@@ -311,8 +329,10 @@ static unsigned int nf_nat_sip_expect(struct sk_buff *skb, unsigned int protoff,
enum ip_conntrack_info ctinfo;
struct nf_conn *ct = nf_ct_get(skb, &ctinfo);
enum ip_conntrack_dir dir = CTINFO2DIR(ctinfo);
+ struct nf_ct_sip_master *ct_sip_info = nfct_help_data(ct);
union nf_inet_addr newaddr;
u_int16_t port;
+ __be16 srcport;
char buffer[INET6_ADDRSTRLEN + sizeof("[]:nnnnn")];
unsigned int buflen;
@@ -326,8 +346,9 @@ static unsigned int nf_nat_sip_expect(struct sk_buff *skb, unsigned int protoff,
/* If the signalling port matches the connection's source port in the
* original direction, try to use the destination port in the opposite
* direction. */
- if (exp->tuple.dst.u.udp.port ==
- ct->tuplehash[dir].tuple.src.u.udp.port)
+ srcport = ct_sip_info->forced_dport ? :
+ ct->tuplehash[dir].tuple.src.u.udp.port;
+ if (exp->tuple.dst.u.udp.port == srcport)
port = ntohs(ct->tuplehash[!dir].tuple.dst.u.udp.port);
else
port = ntohs(exp->tuple.dst.u.udp.port);
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] tuntap: fix sparse warning
From: David Miller @ 2012-12-18 4:49 UTC (permalink / raw)
To: jasowang; +Cc: netdev, linux-kernel, fengguang.wu
In-Reply-To: <1355799627-55529-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Tue, 18 Dec 2012 11:00:27 +0800
> Make tun_enable_queue() static to fix the sparse warning:
>
> drivers/net/tun.c:399:19: sparse: symbol 'tun_enable_queue' was not declared. Should it be static?
>
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] netlink: change presentation of portid in procfs to unsigned
From: David Miller @ 2012-12-18 4:51 UTC (permalink / raw)
To: hannes; +Cc: netdev
In-Reply-To: <20121216010919.GA1528@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Sun, 16 Dec 2012 02:09:19 +0100
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
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