* 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
* Re: [PATCH] netlink: validate addr_len on bind
From: David Miller @ 2012-12-18 4:52 UTC (permalink / raw)
To: hannes; +Cc: netdev
In-Reply-To: <20121216014219.GB1528@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Sun, 16 Dec 2012 02:42:19 +0100
> Otherwise an out of bounds read could happen.
>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied.
^ permalink raw reply
* Re: [PATCH] atm: use scnprintf() instead of sprintf()
From: David Miller @ 2012-12-18 4:52 UTC (permalink / raw)
To: chas; +Cc: netdev, gang.chen
In-Reply-To: <20121217110001.3eaf3ac5@thirdoffive.cmf.nrl.navy.mil>
From: chas williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Date: Mon, 17 Dec 2012 11:00:01 -0500
>
> As reported by Chen Gang <gang.chen@asianux.com>, we should ensure there
> is enough space when formatting the sysfs buffers.
>
> Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2 v2] qmi_wwan/cdc_ether: add Dell Wireless 5800 (Novatel E362) USB IDs
From: David Miller @ 2012-12-18 4:52 UTC (permalink / raw)
To: dcbw; +Cc: bjorn, aleksander, netdev
In-Reply-To: <1355768261.1424.50.camel@dcbw.foobar.com>
From: Dan Williams <dcbw@redhat.com>
Date: Mon, 17 Dec 2012 12:17:41 -0600
> Signed-off-by: Dan Williams <dcbw@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2 v2] cdc_ether: cleanup: use USB_DEVICE_AND_INTERFACE_INFO for Novatel 551/E362
From: David Miller @ 2012-12-18 4:52 UTC (permalink / raw)
To: dcbw; +Cc: bjorn, aleksander, netdev
In-Reply-To: <1355768386.1424.52.camel@dcbw.foobar.com>
From: Dan Williams <dcbw@redhat.com>
Date: Mon, 17 Dec 2012 12:19:46 -0600
> Signed-off-by: Dan Williams <dcbw@redhat.com>
Applied.
^ permalink raw reply
* [RFC][PATCH] ipv6 multicast forwarding: Remove threshold checking and some trivial bugs
From: Ang Way Chuang @ 2012-12-18 4:57 UTC (permalink / raw)
To: netdev; +Cc: yoshfuji
This patch fixes trivial bugs for IPv6 multicast forwarding code and remove
threshold checking for multicast forwarding cache.
1. Threshold checking in IPv6 multicast forwarding cache (MFC) was not properly implemented.
syscall to setsockopt(... MRT6_ADD_MIF,...) doesn't affect the TTL because it is never used.
In fact, all MFC will always have ttl of 1 as set by ip6mr_mfc_add. From my limited knowledge of
multicast routing, threshold setting on interface is only used by DVMRP which doesn't support
IPv6. FreeBSD's struct mif6ctl doesn't have vifc_threshold. This patch removes the ttl cruft
within kernel. Userspace ABI for backward compatibility. Can someone knowledgable in multicast
routing please verify whether my understanding is correct?
2. Don't allow addition of MFC with non-existent multicast interface index.
3. Don't allow addition of MFC where incoming interface is part of oif list. This does not make
sense. Why would we want to send a multicast back to the interface where it originates from.
4. setsockopt(....MRT6_ADD_MIF, ) allows a "physical" interface to be registered as multicast
interface multiple times. This doesn't make sense. Don't allow registration duplicate
registration of the same "physical" interface.
This patch has been tested, albeit minimally using a simple program. Is this patch okay for
inclusion? Will sign off if it is okay.
---
include/linux/mroute6.h | 3 +-
net/ipv6/ip6mr.c | 79 +++++++++++++++++++++++++----------------------
2 files changed, 43 insertions(+), 39 deletions(-)
diff --git a/include/linux/mroute6.h b/include/linux/mroute6.h
index a223561..88a79d8 100644
--- a/include/linux/mroute6.h
+++ b/include/linux/mroute6.h
@@ -66,7 +66,6 @@ struct mif_device {
unsigned long bytes_in,bytes_out;
unsigned long pkt_in,pkt_out; /* Statistics */
unsigned long rate_limit; /* Traffic shaping (NI) */
- unsigned char threshold; /* TTL threshold */
unsigned short flags; /* Control flags */
int link; /* Physical interface index */
};
@@ -92,7 +91,7 @@ struct mfc6_cache {
unsigned long bytes;
unsigned long pkt;
unsigned long wrong_if;
- unsigned char ttls[MAXMIFS]; /* TTL thresholds */
+ struct if_set mf6c_ifset; /* Where it is going */
} res;
} mfc_un;
};
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 26dcdec..0a12fe4 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -122,6 +122,7 @@ static int ip6mr_rtm_dumproute(struct sk_buff *skb,
struct netlink_callback *cb);
static void mroute_clean_tables(struct mr6_table *mrt);
static void ipmr_expire_process(unsigned long arg);
+static int ip6mr_find_vif(struct mr6_table *mrt, struct net_device *dev);
#ifdef CONFIG_IPV6_MROUTE_MULTIPLE_TABLES
#define ip6mr_for_each_table(mrt, net) \
@@ -574,10 +575,10 @@ static int ipmr_mfc_seq_show(struct seq_file *seq, void *v)
for (n = mfc->mfc_un.res.minvif;
n < mfc->mfc_un.res.maxvif; n++) {
if (MIF_EXISTS(mrt, n) &&
- mfc->mfc_un.res.ttls[n] < 255)
+ IF_ISSET(n, &mfc->mfc_un.res.mf6c_ifset))
seq_printf(seq,
" %2d:%-3d",
- n, mfc->mfc_un.res.ttls[n]);
+ n, 1);
}
} else {
/* unresolved mfc_caches don't contain
@@ -895,28 +896,6 @@ static void ipmr_expire_process(unsigned long arg)
spin_unlock(&mfc_unres_lock);
}
-/* Fill oifs list. It is called under write locked mrt_lock. */
-
-static void ip6mr_update_thresholds(struct mr6_table *mrt, struct mfc6_cache *cache,
- unsigned char *ttls)
-{
- int vifi;
-
- cache->mfc_un.res.minvif = MAXMIFS;
- cache->mfc_un.res.maxvif = 0;
- memset(cache->mfc_un.res.ttls, 255, MAXMIFS);
-
- for (vifi = 0; vifi < mrt->maxvif; vifi++) {
- if (MIF_EXISTS(mrt, vifi) &&
- ttls[vifi] && ttls[vifi] < 255) {
- cache->mfc_un.res.ttls[vifi] = ttls[vifi];
- if (cache->mfc_un.res.minvif > vifi)
- cache->mfc_un.res.minvif = vifi;
- if (cache->mfc_un.res.maxvif <= vifi)
- cache->mfc_un.res.maxvif = vifi + 1;
- }
- }
-}
static int mif6_add(struct net *net, struct mr6_table *mrt,
struct mif6ctl *vifc, int mrtsock)
@@ -955,6 +934,12 @@ static int mif6_add(struct net *net, struct mr6_table *mrt,
dev = dev_get_by_index(net, vifc->mif6c_pifi);
if (!dev)
return -EADDRNOTAVAIL;
+
+ if (ip6mr_find_vif(mrt, dev) >= 0) {
+ dev_put(dev);
+ return -EADDRINUSE;
+ }
+
err = dev_set_allmulti(dev, 1);
if (err) {
dev_put(dev);
@@ -980,7 +965,6 @@ static int mif6_add(struct net *net, struct mr6_table *mrt,
v->flags = vifc->mif6c_flags;
if (!mrtsock)
v->flags |= VIFF_STATIC;
- v->threshold = vifc->vifc_threshold;
v->bytes_in = 0;
v->bytes_out = 0;
v->pkt_in = 0;
@@ -1393,22 +1377,37 @@ void ip6_mr_cleanup(void)
static int ip6mr_mfc_add(struct net *net, struct mr6_table *mrt,
struct mf6cctl *mfc, int mrtsock)
{
+ int minvif = MAXMIFS;
+ int maxvif = 0;
bool found = false;
int line;
struct mfc6_cache *uc, *c;
- unsigned char ttls[MAXMIFS];
int i;
- if (mfc->mf6cc_parent >= MAXMIFS)
+ if (mfc->mf6cc_parent >= MAXMIFS || !MIF_EXISTS(mrt, mfc->mf6cc_parent))
return -ENFILE;
- memset(ttls, 255, MAXMIFS);
- for (i = 0; i < MAXMIFS; i++) {
- if (IF_ISSET(i, &mfc->mf6cc_ifset))
- ttls[i] = 1;
+ /* incoming interface should not be part of outgoing interfaces, doing so
+ * will cause duplicate
+ */
+ if (IF_ISSET(mfc->mf6cc_parent, &mfc->mf6cc_ifset))
+ return -EINVAL;
+ for (i = 0; i < MAXMIFS; i++) {
+ if (IF_ISSET(i, &mfc->mf6cc_ifset)) {
+ if (!MIF_EXISTS(mrt, i))
+ return -ENFILE;
+
+ if (minvif > i)
+ minvif = i;
+ if (maxvif <= i)
+ maxvif = i + 1;
+ }
}
+ if (maxvif <= minvif) /* mf6cc_ifset is basically empty */
+ return -EINVAL;
+
line = MFC6_HASH(&mfc->mf6cc_mcastgrp.sin6_addr, &mfc->mf6cc_origin.sin6_addr);
list_for_each_entry(c, &mrt->mfc6_cache_array[line], list) {
@@ -1422,7 +1421,10 @@ static int ip6mr_mfc_add(struct net *net, struct mr6_table *mrt,
if (found) {
write_lock_bh(&mrt_lock);
c->mf6c_parent = mfc->mf6cc_parent;
- ip6mr_update_thresholds(mrt, c, ttls);
+ c->mfc_un.res.mf6c_ifset = mfc->mf6cc_ifset;
+ c->mfc_un.res.minvif = minvif;
+ c->mfc_un.res.maxvif = maxvif;
+
if (!mrtsock)
c->mfc_flags |= MFC_STATIC;
write_unlock_bh(&mrt_lock);
@@ -1440,7 +1442,10 @@ static int ip6mr_mfc_add(struct net *net, struct mr6_table *mrt,
c->mf6c_origin = mfc->mf6cc_origin.sin6_addr;
c->mf6c_mcastgrp = mfc->mf6cc_mcastgrp.sin6_addr;
c->mf6c_parent = mfc->mf6cc_parent;
- ip6mr_update_thresholds(mrt, c, ttls);
+ c->mfc_un.res.mf6c_ifset = mfc->mf6cc_ifset;
+ c->mfc_un.res.minvif = minvif;
+ c->mfc_un.res.maxvif = maxvif;
+
if (!mrtsock)
c->mfc_flags |= MFC_STATIC;
@@ -2036,7 +2041,7 @@ static int ip6_mr_forward(struct net *net, struct mr6_table *mrt,
large chunk of pimd to kernel. Ough... --ANK
*/
(mrt->mroute_do_pim ||
- cache->mfc_un.res.ttls[true_vifi] < 255) &&
+ IF_ISSET(true_vifi, &cache->mfc_un.res.mf6c_ifset)) &&
time_after(jiffies,
cache->mfc_un.res.last_assert + MFC_ASSERT_THRESH)) {
cache->mfc_un.res.last_assert = jiffies;
@@ -2052,7 +2057,7 @@ static int ip6_mr_forward(struct net *net, struct mr6_table *mrt,
* Forward the frame
*/
for (ct = cache->mfc_un.res.maxvif - 1; ct >= cache->mfc_un.res.minvif; ct--) {
- if (ipv6_hdr(skb)->hop_limit > cache->mfc_un.res.ttls[ct]) {
+ if (IF_ISSET(ct, &cache->mfc_un.res.mf6c_ifset)) {
if (psend != -1) {
struct sk_buff *skb2 = skb_clone(skb, GFP_ATOMIC);
if (skb2)
@@ -2143,7 +2148,7 @@ static int __ip6mr_fill_mroute(struct mr6_table *mrt, struct sk_buff *skb,
return -EMSGSIZE;
for (ct = c->mfc_un.res.minvif; ct < c->mfc_un.res.maxvif; ct++) {
- if (MIF_EXISTS(mrt, ct) && c->mfc_un.res.ttls[ct] < 255) {
+ if (MIF_EXISTS(mrt, ct) && IF_ISSET(ct, &c->mfc_un.res.mf6c_ifset)) {
nhp = nla_reserve_nohdr(skb, sizeof(*nhp));
if (nhp == NULL) {
nla_nest_cancel(skb, mp_attr);
@@ -2151,7 +2156,7 @@ static int __ip6mr_fill_mroute(struct mr6_table *mrt, struct sk_buff *skb,
}
nhp->rtnh_flags = 0;
- nhp->rtnh_hops = c->mfc_un.res.ttls[ct];
+ nhp->rtnh_hops = 1; /* this is broken as IPv6 does not use TTL threshold */
nhp->rtnh_ifindex = mrt->vif6_table[ct].dev->ifindex;
nhp->rtnh_len = sizeof(*nhp);
}
^ permalink raw reply related
* Re: [RFC][PATCH] ipv6 multicast forwarding: Remove threshold checking and some trivial bugs
From: David Miller @ 2012-12-18 5:03 UTC (permalink / raw)
To: wcang; +Cc: netdev, yoshfuji
In-Reply-To: <50CFF7A7.1070508@sfc.wide.ad.jp>
From: Ang Way Chuang <wcang@sfc.wide.ad.jp>
Date: Tue, 18 Dec 2012 12:57:11 +0800
> This patch fixes trivial bugs for IPv6 multicast forwarding code and remove
> threshold checking for multicast forwarding cache.
>
> 1. Threshold checking in IPv6 multicast forwarding cache (MFC) was not properly implemented.
> syscall to setsockopt(... MRT6_ADD_MIF,...) doesn't affect the TTL because it is never used.
> In fact, all MFC will always have ttl of 1 as set by ip6mr_mfc_add. From my limited knowledge of
> multicast routing, threshold setting on interface is only used by DVMRP which doesn't support
> IPv6. FreeBSD's struct mif6ctl doesn't have vifc_threshold. This patch removes the ttl cruft
> within kernel. Userspace ABI for backward compatibility. Can someone knowledgable in multicast
> routing please verify whether my understanding is correct?
> 2. Don't allow addition of MFC with non-existent multicast interface index.
> 3. Don't allow addition of MFC where incoming interface is part of oif list. This does not make
> sense. Why would we want to send a multicast back to the interface where it originates from.
> 4. setsockopt(....MRT6_ADD_MIF, ) allows a "physical" interface to be registered as multicast
> interface multiple times. This doesn't make sense. Don't allow registration duplicate
> registration of the same "physical" interface.
>
> This patch has been tested, albeit minimally using a simple program. Is this patch okay for
> inclusion? Will sign off if it is okay.
How about we don't mix together a set of bug fixes, with a semantic
change (the removal of the threshold checking)?
I also don't see what the point is of not signing off on this change
when you submit it.
If you delay the signoff until after review, you're just causing it to
take longer to have your changes integrated. It also makes it look
like you didn't believe fully in your change, so you probably should
have sent it as an RFC and listed your doubts in the email instead.
Overall I would rate this as an extremely poor patch submission,
sorry.
^ permalink raw reply
* Re: [RFC][PATCH] ipv6 multicast forwarding: Remove threshold checking and some trivial bugs
From: Ang Way Chuang @ 2012-12-18 5:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev, yoshfuji
In-Reply-To: <20121217.210333.1952508082741483861.davem@davemloft.net>
Oops, sorry. You're right. I am not very confident with this modification. It may break some multicast
routing daemon. Let's drop this for now.
On 18/12/2012 13:03, David Miller wrote:
> From: Ang Way Chuang <wcang@sfc.wide.ad.jp>
> Date: Tue, 18 Dec 2012 12:57:11 +0800
>
>> This patch fixes trivial bugs for IPv6 multicast forwarding code and remove
>> threshold checking for multicast forwarding cache.
>>
>> 1. Threshold checking in IPv6 multicast forwarding cache (MFC) was not properly implemented.
>> syscall to setsockopt(... MRT6_ADD_MIF,...) doesn't affect the TTL because it is never used.
>> In fact, all MFC will always have ttl of 1 as set by ip6mr_mfc_add. From my limited knowledge of
>> multicast routing, threshold setting on interface is only used by DVMRP which doesn't support
>> IPv6. FreeBSD's struct mif6ctl doesn't have vifc_threshold. This patch removes the ttl cruft
>> within kernel. Userspace ABI for backward compatibility. Can someone knowledgable in multicast
>> routing please verify whether my understanding is correct?
>> 2. Don't allow addition of MFC with non-existent multicast interface index.
>> 3. Don't allow addition of MFC where incoming interface is part of oif list. This does not make
>> sense. Why would we want to send a multicast back to the interface where it originates from.
>> 4. setsockopt(....MRT6_ADD_MIF, ) allows a "physical" interface to be registered as multicast
>> interface multiple times. This doesn't make sense. Don't allow registration duplicate
>> registration of the same "physical" interface.
>>
>> This patch has been tested, albeit minimally using a simple program. Is this patch okay for
>> inclusion? Will sign off if it is okay.
>
> How about we don't mix together a set of bug fixes, with a semantic
> change (the removal of the threshold checking)?
>
> I also don't see what the point is of not signing off on this change
> when you submit it.
>
> If you delay the signoff until after review, you're just causing it to
> take longer to have your changes integrated. It also makes it look
> like you didn't believe fully in your change, so you probably should
> have sent it as an RFC and listed your doubts in the email instead.
>
> Overall I would rate this as an extremely poor patch submission,
> sorry.
> --
> 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
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