Re: [2.6 patch] the overdue eepro100 removal
Adrian Bunk wrote: This patch contains the overdue removal of the eepro100 driver. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] The hardware supported by this driver is still in use, thanks. It's probably easier to leave the eepro100 driver in than find anyone who wants to investigate why the other driver (e100? from memory) doesn't work with some cards. As I recall this was suggested over a year ago and it was decided to leave it in, all of the reasons for doing so still seem valid. There really doesn't seem to be a benefit, it's not like people are working night and day to support new cards for this chip. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Big sized packets have been dropped strangly
gshan wrote: Hey Guys, I got a strange problem recently but no ideas, so to post the question here. We have a FPGA what finish ATM AAL5 to ethernet frame, and CPU receives IP packets from it. The interface based on the FPGA (called sar0) has been bound with several IP addresses. When the MTU of the interface is configurated to 1500, trivial packets can be received, but big-sized packets are dropped. If the MTU is increased to 9500, everything is ok except the NFS connection. We mounted with another machine through sar0. When the MTU is 9500, the speed of the NFS becomes very very slow (it almost took 10 minutes to transfer 100KB files). I don't know why it is and how to solve it. Any suggestions are appreciated! http://groups.google.com/group/fa.linux.kernel/msg/4434f7c5d38d9292 I think that's relevant. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] the overdue eepro100 removal
Please do not make unnecessary kernel changes which require changes in our systems. Kok, Auke wrote: Bill Davidsen wrote: Adrian Bunk wrote: This patch contains the overdue removal of the eepro100 driver. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] The hardware supported by this driver is still in use, thanks. It's probably easier to leave the eepro100 driver in than find anyone who wants to investigate why the other driver (e100? from memory) doesn't work with some cards. As I recall this was suggested over a year ago and it was decided to leave it in, all of the reasons for doing so still seem valid. There really doesn't seem to be a benefit, it's not like people are working night and day to support new cards for this chip. please see the thread Re: [PATCH] fix e100 rx path on ARM (was [PATCH] e100 rx: or s and el bits) which is discussing a fix for this issue and currently being worked. eepro100 will *still* be removed once e100 is fixed to support those devices. Frankly I think there are more of us running old cards on PC hardware than people running ARM! And for a number of card for old buses like ISA, EISA, and VESA, the e100 has not worked. These are old PCs converted to routers and firewalls, and for security should not be left without upgrades. Moreover, we now also have a fix for the e100 IPMI issues on some tyan boards (patch coming this week!). That hopefully solves all e100 issues that are still open. If you think the e100 driver fixes your problems use it and be happy. But since you don't have to test system behavior with the new driver, and you won't be called at night or on weekends if it doesn't work, do the rest of the world a favor and stop taking out things we know to work! Leaving in the eepro100 causes no work for you, and even if e100 works perfectly it needs to be validated in any sane network. it still makes work. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] the overdue eepro100 removal
Adrian Bunk wrote: On Thu, Jul 05, 2007 at 12:01:56PM -0400, Bill Davidsen wrote: Please do not make unnecessary kernel changes which require changes in our systems. If you think the e100 driver fixes your problems use it and be happy. But since you don't have to test system behavior with the new driver, and you won't be called at night or on weekends if it doesn't work, do the rest of the world a favor and stop taking out things we know to work! Leaving in the eepro100 causes no work for you, and even if e100 works perfectly it needs to be validated in any sane network. it still makes work. The goal is to get e100 better, and removing eepro100 helps with reaching this goal. That's *your* goal, it should not be a shock that users have a goal of using their systems without having to reconfigure them every time there's a kernel upgrade containing a security fix. Why didn't _you_ try the e100 driver when you validated your systems after you upgraded them to kernel 2.6, and if you did and it didn't work, where is your bug report? Is that a joke, or subtle irony? Do you generally validate drivers you don't use just because your hardware might be able to support them? I don't validate various accelerated video drivers on systems running mostly text console, never check sound options on systems with an audio application, etc. After I tried the e100 driver on the first few systems and found issues (which may be resolved by now) I went back to eepro100 and used what worked. And used the driver for any new systems in other installs. If there were any benefit to removing a working driver I would at least be able to see it as a resources issue, but as far as I can see you just seem to have a personal preference for the e100 driver and want to force others to use it because you are so much better able to decide what users need than the system administrators. That's one of the reasons people choose open source, because they have a choice, and can use what's best for them. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [announce] iproute2 2.6.19-061214
Stephen Hemminger wrote: This is an update to the iproute2 command set. It can be downloaded from: http://developer.osdl.org/dev/iproute2/download/iproute2-2.6.18-061214.tar.gz The 2.6.18 should be 2.6.19. Am I the first person to actually try that link? Repository: git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git For more info on iproute2 see: http://linux-net.osdl.org/index.php/Iproute2 The version number includes the kernel version to denote what features are supported. The same source should build on older systems, but obviously the newer kernel features won't be available. As much as possible, this package tries to be source compatible across releases. Changes from 2.6.18-061002 to 2.6.19-061214: Boian Bonev: Display local route table name correctly in output of: Hasso Tepper: Fixes for tc help commands jamal: Multicast computation off by one Update generic netlink header Add controller support for new features exposed clarify ok and pass Fix missing class/flowid oddity Mention need for db dev package update xfrm async events make muticast group to bitmask conversion generic update xfrm monitoring to use nl_mgrp Masahide NAKAMURA: ADDR: Fix print format for lifetimes. ADDR: Enable to add IPv6 address with valid/preferred lifetime. ADDR: Define 0xU as INFINITY_LIFE_TIME regarding to the kernel. TUNNEL: Split common functions to export them. TUNNEL: Import ip6tunnel.c. TUNNEL: IPv6-over-IPv6 tunnel support. XFRM: sub policy support. XFRM: Mobile IPv6 route optimization support. XFRM: support report message by monitor. XFRM: Mobility header support. Noriaki TAKAMIYA: ADDR: Add the 'change' and 'replace' commands to the IPv6 address manipulation context. Patrick McHardy: [IPROUTE]: Add support for routing rule fwmark masks Stephen Hemminger: Man page for ss submitted by Alex Wirt Typo in man page Trap possible overflow in usec values to netem genl Makefile LDFLAGS SA and SP in IPSec BEET mode. Route metrics decode bug. lnstat man page Man page for rtmon Update to 2.6.19 headers Add more includes Change to post 2.6.19 sanitized headers Eliminate trailing whitespace Thomas Graf: Add support for inverted selectors Add rule notification support to ip monitor - To unsubscribe from this list: send the line unsubscribe linux-net in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Safe remote kernel install howto (Re: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc))
Meelis Roos wrote: Unfortunatlety, 2.6.15 does not boot on this machine so I'm locked out remotely at the moment. Here it my paranoid boot setup: Thanks, but it's not much use here, since the machine is a PReP powerpc machine that can boot one kernel from disk (directly loaded from boot partition, no fancy bootloader) or netboot via serial console for test kernels. However, if the test kernel hangs, it hangs and I would need remote power cycling device that I do not have. I did a lot of this at one time, and used lilo in just the way described. I did have a remote reboot device, however, an operator (1st shift), janitor (2nd shift), or security guard (3rd/wkend shift) who had been instructed to push the clearly marked reset button on demand when the weird guy in New York tells you. IBM rack units, like x345 and such, can have an RSA card which allows remote hardware monitor and reboot with a separate IP address for control. Worth its weight in gold! The latest will let you do remote console as well. -- Bill Davidsen [EMAIL PROTECTED] Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a normal user and is setuid root, with the vi line edit mode selected, and the character set is big5, an off-by-one errors occurs during wildcard (glob) expansion. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] the scheduled eepro100 removal
Adrian Bunk wrote: This patch contains the scheduled removal of the eepro100 driver. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] This keeps coming around, but I haven't seen an answer to the questions raised by Eric Piel or Kiszka. I do know that e100 didn't work on some IBM rackmount servers and eepro100 did, but since I'm no longer responsible for those machines I can't retest. Perhaps someone will be able to provide data points. IBM current offerings as of about three years ago, I had a few dozen of them at one time. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.17.1: fails to fully get webpage
CaT wrote: On Wed, Jun 28, 2006 at 08:47:09PM -0700, David Miller wrote: You can save yourself that hassle by informing the site admin of the affected site that they have a firewall that misinterprets the RFC standard window scaling field of the TCP headers. These devices assume it is zero because they don't remember the window scale negotiated at the beginning of the TCP connection. Your TCP performance will suffer greatly if you disable window scaling across the board. It means that only a 64K window will be usable by TCP, and you'll not be able to fill the pipe. Please don't use a screwdriver to pound in a nail :) Indeed. The hassle I'm thinking of is the reverse situation (and please correct me if this does not apply). Say for example I run a web server. I have customers and they have customers (lets call them CCs :). Somewhere along the path between me and CCs there is such a misbehaving device. The CCs try to get to my customers website and fail (I assume). If my assumption is right, what's the probability of the CCs ever informing my customer that there is a problem? I think it's more likely they would just move on to another site offering the same thing, especially since they would mostlikely need to load the site in order to get the appropriate contact details. Basically the mostlikely end-result is I don't know what there is a problem and my customer doesn't know that there is a problem but they're just not getting as many hits to their site that they otherwise would. Ofcourse, this all depends if such a situation is possible. If it is possible would it affect dns and mail in a similar manner too? I'm glad David Miller clarified this, because I was about to send a don't do that followup ;-) But your example is misleading, or at least doesn't reflect customers I know. While a few clients with broken network connections may be unhappy, disabling scaling will make your web server really, really, slow, and that will make everyone unhappy. Particularly if the web content is flash or 2MB jpegs, or other ill-chosen stuff. You don't want people to think you are running at dial-up speeds. -- Bill Davidsen [EMAIL PROTECTED] Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a normal user and is setuid root, with the vi line edit mode selected, and the character set is big5, an off-by-one errors occurs during wildcard (glob) expansion. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] the overdue eepro100 removal
Adrian Bunk wrote: On Mon, Jul 09, 2007 at 01:27:55PM -0400, Bill Davidsen wrote: For how many years do you know that there's a new and actively maintained e100 driver for your hardware? And if you don't follow a stable line like the 2.6.16 kernel or a distribution kernel it's simply a part of the current development model that some kernel parts change. If changing one driver results in a big problem in your setup you should reconsider your setup. And every new kernel except for -stable kernels will anyway require a revalidation, so changing the network driver as part of this shouldn't be a big issue. Nothing is a big issue if you can force someone else to do the work. And if you have no impact from a production outage if some new driver works for hours and then does something unexpected. Why didn't _you_ try the e100 driver when you validated your systems after you upgraded them to kernel 2.6, and if you did and it didn't work, where is your bug report? Is that a joke, or subtle irony? Do you generally validate drivers you don't use just because your hardware might be able to support them? I don't validate various accelerated video drivers on systems running mostly text console, never check sound options on systems with an audio application, etc. After I tried the e100 driver on the first few systems and found issues (which may be resolved by now) I went back to eepro100 and used what worked. And used the driver for any new systems in other installs. And exactly this is the reason why the eepro100 driver has to be removed, and that this will result in a better hardware support for everyone in the long term. If this was a case of a kernel change requiring an effort to keep the driver I would not be suggesting someone take time to update the driver from threads to tasklets or fartlets or whatever the next ultimate irq handling happens to be. But when there's zero effort at the moment to retain the driver, I think it's change for the sake of change. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sk98lin for 2.6.23-rc1
Adrian Bunk wrote: On Tue, Sep 11, 2007 at 10:05:26AM +0200, Stephen Hemminger wrote: There are several different problems in this thread: 1. The removal of old sk98lin driver caused some users to be forced to use skge. These users have uncovered issues with the dual port fiber based versions of the board. Short term: The sk98lin driver should be restored to previous state, and the PCI table should be used to limit the usage to only fiber systems. If Adrian doesn't do it, I'll do it when I return from Germany. ... No problem with this, but since it was Jeff's patch it should better be him who reverts it (and he's anyway one step nearer to Linus). But the underlying general problem still remains: How can we get people to test and report bugs with the new drivers before removing the old driver? Sorry for a long answer, I'm trying to provide insight on two recent cases. Thinking back to several drivers, when e100 was new I tried it because I had problems with eepro100 in the area of multiple cards, multiple cables on a single card, and jumbo packets. For a while I used both, until e100 worked where I need it. So I initially tried it because it had features I needed, and then dropped to older driver just to avoid having to decide. With sk98lin, the driver worked flawlessly with all (3-4) systems, so I had no reason to try any other. When removing sk98lin was first proposed, I tried skge, first measurements showed it was 5-8% slower, NOT what I want, so I went back. For me there was no reliability issue, but I never tried it in a system with more than on NIC on the driver. Would it's a little slower be a valid bug report? Or would I have gotten works fine for me from people not beating it over Gbit? I didn't try sky2 until you suggested it, and I have reported my results previously, just stops working. Could it be my hardware? I tried it on one system, so yes, but sk98lin works for months. That's a question especially for the people who now had problems after sk98lin was removed. So if you want people to try a new driver, I think it really has to have some benefits to the users, in terms of performance, reliability, or features. Cleaner design doesn't motivate, and it does raise the question of why the old driver wasn't just cleaned up. I've been doing software for decades, I appreciate why, but users in general just want to use their system. Which raises the question of why to delete drivers which work for many or even most users? Testing a new kernel is no longer a drop in a boot operation if modprobe.conf must be edited to get the network up, and the typical user isn't going to write that shell script to try one or the other driver. Honestly, new drivers which offer little benefit to most users are the exception rather than the rule, so this may a corner case I would like to see sk98lin back in the kernel, for a while I can build my own kernels and patch it in, but until other drivers are drop-in, I probably won't change. Separate but related: why keep skge and sky2? Are we going through this again in a year? Is the benefit worth the effort? Hope some of this is helpful. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] 2.6.22.6 NETWORKING [IPV4]: Always use source addr in skb to reply packet
David Miller wrote: From: lepton [EMAIL PROTECTED] Date: Tue, 18 Sep 2007 10:16:17 +0800 Hi, In some situation, icmp_reply and ip_send_reply will send out packet with the wrong source addr, the following patch will fix this. I don't understand why we must use rt-rt_src in the current code, if this is a wrong fix, please correct me. Signed-off-by: Lepton Wu [EMAIL PROTECTED] That the address is wrong is your opinion only :-) Mine too, since an ICMP reply from an unexpected source IP is likely to be logged as a probe and dropped. Source address selection is a rather complex topic, and here we are definitely purposefully using the source address selected by the routing lookup for the reply. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bnx2 dirver's firmware images
David Miller wrote: From: Michael Chan [EMAIL PROTECTED] Date: Tue, 18 Sep 2007 13:05:51 -0700 The bnx2 firmware changes quite frequently. A new driver quite often requires new firmware to work correctly. Splitting them up makes things difficult for the user. The firmware in tg3 is a lot more mature and I don't expect it to change. I think tg3 is better suited for using request_firmware(). Like I said, I think neither should change and the driver should be fully functional when built statically into the kernel. Is that a suggestion that the driver work differently when built as a module or built in? I've seen that behavior many time over the years, but it usually not deliberate. ;-) -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sky2: jumbo frame regression fix
Ian Kumlien wrote: On tis, 2007-10-02 at 18:02 -0700, Stephen Hemminger wrote: Remove unneeded check that caused problems with jumbo frame sizes. The check was recently added and is wrong. When using jumbo frames the sky2 driver does fragmentation, so rx_data_size is less than mtu. Confirmed working. Now running with 9k mtu with no errors, =) Have you verified that you are actually getting jumbo packets out of the NIC? I had one machine which did standard packets silently using sky2 and jumbo using sk98lin. I was looking for something else with tcpdump and got one of those WTF moments when I saw all the tiny packets. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] iptables: mangle table obsoletes filter table
Al Boldi wrote:
Patrick McHardy wrote:
Please send mails discussing netfilter to netfilter-devel.
Ok. I just found out this changed to vger. But
[EMAIL PROTECTED] is bouncing me.
Al Boldi wrote:
With the existence of the mangle table, how useful is the filter table?
Other than requiring the REJECT target to be ported to the mangle table,
is the filter table faster than the mangle table?
There are some minor differences in ordering (mangle comes before
DNAT, filter afterwards), but for most rulesets thats completely
irrelevant. The only difference that really matters is that mangle
performs rerouting in LOCAL_OUT for packets that had their routing
key changed, so its really a superset of the filter table. If you
want to use REJECT in the mangle table, you just need to remove the
restriction to filter, it works fine. I would prefer to also remove
the restriction of MARK, CONNMARK etc. to mangle, they're used for
more than just routing today so that restriction also doesn't make
much sense. Patches for this are welcome.
Something like this (untested):
--- ipt_REJECT.bak.c2007-10-12 08:25:17.0 +0300
+++ ipt_REJECT.c2007-10-12 08:31:44.0 +0300
@@ -165,6 +165,7 @@ static void send_reset(struct sk_buff *o
static inline void send_unreach(struct sk_buff *skb_in, int code)
{
+ if (!skb_in-dst) ip_route_me_harder(skb_in, RTN_UNSPEC);
icmp_send(skb_in, ICMP_DEST_UNREACH, code, 0);
}
@@ -245,9 +246,6 @@ static struct xt_target ipt_reject_reg =
.family = AF_INET,
.target = reject,
.targetsize = sizeof(struct ipt_reject_info),
- .table = filter,
- .hooks = (1 NF_IP_LOCAL_IN) | (1 NF_IP_FORWARD) |
- (1 NF_IP_LOCAL_OUT),
.checkentry = check,
.me = THIS_MODULE,
};
If not, then shouldn't the filter table be obsoleted to avoid confusion?
That would probably confuse people. Just don't use it if you don't
need to.
That is a most practical suggestion.
The problem is that people think they are safe with the filter table, when in
fact they need the prerouting chain to seal things. Right now this is only
possible in the mangle table.
I'm not sure what you think is unsafe about using the filter table, and
the order of evaluation issues certainly seem to suggest that some
actions would take a major rethink at least. Perhaps you could avoid
breaking all of the setups which currently work, rather than force
everyone to do things differently because you feel that your way is better.
--
Bill Davidsen [EMAIL PROTECTED]
We have more to fear from the bungling of the incompetent than from
the machinations of the wicked. - from Slashdot
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] iptables: mangle table obsoletes filter table
Bill Davidsen wrote: If not, then shouldn't the filter table be obsoleted to avoid confusion? That would probably confuse people. Just don't use it if you don't need to. That is a most practical suggestion. The problem is that people think they are safe with the filter table, when in fact they need the prerouting chain to seal things. Right now this is only possible in the mangle table. I'm not sure what you think is unsafe about using the filter table, and the order of evaluation issues certainly seem to suggest that some actions would take a major rethink at least. Perhaps you could avoid breaking all of the setups which currently work, rather than force everyone to do things differently because you feel that your way is better. It was my intention to suggest that unintentional breakage of existing setups should be avoided, not that removing the filter table was some evil plot. ;-) On rereading my original post I failed to make that clear, please take it as intended. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] iptables: mangle table obsoletes filter table
Al Boldi wrote: [EMAIL PROTECTED] wrote: On Sat, 20 Oct 2007 06:40:02 +0300, Al Boldi said: Sure, the idea was to mark the filter table obsolete as to make people start using the mangle table to do their filtering for new setups. The filter table would then still be available for legacy/special setups. But this would only be possible if we at least ported the REJECT target to mangle. That's *half* the battle. The other half is explaining why I should move from a perfectly functional setup that uses the filter table. What gains do I get from doing so? What isn't working that I don't know about? etc? In other words - why do I want to move from filter to mangle? This has already been explained in this thread; here it is again: Al Boldi wrote: The problem is that people think they are safe with the filter table, when in fact they need the prerouting chain to seal things. Right now this is only possible in the mangle table. Why do they need PREROUTING? Well, for example to stop any transient packets being forwarded. You could probably hack around this using mark's, but you can't stop the implied route lookup, unless you stop it in prerouting. Basically, you have one big unintended gaping whole in your firewall, that could easily be exploited for DoS attacks at the least, unless you put in specific rules to limit this. Well... true enough on a small firewall machine with a really fast link, maybe. I like your point about efficiency better, it's more logical, like putting an ACCEPT of established connections before a lot of low probability rules. The only time I have seen rules actually bog a machine was when a major ISP sent out a customer upgrade with a bug which caused certain connections to be SYN-SYN/ACK-RST leaving half open sockets. They sent out 160k of them and the blocking list became very long as blocking rules were added. Plus, it's outrageously incorrect to accept invalid packets, just because your filtering infrastructure can only reject packets after they have been prerouted. As long as the filter table doesn't go away, sometimes things change after PREROUTING, like NAT, and additional rules must be used. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.25 patch] the planned eepro100 removal
Adrian Bunk wrote: This patch contains the planned removal of the eepro100 driver. Are the e100 people satisfied that e100 now handles all known cases? I remember that there were corner cases e100 didn't handle, have they all been fixed? -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sockets affected by IPsec always block (2.6.23)
David Miller wrote: From: Herbert Xu [EMAIL PROTECTED] Date: Wed, 5 Dec 2007 11:12:32 +1100 [INET]: Export non-blocking flags to proto connect call Previously we made connect(2) block on IPsec SA resolution. This is good in general but not desirable for non-blocking sockets. To fix this properly we'd need to implement the larval IPsec dst stuff that we talked about. For now let's just revert to the old behaviour on non-blocking sockets. Signed-off-by: Herbert Xu [EMAIL PROTECTED] We made an explicit decision not to do things this way. Non-blocking has a meaning dependant upon the xfrm_larval_drop sysctl setting, and this is across the board. If xfrm_larval_drop is zero, non-blocking semantics do not extend to IPSEC route resolution, otherwise it does. If he sets this sysctl to 1 as I detailed in my reply, he'll get the behavior he wants. I think you for the hint, but I would hardly call this sentence detailed in terms of being a cookbook solution to the problem. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/29] Swap over NFS -v15
Peter Zijlstra wrote: Hi, Another posting of the full swap over NFS series. Andrew/Linus, could we start thinking of sticking this in -mm? Two questions: 1 - what is the memory use impact on the system which don't do swap over NFS, such as embedded systems, and 2 - what is the advantage of this code over the two existing network swap approaches, swapping to NFS mounted file and swap to NBD device? I've used the NFS file when a program was running out of memory and that seemed to work, people in UNYUUG have reported that the nbd swap works, so what's better here? -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
