Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next

Pull networking changes from David Miller:

 1) GRE now works over ipv6, from Dmitry Kozlov.

 2) Make SCTP more network namespace aware, from Eric Biederman.

 3) TEAM driver now works with non-ethernet devices, from Jiri Pirko.

 4) Make openvswitch network namespace aware, from Pravin B Shelar.

 5) IPV6 NAT implementation, from Patrick McHardy.

 6) Server side support for TCP Fast Open, from Jerry Chu and others.

 7) Packet BPF filter supports MOD and XOR, from Eric Dumazet and Daniel
    Borkmann.

 8) Increate the loopback default MTU to 64K, from Eric Dumazet.

 9) Use a per-task rather than per-socket page fragment allocator for
    outgoing networking traffic.  This benefits processes that have very
    many mostly idle sockets, which is quite common.

    From Eric Dumazet.

10) Use up to 32K for page fragment allocations, with fallbacks to
    smaller sizes when higher order page allocations fail.  Benefits are
    a) less segments for driver to process b) less calls to page
    allocator c) less waste of space.

    From Eric Dumazet.

11) Allow GRO to be used on GRE tunnels, from Eric Dumazet.

12) VXLAN device driver, one way to handle VLAN issues such as the
    limitation of 4096 VLAN IDs yet still have some level of isolation.
    From Stephen Hemminger.

13) As usual there is a large boatload of driver changes, with the scale
    perhaps tilted towards the wireless side this time around.

Fix up various fairly trivial conflicts, mostly caused by the user
namespace changes.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next: (1012 commits)
  hyperv: Add buffer for extended info after the RNDIS response message.
  hyperv: Report actual status in receive completion packet
  hyperv: Remove extra allocated space for recv_pkt_list elements
  hyperv: Fix page buffer handling in rndis_filter_send_request()
  hyperv: Fix the missing return value in rndis_filter_set_packet_filter()
  hyperv: Fix the max_xfer_size in RNDIS initialization
  vxlan: put UDP socket in correct namespace
  vxlan: Depend on CONFIG_INET
  sfc: Fix the reported priorities of different filter types
  sfc: Remove EFX_FILTER_FLAG_RX_OVERRIDE_IP
  sfc: Fix loopback self-test with separate_tx_channels=1
  sfc: Fix MCDI structure field lookup
  sfc: Add parentheses around use of bitfield macro arguments
  sfc: Fix null function pointer in efx_sriov_channel_type
  vxlan: virtual extensible lan
  igmp: export symbol ip_mc_leave_group
  netlink: add attributes to fdb interface
  tg3: unconditionally select HWMON support when tg3 is enabled.
  Revert "net: ti cpsw ethernet: allow reading phy interface mode from DT"
  gre: fix sparse warning
  ...
This commit is contained in:
Linus Torvalds
2012-10-02 13:38:27 -07:00
967 changed files with 42768 additions and 21940 deletions

View File

@@ -19,7 +19,11 @@ Date: September 2010
Contact: Richard Cochran <richardcochran@gmail.com>
Description:
This file contains the name of the PTP hardware clock
as a human readable string.
as a human readable string. The purpose of this
attribute is to provide the user with a "friendly
name" and to help distinguish PHY based devices from
MAC based ones. The string does not necessarily have
to be any kind of unique id.
What: /sys/class/ptp/ptpN/max_adjustment
Date: September 2010

View File

@@ -0,0 +1,49 @@
Bosch C_CAN/D_CAN controller Device Tree Bindings
-------------------------------------------------
Required properties:
- compatible : Should be "bosch,c_can" for C_CAN controllers and
"bosch,d_can" for D_CAN controllers.
- reg : physical base address and size of the C_CAN/D_CAN
registers map
- interrupts : property with a value describing the interrupt
number
Optional properties:
- ti,hwmods : Must be "d_can<n>" or "c_can<n>", n being the
instance number
Note: "ti,hwmods" field is used to fetch the base address and irq
resources from TI, omap hwmod data base during device registration.
Future plan is to migrate hwmod data base contents into device tree
blob so that, all the required data will be used from device tree dts
file.
Example:
Step1: SoC common .dtsi file
dcan1: d_can@481d0000 {
compatible = "bosch,d_can";
reg = <0x481d0000 0x2000>;
interrupts = <55>;
interrupt-parent = <&intc>;
status = "disabled";
};
(or)
dcan1: d_can@481d0000 {
compatible = "bosch,d_can";
ti,hwmods = "d_can1";
reg = <0x481d0000 0x2000>;
interrupts = <55>;
interrupt-parent = <&intc>;
status = "disabled";
};
Step 2: board specific .dts file
&dcan1 {
status = "okay";
};

View File

@@ -0,0 +1,109 @@
TI SoC Ethernet Switch Controller Device Tree Bindings
------------------------------------------------------
Required properties:
- compatible : Should be "ti,cpsw"
- reg : physical base address and size of the cpsw
registers map
- interrupts : property with a value describing the interrupt
number
- interrupt-parent : The parent interrupt controller
- cpdma_channels : Specifies number of channels in CPDMA
- host_port_no : Specifies host port shift
- cpdma_reg_ofs : Specifies CPDMA submodule register offset
- cpdma_sram_ofs : Specifies CPDMA SRAM offset
- ale_reg_ofs : Specifies ALE submodule register offset
- ale_entries : Specifies No of entries ALE can hold
- host_port_reg_ofs : Specifies host port register offset
- hw_stats_reg_ofs : Specifies hardware statistics register offset
- bd_ram_ofs : Specifies internal desciptor RAM offset
- bd_ram_size : Specifies internal descriptor RAM size
- rx_descs : Specifies number of Rx descriptors
- mac_control : Specifies Default MAC control register content
for the specific platform
- slaves : Specifies number for slaves
- slave_reg_ofs : Specifies slave register offset
- sliver_reg_ofs : Specifies slave sliver register offset
- phy_id : Specifies slave phy id
- mac-address : Specifies slave MAC address
Optional properties:
- ti,hwmods : Must be "cpgmac0"
- no_bd_ram : Must be 0 or 1
Note: "ti,hwmods" field is used to fetch the base address and irq
resources from TI, omap hwmod data base during device registration.
Future plan is to migrate hwmod data base contents into device tree
blob so that, all the required data will be used from device tree dts
file.
Examples:
mac: ethernet@4A100000 {
compatible = "ti,cpsw";
reg = <0x4A100000 0x1000>;
interrupts = <55 0x4>;
interrupt-parent = <&intc>;
cpdma_channels = <8>;
host_port_no = <0>;
cpdma_reg_ofs = <0x800>;
cpdma_sram_ofs = <0xa00>;
ale_reg_ofs = <0xd00>;
ale_entries = <1024>;
host_port_reg_ofs = <0x108>;
hw_stats_reg_ofs = <0x900>;
bd_ram_ofs = <0x2000>;
bd_ram_size = <0x2000>;
no_bd_ram = <0>;
rx_descs = <64>;
mac_control = <0x20>;
slaves = <2>;
cpsw_emac0: slave@0 {
slave_reg_ofs = <0x208>;
sliver_reg_ofs = <0xd80>;
phy_id = "davinci_mdio.16:00";
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
cpsw_emac1: slave@1 {
slave_reg_ofs = <0x308>;
sliver_reg_ofs = <0xdc0>;
phy_id = "davinci_mdio.16:01";
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
};
(or)
mac: ethernet@4A100000 {
compatible = "ti,cpsw";
ti,hwmods = "cpgmac0";
cpdma_channels = <8>;
host_port_no = <0>;
cpdma_reg_ofs = <0x800>;
cpdma_sram_ofs = <0xa00>;
ale_reg_ofs = <0xd00>;
ale_entries = <1024>;
host_port_reg_ofs = <0x108>;
hw_stats_reg_ofs = <0x900>;
bd_ram_ofs = <0x2000>;
bd_ram_size = <0x2000>;
no_bd_ram = <0>;
rx_descs = <64>;
mac_control = <0x20>;
slaves = <2>;
cpsw_emac0: slave@0 {
slave_reg_ofs = <0x208>;
sliver_reg_ofs = <0xd80>;
phy_id = "davinci_mdio.16:00";
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
cpsw_emac1: slave@1 {
slave_reg_ofs = <0x308>;
sliver_reg_ofs = <0xdc0>;
phy_id = "davinci_mdio.16:01";
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
};

View File

@@ -0,0 +1,33 @@
TI SoC Davinci MDIO Controller Device Tree Bindings
---------------------------------------------------
Required properties:
- compatible : Should be "ti,davinci_mdio"
- reg : physical base address and size of the davinci mdio
registers map
- bus_freq : Mdio Bus frequency
Optional properties:
- ti,hwmods : Must be "davinci_mdio"
Note: "ti,hwmods" field is used to fetch the base address and irq
resources from TI, omap hwmod data base during device registration.
Future plan is to migrate hwmod data base contents into device tree
blob so that, all the required data will be used from device tree dts
file.
Examples:
mdio: davinci_mdio@4A101000 {
compatible = "ti,cpsw";
reg = <0x4A101000 0x1000>;
bus_freq = <1000000>;
};
(or)
mdio: davinci_mdio@4A101000 {
compatible = "ti,cpsw";
ti,hwmods = "davinci_mdio";
bus_freq = <1000000>;
};

View File

@@ -0,0 +1,75 @@
Properties for an MDIO bus multiplexer controlled by a memory-mapped device
This is a special case of a MDIO bus multiplexer. A memory-mapped device,
like an FPGA, is used to control which child bus is connected. The mdio-mux
node must be a child of the memory-mapped device. The driver currently only
supports devices with eight-bit registers.
Required properties in addition to the generic multiplexer properties:
- compatible : string, must contain "mdio-mux-mmioreg"
- reg : integer, contains the offset of the register that controls the bus
multiplexer. The size field in the 'reg' property is the size of
register, and must therefore be 1.
- mux-mask : integer, contains an eight-bit mask that specifies which
bits in the register control the actual bus multiplexer. The
'reg' property of each child mdio-mux node must be constrained by
this mask.
Example:
The FPGA node defines a memory-mapped FPGA with a register space of 0x30 bytes.
For the "EMI2" MDIO bus, register 9 (BRDCFG1) controls the mux on that bus.
A bitmask of 0x6 means that bits 1 and 2 (bit 0 is lsb) are the bits on
BRDCFG1 that control the actual mux.
/* The FPGA node */
fpga: board-control@3,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,p5020ds-fpga", "fsl,fpga-ngpixis";
reg = <3 0 0x30>;
ranges = <0 3 0 0x30>;
mdio-mux-emi2 {
compatible = "mdio-mux-mmioreg", "mdio-mux";
mdio-parent-bus = <&xmdio0>;
#address-cells = <1>;
#size-cells = <0>;
reg = <9 1>; // BRDCFG1
mux-mask = <0x6>; // EMI2
emi2_slot1: mdio@0 { // Slot 1 XAUI (FM2)
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
phy_xgmii_slot1: ethernet-phy@0 {
compatible = "ethernet-phy-ieee802.3-c45";
reg = <4>;
};
};
emi2_slot2: mdio@2 { // Slot 2 XAUI (FM1)
reg = <2>;
#address-cells = <1>;
#size-cells = <0>;
phy_xgmii_slot2: ethernet-phy@4 {
compatible = "ethernet-phy-ieee802.3-c45";
reg = <0>;
};
};
};
};
/* The parent MDIO bus. */
xmdio0: mdio@f1000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,fman-xmdio";
reg = <0xf1000 0x1000>;
interrupts = <100 1 0 0>;
};

View File

@@ -78,7 +78,8 @@ nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]
flags = hard, nointr, noposix, cto, ac
ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:
<dns0-ip>:<dns1-ip>
This parameter tells the kernel how to configure IP addresses of devices
and also how to set up the IP routing table. It was originally called
@@ -158,6 +159,13 @@ ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
Default: any
<dns0-ip> IP address of first nameserver.
Value gets exported by /proc/net/pnp which is often linked
on embedded systems by /etc/resolv.conf.
<dns1-ip> IP address of secound nameserver.
Same as above.
nfsrootdebug

View File

@@ -24,6 +24,9 @@ Partitions and P_Keys
The P_Key for any interface is given by the "pkey" file, and the
main interface for a subinterface is in "parent."
Child interface create/delete can also be done using IPoIB's
rtnl_link_ops, where childs created using either way behave the same.
Datagram vs Connected modes
The IPoIB driver supports two modes of operation: datagram and

View File

@@ -75,9 +75,10 @@ folder:
There is a special folder for debugging information:
# ls /sys/kernel/debug/batman_adv/bat0/
# bla_claim_table log socket transtable_local
# gateways originators transtable_global vis_data
# ls /sys/kernel/debug/batman_adv/bat0/
# bla_backbone_table log transtable_global
# bla_claim_table originators transtable_local
# gateways socket vis_data
Some of the files contain all sort of status information regard-
ing the mesh network. For example, you can view the table of

View File

@@ -752,12 +752,22 @@ xmit_hash_policy
protocol information to generate the hash.
Uses XOR of hardware MAC addresses and IP addresses to
generate the hash. The formula is
generate the hash. The IPv4 formula is
(((source IP XOR dest IP) AND 0xffff) XOR
( source MAC XOR destination MAC ))
modulo slave count
The IPv6 formula is
hash = (source ip quad 2 XOR dest IP quad 2) XOR
(source ip quad 3 XOR dest IP quad 3) XOR
(source ip quad 4 XOR dest IP quad 4)
(((hash >> 24) XOR (hash >> 16) XOR (hash >> 8) XOR hash)
XOR (source MAC XOR destination MAC))
modulo slave count
This algorithm will place all traffic to a particular
network peer on the same slave. For non-IP traffic,
the formula is the same as for the layer2 transmit
@@ -778,19 +788,29 @@ xmit_hash_policy
slaves, although a single connection will not span
multiple slaves.
The formula for unfragmented TCP and UDP packets is
The formula for unfragmented IPv4 TCP and UDP packets is
((source port XOR dest port) XOR
((source IP XOR dest IP) AND 0xffff)
modulo slave count
For fragmented TCP or UDP packets and all other IP
protocol traffic, the source and destination port
The formula for unfragmented IPv6 TCP and UDP packets is
hash = (source port XOR dest port) XOR
((source ip quad 2 XOR dest IP quad 2) XOR
(source ip quad 3 XOR dest IP quad 3) XOR
(source ip quad 4 XOR dest IP quad 4))
((hash >> 24) XOR (hash >> 16) XOR (hash >> 8) XOR hash)
modulo slave count
For fragmented TCP or UDP packets and all other IPv4 and
IPv6 protocol traffic, the source and destination port
information is omitted. For non-IP traffic, the
formula is the same as for the layer2 transmit hash
policy.
This policy is intended to mimic the behavior of
The IPv4 policy is intended to mimic the behavior of
certain switches, notably Cisco switches with PFC2 as
well as some Foundry and IBM products.

View File

@@ -439,7 +439,9 @@ tcp_stdurg - BOOLEAN
tcp_synack_retries - INTEGER
Number of times SYNACKs for a passive TCP connection attempt will
be retransmitted. Should not be higher than 255. Default value
is 5, which corresponds to ~180seconds.
is 5, which corresponds to 31seconds till the last retransmission
with the current initial RTO of 1second. With this the final timeout
for a passive TCP connection will happen after 63seconds.
tcp_syncookies - BOOLEAN
Only valid when the kernel was compiled with CONFIG_SYNCOOKIES
@@ -465,20 +467,37 @@ tcp_syncookies - BOOLEAN
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 not use connect(). Instead, it should use sendmsg() or sendto()
with MSG_FASTOPEN flag which performs a TCP handshake automatically.
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
5: Enables sending data in the opening SYN on the client regardless
of cookie availability.
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.
tcp_syn_retries - INTEGER
Number of times initial SYNs for an active TCP connection attempt
will be retransmitted. Should not be higher than 255. Default value
is 5, which corresponds to ~180seconds.
is 6, which corresponds to 63seconds till the last restransmission
with the current initial RTO of 1second. With this the final timeout
for an active TCP connection attempt will happen after 127seconds.
tcp_timestamps - BOOLEAN
Enable timestamps as defined in RFC1323.

View File

@@ -173,7 +173,6 @@ Where:
For MDIO bus The we have:
struct stmmac_mdio_bus_data {
int bus_id;
int (*phy_reset)(void *priv);
unsigned int phy_mask;
int *irqs;
@@ -181,7 +180,6 @@ For MDIO bus The we have:
};
Where:
o bus_id: bus identifier;
o phy_reset: hook to reset the phy device attached to the bus.
o phy_mask: phy mask passed when register the MDIO bus within the driver.
o irqs: list of IRQs, one per PHY.
@@ -230,9 +228,6 @@ there are two MAC cores: one MAC is for MDIO Bus/PHY emulation
with fixed_link support.
static struct stmmac_mdio_bus_data stmmac1_mdio_bus = {
.bus_id = 1,
|
|-> phy device on the bus_id 1
.phy_reset = phy_reset;
|
|-> function to provide the phy_reset on this board

View File

@@ -0,0 +1,47 @@
Virtual eXtensible Local Area Networking documentation
======================================================
The VXLAN protocol is a tunnelling protocol that is designed to
solve the problem of limited number of available VLAN's (4096).
With VXLAN identifier is expanded to 24 bits.
It is a draft RFC standard, that is implemented by Cisco Nexus,
Vmware and Brocade. The protocol runs over UDP using a single
destination port (still not standardized by IANA).
This document describes the Linux kernel tunnel device,
there is also an implantation of VXLAN for Openvswitch.
Unlike most tunnels, a VXLAN is a 1 to N network, not just point
to point. A VXLAN device can either dynamically learn the IP address
of the other end, in a manner similar to a learning bridge, or the
forwarding entries can be configured statically.
The management of vxlan is done in a similar fashion to it's
too closest neighbors GRE and VLAN. Configuring VXLAN requires
the version of iproute2 that matches the kernel release
where VXLAN was first merged upstream.
1. Create vxlan device
# ip li add vxlan0 type vxlan id 42 group 239.1.1.1 dev eth1
This creates a new device (vxlan0). The device uses the
the multicast group 239.1.1.1 over eth1 to handle packets where
no entry is in the forwarding table.
2. Delete vxlan device
# ip link delete vxlan0
3. Show vxlan info
# ip -d show vxlan0
It is possible to create, destroy and display the vxlan
forwarding table using the new bridge command.
1. Create forwarding table entry
# bridge fdb add to 00:17:42:8a:b4:05 dst 192.19.0.2 dev vxlan0
2. Delete forwarding table entry
# bridge fdb delete 00:17:42:8a:b4:05
3. Show forwarding table
# bridge fdb show dev vxlan0

View File

@@ -4806,6 +4806,7 @@ M: Lauro Ramos Venancio <lauro.venancio@openbossa.org>
M: Aloisio Almeida Jr <aloisio.almeida@openbossa.org>
M: Samuel Ortiz <sameo@linux.intel.com>
L: linux-wireless@vger.kernel.org
L: linux-nfc@lists.01.org (moderated for non-subscribers)
S: Maintained
F: net/nfc/
F: include/linux/nfc.h

View File

@@ -67,7 +67,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m

View File

@@ -67,7 +67,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m

View File

@@ -65,7 +65,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m

View File

@@ -65,7 +65,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m

View File

@@ -66,7 +66,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m

View File

@@ -61,7 +61,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m

View File

@@ -80,7 +80,6 @@ CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m

Some files were not shown because too many files have changed in this diff Show More