Re: possible dos / wsize affected frozen connection length (was: Re: 2.6.17.1: fails to fully get webpage)
On Tue, 4 Jul 2006, CaT wrote: On Fri, Jun 30, 2006 at 08:50:39AM +1000, CaT wrote: Another datapoint to this is that I've had this my netcat web test running since 8:42pm yesterday. It's 8:37am now. It hasn't progressed in any way. It hasn't quit. It hasn't timed out. It just sits there, hung. This leads me to consider the possibility of a DOS, either intentional or accidental (think about 2.6.17.x running on a mail server and someone mails/spams from a broken place). I'm just wondering if connections hanging around this long are normal. The above has now been running for 6 days. netstat is still reporting an established session. netcat has not timed out. It's all just sitting there doing nothing. -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby TCP/IP connections can continue forever. That's one of the reasons why Berkeley sockets has SO_KEEPALIVE for a socket option. In the absence of such an option, the physical connection can be broken for a week, reconnected, then the session can continue. In your case, you probably have a real error in which one end of the connection crashed. However, until the other end shuts down that socket, the connection is logically correct and should not be forcefully terminated. A DOS is unlikely because with no data being transferred, little non-swapable resources are used. You can control the maximum number of connections allowed from a host with your firewall software (like iptables). Cheers, Dick Johnson Penguin : Linux version 2.6.16.4 on an i686 machine (5592.86 BogoMips). New book: http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: Linux kernel and laws
On Mon, 5 Jun 2006, Adrian Bunk wrote: On Mon, Jun 05, 2006 at 08:52:35AM -0400, Jeff Garzik wrote: ... Paying attention to proper reverse engineering is good. Being overzealous is not. Being overzealous about merging drivers without first checking the legal ramifications is a good way to torpedo Linux. Far too many people have a careless U.S.A. laws suck, merge it anyway attitude. Independent of this issue: An interesting question is how to handle legal issues properly. Where is the borderline for rejecting code due to legal issues? Might not be 100% correct according to laws in the USA. Might not be 100% correct according to laws in Germany. Might not be 100% correct according to laws in Finland. Might not be 100% correct according to laws in Norway. Might not be 100% correct according to laws in Brasil. Might not be 100% correct according to laws in Japan. Might not be 100% correct according to laws in India. Might not be 100% correct according to laws in Russia. Might not be 100% correct according to laws in China. Might not be 100% correct according to laws in Saudi Arabia. Might not be 100% correct according to laws in Iran. For me living in Germany, none of these laws except for the German one has any relevance. I've never seen people on this list pointing to probable problems with Chinese laws although these laws are relevant for four times as many people as US laws. If someone would state a submission to the kernel might have issues according to Chinese laws, or Iranian laws, or Russian laws, would this be enough for keeping code out of the kernel? This might sound like a theoretical question, but e.g. considering that the kernel contains cryptography code it's a question that might have wide practical implications. Jeff cu Adrian If the kernel represented simply a knowledge base, then the burden about whether or not someone could use it used to rest entirely upon the user. That's why some Pacific rim governments are reportedly fire-walling information. In most western cultures, knowledge was not a crime. For many years, someone could write a book, telling you how to kill somebody and, as long as he didn't carry it out, he could not be held culpable. Recently, in the US and some other countries, knowledge has become criminalized. If you know how to defeat copy protection, and you are not in a protected industry, you could be tried and convicted of a federal crime. That's one of the reasons why there are now no general guidelines about kernel code, or any intellectual property use, for that matter. The conditions could occur where the government thinks that you know too much and are, therefore, a threat to national security. So, again, see a lawyer. The fact that you sought and accepted legal opinion may in the future be your only viable defense as governments bring charges against you! Sorry state of affairs for sure. Cheers, Dick Johnson Penguin : Linux version 2.6.16.4 on an i686 machine (5592.88 BogoMips). New book: http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: Van Jacobson's net channels and real-time
On Mon, 24 Apr 2006, Auke Kok wrote: linux-os (Dick Johnson) wrote: On Mon, 24 Apr 2006, Auke Kok wrote: Ingo Oeser wrote: On Saturday, 22. April 2006 15:49, Jörn Engel wrote: That was another main point, yes. And the endpoints should be as little burden on the bottlenecks as possible. One bottleneck is the receive interrupt, which shouldn't wait for cachelines from other cpus too much. Thats right. This will be made a non issue with early demuxing on the NIC and MSI (or was it MSI-X?) which will select the right CPU based on hardware channels. MSI-X. with MSI you still have only one cpu handling all MSI interrupts and that doesn't look any different than ordinary interrupts. MSI-X will allow much better interrupt handling across several cpu's. Auke - Message signaled interrupts are just a kudge to save a trace on a PC board (read make junk cheaper still). yes. Also in PCI-Express there is no physical interrupt line anymore due to the architecture, so even classical interrupts are sent as message over the bus. They are not faster and may even be slower. thus in the case of PCI-Express, MSI interrupts are just as fast as the ordinary ones. I have no numbers on whether MSI is faster or not then e.g. interrupts on PCI-X, but generally speaking, the PCI-Express bus is not designed to be low latency at all, at best it gives you X latency, where X is something like microseconds. The MSI message itself only takes 10-20 nanoseconds though, but all the handling probably adds a large factor to that (1000 or so). No clue on classical interrupt line latency - anyone? About 9 nanosecond per foot of FR-4 (G10) trace, plus the access time through the gate-arrays (about 20 ns) so, from the time a device needs the CPU, until it hits the interrupt pin, you have typically 30 to 50 nanoseconds. Of course the CPU is __much__ slower. However, these physical latencies are in series, cannot be compensated for because the CPU can't see into the future. They will not be the salvation of any interrupt latency problems. This is also not the problem - we really don't care that our 100.000 packets arrive 20usec slower per packet, just as long as the bus is not idle for those intervals. We would care a lot if 25.000 of those arrive directly at the proper CPU, without the need for one of the cpu's to arbitrate on every interrupt. That's the idea anyway. It forces driver-writers to loop in ISRs to handle new status changes that happened before an asserted interrupt even got to the CPU. This is bad. You end up polled in the ISR, with the interrupts off. Turning on the interrupts exacerbates the problem, you may never leave the ISR! It becomes the new idle task. To properly use interrupts, the hardware latency must be less than the CPUs response to the hardware stimulus. Nowadays with irq throttling we introduce a lot of designed latency anyway, especially with network devices. The solutions for increasing networking speed, where the bit-rate on the wire gets close to the bit-rate on the bus, is to put more and more of the networking code inside the network board. The CPU get interrupted after most things (like network handshakes) are complete. That is a limited vision of the situation. You could argue that the current CPU's have so much power that they can easily do a lot of the processing instead of the hardware, and thus warm caches for userspace, setup sockets etc. This is the whole idea of Van Jacobsen's net channels. Putting more offloading into the hardware just brings so much problems with itself, that are just far easier solved in the OS. Cheers, Auke Cheers, Dick Johnson Penguin : Linux version 2.6.16.4 on an i686 machine (5592.89 BogoMips). Warning : 98.36% of all statistics are fiction, book release in April. _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: Van Jacobson's net channels and real-time
On Mon, 24 Apr 2006, Auke Kok wrote: Ingo Oeser wrote: On Saturday, 22. April 2006 15:49, Jörn Engel wrote: That was another main point, yes. And the endpoints should be as little burden on the bottlenecks as possible. One bottleneck is the receive interrupt, which shouldn't wait for cachelines from other cpus too much. Thats right. This will be made a non issue with early demuxing on the NIC and MSI (or was it MSI-X?) which will select the right CPU based on hardware channels. MSI-X. with MSI you still have only one cpu handling all MSI interrupts and that doesn't look any different than ordinary interrupts. MSI-X will allow much better interrupt handling across several cpu's. Auke - Message signaled interrupts are just a kudge to save a trace on a PC board (read make junk cheaper still). They are not faster and may even be slower. They will not be the salvation of any interrupt latency problems. The solutions for increasing networking speed, where the bit-rate on the wire gets close to the bit-rate on the bus, is to put more and more of the networking code inside the network board. The CPU get interrupted after most things (like network handshakes) are complete. Cheers, Dick Johnson Penguin : Linux version 2.6.16.4 on an i686 machine (5592.89 BogoMips). Warning : 98.36% of all statistics are fiction, book release in April. _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: Van Jacobson's net channels and real-time
On Mon, 24 Apr 2006, Rick Jones wrote: Thats right. This will be made a non issue with early demuxing on the NIC and MSI (or was it MSI-X?) which will select the right CPU based on hardware channels. MSI-X. with MSI you still have only one cpu handling all MSI interrupts and that doesn't look any different than ordinary interrupts. MSI-X will allow much better interrupt handling across several cpu's. Auke - Message signaled interrupts are just a kudge to save a trace on a PC board (read make junk cheaper still). They are not faster and may even be slower. They will not be the salvation of any interrupt latency problems. The solutions for increasing networking speed, where the bit-rate on the wire gets close to the bit-rate on the bus, is to put more and more of the networking code inside the network board. The CPU get interrupted after most things (like network handshakes) are complete. if the issue is bus vs network bitrates would offloading really buy that much? i suppose that for minimum sized packets not DMA'ing the headers across the bus would be a decent win, but down at small packet sizes where headers would be 1/3 to 1/2 the stuff DMA'd around, I would think one is talking more about CPU path lengths than bus bitrates. and up and full size segments, since everyone is so fond of bulk transfer tests, the transfer saved by not shovig headers across the bus is what 54/1448 or ~3.75% spreading interrupts via MSI-X seems nice and all, but i keep wondering if the header field-based distribution that is (will be) done by the NICs is putting the cart before the horse - should the NIC essentially be telling the system the CPU on which to run the application, or should the CPU on which the application runs be telling networking where it should be happening? rick jones Ideally, TCP/IP is so mature that one should be able to tell some hardware state-machine Connect with 123.555.44.333, port 23 and it signals via interrupt when that happens. Then one should be able to say send these data to that address or fill this buffer with data from that address. All the networking could be done on the board, perhaps with a dedicated CPU (as is now done) or all in silicon. So, the driver end of the networking software just handles buffers. There are interrupts that show status such as completions or time-outs, trivial stuff. Cheers, Dick Johnson Penguin : Linux version 2.6.16.4 on an i686 machine (5592.89 BogoMips). Warning : 98.36% of all statistics are fiction, book release in April. _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: Router stops routing after changing MAC Address
On Tue, 14 Mar 2006, Bart Samwel wrote: linux-os (Dick Johnson) wrote: On Mon, 13 Mar 2006, Greg Scott wrote: Bst... Not! There are not any MAC addresses associated with any of the intercity links, usually not even in WANs! MAC is for Ethernet! Once you go to fiber, ATM, T-N, etc., there are no MAC addresses. Bt. According to WikiPedia: http://en.wikipedia.org/wiki/MAC_address MAC addresses are used for: - Token ring - 802.11 wireless networks - Bluetooth - FDDI - ATM (switched virtual connections only, as part of an NSAP address) - SCSI and Fibre Channel (as part of a World Wide Name) FDDI = fiber, ATM = ATM. --Bart A name is NOT. I can call my mail route number RFD#2 a MAC address. Also token-ring is a form of Ethernet as are all known wireless networks unless they use light. Even cable modems use Ethernet, with FDM on the cable side and baseband on the customer side. Calling SCSI MAC is absurd. All of the above, except the ethernets are forms of point-to-point communications links. IP (over/under or through) these links uses a source and destination IP and any hardware addressing scheme is incidental. Cheers, Dick Johnson Penguin : Linux version 2.6.15.4 on an i686 machine (5589.54 BogoMips). Warning : 98.36% of all statistics are fiction, book release in April. _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: Router stops routing after changing MAC Address
On Mon, 13 Mar 2006, Stephen Hemminger wrote:
There still is a bug in the 3c59x driver. It doesn't include any code
to handle changing the mac address. It will work if you take the device
down, change address, then bring it up. But you shouldn't have to do that.
Also, if the driver handles setting mac address, it could have prevented
you from using a multicast address.
Something like this is needed (untested, I don't have that hardware).
--- linux-2.6/drivers/net/3c59x.c.orig2006-03-13 09:58:25.0
-0800
+++ linux-2.6/drivers/net/3c59x.c 2006-03-13 09:52:47.0 -0800
@@ -895,6 +895,7 @@ static void dump_tx_ring(struct net_devi
static void update_stats(void __iomem *ioaddr, struct net_device *dev);
static struct net_device_stats *vortex_get_stats(struct net_device *dev);
static void set_rx_mode(struct net_device *dev);
+static int set_rx_address(struct net_device *dev, void *addr);
#ifdef CONFIG_PCI
static int vortex_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
#endif
@@ -1563,6 +1564,7 @@ static int __devinit vortex_probe1(struc
#endif
dev-ethtool_ops = vortex_ethtool_ops;
dev-set_multicast_list = set_rx_mode;
+ dev-set_mac_address = set_rx_address;
dev-tx_timeout = vortex_tx_timeout;
dev-watchdog_timeo = (watchdog * HZ) / 1000;
#ifdef CONFIG_NET_POLL_CONTROLLER
@@ -3150,6 +3152,27 @@ static void set_rx_mode(struct net_devic
iowrite16(new_mode, ioaddr + EL3_CMD);
}
+
+static int set_rx_address(struct net_device *dev, void *p)
+{
+ struct vortex_private *vp = netdev_priv(dev);
+ void __iomem *ioaddr = vp-ioaddr;
+ const struct sockaddr *addr = p;
+
+ if (!is_valid_ether_addr(addr-sa_data))
+ return -EADDRNOTAVAIL;
+
+ spin_lock_bh(vp-lock);
+ memcpy(dev-dev_addr, addr-sa_data, ETH_ALEN);
+
+ EL3WINDOW(2);
+ for (i = 0; i ETH_ALEN; i++)
+ iowrite8(dev-dev_addr[i], ioaddr + i);
+ spin_unlock_bh(vp-lock);
+
+ return 0;
+}
+
#if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE)
/* Setup the card so that it can receive frames with an 802.1q VLAN tag.
Note that this must be done after each RxReset due to some backwards
-
Actually, it doesn't make any difference. Changing the IEEE station
(physical) address is not an allowed procedure even though hooks are
available in many drivers to do this. According to the IEEE 802
physical media specification, this 48-bit address must be unique and
must be one of a group assigned by IEEE. Failure to follow this
simple protocol can (will) cause an entire network to fail. If
you don't care, then you certainly don't care about multicast
bits either, basically let them set it to all ones as well.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.54 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
The information transmitted in this message is confidential and may be
privileged. Any review, retransmission, dissemination, or other use of this
information by persons or entities other than the intended recipient is
prohibited. If you are not the intended recipient, please notify Analogic
Corporation immediately - by replying to this message or by sending an email to
[EMAIL PROTECTED] - and destroy all copies of this information, including any
attachments, without reading or disclosing them.
Thank you.
-
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: Router stops routing after changing MAC Address
On Mon, 13 Mar 2006, Greg Scott wrote: But in a failover scenario you want two devices to have the same IEEE (station) Address (or MAC Address or hardware address). So many names for the same thing! When the primary unit fails, you want the backup unit to completely assume the failed unit's identity - right down to the MAC Address. The other way to do it using gratuitous ARPs is not good enough because some cheap router someplace with an ARP cache of several hours will not listen and will never update its own ARP cache. I like to think of this as bending the rules a little bit, not really breaking them. :) - Greg Top posting, NotGood(tm). Anyway, if the device fails, you have routers and hosts ARPing the interface, trying to establish a route anyway. Actually, it doesn't make any difference. Changing the IEEE station (physical) address is not an allowed procedure even though hooks are available in many drivers to do this. According to the IEEE 802 physical media specification, this 48-bit address must be unique and must be one of a group assigned by IEEE. Failure to follow this simple protocol can (will) cause an entire network to fail. If you don't care, then you certainly don't care about multicast bits either, basically let them set it to all ones as well. Cheers, Dick Johnson Penguin : Linux version 2.6.15.4 on an i686 machine (5589.54 BogoMips). Warning : 98.36% of all statistics are fiction, book release in April. Cheers, Dick Johnson Penguin : Linux version 2.6.15.4 on an i686 machine (5589.54 BogoMips). Warning : 98.36% of all statistics are fiction, book release in April. _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: Router stops routing after changing MAC Address
On Mon, 13 Mar 2006, Greg Scott wrote: Yup. I had a situation 2 weeks ago where a customer connected a system to the Internet with an IP Address he should not have used. And the little Cisco router on the frontend dutifully recorded it in its ARP cache - forever, with no TTL! This took down their webmail for most of a day until we finally had to cycle the power on that nasty little Cisco 678. Bigger routers do it too. I've had several situations over the years where I replaced an older firewall with a newer one with the same IP Addresses. All the internal servers find it soon enough. But I've waited literally hours for the routers to finally purge their ARP caches so they would see my replacement systems - often with the customer looking over my shoulders getting more and more nervous by the minute. And sometimes the routers are not accessible - you can't cycle them even if you had permission. Consider the cases of bridged DSL service - Bst... Not! There are not any MAC addresses associated with any of the intercity links, usually not even in WANs! MAC is for Ethernet! Once you go to fiber, ATM, T-N, etc., there are no MAC addresses. That's why there are bridges and routers, you got to connect your tiny time-slot to your LAN and that first device contains the MAC address that all your other stuff talks to. where the real router could be on the other side of the country. Try calling an ISP and asking the tech on the other end to purge an ARP cache on a router. So the same IP Addresses but different MAC addresses, all you can do is wait for the passage of (lots of) time. That happened to me in my own network once. I accidently took down my email server for something like 4 hours one time when I got careless. Indeed, there is a large onus on the software doing the MAC override to make sure it does not break the required uniqueness. Just as if one were using locally administered MAC addresses. Yes. My 12:34:56 OUI scheme will work for this project but it is definitely not good for the long term. I really really hope I have to spend some money with the IEEE soon to support lots and lots of rollouts. :) - Greg Scott -Original Message- From: Rick Jones [mailto:[EMAIL PROTECTED] Sent: Monday, March 13, 2006 3:50 PM To: linux-os (Dick Johnson) Cc: Greg Scott; Chuck Ebbert; linux-kernel; netdev@vger.kernel.org; Bart Samwel; Alan Cox; Simon Mackinlay Subject: Re: Router stops routing after changing MAC Address Anyway, if the device fails, you have routers and hosts ARPing the interface, trying to establish a route anyway. But only after what may be a much longer time than the customer is willing to accept or able to configure. I know of a number of HA situations where the new device is given the old MAC just to avoid that speicific situation of ARP caches not being updated except after quite some time. Not necessarily on the end-systems, the issue can be with intermediate devices (routers). And if one has to work with static ARP entries to deal (however imperfectly) with ARP poisioning or whatnot... Indeed, there is a large onus on the software doing the MAC override to make sure it does not break the required uniqueness. Just as if one were using locally administered MAC addresses. rick jones - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Cheers, Dick Johnson Penguin : Linux version 2.6.15.4 on an i686 machine (5589.54 BogoMips). Warning : 98.36% of all statistics are fiction, book release in April. _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: [RFC] ip / ifconfig redesign
On Fri, 2 Dec 2005, Al Boldi wrote: The current ip / ifconfig configuration is arcane and inflexible. The reason being, that they are based on design principles inherited from the last century. In a GNU/OpenSource environment, OpenMinds should not inhibit themselves achieving new design-goals to enable a flexible non-redundant configuration. Specifically, '# ip addr ' exhibits this issue clearly, by requiring to associate the address to a link instead of the other way around. Consider this new approach for better address management: 1. Allow the definition of an address pool 2. Relate links to addresses 3. Implement to make things backward-compatible. The obvious benefit here, would be the transparent ability for apps to bind to addresses, regardless of the link existence. A link needs to exist for it to have an address. Another benefit includes the ability to scale the link level transparently, regardless of the application bind state. That doesn't make any sense. Multiple applications can bind to the same address. Then can't bind to the same port because they won't get all their data. And there may be many other benefits... (i.e. 100% OSI compliance) What does Open Source Initiative have to do with this at all??? You are just spewing stuff out. -- Al Also, how does this involve the kernel? The interface to the kernel for hardware configuration is via ioctl(). For logic, sockets. If the user-level tools suck, then they should be fixed. It really doesn't have anything to do with the kernel. Cheers, Dick Johnson Penguin : Linux version 2.6.13.4 on an i686 machine (5589.44 BogoMips). Warning : 98.36% of all statistics are fiction. . The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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
