Re: What were the reasons of having mandatory IP address at AX.25 interfaces ?
.. the original reason was apparently that _ifconfig_ blew up when it saw protocols that it didn't understand on network interfaces. Possibly when there was no IP protocol on an interface. This happened on DECNET, and apparently on others too. Thus the SIOCGIFCONF ioctl is not returning much else than interfaces with IP addresses on them, and to get _all_ interfaces, one must read thru /proc/net/dev file. Some reason like that is possibly behind the reason why SIOCGIFCONF does not find anything but PF_INET sockets even when it is run on PF_AX25 type socket.. The fun part is that ifconfig does look for all devices in /proc/net/dev. Perhaps we should just make all devices findable with SIOCGIFCONF regardless of what protocols they may support ? And if the ifconfig blows up, the bug is in ifconfig tool, not kernel. Alternatively one could iterate all network devices of protocol family X being enabled when ioctl() is called on socket with PF_x (like PF_AX25.) Can anyone recall any real reason why this would not be acceptable ? /Matti Aarnio -- 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: What were the reasons of having mandatory IP address at AX.25 interfaces ?
On Mon, Feb 04, 2008 at 03:38:35PM +0100, Andi Kleen wrote: Matti Aarnio [EMAIL PROTECTED] writes: .. the original reason was apparently that _ifconfig_ blew up when it saw protocols that it didn't understand on network interfaces. Possibly when there was no IP protocol on an interface. It's not only ifconfig, a lot of programs use SIOCGIFCONF to query ip addresses. So ? My codes do too, and filter away things they are not interested in. (When they specifically look for IP addresses.) Of course I may be in minority by expecting the unexpected, and handling such weird multiprotocol systems... I found original explanation for that mandatoryness finally. It was in order to silence bug reports in certain cases when real fix would have been to really find all interfaces instead of complaining. In the end I used same trick that ifconfig tool uses to find all interfaces, and filter away those that AX.25 subsystems are not interested in - end of SIOCGIFCONF problems. netdev:ish developemnt thing would be, that we ( = myself probably ) make SIOCGIFCONF to return those devices that have addresses in the protocol family that the socket used for the query has. For PF_INET we might return also PF_INET6 values to lessen the spanish-inquisition -impact... .. or do you know any who looks up interface IP addresses with PF_FILE ( = AF_UNIX ) socket ? What do the competitor systems B, S, and W do ? -Andi /Matti Aarnio -- 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: Packet per Second
On Mon, Dec 17, 2007 at 11:18:57AM +, Flávio Pires wrote: In article [EMAIL PROTECTED] Glen Turner[EMAIL PROTECTED] wrote: On Fri, 2007-12-14 at 15:34 +, Flvio Pires wrote: Well, I work on an ISP and we have a linux box acting as a bridge+firewall. With this bridge+firewall we control the packet rate per second from each client and from our repeaters. But I can`t measure the packet rate per IP. Is there any tool for this? Thx for the answer Glen, I alread though about something like this. But, isn`t NetFlow just for Cisco IOS ? You probably want this, or at least its sources: http://packages.debian.org/stable/net/fprobe-ng the non-ng version is probably called: fprobe-ulog Then you want also NetFlow collector/accounter.. /Matti Aarnio -- 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
System test of vger.kernel.org
I just tuned things a bit at vger, and now it is time to verify that nothing broke seriously.. - 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
No implementation of NETLINK_USERSOCK ?
Some 6 months ago I asked about a way to make network protocol servers(s) that live in userspace, but whose application interface still uses kernel socket calls. I recall getting an answer that there is NETLINK_USERSOCK for that use. I have tried to have a look into what NETLINK_USERSOCK supplies to its users, but alas there appears to be no implementation at all in existence. Is it some sort of placeholder of things to implement some day ? /Matti Aarnio - 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: No implementation of NETLINK_USERSOCK ?
Following up on myself... On Thu, Nov 08, 2007 at 05:15:12PM +0200, Matti Aarnio wrote: Some 6 months ago I asked about a way to make network protocol servers(s) that live in userspace, but whose application interface still uses kernel socket calls. I recall getting an answer that there is NETLINK_USERSOCK for that use. I have tried to have a look into what NETLINK_USERSOCK supplies to its users, but alas there appears to be no implementation at all in existence. Is it some sort of placeholder of things to implement some day ? The more I am reading around places, the more it looks like there really is no implementation, but somebody thought that such would be a nice thing to have. It did appear around Linux 2.2, and probable reservation maker was Alexey N. Kuznetsov. So, in order to implement the thing, something must be defined at first. Requirements are at least: - Applications see SOCKET API, and addresses are presentable via struct sockaddr* -- meaning that 16 bit sa_family leads the record, or possibly leading byte is record size and second one is family. - sa_family number space must be somehow managed, for example with file: /etc/socketfamilies #PF_## value: 128-254 #nn 'struct sockaddr' size in bytes # # PF_### keyword name # Explanatory name # 128 36 PF_USERSOCK1 Experimental usersock 1 129 80 PF_USERSOCK2 Experimental usersock 2 130 22 PF_USERSOCK3 Experimental usersock 3 And why not all the built in hard-coded ones, too. The sa_family numbers _must_ be static for at least machine runtime, even if they are otherwise quite dynamic in nature. (Registering and reading them from /proc/sys/... -file is a possibility.) - There is only one NETLINK_USERSOCK, but it should somehow manage N different protocols. N being at least 32. - Netlink itself is unrealiable protocol, but applications should still be able to read() and write() from it reliably. There is some reliability-thing in documentation. - For all intents and purposes the only difference from well established socket API based protocols, applications using NETLINK_USERSOCK implemented ones shall not be aware of anything being different except with the the how PF_ literal is resolved. What else is needed ? Any pointers on how to construct this framework ? Or does it exist although I didn't spot it yet ? /Matti Aarnio - 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: Will RFC1146 (tcp alternative checksum options) be implemented in Linux tcp stack ?
On Mon, Oct 15, 2007 at 06:15:11PM -0700, Yanping Du wrote: Hi, We found the standard 16-bit tcp checksum is not strong enough in some cases. Is there any roadmap on implementing RFC1146 (tcp alternative checksum options) in Linux tcp stack ? If yes, how soon will that be in ? If you want to pay to somebody to implement it, possibly soon. Otherwise it is up to whims of capable kernel coders, who usually have their hands quite full. The tcp alternate checksum option does have severe performance hinderance issue. It may be implemented by intermingling it into standard tcp_checksum_and_copy routine, but in cases where the hardware can do tcp checksum offloading, it definitely does not improve the performance. Your alternate approach could be to use a IPSEC VPN tunnel, which will detect an attempt to alter data ( = transmission error ) even when the original TCP does not detect anything. Yet third way could be to do it in application: ssh datastream as one example - or tunnel via SSH port forward. Need for alternate checksums does appear to indicate that you are using bad quality transmission system -- those are not usually very high speed things, and then hacks like IPSEC or SSH tunnels are excellent choices. Nevertheless, adding checksum complexity/size on each packet does not guarantee error detection, it merely lowers the probability of error detection failure. There _will_ happen an error which wasn't detected, but will it be once a minute or once a year, or once per billion years.. Bad quality ( = error introducing ) transmission system will also make speedy data transmission that much more difficult, thus my presumption that it isn't very fast link... Anyway, we have seen data corruption on disk, over the network etc. Having application level MD5 checksumming of the datastream every N kilobytes has its own attractions. Including embedding those checksums in the stored datastreams. Please kindly copy reply to my email address as I've not subscribed the netdev@ mailing list at present. http://www.faqs.org/rfcs/rfc1146.html Thanks! -Yanping /Matti Aarnio - 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: Undocumented IPv6 options
On Mon, Oct 15, 2007 at 08:54:49AM +0200, Michael Kerrisk wrote: Hello netdev, Andrew McDonald kindly fixed the description of IPV6_ROUTER_ALERT in the ipv7.7 man page. As long as we're on the topic, I'll point out that the following IPV6 options (and possibly others) are still not documented on that page: IPV6_CHECKSUM IPV6_JOIN_ANYCAST IPV6_LEAVE_ANYCAST IPV6_V6ONLY IPV6_RECVPKTINFO IPV6_2292PKTINFO Can anyone help with documenting any of these please? RFC 2553 was obsoleted by RFC 3493, and it added IPV6_V6ONLY into Basic API. RFC 2292 (IPV6 Advanced API) defines IPV6_CHECKSUM, and IPV6_PKTINFO (latter of which is known above as IPV6_2292PKTINFO) RFC 3542 obsoletes RFC 2292, and defines IPV6_RECVPKTINFO, and modifies IPV6_PKTINFO. The IPV6_JOIN_ANYCAST and IPV6_LEAVE_ANYCAST are not defined in any RFC. Undocumented are also IPV6_JOIN_GROUP and IPV6_LEAVE_GROUP (RFC 2553 / 3493) It really looks like time for major overhaul of that (and related) man-pages is needed... Cheers, Michael -- Michael Kerrisk maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 /Matti Aarnio - 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: [BNX2X RESUBMIT][PATCH 0/8] New driver for Broadcom 10Gb Ethernet, take two.
On Mon, Oct 08, 2007 at 02:34:45PM +0200, Eliezer Tamir wrote: Message-ID: [EMAIL PROTECTED] Date: Mon, 08 Oct 2007 14:34:45 +0200 From: Eliezer Tamir [EMAIL PROTECTED] User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: netdev@vger.kernel.org netdev@vger.kernel.org (...) Subject: [BNX2X RESUBMIT][PATCH 0/8] New driver for Broadcom 10Gb Ethernet, take two. X-WSS-ID: 6B14FC184VK13380170-01-01 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit [resubmitting, this time without line breaks, sorry] I am sorry, but you had no success in this round either. Thunderbird is somewhat(*) difficult when you try to include the source (diff-) file into message body text. (*: like serious pain in the rear section..) The classical instruction is that thy shall post source as diffs against baseline in email message textbody --- but now your only real choice is in between using genuine attachments, and placing it into some public downloadable file, which the rest of the world can download - or to use the ATTACH -button. Two failures with preferred method is (IMO) a good excuse to resort on MIME attachments. Please consider applying to 2.6.24 Thanks Eliezer Matti Aarnio - 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: [BNX2X][PATCH 0/8] New driver for Broadcom 10Gb Ethernet, take two.
On Sun, Oct 07, 2007 at 06:20:56PM +0200, Eliezer Tamir wrote:
This is an initial version of the BNX2X, the Linux driver for the
BCM5771X 10Gb Ethernet controller family.
Although the chip is very different from the 5706-8 family we based the
driver code on the BNX2 driver.
Since the hardware is supposed to be generally available soon I have
posted an initial version and after hearing all the comments I am reposting
with changes to address them.
Some planned feature are still under development, but we want to get
whatever we have out now so people can start using the HW.
Your patch-posting procedure is yet in a bit problem state..
+{
+static const u32 EVST_TSEM_FAST_MEMORY_COMMON_MEMORY_INIT_EMULATION_7[] = {
+0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0,
+0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0,
+0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0,
It does look like your Thunderbird 2.0 did wrap long text lines when you
included the texts into the posts.
The result is that currently your patches are not usable at all.
Your options:
- instead of including the patch in message body, use Attach
- use some other email program that does not scramble your texts
(e.g. mutt + emacs)
- publish the patch file on network somewhere, and just tell URL
to that one in email
Main changes from first version.
* Fixed most issues raised by Michael Buesch. (Thanks Michael!)
* Some slow path bug fixes.
* Yitchak Gertner re-grouped the code in a more logical manner.
* A lot of work was done to get the generated code to comply with coding
style requirements.
Known issues/TODO.
* Move slowpath event handling from tasklet to workqueue context. This will
allow replacing the busy waits in the link management code with sleeps.
Please consider applying to 2.6.24
Thanks
Eliezer
/Matti Aarnio -- one of [EMAIL PROTECTED]
-
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
We have FUSE, could we have NUSE ?
(somebody should invent a better name for this) We do have a support of file-system engine in userspace process. Could we have a socket interfaced network protocol engine in userspace ? I would like to place things like AX.25 service into userspace, but have application codes to use kernel socket API (and even ABI) as if the service is in the kernel. Required bandwidth for many of these protocols is quite small, therefore having those within the kernel is unnecessary. (Not to mention that quite many system integrators choose not to turn them on...) The aim of NUSE from applications point of view would be to be indistinguishable from kernel implemented services. What would this require from the service hook side ? - Socket read and write can be trivialishly done like a pipe in between processes - Somehow pass ancilliary data for: - socket, socketpair - connect, bind - accept - listen - getpeername, getsockname - sendto, send - recvfrom, revc - setsockopt, getsockopt - poll / epoll ? Death of the protocol engine process must also destroy all existing sockets of the served protocol type, and refuse to generate any new sockets of the type. The first protocol that I have in mind to implement on top of this service does not need very much of local sockets. (It is called STANAG-5066 - radio data communication on HF frequencies. Specification is written by NATO, thus STANAG, but my use plans for it are more along the AX.25 ham-radio things.) /Matti Aarnio - 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: skge dysfunction on Amd X2 machine with 4GB memory
On Mon, Feb 19, 2007 at 11:15:02PM -0800, Chris Wedgwood wrote: On Sun, Feb 11, 2007 at 04:57:55PM +0200, Matti Aarnio wrote: With the skge driver there seems to be some sort of problem to work in a system with memory above the 4 GB of PCI address space. The chipset (apparently) doesn't deal with bus addresses over 4GB even though the MAC does. Would NVidia made such a mistake at nForce4 ? The system is ASUS board (A8N-*) for AMD Athlon X2 with NVidia nForce4 chipset, which (I am sure I did mention it) should be apparent from forcedeth ethernet driver. That one is working just fine with its HIGHDMA mode. Peeking deeper into system hardware: # dmesg|grep forcedeth forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.59. forcedeth: using HIGHDMA eth0: forcedeth.c: subsystem: 01043:8141 bound to :00:0a.0 # dmesg|grep skge skge 1.9 addr 0xc9008000 irq 17 chip Yukon-Lite rev 9 forcedeth: 00:0a.0 0680: 10de:0057 (rev f3) Subsystem: 1043:8141 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 20 Memory at ca10 (32-bit, non-prefetchable) [size=4K] I/O ports at d000 [size=8] Capabilities: [44] Power Management version 2 skge: 05:0c.0 0200: 11ab:4320 (rev 13) Subsystem: 1043:811a Flags: 66MHz, medium devsel, IRQ 17 Memory at c9008000 (32-bit, non-prefetchable) [size=16K] I/O ports at c400 [size=256] Expansion ROM at ca02 [disabled] [size=128K] Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Hmm.. The skge is on bus #5, which is behind bridge: 00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev f2) (prog-if 01 [Subtractive decode]) Flags: bus master, 66MHz, fast devsel, latency 0 Bus: primary=00, secondary=05, subordinate=05, sec-latency=128 I/O behind bridge: b000-cfff Memory behind bridge: c800-c9ff Prefetchable memory behind bridge: ca00-ca0f I guess the right way to fix this long term is to detect systems with these chips and mask the dma_mask globally (or if you're clever per bus)? I don't have any DAC capable PCI cards to see if the bus #5 is unable to pass DACs to primary bus and to Athlon's memory controller. The bus #5 has following devices: 05:06.0 FireWire (IEEE 1394): Texas Instruments TSB12LV23 IEEE-1394 Controller 05:08.0 Multimedia video controller: Brooktree Corporation Bt848 Video Capture (rev 12) 05:0a.0 RAID bus controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02) 05:0b.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22A IEEE-1394a-2000 Controller (PHY/Link) 05:0c.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13) Numbers 6 and 8 are plugin cards, and they don't use DACs. I don't think that SiI 3114 or TI TSB43AB22A are using DACs either. /Matti Aarnio - 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
skge dysfunction on Amd X2 machine with 4GB memory
With the skge driver there seems to be some sort of problem to work in a system with memory above the 4 GB of PCI address space. System doesn't crash (not outright anyway) with skge, but that network interface just doesn't function. My box has also forcedeth network interface, which works just fine. Running kernel is: 2.6.20-1.2922.fc7 This system board had previously buggy bios that prevented the functioning with more than around 3GB memory at all. Now things do work, and Rev.E memory hoist kicks 1280 MB of memory above the 4 GB mark. Without the previously dysfunctioning 4GB memory or more the same kernel and drivers worked just fine. Indeed the skge was my eth0. Any ideas ? /Matti Aarnio - 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 blocked
On Tue, Sep 19, 2006 at 04:33:17PM +0800, Zang Roy-r61911 wrote: Hi, Does anyone can tell me why some of my patches were blocked in the mailing list. I do not use attachment. The body of the mail is not exceed 40KB in size. Roy We are filtering by means of bogofilter, and we are training it with all messages gone thru the list as ham -- but words that it does not know are neutral to the statistics so entirely new kind of message will easily receive that is junk treatment. The rejection message does tell couple technical details, including where to contact to ask advice. /Matti Aarnio -- one of [EMAIL PROTECTED] - 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.16, sk98lin out of date
On Mon, Feb 13, 2006 at 10:58:03AM +, Alistair John Strachan wrote: From: Alistair John Strachan [EMAIL PROTECTED] To: netdev@vger.kernel.org Subject: 2.6.16, sk98lin out of date Date: Mon, 13 Feb 2006 10:58:03 + Cc: linux-kernel@vger.kernel.org Hi, As I'm sure the drivers/net maintainers are well aware, SysKonnect constantly update their sk98lin/sky2 driver without bothering to sync their changes with the official linux kernel. My understanding is, that skge driver has superceded the sk98lin in most uses. There could, of course, be a change to insert vendor driver _as_is_ into baseline kernel with its own name. I quickly downloaded driver version 8.31 from http://www.skd.de/ today and used the install script to generate a diff against 2.6.16-rc3. Even after fixing up some DOS EOLs in the package, the diff was still well over 1.5MBs. This is an enormous number of changes. The reason I'm posting is that my DFI LanParty-UT SLI-D works with this version of the driver, but not the version 2.6.16-rc3. [alistair] 10:55 [~] dmesg | grep sk98lin sk98lin: Could not read VPD data. sk98lin: probe of :01:0a.0 failed with error -5 I wonder if it's worth just identifying the quick fix (I've seen workarounds for corrupt VPDs like mine) or whether a general merge up would be beneficial.. See if 'skge' driver would work instead of 'sk98lin' ? If nobody's maintaining this driver I wouldn't mind helping out. -- Cheers, Alistair. /Matti Aarnio - 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
