* Re: atheros driver - desc
From: Kalle Valo @ 2005-08-06 19:57 UTC (permalink / raw)
To: Mateusz Berezecki; +Cc: kernel-mentors, netdev
In-Reply-To: <42F2D523.9020702@gmail.com>
Mateusz Berezecki <mateuszb@gmail.com> writes:
> The driver is not yet fully working because I didn't finish kernel
> integration yet. Almost all
> driver I/O ops are reverse engineered independently of openbsd openhal
> which is missing just too much.
>
>
> Ok, enough talking. Most of the atheros 5212 hal is now open :)
This is great news. An open source Atheros driver which could be
included to Linux is really needed.
But how was the reverse engineering done? I noticed that forcedeth
driver was implemented using the clean room design[1] and Linux
Broadcom 4301 driver project[2] seems to be using the same method.
The reason I'm asking this is that I just wouldn't want see the same
happening this with this driver as happened during reverse engineering
of pwc Philips Webcam driver (some parts of the driver were removed
from kernel, but I believe the situation is now solved).
Actually, what are requirements to get a reverse engineered driver
included to Linux? Is clean room design an absolute must? It seems
that reverse engineering is needed if we want Linux support for most
of the WLAN cards on the market :(
[1] http://en.wikipedia.org/wiki/Clean_room_design
[2] http://linux-bcom4301.sourceforge.net/go/progress
--
Kalle Valo
^ permalink raw reply
* Re: ICMP broken in 2.6.13-rc5
From: Harald Welte @ 2005-08-06 16:17 UTC (permalink / raw)
To: Vladimir B. Savkin; +Cc: akpm, netdev, Netfilter Development Mailinglist
In-Reply-To: <20050806092543.GA596@tentacle.sectorb.msk.ru>
[-- Attachment #1.1: Type: text/plain, Size: 1647 bytes --]
On Sat, Aug 06, 2005 at 01:25:43PM +0400, Vladimir B. Savkin wrote:
> On Sat, Aug 06, 2005 at 11:13:37AM +0200, Harald Welte wrote:
> > On Sat, Aug 06, 2005 at 02:08:15AM +0400, Vladimir B. Savkin wrote:
> > > I found that it really is NOTRACK who cause? bogus ICMP errors.
> >
> > Well, this means that your ICMP errors need to be NAT'ed but they
> > cannot, since the original connection causing the ICMP error did not go
> > through connection tracking.
>
> How so, when there are no NAT rules that can match either source packets
> or ICMP errors?
Ok, I re-thought. Given the following assumptions (combined from your
three mails):
1) tcp/udp packets are matched by NOTRACK
2) icmp errors for packets in '1' are matched by NOTRACK
3) there are no NAT rules that affect the packets in '1' and '2'
I see a case where packets get corrupted within iptable_nat. Please try
the attached (untested) patch attached to my mail.
Still, my initial comments about this being an invalid setup upholds.
The NAT code needs to see all packets/connections in order to learn
about used port/ip tuples. Otherwise, when allocating a tuple, it could
reuse a tuple that is already used by a non-NAT'ed connection.
So using nat in combination with NOTRACK should be prevented. I'll hack
up a patch for that, too.
--
- Harald Welte <laforge@gnumonks.org> http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
[-- Attachment #1.2: untracked.diff --]
[-- Type: text/plain, Size: 1553 bytes --]
[NETFILTER] don't try to do any NAT on untracked connections
With the introduction of 'rustynat' in 2.6.11, the old tricks of preventing
NAT of 'untracked' connections (e.g. NOTRACK target in 'raw' table) are no
longer sufficient. The ip_conntrack_untracked.status |= IPS_NAT_DONE_MASK
effectively prevents iteration of the 'nat' table, but doesn't prevent
nat_packet() to be executed. Since nr_manips is gone in 'rustynat',
nat_packet() now implicitly thinks that it has to do NAT on the packet.
This patch fixes that problem by explicitly checking for
ip_conntrack_untracked in ip_nat_fn().
Signed-off-by: Harald Welte <laforge@netfilter.org>
---
commit c16fd4ffed6349d0888cd97a75d04394dac42021
tree b4f0e73c7c36f3a52b23593c40f1f49353ba67e3
parent 4d08142e287f852db3f4bfd614f2d73521bd7f07
author Harald Welte <laforge@netfilter.org> Sa, 06 Aug 2005 18:11:00 +0200
committer Harald Welte <laforge@netfilter.org> Sa, 06 Aug 2005 18:11:00 +0200
net/ipv4/netfilter/ip_nat_standalone.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/netfilter/ip_nat_standalone.c b/net/ipv4/netfilter/ip_nat_standalone.c
--- a/net/ipv4/netfilter/ip_nat_standalone.c
+++ b/net/ipv4/netfilter/ip_nat_standalone.c
@@ -100,6 +100,10 @@ ip_nat_fn(unsigned int hooknum,
return NF_ACCEPT;
}
+ /* Don't try to NAT if this packet is not conntracked */
+ if (ct == &ip_conntrack_untracked)
+ return NF_ACCEPT;
+
switch (ctinfo) {
case IP_CT_RELATED:
case IP_CT_RELATED+IP_CT_IS_REPLY:
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] emac: add support for platform-specific unsupported PHY features
From: Eugene Surovegin @ 2005-08-06 0:05 UTC (permalink / raw)
To: Wade Farnsworth; +Cc: jgarzik, netdev, Matt Porter
In-Reply-To: <1123284725.27880.26.camel@rhino.az.mvista.com>
On Fri, Aug 05, 2005 at 04:32:05PM -0700, Wade Farnsworth wrote:
> Hello,
>
> This patch adds support to the ibm_emac driver for platform-specific
> unsupported PHY features.
>
> The patch attempts to determine the highest speed and duplex when
> autonegotiation is unsupported.
Looks good.
>
> -Wade Farnsworth
>
> Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
> diff -upr linux-2.6/drivers/net/ibm_emac/ibm_emac_core.c linux-2.6-dev/drivers/net/ibm_emac/ibm_emac_core.c
> --- linux-2.6/drivers/net/ibm_emac/ibm_emac_core.c 2005-08-03 13:33:42.000000000 -0700
> +++ linux-2.6-dev/drivers/net/ibm_emac/ibm_emac_core.c 2005-08-02 10:42:59.000000000 -0700
> @@ -1876,6 +1876,9 @@ static int emac_init_device(struct ocp_d
> rc = -ENODEV;
> goto bail;
> }
> +
> + /* Disable any PHY features not supported by the platform */
> + ep->phy_mii.def->features &= ~emacdata->feat_unsupp;
>
> /* Setup initial PHY config & startup aneg */
> if (ep->phy_mii.def->ops->init)
> @@ -1883,6 +1886,38 @@ static int emac_init_device(struct ocp_d
> netif_carrier_off(ndev);
> if (ep->phy_mii.def->features & SUPPORTED_Autoneg)
> ep->want_autoneg = 1;
> + else {
> + ep->want_autoneg = 0;
> +
> + /* Select highest supported speed/duplex */
> + if (ep->phy_mii.def->features & SUPPORTED_10000baseT_Full) {
> + ep->phy_mii.speed = SPEED_10000;
> + ep->phy_mii.duplex = DUPLEX_FULL;
I think you are being too optimistic here :). EMAC doesn't support 10G
Ethernet and will never will (at least sanely) given it's
brain-damaged design. So I think it's safe to drop
SUPPORTED_10000baseT_Full test.
I'll update my NAPI tree with similar code.
--
Eugene
^ permalink raw reply
* [PATCH] emac: add support for platform-specific unsupported PHY features
From: Wade Farnsworth @ 2005-08-05 23:32 UTC (permalink / raw)
To: jgarzik, netdev, Matt Porter; +Cc: Eugene Surovegin
[-- Attachment #1: Type: text/plain, Size: 277 bytes --]
Hello,
This patch adds support to the ibm_emac driver for platform-specific
unsupported PHY features.
The patch attempts to determine the highest speed and duplex when
autonegotiation is unsupported.
-Wade Farnsworth
Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
[-- Attachment #2: ibm-emac-phy-feat-unsupp-core.patch --]
[-- Type: text/x-patch, Size: 1887 bytes --]
diff -upr linux-2.6/drivers/net/ibm_emac/ibm_emac_core.c linux-2.6-dev/drivers/net/ibm_emac/ibm_emac_core.c
--- linux-2.6/drivers/net/ibm_emac/ibm_emac_core.c 2005-08-03 13:33:42.000000000 -0700
+++ linux-2.6-dev/drivers/net/ibm_emac/ibm_emac_core.c 2005-08-02 10:42:59.000000000 -0700
@@ -1876,6 +1876,9 @@ static int emac_init_device(struct ocp_d
rc = -ENODEV;
goto bail;
}
+
+ /* Disable any PHY features not supported by the platform */
+ ep->phy_mii.def->features &= ~emacdata->feat_unsupp;
/* Setup initial PHY config & startup aneg */
if (ep->phy_mii.def->ops->init)
@@ -1883,6 +1886,38 @@ static int emac_init_device(struct ocp_d
netif_carrier_off(ndev);
if (ep->phy_mii.def->features & SUPPORTED_Autoneg)
ep->want_autoneg = 1;
+ else {
+ ep->want_autoneg = 0;
+
+ /* Select highest supported speed/duplex */
+ if (ep->phy_mii.def->features & SUPPORTED_10000baseT_Full) {
+ ep->phy_mii.speed = SPEED_10000;
+ ep->phy_mii.duplex = DUPLEX_FULL;
+ } else if (ep->phy_mii.def->features &
+ SUPPORTED_1000baseT_Full) {
+ ep->phy_mii.speed = SPEED_1000;
+ ep->phy_mii.duplex = DUPLEX_FULL;
+ } else if (ep->phy_mii.def->features &
+ SUPPORTED_1000baseT_Half) {
+ ep->phy_mii.speed = SPEED_1000;
+ ep->phy_mii.duplex = DUPLEX_HALF;
+ } else if (ep->phy_mii.def->features &
+ SUPPORTED_100baseT_Full) {
+ ep->phy_mii.speed = SPEED_100;
+ ep->phy_mii.duplex = DUPLEX_FULL;
+ } else if (ep->phy_mii.def->features &
+ SUPPORTED_100baseT_Half) {
+ ep->phy_mii.speed = SPEED_100;
+ ep->phy_mii.duplex = DUPLEX_HALF;
+ } else if (ep->phy_mii.def->features &
+ SUPPORTED_10baseT_Full) {
+ ep->phy_mii.speed = SPEED_10;
+ ep->phy_mii.duplex = DUPLEX_FULL;
+ } else {
+ ep->phy_mii.speed = SPEED_10;
+ ep->phy_mii.duplex = DUPLEX_HALF;
+ }
+ }
emac_start_link(ep, NULL);
/* read the MAC Address */
^ permalink raw reply
* error about rp_filter
From: Sam Ravnborg @ 2005-08-05 21:02 UTC (permalink / raw)
To: Adrian Buciuman, netdev; +Cc: kbuild-devel
In-Reply-To: <35e353d505080508444dbb7189@mail.gmail.com>
Hi Adrian.
This is better suited for netdev, so I've forwarded your mail there.
[It was originally sent to kbuild-devel]
Sam
On Fri, Aug 05, 2005 at 06:44:59PM +0300, Adrian Buciuman wrote:
> Hello,
>
> rp-filter is default off (see ip-sysctl.txt and proc.txt or test it),
> but comments in
>
>
> Documentation/Configure/help --- 2.4 kernels
> net/ipv4/Kconfig --- 2.6 kernels
>
>
> have led some (look at /etc/rc.d/rc.ip_forward on Slackware) to
> believe it is default on.
>
>
> Regards,
> Adrian Buciuman
>
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply
* Re: argh... ;/
From: Daniel Phillips @ 2005-08-05 18:56 UTC (permalink / raw)
To: Dave Jones; +Cc: kernel-mentors, netdev
In-Reply-To: <20050805174946.GK2241@redhat.com>
On Saturday 06 August 2005 03:49, Dave Jones wrote:
> On Fri, Aug 05, 2005 at 01:20:59PM -0400, John W. Linville wrote:
> > On Sat, Aug 06, 2005 at 02:41:30AM +1000, Daniel Phillips wrote:
> > > On Friday 05 August 2005 13:04, Mateusz Berezecki wrote:
> > > > I accidentaly posted the patches as MIME attachments... its 5:03 am
> > > > here
> > >
> > > Does anybody still care if patches are posted as attachments,
> > > particularly for review as opposed to submission?
> >
> > Yes. Opening attachments makes them harder to review.
>
> Indeed. Replying to such mails ends up looking like..
>
Hi, sorry, about the misfired "test" mail... the _real_ issue for me was that
Kmail was turning tabs into spaces for the longest time, so forcing me either
to switch mailers (and you know how appealing that is) or send patches as
attachments. It's finally fixed, so I'll happily join in with dumping on the
poor misguided folks who insist on posting their patches as attachments.
Regards,
Daniel "the flexible" Phillips
^ permalink raw reply
* Re: atheros driver - desc
From: Mateusz Berezecki @ 2005-08-05 18:54 UTC (permalink / raw)
To: Jeff Garzik; +Cc: kernel-mentors, netdev
In-Reply-To: <42F3B279.2010200@pobox.com>
On 8/5/05, Jeff Garzik <jgarzik@pobox.com> wrote:
> There is no document describing the API AFAIK.
>
> The best thing to do is read over the ipw2[12]00 drivers.
>
> Jeff
Ok, thanks for pointing me there.
best
Mateusz
^ permalink raw reply
* Re: atheros driver - desc
From: Jeff Garzik @ 2005-08-05 18:39 UTC (permalink / raw)
To: Mateusz Berezecki; +Cc: kernel-mentors, netdev
In-Reply-To: <20050805180709.GD3067@ntjohd.mshome.net>
Mateusz Berezecki wrote:
> And regarding that ieee80211 API, I would be very excited if
> anyone could explain the general overview of how new wireless
> API works. I read the source but sometimes a quick answer from
> experienced kernel coder would do more good.
There is no document describing the API AFAIK.
The best thing to do is read over the ipw2[12]00 drivers.
Jeff
^ permalink raw reply
* [PATCH] sockaddr_ll change for IPoIB interfaces
From: Hal Rosenstock @ 2005-08-05 18:25 UTC (permalink / raw)
To: netdev; +Cc: openib-general
Hi,
The patch below is to accomodate IPoIB link layer address in the
sockaddr_ll struct so that user space can send and receive IPoIB link
later packets. Unfortunately, IPoIB has 20 bytes LL addresses rather
than the 8 byte MAC addresses (or under) used by other LLs.
There is a similar change to both:
/usr/include/linux/if_packet.h
/usr/include/netpacket/packet.h
as in:
include/linux/if_packet.h below
to increase sll_addr from 8 to 20 bytes.
Thanks.
-- Hal
sockaddr_ll changes to accomodate IPoIB interfaces.
This is due to the fact that the IPoIB link layer
address is 20 bytes rather than 8 bytes. With the current 8 byte
address, it is not possible to send ARPs and RARPs from userspace as the
broadcast and unicast IPoIB addresses cannot be supplied properly.
There is backward compatibility support for those applications built
with the existing structure (prior to this patch).
Signed-off-by: Hal Rosenstock <halr@voltaire.com>
--- include/linux/if_packet.h.orig 2005-06-29 19:00:53.000000000 -0400
+++ include/linux/if_packet.h 2005-08-05 10:04:06.000000000 -0400
@@ -8,6 +8,7 @@ struct sockaddr_pkt
unsigned short spkt_protocol;
};
+#define SOCKADDR_LL_COMPAT 12
struct sockaddr_ll
{
unsigned short sll_family;
@@ -16,7 +17,7 @@ struct sockaddr_ll
unsigned short sll_hatype;
unsigned char sll_pkttype;
unsigned char sll_halen;
- unsigned char sll_addr[8];
+ unsigned char sll_addr[20];
};
/* Packet types */
--- af_packet.c.orig 2005-06-29 19:00:53.000000000 -0400
+++ af_packet.c 2005-08-05 13:28:49.000000000 -0400
@@ -708,8 +708,12 @@ static int packet_sendmsg(struct kiocb *
addr = NULL;
} else {
err = -EINVAL;
- if (msg->msg_namelen < sizeof(struct sockaddr_ll))
- goto out;
+ if (msg->msg_namelen < sizeof(struct sockaddr_ll)) {
+ /* Support for older sockaddr_ll structs */
+ if ((msg->msg_namelen != sizeof(struct sockaddr_ll) - SOCKADDR_LL_COMPAT) ||
+ (saddr->sll_hatype == ARPHRD_INFINIBAND))
+ goto out;
+ }
ifindex = saddr->sll_ifindex;
proto = saddr->sll_protocol;
addr = saddr->sll_addr;
@@ -937,7 +941,11 @@ static int packet_bind(struct socket *so
*/
if (addr_len < sizeof(struct sockaddr_ll))
- return -EINVAL;
+ /* Support for older sockaddr_ll structs */
+ if ((addr_len != sizeof(struct sockaddr_ll) -
+ SOCKADDR_LL_COMPAT) ||
+ (sll->sll_hatype == ARPHRD_INFINIBAND))
+ return -EINVAL;
if (sll->sll_family != AF_PACKET)
return -EINVAL;
^ permalink raw reply
* Re: atheros driver - desc
From: Mateusz Berezecki @ 2005-08-05 18:07 UTC (permalink / raw)
To: kernel-mentors; +Cc: netdev
On 09:46 Fri 05 Aug , Bryan O'Sullivan wrote:
> On Fri, 2005-08-05 at 04:55 +0200, Mateusz Berezecki wrote:
>
> How far from working is it? I have a miniPCI Atheros card and would be
> interested in helping out with bringing the driver up, but it would be
> good to know what to expect first :-)
>
HAL is completely reversed, and it appears to work quite good. I have
tested quite a lot using *cough* hardcoded solutions :-)
What the driver is missing is integration with ieee80211 API
from netdev tree, Wireless Extensions and I've recently added
empty ioctl function templates. Basically that's what is missing.
Nothing more, nothing less :-)
And regarding that ieee80211 API, I would be very excited if
anyone could explain the general overview of how new wireless
API works. I read the source but sometimes a quick answer from
experienced kernel coder would do more good.
kind regards
Mateusz
^ permalink raw reply
* Re: argh... ;/
From: Dave Jones @ 2005-08-05 17:49 UTC (permalink / raw)
To: Daniel Phillips, Mateusz Berezecki, kernel-mentors, netdev
In-Reply-To: <20050805172055.GB5641@tuxdriver.com>
On Fri, Aug 05, 2005 at 01:20:59PM -0400, John W. Linville wrote:
> On Sat, Aug 06, 2005 at 02:41:30AM +1000, Daniel Phillips wrote:
> > On Friday 05 August 2005 13:04, Mateusz Berezecki wrote:
> > > I accidentaly posted the patches as MIME attachments... its 5:03 am here
>
> > Does anybody still care if patches are posted as attachments, particularly for
> > review as opposed to submission?
>
> Yes. Opening attachments makes them harder to review.
Indeed. Replying to such mails ends up looking like..
>
---end quoted text---
Which means you need to futz around saving it, reading it back in, deleting it etc..
Saving reviewers keystrokes == good thing.
Dave
^ permalink raw reply
* Re: atheros driver - desc
From: Jeff Garzik @ 2005-08-05 17:46 UTC (permalink / raw)
To: Mateusz Berezecki; +Cc: kernel-mentors, netdev
In-Reply-To: <42F2D523.9020702@gmail.com>
Mateusz Berezecki wrote:
> Hi list members,
>
> I just post the code for review for anyone interested.
> I would be more than pleased to hear some feedback from you on the code.
>
> Im sending a series of 8 patches splitted and diffed as in
> SubmittingPatches documentation.
>
> The driver is not yet fully working because I didn't finish kernel
> integration yet. Almost all
> driver I/O ops are reverse engineered independently of openbsd openhal
> which is missing just too much.
>
>
> Ok, enough talking. Most of the atheros 5212 hal is now open :)
>
> sending patches...
It's a good start. When you get a basic working driver, I'll push it
into ieee80211 branch, and further review and work can occur.
Jeff
^ permalink raw reply
* Re: argh... ;/
From: Jeff Garzik @ 2005-08-05 17:45 UTC (permalink / raw)
To: John W. Linville; +Cc: kernel-mentors, netdev, Daniel Phillips
In-Reply-To: <20050805172055.GB5641@tuxdriver.com>
John W. Linville wrote:
> On Sat, Aug 06, 2005 at 02:41:30AM +1000, Daniel Phillips wrote:
>
>>On Friday 05 August 2005 13:04, Mateusz Berezecki wrote:
>>
>>>I accidentaly posted the patches as MIME attachments... its 5:03 am here
>
>
>>Does anybody still care if patches are posted as attachments, particularly for
>>review as opposed to submission?
>
>
> Yes. Opening attachments makes them harder to review.
Strongly agreed.
Jeff
^ permalink raw reply
* Re: argh... ;/
From: John W. Linville @ 2005-08-05 17:20 UTC (permalink / raw)
To: Daniel Phillips; +Cc: kernel-mentors, netdev
In-Reply-To: <200508060241.30507.phillips@istop.com>
On Sat, Aug 06, 2005 at 02:41:30AM +1000, Daniel Phillips wrote:
> On Friday 05 August 2005 13:04, Mateusz Berezecki wrote:
> > I accidentaly posted the patches as MIME attachments... its 5:03 am here
> Does anybody still care if patches are posted as attachments, particularly for
> review as opposed to submission?
Yes. Opening attachments makes them harder to review.
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [RFC PATCH] convert ebt_ulog to nfnetlink_log
From: Harald Welte @ 2005-08-05 17:10 UTC (permalink / raw)
To: Bart De Schuymer
Cc: Linux Netdev List, Netfilter Development Mailinglist, kaber
In-Reply-To: <20050805163709.GF4033@rama.de.gnumonks.org>
[-- Attachment #1: Type: text/plain, Size: 6483 bytes --]
On Fri, Aug 05, 2005 at 06:37:09PM +0200, Harald Welte wrote:
> Ok, I'll extend nfnetlink_log.c to add TLV's for those two fields in
> case CONFIG_BRIDGE_NF is set. I'll send a patch later tonight.
What about the following (only compile-tested) patch ?
[NETFILTER] add phys{in,out}dev support to nfnetlink_log and nfnetlink_queue
Since bridges don't have a 'reasonable' input and output net_device
(e.g. 'br0'), we need to add seperate TLV's for the 'physindev' and 'physoutdev'
to get to the real underlying device (e.g. 'eth0').
I really hate to have those CONFIG_BRIDGE_NETFILTER ifdef's all over the
code - but for now we have them almost everywhere, so two more doesn't
hurt. At some point we need to get rid of this ugliness and have something
like an 'input device stack' that can be traversed.
Signed-off-by: Harald Welte <laforge@netfilter.org>
---
commit 9f7972a4e1af559a1aeecfacfb1d6ca87f99f762
tree 36b9459801b3e4a2c61d1238a32bddbb4b5946e0
parent ed8612c164a21e71cf6139c4e67a98b7a417b1cb
author Harald Welte <laforge@netfilter.org> Fr, 05 Aug 2005 19:07:28 +0200
committer Harald Welte <laforge@netfilter.org> Fr, 05 Aug 2005 19:07:28 +0200
include/linux/netfilter/nfnetlink_log.h | 2 ++
include/linux/netfilter/nfnetlink_queue.h | 2 ++
net/netfilter/nfnetlink_log.c | 22 ++++++++++++++++++++++
net/netfilter/nfnetlink_queue.c | 22 ++++++++++++++++++++++
4 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/include/linux/netfilter/nfnetlink_log.h b/include/linux/netfilter/nfnetlink_log.h
--- a/include/linux/netfilter/nfnetlink_log.h
+++ b/include/linux/netfilter/nfnetlink_log.h
@@ -40,6 +40,8 @@ enum nfulnl_attr_type {
NFULA_TIMESTAMP, /* nfulnl_msg_packet_timestamp */
NFULA_IFINDEX_INDEV, /* u_int32_t ifindex */
NFULA_IFINDEX_OUTDEV, /* u_int32_t ifindex */
+ NFULA_IFINDEX_PHYSINDEV, /* u_int32_t ifindex */
+ NFULA_IFINDEX_PHYSOUTDEV, /* u_int32_t ifindex */
NFULA_HWADDR, /* nfulnl_msg_packet_hw */
NFULA_PAYLOAD, /* opaque data payload */
NFULA_PREFIX, /* string prefix */
diff --git a/include/linux/netfilter/nfnetlink_queue.h b/include/linux/netfilter/nfnetlink_queue.h
--- a/include/linux/netfilter/nfnetlink_queue.h
+++ b/include/linux/netfilter/nfnetlink_queue.h
@@ -36,6 +36,8 @@ enum nfqnl_attr_type {
NFQA_TIMESTAMP, /* nfqnl_msg_packet_timestamp */
NFQA_IFINDEX_INDEV, /* u_int32_t ifindex */
NFQA_IFINDEX_OUTDEV, /* u_int32_t ifindex */
+ NFQA_IFINDEX_PHYSINDEV, /* u_int32_t ifindex */
+ NFQA_IFINDEX_PHYSOUTDEV, /* u_int32_t ifindex */
NFQA_HWADDR, /* nfqnl_msg_packet_hw */
NFQA_PAYLOAD, /* opaque data payload */
diff --git a/net/netfilter/nfnetlink_log.c b/net/netfilter/nfnetlink_log.c
--- a/net/netfilter/nfnetlink_log.c
+++ b/net/netfilter/nfnetlink_log.c
@@ -33,6 +33,10 @@
#include <asm/atomic.h>
+#ifdef CONFIG_BRIDGE_NETFILTER
+#include "../bridge/br_private.h"
+#endif
+
#define NFULNL_NLBUFSIZ_DEFAULT 4096
#define NFULNL_TIMEOUT_DEFAULT 100 /* every second */
#define NFULNL_QTHRESH_DEFAULT 100 /* 100 packets */
@@ -414,12 +418,26 @@ __build_packet_message(struct nfulnl_ins
tmp_uint = htonl(indev->ifindex);
NFA_PUT(inst->skb, NFULA_IFINDEX_INDEV, sizeof(tmp_uint),
&tmp_uint);
+#ifdef CONFIG_BRIDGE_NETFILTER
+ if (indev->br_port) {
+ tmp_uint = htonl(indev->br_port->br->dev->ifindex);
+ NFA_PUT(inst->skb, NFULA_IFINDEX_PHYSINDEV,
+ sizeof(tmp_uint), &tmp_uint);
+ }
+#endif
}
if (outdev) {
tmp_uint = htonl(outdev->ifindex);
NFA_PUT(inst->skb, NFULA_IFINDEX_OUTDEV, sizeof(tmp_uint),
&tmp_uint);
+#ifdef CONFIG_BRIDGE_NETFILTER
+ if (outdev->br_port) {
+ tmp_uint = htonl(outdev->br_port->br->dev->ifindex);
+ NFA_PUT(inst->skb, NFULA_IFINDEX_PHYSOUTDEV,
+ sizeof(tmp_uint), &tmp_uint);
+ }
+#endif
}
if (skb->nfmark) {
@@ -536,6 +554,10 @@ nfulnl_log_packet(unsigned int pf,
+ NFA_SPACE(sizeof(struct nfulnl_msg_packet_hdr))
+ NFA_SPACE(sizeof(u_int32_t)) /* ifindex */
+ NFA_SPACE(sizeof(u_int32_t)) /* ifindex */
+#ifdef CONFIG_BRIDGE_NETFILTER
+ + NFA_SPACE(sizeof(u_int32_t)) /* ifindex */
+ + NFA_SPACE(sizeof(u_int32_t)) /* ifindex */
+#endif
+ NFA_SPACE(sizeof(u_int32_t)) /* mark */
+ NFA_SPACE(sizeof(u_int32_t)) /* uid */
+ NFA_SPACE(NFULNL_PREFIXLEN) /* prefix */
diff --git a/net/netfilter/nfnetlink_queue.c b/net/netfilter/nfnetlink_queue.c
--- a/net/netfilter/nfnetlink_queue.c
+++ b/net/netfilter/nfnetlink_queue.c
@@ -30,6 +30,10 @@
#include <asm/atomic.h>
+#ifdef CONFIG_BRIDGE_NETFILTER
+#include "../bridge/br_private.h"
+#endif
+
#define NFQNL_QMAX_DEFAULT 1024
#if 0
@@ -361,6 +365,10 @@ nfqnl_build_packet_message(struct nfqnl_
size = NLMSG_SPACE(sizeof(struct nfqnl_msg_packet_hdr))
+ NLMSG_SPACE(sizeof(u_int32_t)) /* ifindex */
+ NLMSG_SPACE(sizeof(u_int32_t)) /* ifindex */
+#ifdef CONFIG_BRIDGE_NETFILTER
+ + NLMSG_SPACE(sizeof(u_int32_t)) /* ifindex */
+ + NLMSG_SPACE(sizeof(u_int32_t)) /* ifindex */
+#endif
+ NLMSG_SPACE(sizeof(u_int32_t)) /* mark */
+ NLMSG_SPACE(sizeof(struct nfqnl_msg_packet_hw))
+ NLMSG_SPACE(sizeof(struct nfqnl_msg_packet_timestamp));
@@ -413,11 +421,25 @@ nfqnl_build_packet_message(struct nfqnl_
if (entry->info->indev) {
tmp_uint = htonl(entry->info->indev->ifindex);
NFA_PUT(skb, NFQA_IFINDEX_INDEV, sizeof(tmp_uint), &tmp_uint);
+#ifdef CONFIG_BRIDGE_NETFILTER
+ if (entry->info->indev->br_port) {
+ tmp_uint = htonl(entry->info->indev->br_port->br->dev->ifindex);
+ NFA_PUT(skb, NFQA_IFINDEX_PHYSINDEV,
+ sizeof(tmp_uint), &tmp_uint);
+ }
+#endif
}
if (entry->info->outdev) {
tmp_uint = htonl(entry->info->outdev->ifindex);
NFA_PUT(skb, NFQA_IFINDEX_OUTDEV, sizeof(tmp_uint), &tmp_uint);
+#ifdef CONFIG_BRIDGE_NETFILTER
+ if (entry->info->outdev->br_port) {
+ tmp_uint = htonl(entry->info->outdev->br_port->br->dev->ifindex);
+ NFA_PUT(skb, NFQA_IFINDEX_PHYSOUTDEV,
+ sizeof(tmp_uint), &tmp_uint);
+ }
+#endif
}
if (entry->skb->nfmark) {
--
- Harald Welte <laforge@gnumonks.org> http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: atheros driver - desc
From: Bryan O'Sullivan @ 2005-08-05 16:46 UTC (permalink / raw)
To: Mateusz Berezecki; +Cc: kernel-mentors, netdev
In-Reply-To: <42F2D523.9020702@gmail.com>
On Fri, 2005-08-05 at 04:55 +0200, Mateusz Berezecki wrote:
> The driver is not yet fully working because I didn't finish kernel
> integration yet.
How far from working is it? I have a miniPCI Atheros card and would be
interested in helping out with bringing the driver up, but it would be
good to know what to expect first :-)
<b
^ permalink raw reply
* Re: argh... ;/
From: Daniel Phillips @ 2005-08-05 16:41 UTC (permalink / raw)
To: Mateusz Berezecki; +Cc: kernel-mentors, netdev
In-Reply-To: <42F2D749.70306@gmail.com>
On Friday 05 August 2005 13:04, Mateusz Berezecki wrote:
> I accidentaly posted the patches as MIME attachments... its 5:03 am here
> already. Sorry guys.
> I can resubmit if you want. I just dont want do that now and not trash
> your mailboxes
Does anybody still care if patches are posted as attachments, particularly for
review as opposed to submission?
I will make the standard comment about C99 // comments, but add that I use
them myself to mean "this comment will definitely be gone by the time it gets
officially submitted", in other words, work in progress.
Heroic work! And nicely lindented at least. Some long lines, but in the same
kinds of places I write them myself.
Only commenting on the form, not substance. Best of luck. I have one of
these things here so when you declare it ready I will try it.
Regards,
Daniel
^ permalink raw reply
* Re: [PATCH] ctnetlink: make sure event order is correct
From: David S. Miller @ 2005-08-05 16:39 UTC (permalink / raw)
To: laforge; +Cc: netdev, netfilter-devel
In-Reply-To: <20050805162738.GD4033@rama.de.gnumonks.org>
From: Harald Welte <laforge@netfilter.org>
Date: Fri, 5 Aug 2005 18:27:38 +0200
> [NETFILTER] ctnetlink: make sure event order is correct
Applied.
^ permalink raw reply
* Re: [PATCH] ctnetlink: fix conntrack expect refcount leak
From: David S. Miller @ 2005-08-05 16:39 UTC (permalink / raw)
To: laforge; +Cc: netdev, netfilter-devel
In-Reply-To: <20050805162820.GE4033@rama.de.gnumonks.org>
From: Harald Welte <laforge@netfilter.org>
Date: Fri, 5 Aug 2005 18:28:20 +0200
> [NETFILTER] fix conntrack refcount leak in unlink_expect()
Applied.
^ permalink raw reply
* Re: [PATCH] ctnetlink: fix typo in ctnl_exp_cb array
From: David S. Miller @ 2005-08-05 16:39 UTC (permalink / raw)
To: laforge; +Cc: netdev, netfilter-devel
In-Reply-To: <20050805162142.GA4033@rama.de.gnumonks.org>
From: Harald Welte <laforge@netfilter.org>
Date: Fri, 5 Aug 2005 18:21:42 +0200
> [NETFILTER] Fix typo in ctnl_exp_cb array (no bug, just memory waste)
Applied.
^ permalink raw reply
* Re: [PATCH] ctnetlink: fix list traversal order
From: David S. Miller @ 2005-08-05 16:39 UTC (permalink / raw)
To: laforge; +Cc: netdev, netfilter-devel
In-Reply-To: <20050805162650.GC4033@rama.de.gnumonks.org>
From: Harald Welte <laforge@netfilter.org>
Date: Fri, 5 Aug 2005 18:26:50 +0200
> [NETFILTER] fix list traversal order in ctnetlink
Applied.
^ permalink raw reply
* [PATCH] ctnetlink: fix conntrack expect refcount leak
From: Harald Welte @ 2005-08-05 16:28 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, Netfilter Development Mailinglist
[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]
Hi Dave, please apply.
[NETFILTER] fix conntrack refcount leak in unlink_expect()
In unlink_expect(), the expectation is removed from the list so the
refcount must be dropped as well.
Signed-off-by: Pablo Neira Ayuso <pablo@eurodev.net>
Signed-off-by: Harald Welte <laforge@netfilter.org>
---
commit ed8612c164a21e71cf6139c4e67a98b7a417b1cb
tree 4d4493874742690f9d997c4846a7e4b6becf3da2
parent 1d35273dd7935f4b6a64f3526d85c5df9ba254de
author Harald Welte <laforge@netfilter.org> Fr, 05 Aug 2005 15:19:35 +0200
committer Harald Welte <laforge@netfilter.org> Fr, 05 Aug 2005 15:19:35 +0200
net/ipv4/netfilter/ip_conntrack_core.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/netfilter/ip_conntrack_core.c b/net/ipv4/netfilter/ip_conntrack_core.c
--- a/net/ipv4/netfilter/ip_conntrack_core.c
+++ b/net/ipv4/netfilter/ip_conntrack_core.c
@@ -204,6 +204,7 @@ static void unlink_expect(struct ip_conn
list_del(&exp->list);
CONNTRACK_STAT_INC(expect_delete);
exp->master->expecting--;
+ ip_conntrack_expect_put(exp);
}
void __ip_ct_expect_unlink_destroy(struct ip_conntrack_expect *exp)
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] ctnetlink: make sure event order is correct
From: Harald Welte @ 2005-08-05 16:27 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, Netfilter Development Mailinglist
[-- Attachment #1: Type: text/plain, Size: 2126 bytes --]
Hi Dave, please apply.
[NETFILTER] ctnetlink: make sure event order is correct
The following sequence is displayed during events dumping of an ICMP
connection: [NEW] [DESTROY] [UPDATE]
This happens because the event IPCT_DESTROY is delivered in
death_by_timeout(), that is called from the icmp protocol helper
(ct->timeout.function) once we see the reply.
To fix this, we move this event to destroy_conntrack().
Signed-off-by: Pablo Neira Ayuso <pablo@eurodev.net>
Signed-off-by: Harald Welte <laforge@netfilter.org>
---
commit cb90ab7c56471a733f5a91a3ec2cfbd45093e8a0
tree cf84842a1e41dcaefd9934f9752df2ca977831d7
parent 570b2053cc2c68da90b71add2a4f4366673b48d8
author Harald Welte <laforge@netfilter.org> Fr, 05 Aug 2005 14:28:31 +0200
committer Harald Welte <laforge@netfilter.org> Fr, 05 Aug 2005 14:28:31 +0200
net/ipv4/netfilter/ip_conntrack_core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/netfilter/ip_conntrack_core.c b/net/ipv4/netfilter/ip_conntrack_core.c
--- a/net/ipv4/netfilter/ip_conntrack_core.c
+++ b/net/ipv4/netfilter/ip_conntrack_core.c
@@ -327,6 +327,7 @@ destroy_conntrack(struct nf_conntrack *n
IP_NF_ASSERT(atomic_read(&nfct->use) == 0);
IP_NF_ASSERT(!timer_pending(&ct->timeout));
+ ip_conntrack_event(IPCT_DESTROY, ct);
set_bit(IPS_DYING_BIT, &ct->status);
/* To make sure we don't get any weird locking issues here:
@@ -366,7 +367,6 @@ static void death_by_timeout(unsigned lo
{
struct ip_conntrack *ct = (void *)ul_conntrack;
- ip_conntrack_event(IPCT_DESTROY, ct);
write_lock_bh(&ip_conntrack_lock);
/* Inside lock so preempt is disabled on module removal path.
* Otherwise we can get spurious warnings. */
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] ctnetlink: fix list traversal order
From: Harald Welte @ 2005-08-05 16:26 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, Netfilter Development Mailinglist
[-- Attachment #1: Type: text/plain, Size: 3184 bytes --]
Hi Dave, please apply.
[NETFILTER] fix list traversal order in ctnetlink
Currently conntracks are inserted after the head. That means that
conntracks are sorted from the biggest to the smallest id. This happens
because we use list_prepend (list_add) instead list_add_tail. This can
result in problems during the list iteration.
list_for_each(i, &ip_conntrack_hash[cb->args[0]]) {
h = (struct ip_conntrack_tuple_hash *) i;
if (DIRECTION(h) != IP_CT_DIR_ORIGINAL)
continue;
ct = tuplehash_to_ctrack(h);
if (ct->id <= *id)
continue;
In that case just the first conntrack in the bucket will be dumped. To
fix this, we iterate the list from the tail to the head via
list_for_each_prev. Same thing for the list of expectations.
Signed-off-by: Pablo Neira Ayuso <pablo@eurodev.net>
Signed-off-by: Harald Welte <laforge@netfilter.org>
---
commit 570b2053cc2c68da90b71add2a4f4366673b48d8
tree bbcf496f0fb3fc468db26a03ccf1455e206a2251
parent 76596b57e2fe552da8beef4a59d5b559dfc3d0e5
author Harald Welte <laforge@netfilter.org> Fr, 05 Aug 2005 14:25:50 +0200
committer Harald Welte <laforge@netfilter.org> Fr, 05 Aug 2005 14:25:50 +0200
net/ipv4/netfilter/ip_conntrack_netlink.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/netfilter/ip_conntrack_netlink.c b/net/ipv4/netfilter/ip_conntrack_netlink.c
--- a/net/ipv4/netfilter/ip_conntrack_netlink.c
+++ b/net/ipv4/netfilter/ip_conntrack_netlink.c
@@ -404,7 +404,7 @@ ctnetlink_dump_table(struct sk_buff *skb
read_lock_bh(&ip_conntrack_lock);
for (; cb->args[0] < ip_conntrack_htable_size; cb->args[0]++, *id = 0) {
- list_for_each(i, &ip_conntrack_hash[cb->args[0]]) {
+ list_for_each_prev(i, &ip_conntrack_hash[cb->args[0]]) {
h = (struct ip_conntrack_tuple_hash *) i;
if (DIRECTION(h) != IP_CT_DIR_ORIGINAL)
continue;
@@ -441,7 +441,7 @@ ctnetlink_dump_table_w(struct sk_buff *s
write_lock_bh(&ip_conntrack_lock);
for (; cb->args[0] < ip_conntrack_htable_size; cb->args[0]++, *id = 0) {
- list_for_each(i, &ip_conntrack_hash[cb->args[0]]) {
+ list_for_each_prev(i, &ip_conntrack_hash[cb->args[0]]) {
h = (struct ip_conntrack_tuple_hash *) i;
if (DIRECTION(h) != IP_CT_DIR_ORIGINAL)
continue;
@@ -1214,7 +1214,7 @@ ctnetlink_exp_dump_table(struct sk_buff
DEBUGP("entered %s, last id=%llu\n", __FUNCTION__, *id);
read_lock_bh(&ip_conntrack_lock);
- list_for_each(i, &ip_conntrack_expect_list) {
+ list_for_each_prev(i, &ip_conntrack_expect_list) {
exp = (struct ip_conntrack_expect *) i;
if (exp->id <= *id)
continue;
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] ctnetlink: fix typo in ctnl_exp_cb array
From: Harald Welte @ 2005-08-05 16:21 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, Netfilter Development Mailinglist
[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]
Hi Dave, please apply.
[NETFILTER] Fix typo in ctnl_exp_cb array (no bug, just memory waste)
This fixes the size of the ctnl_exp_cb array that is IPCTNL_MSG_EXP_MAX
instead of IPCTNL_MSG_MAX. Simple typo.
Signed-off-by: Pablo Neira Ayuso <pablo@eurodev.net>
Signed-off-by: Harald Welte <laforge@netfilter.org>
---
commit 76596b57e2fe552da8beef4a59d5b559dfc3d0e5
tree 84acf2c3953dd3b824cfdb0b501e1b778ac2de19
parent cc45a2a7c15b72bf38d611e469fa30d62ade8f1f
author Harald Welte <laforge@netfilter.org> Fr, 05 Aug 2005 14:23:56 +0200
committer Harald Welte <laforge@netfilter.org> Fr, 05 Aug 2005 14:23:56 +0200
net/ipv4/netfilter/ip_conntrack_netlink.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/netfilter/ip_conntrack_netlink.c b/net/ipv4/netfilter/ip_conntrack_netlink.c
--- a/net/ipv4/netfilter/ip_conntrack_netlink.c
+++ b/net/ipv4/netfilter/ip_conntrack_netlink.c
@@ -1490,7 +1490,7 @@ static struct nfnl_callback ctnl_cb[IPCT
.cap_required = CAP_NET_ADMIN },
};
-static struct nfnl_callback ctnl_exp_cb[IPCTNL_MSG_MAX] = {
+static struct nfnl_callback ctnl_exp_cb[IPCTNL_MSG_EXP_MAX] = {
[IPCTNL_MSG_EXP_GET] = { .call = ctnetlink_get_expect,
.attr_count = CTA_EXPECT_MAX,
.cap_required = CAP_NET_ADMIN },
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ 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