First of all thank you for your answer, first i post my specifications if my system works well: /etc/network/interfaces: ######################################################################## auto lo iface lo inet loopback allow-hotplug eth0 iface eth0 inet dhcp iface dsl-provider inet ppp pre-up /sbin/ifconfig eth0 up -arp 0 # line maintained by pppoeconf provider dsl-provider ######################################################################## $route ...

Hi All, i am working on a combined Firewall, means 2 Firewalls on one Personal Computer. The first firewall is for my <ppp0> and the second firewall is for <eth0> if i connect through my Server to the internet. However, if i plug off and plug in my network cable, to change the connection from <eth0> to <ppp0>, the connection to internet fails. From <ppp0> to <eth0> works, but than i can not switch back because of a unkown connection error. <dmesg> prints out: no IPv6 Router ...

When the 82575 is fed 802.1q packets, it chokes with an error of the form: igb 0000:08:00.1: partial checksum but proto=81 As the logic there was not smart enough to look into the vlan header to pick out the encapsulated protocol. There are times when we'd like to send these packets out without having to configure a vlan on the interface. Here we check for the vlan tag and allow the packet to go out with the correct hardware checksum. Thanks to Kand Ly <kand@riverbed.com> for ...

I have added a few comments inline. This should probably reference skb_mac_header(skb) instead of data in Thanks, Alex --

On Thu, 12 Mar 2009 14:00:57 -0700 Actually, it is there just a little furthur down than I was looking --

Hi Stephen, ... Ok, thanks, I'll test that one... Arthur --

Yes, it's called gmane.linux.network there. Ben. -- Ben Hutchings, Senior Software Engineer, Solarflare Communications Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. --

Hi David This a small set of fixes in sctp: 1) clean up and simplify sctp listening code. 2) fix ASCONF indication in INIT-ACK. 3) send FORWARD TSN chunks only when peer supports the extension. 4) include Adaptation Indication parameter only when user set it. Thanks -vlad --

From: Wei Yongjun <yjwei@cn.fujitsu.com> This patch fix to indicate ASCONF support in INIT-ACK only if peer has such capable. This patch also fix to calc the chunk size if peer has no FWD-TSN capable. Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com> --- net/sctp/sm_make_chunk.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c index b40e95f..9484f33 ...

From: malc <mlashley@gmail.com> RFC5061 states: Each adaptation layer that is defined that wishes to use this parameter MUST specify an adaptation code point in an appropriate RFC defining its use and meaning. If the user has not set one - assume they don't want to sent the param with a zero Adaptation Code Point. Rationale - Currently the IANA defines zero as reserved - and 1 as the only valid value - so we consider zero to be unset - to save adding a boolean to ...

So far there was not a chance to set a mac address on running 8139cp device. This is for example needed when you want to use this NIC as a bonding slave in bonding device in mode balance-alb. This simple patch allows it. Jirka Signed-off-by: Jiri Pirko <jpirko@redhat.com> drivers/net/8139cp.c | 24 +++++++++++++++++++++++- 1 files changed, 23 insertions(+), 1 deletions(-) diff --git a/drivers/net/8139cp.c b/drivers/net/8139cp.c index 4e19ae3..13b708a 100644 --- ...

The patches below have more information on the problem but the issue is that we are not correctly labeling incoming TCP connection sockets at present. Due to a variety of things all coming together we've gotten a bit lucky in that the majority of labeled TCP connections are labeled correctly now but this won't hold for long as some of the new features added recently will break this "happy coincidence" for some configurations. For the folks on netdev, you probably only care about the relocation ...

The current placement of the security_inet_conn_request() hooks do not allow individual LSMs to override the IP options of the connection's request_sock. This is a problem as both SELinux and Smack have the ability to use labeled networking protocols which make use of IP options to carry security attributes and the inability to set the IP options at the start of the TCP handshake is problematic. This patch moves the IPv4 security_inet_conn_request() hooks past the code where the request_sock's ...

This patch fixes the circular locking problem by changing the locking strategy concerning the logging of firmware handles. Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com> --- drivers/net/ehea/ehea.h | 2 +- drivers/net/ehea/ehea_main.c | 56 ++++++++++++++++++++++------------------- 2 files changed, 31 insertions(+), 27 deletions(-) diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h index 029631c..6e317ca 100644 --- a/drivers/net/ehea/ehea.h +++ ...

Your email ID has been awarded £950,000,00 GBP in our COMPAQ AWARD, Reply to the email above in your in subjuect with your information Email:jerry.smith100@btinternet.com Name:.................... Country:................. Sex:..................... Age/Tell Number:............ Addres:................... --

This patch adds prefix lables for "ip monitor all" command to simplfy understanding of the output. Signed-off-by: Varun Chandramohan <varunc@linux.vnet.ibm.com> --- ip/ipmonitor.c | 16 ++++++++++++++++ 1 files changed, 16 insertions(+), 0 deletions(-) diff --git a/ip/ipmonitor.c b/ip/ipmonitor.c index a74730e..baf25a8 100644 --- a/ip/ipmonitor.c +++ b/ip/ipmonitor.c @@ -25,6 +25,7 @@ #include "ip_common.h" static void usage(void) __attribute__((noreturn)); +int prefix_banner; ...

From: Pantelis Koukousoulas <pktoss@gmail.com> Yes, absolutely. --

So, NetworkManager ignores the device because it doesn't support carrier detection? That seems weird, but I have nothing against this patch in general. Thanks, --

(to be 100% clear, I believe that Pantelis' patch to add minimal ethtool support is *correct*, and it will fix the issue with NetworkManager) Dan --

From: Pantelis Koukousoulas <pktoss@gmail.com> I think Dan is right. If the driver doesn't provide an explicit carrier, there is no way to know for sure that it is on of off. If NetworkManager decides that this means on, and it's really off, that isn't so nice. And lots of very old drivers in the tree don't have a link indication handler, so this is a very real issue. Not adding a link state handler to virtio_net for pompous reasons like some theoretical "clean design" claim is idiotic, ...

Checking up more this morning in NetworkManager, here's the current behavior with 0.7.x. If the device doesn't support carrier detection (determined by checking for ethtool or MII ioctl support), NetworkManager will *not* listen for netlink carrier events. These are triggered by netif_carrier_on()/netif_carrier_off(), which even drivers that don't support carrier detection will still sometimes send. However, NetworkManager will assume carrier=on, because NM is designed such that if the ...

Actually, I've changed my mind. Unlike a device which *has* a carrier which we can't detect, there's no virtio_net "device" which can turn off link (not kvm/qemu, not lguest) without the pending VIRTIO_NET_S_LINK feature. Here's the patch for Dave's tree; the q. is do we want to put Pantelis' patch in 2.6.29 and stable? Rusty. Subject: virtio_net: set carrier on by default. Impact: fix carrier detection, older NetworkManager This is actually two fixes: 1) If the virtio_net device ...

On Thu, Mar 12, 2009 at 12:23 PM, Pantelis Koukousoulas After reading this one more time, it doesn't make much sense, so let me try to explain my point of view more clearly: For the wired case, carrier status == "is cable connected?" (NetworkManager is asking that) So, * virtio saying "Hey, I have no idea if cable is connected or not. I have no way to know that". (aka carrier detect not supported) I think this is closer to lying than: * "Hey, I know that the cable is connected". == ...

On Fri, 13 Mar 2009 10:17:11 +1030 Yes, need that feature, it is really useful for testing. It is about the only reason I hold onto using VMware. --

Doubtful, this patch should be a no-op, any alignment problems that existed before will still be there. Harvey --

On Thu, Mar 12, 2009 at 05:45:57AM +0100, Eric Dumazet wrote: > > @@ -1845,10 +1846,11 @@ static void velocity_free_tx_buf(struct velocity_info *vptr, struct velocity_td_ > > if (tdinfo->skb_dma) { > > > > + pktlen = (skb->len > ETH_ZLEN ? : ETH_ZLEN); > > I personally find better to use max(skb->len, ETH_ZLEN) macro, but YMMV ;) > > It actually can avoid you a bug ;) I prefer that too, but it makes a warning. drivers/net/via-velocity.c:2093: warning: comparison of ...

I personally find better to use max(skb->len, ETH_ZLEN) macro, but YMMV ;) It actually can avoid you a bug ;) --

On Wed, Mar 11, 2009 at 09:20:09PM -0700, David Miller wrote: > From: David Miller <davem@davemloft.net> > Date: Wed, 11 Mar 2009 21:17:06 -0700 (PDT) > > > > > velocity_xmit() needs to set 'pktlen = skb->len;' after, > > not before, the skb_padto() call. > > Actually that won't work since, as you suggest, skb->len > isn't updated by skb_padto(). > > So the transmit needs something like: > > pktlen = (skb->len > ETH_ZLEN ? : ETH_ZLEN); > > velocity_free_tx_buf() ...

I think I've found a bug in the via-velocity driver, but I'm not sure how to fix it. We've been carrying some debug patches in the Fedora kernel that dwmw2 wrote, which do some sanity checks on dma allocations. Velocity triggered this trace.. [ 324.777540] ------------[ cut here ]------------ [ 324.777559] WARNING: at lib/dma-debug.c:470 check_unmap+0x196/0x3e4() (Not tainted) [ 324.777575] Hardware name: [ 324.777591] via-velocity 0000:00:0e.0: DMA-API: device driver frees DMA memory ...

We can remove this lock here, since we are in cgroup write handler and thus the cgrp is guaranteed to be valid, and no lock is needed when writing a u32 variable. Signed-off-by: Li Zefan <lizf@cn.fujitsuc.com> --- net/sched/cls_cgroup.c | 6 ------ 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/net/sched/cls_cgroup.c b/net/sched/cls_cgroup.c index 91a3db4..1ab4542 100644 --- a/net/sched/cls_cgroup.c +++ b/net/sched/cls_cgroup.c @@ -62,13 +62,7 @@ static u64 ...

If i understand right, it must look like this to simulate SFQ This example with just 2 "queues". tc qdisc add dev eth0.100 root handle 1: htb tc class add dev eth0.100 parent 1: classid 1:1 htb rate 15Kbit ceil 15Kbit tc qdisc add dev eth0.100 parent 1:1 handle 2: drr tc class add dev eth0.100 parent 2: classid 2:1 drr quantum 1600 tc class add dev eth0.100 parent 2: classid 2:2 drr quantum 1600 tc qdisc add dev eth0.100 parent 2:1 handle 10: bfifo 9000 tc qdisc add dev eth0.100 ...

Unfortunately no. But I had disabled debugging in the driver until now, as it slows down the network transfer considerably. I'll rerun the test with debugging enabled. I'm going to retry 'git bisect' next week. Maybe I find a way to compile a bootable image for older kernel versions. Thanks! Gerhard -- Nur bis 16.03.! DSL-Komplettanschluss inkl. WLAN-Modem für nur 17,95 ¿/mtl. + 1 Monat gratis!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a --

Acked-by: Daniel Lezcano <daniel.lezcano@free.fr> --

Acked-by: Daniel Lezcano <daniel.lezcano@free.fr> --

Acked-by: Daniel Lezcano <daniel.lezcano@free.fr> --

What about the fact that PAWS could bite us leaving us a hung connection if timestamp changes too much when we get the first ACK? Though I doubt you can get windows to run long enough for this to become a problem if they always start from zero... ;-) -- i. --

Interrupt binding is something popular for benchmarks, but most users don't (and shouldn't need to) care. Having it work well out of the box There's a Microsoft spec for a standard hash function that does this on NICs and all the serious ones support it these days. The hash is normally used to select a MSI-X target based on the input header. Point was that any solution shouldn't add more reordering. But when a RSS hash is used there is no reordering on stream basis. -Andi -- ...

In other words, glibc doesn't work on some embedded targets even if I believe the party line on such things is "use udev". Of course, realistically you can't use udev on little embedded systems and you probably wouldn't use it inside initrd either. Oh well! That's a good point. If assigning the MAC to a particular device "eth0" is dubious - someone said because device names aren't guaranteed. Well, why is Another good point: There have been complaints, of a sort, that embedded ...

Yes. Patching your own initrd or your own modified Debian initrd is _also_ not in the official trees, so I can't see any reason why anybody would follow Dave's suggestion. Much more work, different private tree, same behaviour, probably more bloated, probably Debian's initrd doesn't work on nommu anyway. However there was some attempt to get a reference initrd build into the kernel. Did that go anywhere? It would actually be good to use that if it exists. -- Jamie --

Random mac addresses, yuk! :-) I'd much rather have something that I can make "do the right thing" than something I can't. And as I said, what I've encountered many times is a reference board from some manufacturer where the following conditions are present: 1. The bootloader can pass a command line to the kernel and it is saved in non-volatile storage that can be changed from the bootloader 2. I can not modify the bootloader 3. I can modify the Linux kernel 4. The manufacturer ...

It might be possible to build glibc to always use hosts+DNS for name lookup, but since I almost always use uclibc on embedded systems I haven't really tried to do it. If I use glibc, it's on a NFS root and I'm not sure what is happening, but a statically linked uclibc binary that does TCP networking will work happily with one userspace but not another. It would seem to me that a statically linked binary should only depend on the kernel ABI and not on anything userspace (except the ...

On Wed, 11 Mar 2009 21:56:06 +0100 The problem is that usually users end up with all devices with the same address, unless there is some other procedure to hand out addresses during configuration. That is why the random_ether_addr is safer. --

From: Michael Cashwell <mboards@prograde.net> Initial ramdisk. --

You didn't read what I wrote very closely, I specifically said you have to dig or host to do name lookups, specifically because of the issues with getXbyY. When I said I built busybox in 800k (400k compressed), That was with glibc statically linked. End of story. You're making up problems here, its not that big a deal. I've not looked at the figures lately, but how much space does the dhcp client and nfs root code take up in the kernel these days? I imagine that what you save there by ...

Great, but how does this help in setting the MAC address? This would just move this exact discussion to the dracut or whatever mailing list, but we would still be searching for a generic way to say eth0addr=00:01:02:03:04:05 and I bet the arguments stay the same. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 ...

just checked: disabling CONFIG_IP_PNP and CONFIG_IP_PNP_DHCP saves me 4456 bytes of zImage size on an ARM/PXA build Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | --

+1, the simple fact of the matter is that, when building networkable devices, the design requirements must include: 1) The ability to store unit-unique data, like MAC addresses, in persistent storage, in a manner that can be read at arbitrary times from the OS. 2) The abiltiy to access that data from the OS under all relevant operating conditions. You have (1) covered, in that the bootloader passes the MAC on the command line to the kernel which can then be read via /proc/cmdline ...

From: Christer Weinigel <christer@weinigel.se> Yep, and you can parse that and execute the appropriate ifconfig command from userspace in your initial ramdisk. --

Well, for an example of an initrd, you can unpack just about any distribution initramfs that you like. If you want to use busybox, I'd personally recommend either Debian (I think they use busybox normally), or you're welcome to get a copy of the fedora kexec-tools package. I put a script called mkdumprd that generates initramfs files in there based on busybox for the purpose of capturing core dumps. As for the dhcp part of it, that depends on the dhcp client you decide to use. I use the udhcpc ...

Can you share your scripts and tools for creating an initramfs so easily? I too run into this problem -- I've always used the kernel-provided mechanism to DHCP and do the nfs mount of the rootfs, but if the initramfs is the right way to do that, then I'll be happy to change. It always looked rather daunting to me, and a lot of extra effort compared to letting the kernel do the job, but if it really is so easy, then I'll be happy to change my practices. Thanks! Mike (mwester) --

Yup. A week right now is a luxury I usually don't have right now. I shouldn't even be spending time writing this mail, but I'm eh, Actually, I'm quite happy about work so far. When worked on improving the Samsung S3C24A0 patches Sandeep Patil had made, I got approval from my boss to spend time on making them suitable for submission to the official kernel, so I was able to do a lot more than just "make things work now". But the last few months have been kind of hectic. ...

Aren't you basically implying that the in-kernel DHCP client and NFS mounting should be removed from the kernel too? I'd agree with that; it's the trend. But it seems pretty harsh to say "you can do DHCP+NFS now, but if you want to set the MAC address too, then you have to reimplement DHCP+NFS a completely different way from scratch first". -- Jamie --

I'm looking forward to the first patches on Linux Arm Kernel. That's gonna be even more fun than this thread ;) Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | --

You need to do that yourself. the initramfs is where all your platform specific bits go. You're assuming that some tool is automatically going to do this thing for you that is by definition non-standard. Non-standard stuff needs manually process to implement. --

Yes, ridiculous in the complexity of the workarounds for not having a Which means that the non-volatile storage must be available through a Linux driver before the MAC address is set. AFAIK there is no guarantee that the MTD layer will be ready to use by that time. And that is assuming that there actually is a MTD driver available, usually when I work on a Linux port for a reference board, the first thing I do is to get a NFS root up and running, then I can put a have a complete Debian ...

From: Inaky Perez-Gonzalez <inaky@linux.intel.com> Applied. --

Those are both good ideas. I think I like the former suggestion, since the latter requires that a drop in the stack must occur to detect a stack closer to the hardware. Thank you, I'll keep that in mind for a subsequent enhancement. Regards --

This works great in all my tests so far. Thanks, Brian Bloniarz --