* Re: [PATCH] vlan: Fix the ingress VLAN_FLAG_REORDER_HDR check v2
From: Changli Gao @ 2011-06-03 3:59 UTC (permalink / raw)
To: padmanabh ratnakar
Cc: Eric W. Biederman, David Miller, shemminger, greearb,
nicolas.2p.debian, jpirko, netdev, kaber, fubar, eric.dumazet,
andy, jesse
In-Reply-To: <BANLkTikjdz+LkavRiuqdDNS6+djAer-a0A@mail.gmail.com>
On Fri, Jun 3, 2011 at 11:34 AM, padmanabh ratnakar
<pratnakarlx@gmail.com> wrote:
> Doesnt __vlan_put_tag()/vlan_insert_tag() depend on skb->data pointing
> to ethernet header.
> Is'nt the skb->data pointing past ethernet header in netif_receive_skb().
> Am I missing anything?
Yes, you are right. skb->data should be adjusted before feeding to
vlan_insert_tag(), or we make vlan_insert_tag() rely on
skb->mac_header instead.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH RFC 3/3] virtio_net: limit xmit polling
From: Krishna Kumar2 @ 2011-06-03 4:08 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Christian Borntraeger, Carsten Otte, habanero, Heiko Carstens,
kvm, lguest, linux-kernel, linux-s390, linux390, netdev,
Rusty Russell, Martin Schwidefsky, steved, Tom Lendacky,
virtualization, Shirley Ma
In-Reply-To: <20110602153423.GA11300@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> wrote on 06/02/2011 09:04:23 PM:
> > > Is this where the bug was?
> >
> > Return value in free_old_xmit() was wrong. I will re-do against the
> > mainline kernel.
> >
> > Thanks,
> >
> > - KK
>
> Just noting that I'm working on that patch as well, it might
> be more efficient if we don't both of us do this in parallel :)
OK, but my intention was to work on a alternate approach, which
was the reason to base it against your patch.
I will check your latest patch.
thanks,
- KK
^ permalink raw reply
* Re: [PATCH] ftrace: tracepoint of net_dev_xmit sees freed skb and causes panic
From: Koki Sanagi @ 2011-06-03 5:03 UTC (permalink / raw)
To: David Miller
Cc: rostedt, linux-kernel, netdev, nhorman, mingo, fweisbec,
mathieu.desnoyers, tglx, kosaki.motohiro, izumi.taku,
kaneshige.kenji
In-Reply-To: <20110602.140426.765650914977149734.davem@davemloft.net>
(2011/06/03 6:04), David Miller wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
> Date: Thu, 02 Jun 2011 17:01:52 -0400
>
>> On Thu, 2011-06-02 at 13:59 -0700, David Miller wrote:
>>> From: Steven Rostedt <rostedt@goodmis.org>
>>> Date: Tue, 31 May 2011 11:14:27 -0400
>>>
>>>> Note, the subject should not be "ftrace:", but "net:" or maybe even
>>>> "net/tracing", as this really has nothing to do with ftrace code. The
>>>> tracepoints are more generic than ftrace.
>>>
>>> Do you guys mind if I take this in via the net-2.6 tree?
>>
>> I have no issue with that. Heck, I prefer it.
>
> Great, thanks!
O.K.
I will resubmit this patch with appropriate subject "net/tracing:"
Thanks,
Koki Sanagi
^ permalink raw reply
* Re: [PATCH] ftrace: tracepoint of net_dev_xmit sees freed skb and causes panic
From: David Miller @ 2011-06-03 5:23 UTC (permalink / raw)
To: sanagi.koki
Cc: rostedt, linux-kernel, netdev, nhorman, mingo, fweisbec,
mathieu.desnoyers, tglx, kosaki.motohiro, izumi.taku,
kaneshige.kenji
In-Reply-To: <4DE86B37.4070704@jp.fujitsu.com>
From: Koki Sanagi <sanagi.koki@jp.fujitsu.com>
Date: Fri, 03 Jun 2011 14:03:51 +0900
> I will resubmit this patch with appropriate subject "net/tracing:"
You don't need to, I fixed it up when I applied your patch.
^ permalink raw reply
* Re: [PATCH] ftrace: tracepoint of net_dev_xmit sees freed skb and causes panic
From: Koki Sanagi @ 2011-06-03 5:57 UTC (permalink / raw)
To: David Miller
Cc: rostedt, linux-kernel, netdev, nhorman, mingo, fweisbec,
mathieu.desnoyers, tglx, kosaki.motohiro, izumi.taku,
kaneshige.kenji
In-Reply-To: <20110602.222356.1588943715309944982.davem@davemloft.net>
(2011/06/03 14:23), David Miller wrote:
> From: Koki Sanagi <sanagi.koki@jp.fujitsu.com>
> Date: Fri, 03 Jun 2011 14:03:51 +0900
>
>> I will resubmit this patch with appropriate subject "net/tracing:"
>
> You don't need to, I fixed it up when I applied your patch.
>
O.K.
Thanks!
Koki Sanagi
^ permalink raw reply
* Re: [Security] inet_diag insufficient validation?
From: Eugene Teo @ 2011-06-03 6:55 UTC (permalink / raw)
To: Dan Rosenberg; +Cc: davem, kuznet, netdev, security, Arnaldo Carvalho de Melo
In-Reply-To: <1306942849.3150.10.camel@dan>
Cc'ed acme.
On Wed, Jun 1, 2011 at 11:40 PM, Dan Rosenberg <drosenberg@vsecurity.com> wrote:
> It seems to me that the auditing performed by inet_diag_bc_audit() is
> insufficient to prevent pathological INET_DIAG bytecode from doing bad
> things.
>
> Firstly, it's possible to cause an infinite loop in inet_diag_bc_audit()
> with a INET_DIAG_BC_JMP opcode with a "yes" value of 0. The valid_cc()
> function, also called from here, seems suspicious as well.
>
> Once the bytecode is actually run in inet_diag_bc_run(), it looks like
> more infinite loops are possible, if appropriate "yes" or "no" values
> are set to zero and weren't validated by the audit.
>
> Finally, I can't seem to find any validation that the reported length of
> the netlink message header doesn't exceed the skb length, as checked in
> some other netlink receive functions, which could result in reading
> beyond the bounds of the socket data. I could just be missing something
> here though.
>
> Regards,
> Dan
>
> _______________________________________________
> Security mailing list
> Security@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/security
>
^ permalink raw reply
* Re: [net-next,02/13] tg3: Cleanup transmit error path
From: David Miller @ 2011-06-03 7:02 UTC (permalink / raw)
To: alex.williamson; +Cc: mcarlson, netdev
In-Reply-To: <1307063914.3656.22.camel@x201>
From: Alex Williamson <alex.williamson@redhat.com>
Date: Thu, 02 Jun 2011 19:18:34 -0600
> On Thu, 2011-06-02 at 16:01 -0700, Matt Carlson wrote:
>> Does this patch fix the problem?
>
> Yes it does, probably explains the subsequent iommu faults if that off
> by one unmapping sometimes finds a non-zero address to unmap. Thanks,
>
> Alex
>
> Tested-by: Alex Williamson <alex.williamson@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCHv2 NEXT 1/1] netxen: suppress false lro warning messages
From: David Miller @ 2011-06-03 7:03 UTC (permalink / raw)
To: amit.salecha
Cc: netdev, ameen.rahman, anirban.chakraborty, sucheta.chakraborty
In-Reply-To: <1307017454-10826-1-git-send-email-amit.salecha@qlogic.com>
From: amit.salecha@qlogic.com
Date: Thu, 2 Jun 2011 05:24:14 -0700
> From: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
>
> When interface is down, driver prints false warning messages
> during lro configuration through ethtool.
>
> Signed-off-by: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Applied, thanks.
^ permalink raw reply
* [PATCH] iproute: Ignore all output fields of ip route get for route add
From: Andi Kleen @ 2011-06-03 8:39 UTC (permalink / raw)
To: shemminger, netdev
My vpnc-connect script broke in a kernel release because the new
kernel started returning the ipid in ip cache get. The script
would do ip route get, modify the route and then feed it back
to ip route add. But ip route add couldn't parse ipid ..
Make route add skip all status fields output by ip cache get
In theory they could be fed to the kernel too, but that's likely
not very useful (and I'm not fully sure if the kernel would
even use them)
Signed-off-by: Andi Kleen <ak@linux.intel.com>
diff --git a/ip/iproute.c b/ip/iproute.c
index 2fef35b..8b7421e 100644
--- a/ip/iproute.c
+++ b/ip/iproute.c
@@ -936,6 +936,17 @@ int iproute_modify(int cmd, unsigned flags, int argc, char **argv)
strcmp(*argv, "oif") == 0) {
NEXT_ARG();
d = *argv;
+ /* Ignore everything else printed by ip route get. */
+ } else if (strcmp(*argv, "ipid") == 0 ||
+ strcmp(*argv, "ts") == 0 ||
+ strcmp(*argv, "tsage") == 0 ||
+ strcmp(*argv, "age") == 0 ||
+ strcmp(*argv, "used") == 0 ||
+ strcmp(*argv, "users") == 0 ||
+ strcmp(*argv, "error") == 0 ||
+ strcmp(*argv, "cache") == 0 ||
+ strcmp(*argv, "expires") == 0) {
+ NEXT_ARG();
} else {
int type;
inet_prefix dst;
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply related
* Re: [PATCH] iproute: Ignore all output fields of ip route get for route add
From: David Miller @ 2011-06-03 9:07 UTC (permalink / raw)
To: andi; +Cc: shemminger, netdev
In-Reply-To: <20110603083918.GA15883@one.firstfloor.org>
From: Andi Kleen <andi@firstfloor.org>
Date: Fri, 3 Jun 2011 10:39:18 +0200
> My vpnc-connect script broke in a kernel release because the new
> kernel started returning the ipid in ip cache get. The script
> would do ip route get, modify the route and then feed it back
> to ip route add. But ip route add couldn't parse ipid ..
>
> Make route add skip all status fields output by ip cache get
>
> In theory they could be fed to the kernel too, but that's likely
> not very useful (and I'm not fully sure if the kernel would
> even use them)
>
> Signed-off-by: Andi Kleen <ak@linux.intel.com>
I think we've had this discussion before.
There are no guarentees that what the tool outputs for routes is
suitable for creating routes.
People have already put vpnc script fixes into Fedora and similar
already.
iproute2 is not where the hacks belong.
^ permalink raw reply
* Re: [PATCH] TODO FLAG_POINTTOPOINT => FLAG_WWAN? usbnet/cdc_ncm: mark ncm devices as "mobile broadband devices" with FLAG_WWAN
From: Stefan (metze) Metzmacher @ 2011-06-03 9:35 UTC (permalink / raw)
To: Alexey ORISHKO
Cc: Oliver Neukum, Greg Kroah-Hartman, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <2AC7D4AD8BA1C640B4C60C61C8E520153E3C07E6F2@EXDCVYMBSTM006.EQ1STM.local>
[-- Attachment #1: Type: text/plain, Size: 544 bytes --]
Am 01.06.2011 14:27, schrieb Alexey ORISHKO:
>> -----Original Message-----
>> From: Stefan (metze) Metzmacher [mailto:metze@samba.org]
>> Sent: Wednesday, June 01, 2011 1:55 PM
>
>>> If you use udev rules and create an alias for your device, you won't
>>> be dependent on generic driver code.
>>
>> Ok, do you have examples for that?
>
> Please, read udev man pages. Rule might be as follows
> KERNEL=="usb*", ATTRS{idVendor}=="04cc", ATTRS{idProduct}=="xxxx", NAME="ste_bridge0"
Thanks! I got something that works.
metze
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: [TRIVIAL PATCH next 15/15] net: Convert vmalloc/memset to vzalloc
From: Pablo Neira Ayuso @ 2011-06-03 9:39 UTC (permalink / raw)
To: David Miller
Cc: joe, kaber, andy.grover, trivial, netfilter-devel, netfilter,
coreteam, netdev, linux-kernel, rds-devel
In-Reply-To: <20110602.143927.1073346459383432955.davem@davemloft.net>
On 02/06/11 23:39, David Miller wrote:
> From: Pablo Neira Ayuso <pablo@netfilter.org>
> Date: Thu, 02 Jun 2011 16:49:53 +0200
>
>> Are you going to take this patch? it includes one chunck which is out of
>> netfilter scope.
>
> I think the trivial folks submit these things via their own tree
> and are only looking for ACKs from us.
>
> Acked-by: David S. Miller <davem@davemloft.net>
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
^ permalink raw reply
* RE: [PATCH] TODO FLAG_POINTTOPOINT => FLAG_WWAN? usbnet/cdc_ncm: mark ncm devices as "mobile broadband devices" with FLAG_WWAN
From: Alexey ORISHKO @ 2011-06-03 9:45 UTC (permalink / raw)
To: Valdis.Kletnieks-PjAqaU27lzQ@public.gmane.org, Dan Williams
Cc: Stefan Metzmacher, Oliver Neukum, Greg Kroah-Hartman,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <5203.1307062683-+bZmOdGhbsPr6rcHtW+onFJE71vCis6O@public.gmane.org>
> -----Original Message-----
> From: Valdis.Kletnieks-PjAqaU27lzQ@public.gmane.org [mailto:Valdis.Kletnieks-PjAqaU27lzQ@public.gmane.org]
> Sent: Friday, June 03, 2011 2:58 AM
>
> > A follow-on to this is that if you really care about specific
> devices,
> > your application can use udev rules to "tag" specific interfaces
> based
> > on USB VID/PID/GUID or other device attributes, and check for those
> > tags in your program. Use udev (good) or netlink (good) or
> > SIOCGIFCONF (bad) to enumerate the various network interfaces on the
> > system and pick the
>
> I think Alexey's point was that the patch will hose up programs that
> currently do the netlink or SIOCGIFCONF thing and look for
> FLAG_POINTTOPOINT.
Just to clarify, I was objecting to renaming interface name mostly because
devices which use CDC NCM function might be something different from wwan
devices. I would prefer to keep a generic name of interface (usbX or ethX).
As an option anyone can use udev rules to set interface name they want
for their device based on VID/PID or MAC address or something else.
I've already provided udev rule example earlier in this thread.
Dan, is it in line with your statement?
/alexey
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] TODO FLAG_POINTTOPOINT => FLAG_WWAN? usbnet/cdc_ncm: mark ncm devices as "mobile broadband devices" with FLAG_WWAN
From: Oliver Neukum @ 2011-06-03 10:01 UTC (permalink / raw)
To: Alexey ORISHKO
Cc: Valdis.Kletnieks@vt.edu, Dan Williams, Stefan Metzmacher,
Oliver Neukum, Greg Kroah-Hartman, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <2AC7D4AD8BA1C640B4C60C61C8E520153E3C13B5F2@EXDCVYMBSTM006.EQ1STM.local>
Am Freitag, 3. Juni 2011, 11:45:38 schrieb Alexey ORISHKO:
> > -----Original Message-----
> > From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu]
> > Sent: Friday, June 03, 2011 2:58 AM
> >
> > > A follow-on to this is that if you really care about specific
> > devices,
> > > your application can use udev rules to "tag" specific interfaces
> > based
> > > on USB VID/PID/GUID or other device attributes, and check for those
> > > tags in your program. Use udev (good) or netlink (good) or
> > > SIOCGIFCONF (bad) to enumerate the various network interfaces on the
> > > system and pick the
> >
> > I think Alexey's point was that the patch will hose up programs that
> > currently do the netlink or SIOCGIFCONF thing and look for
> > FLAG_POINTTOPOINT.
>
> Just to clarify, I was objecting to renaming interface name mostly because
> devices which use CDC NCM function might be something different from wwan
> devices. I would prefer to keep a generic name of interface (usbX or ethX).
>
> As an option anyone can use udev rules to set interface name they want
> for their device based on VID/PID or MAC address or something else.
> I've already provided udev rule example earlier in this thread.
This is not ideal. Distributions cannot care about every VIP:PID value.
If a device with an NCM interface needs to be treated in a special
manner we'd better have a special name for such interfaces.
Regards
Oliver
--
- - -
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5
90409 Nürnberg
Germany
- - -
^ permalink raw reply
* Re: [PATCH] Use unsigned variables for packet lengths in ip[6]_queue.
From: Pablo Neira Ayuso @ 2011-06-03 10:07 UTC (permalink / raw)
To: Dave Jones; +Cc: David Miller, netdev, Netfilter Development Mailinglist
In-Reply-To: <20110528003651.GA8380@redhat.com>
On 28/05/11 02:36, Dave Jones wrote:
> On Tue, Apr 19, 2011 at 08:41:05PM -0700, David Miller wrote:
> > From: Dave Jones <davej@redhat.com>
> > Date: Tue, 19 Apr 2011 21:42:22 -0400
> >
> > > Not catastrophic, but ipqueue seems to be too trusting of what it gets
> > > passed from userspace, and passes it on down to the page allocator,
> > > where it will spew warnings if the page order is too high.
> > >
> > > __ipq_rcv_skb has several checks for lengths too small, but doesn't
> > > seem to have any for oversized ones. I'm not sure what the maximum
> > > we should check for is. I'll code up a diff if anyone has any ideas
> > > on a sane maximum.
> >
> > Maybe the thing to do is to simply pass __GFP_NOWARN to nlmsg_new()
> > in netlink_ack()?
> >
> > Anyone else have a better idea?
>
> So I went back to this today, and found something that doesn't look right.
> After adding some instrumentation, and re-running my tests, I found that
> the reason we were blowing up with enormous allocations was that we
> were passing down a nlmsglen's like -1061109568
>
> Is there any reason for that to be signed ?
> The nlmsg_len entry of nlmsghdr is a u32, so I'm assuming this is a bug.
>
> With the patch below, I haven't been able to reproduce the problem, but
> I don't know if I've inadvertantly broken some other behaviour somewhere
> deeper in netlink where this is valid.
I have applied this. Thanks.
BTW, ip[6]_queue has been marked obsoleted since long time, probably we
can schedule this for removal anytime soon. The nfnetlink_queue
successor has been there to provide a replacement for this since long time.
^ permalink raw reply
* RE: [PATCH] TODO FLAG_POINTTOPOINT => FLAG_WWAN? usbnet/cdc_ncm: mark ncm devices as "mobile broadband devices" with FLAG_WWAN
From: Alexey ORISHKO @ 2011-06-03 10:23 UTC (permalink / raw)
To: Oliver Neukum
Cc: Valdis.Kletnieks@vt.edu, Dan Williams, Stefan Metzmacher,
Oliver Neukum, Greg Kroah-Hartman, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <201106031201.21933.oneukum@suse.de>
> -----Original Message-----
> From: Oliver Neukum [mailto:oneukum@suse.de]
> Sent: Friday, June 03, 2011 12:01 PM
>
> This is not ideal. Distributions cannot care about every VIP:PID value.
> If a device with an NCM interface needs to be treated in a special
> manner we'd better have a special name for such interfaces.
There is no difference between cdc_ncm and cdc_ether devices, besides
the fact cdc_ncm is more efficient in data transfer and cpu load.
The problem is that you cannot say much about device functionality based
just on interface name. As example existing devices with cdc_ether
interface could be mobile phone which provides connectivity to 3G network,
or could be a phone in the mode "over PC", where phone applications
access internet via broadband connection on PC (to save money).
Network manager cannot simply make decision which devices can be used
for mobile broadband access based on interface name. It needs an additional
info, which does not exist in device descriptor.
So, back to original question, is there any point to rename an interface name,
if it can't be guaranteed that any device would be wwan device?
/alexey
^ permalink raw reply
* Re: [PATCH] TODO FLAG_POINTTOPOINT => FLAG_WWAN? usbnet/cdc_ncm: mark ncm devices as "mobile broadband devices" with FLAG_WWAN
From: Oliver Neukum @ 2011-06-03 10:50 UTC (permalink / raw)
To: Alexey ORISHKO
Cc: Valdis.Kletnieks@vt.edu, Dan Williams, Stefan Metzmacher,
Oliver Neukum, Greg Kroah-Hartman, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <2AC7D4AD8BA1C640B4C60C61C8E520153E3C13B620@EXDCVYMBSTM006.EQ1STM.local>
Am Freitag, 3. Juni 2011, 12:23:21 schrieb Alexey ORISHKO:
> There is no difference between cdc_ncm and cdc_ether devices, besides
> the fact cdc_ncm is more efficient in data transfer and cpu load.
> The problem is that you cannot say much about device functionality based
> just on interface name. As example existing devices with cdc_ether
> interface could be mobile phone which provides connectivity to 3G network,
> or could be a phone in the mode "over PC", where phone applications
> access internet via broadband connection on PC (to save money).
>
> Network manager cannot simply make decision which devices can be used
> for mobile broadband access based on interface name. It needs an additional
> info, which does not exist in device descriptor.
Well, but cdc-ether usually means that you can start up dhcp and use the
interface as a network card. Can the same be done with cdc-ncm or do you always
need to establish a connection through a secondary interface?
Regards
Oliver
--
- - -
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5
90409 Nürnberg
Germany
- - -
^ permalink raw reply
* RE: [PATCH] TODO FLAG_POINTTOPOINT => FLAG_WWAN? usbnet/cdc_ncm: mark ncm devices as "mobile broadband devices" with FLAG_WWAN
From: Alexey ORISHKO @ 2011-06-03 11:47 UTC (permalink / raw)
To: Oliver Neukum
Cc: Valdis.Kletnieks-PjAqaU27lzQ@public.gmane.org, Dan Williams,
Stefan Metzmacher, Oliver Neukum, Greg Kroah-Hartman,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <201106031250.28041.oneukum-l3A5Bk7waGM@public.gmane.org>
> -----Original Message-----
> From: Oliver Neukum [mailto:oneukum-l3A5Bk7waGM@public.gmane.org]
> Sent: Friday, June 03, 2011 12:50 PM
>
> Well, but cdc-ether usually means that you can start up dhcp and use
> the
> interface as a network card. Can the same be done with cdc-ncm or do
> you always
> need to establish a connection through a secondary interface?
>
Some solutions (also based on cdc_ether driver) present IP address assigned
by 3G network. Initially device carrier is OFF. As soon as 3G network PDP
context is established, device send notification
USB_CDC_NOTIFY_NETWORK_CONNECTION and host driver set carrier ON.
In such a case the problem is the lack of control channel definition in both
CDC ECM and CDC NCM. In order for mobile device to setup 3G connection
some application from PC must setup PDP context. The usual way to do it via
modem by using AT commands. So, it might be CDC ACM or some proprietary
solution.
As a result you have to have vendor specific solution to find "real" control
channel (/dev/ttyACMx or other) and setup connection.
The need to know interface name is needed if you want to set default
route to that interface. Do you want to do it while you have pc broadband
connection at hand? Probably not.
I've tried to run 3g modem with cdc_ncm on Ubuntu 8 and later without any
need to specify interface names, same for Fedora.
So connection manager has to know: control interface, vendor-
specific (or ever product specific) AT command sequence and optionally
network interface name.
To sort this out, someone need either to track VID/PID or get
information by other means, for example via AT channel by guessing the
right tty device name.
Anyway, all this discussion is user space application problems.
Solution would be different from vendor to vendor.
/alexey
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Skipping past TCP lost packet in userspace
From: Ilpo Järvinen @ 2011-06-03 11:51 UTC (permalink / raw)
To: Josh Lehan; +Cc: netdev
In-Reply-To: <4DE5F3E3.2080609@krellan.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2062 bytes --]
On Wed, 1 Jun 2011, Josh Lehan wrote:
> On 05/31/2011 10:23 AM, Yuchung Cheng wrote:
> > This paper may have a solution to your problem
> > "Minion—an All-Terrain Packet Packhorse to Jump-Start Stalled Internet
> > Transports"
> > http://csweb1.fandm.edu/jiyengar/lair/papers/minion-pfldnet2010.pdf
>
> Nice, thanks for pointing me to this. I appreciate the helpful answer,
> instead of just saying "use UDP" or "use SCTP". That's not the point.
>
> For better or for worse, TCP is realistically the only viable protocol
> for streaming to the largest possible audience these days, hence my
> question about adding this feature to the Linux TCP implementation.
>
> As for the Linux receiver, I was thinking of 2 features:
>
> 1) Assuming the application has already read all data that would be
> possible without blocking, perform something like an ioctl() to peek at
> the data, and peek to see if there is any out-of-order data behind a gap.
>
> 2) If the out-of-order data is enough to be useful to the application,
> another ioctl() could be done, to ask the kernel to jump over the gap
> and deliver the data to the application. At this point the missing data
> would be considered lost. The data behind the gap would then be
> delivered to the application as part of its normal reading stream. The
> TCP sequence numbers would advance, as usual, just as if the missing
> data had been there all along.
And you'd send a cumulative ACK without the actual data segment...?
...That's gonna break many middleboxes which would want to see that
data segment too ...And there goes your "viability" (though with luck it
will _sometimes_ work as rexmit of the data segment is already in flight).
...The fact is that such change into TCP wire behavior is no longer TCP
enough to work reliably.
In addition, such a non-legimite cumulative ACK probably violates number
of TCP RFCs or at least assumptions made in them... e.g., for starters,
please explain which timestamp you would be putting there into that
particular cumulative ACK?
--
i.
^ permalink raw reply
* Re: [PATCH] TODO FLAG_POINTTOPOINT => FLAG_WWAN? usbnet/cdc_ncm: mark ncm devices as "mobile broadband devices" with FLAG_WWAN
From: Bjørn Mork @ 2011-06-03 12:31 UTC (permalink / raw)
To: Oliver Neukum
Cc: Alexey ORISHKO, Valdis.Kletnieks@vt.edu, Dan Williams,
Stefan Metzmacher, Oliver Neukum, Greg Kroah-Hartman,
linux-usb@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <201106031250.28041.oneukum@suse.de>
Oliver Neukum <oneukum@suse.de> writes:
> Well, but cdc-ether usually means that you can start up dhcp and use the
> interface as a network card. Can the same be done with cdc-ncm or do you always
> need to establish a connection through a secondary interface?
Is there anything in the class definition that prevents either option,
for either protocol? No?
So, could we please kill the device guessing game? Making decisions
based on absolute measures like "do we have a global mac address?" do
make some sense. But guessing based on USB class does not. That will
only tell you the protocol for the USB link. If you want more specific
device information, then you will have to look at the vid/pid. And I
assume you don't want to put all of those into the kernel when a class
driver will do, and whatever additional device specific information just
as well can be added by udev rules. Preferably created by whatever
application wishing to support the device.
But I do also assume you know all this already...
Bjørn
^ permalink raw reply
* [PATCH] bonding: reset queue mapping prior to transmission to physical device (v2)
From: Neil Horman @ 2011-06-03 13:26 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, Jay Vosburgh, Andy Gospodarek, David S. Miller
In-Reply-To: <1307037799-32315-1-git-send-email-nhorman@tuxdriver.com>
The bonding driver is multiqueue enabled, in which each queue represents a slave
to enable optional steering of output frames to given slaves against the default
output policy. However, it needs to reset the skb->queue_mapping prior to
queuing to the physical device or the physical slave (if it is multiqueue) could
wind up transmitting on an unintended tx queue
Change Notes:
v2) Based on first pass review, updated the patch to restore the origional queue
mapping that was found in bond_select_queue, rather than simply resetting to
zero. This preserves the value of queue_mapping when it was set on receive in
the forwarding case which is desireable.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Jay Vosburgh <fubar@us.ibm.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: "David S. Miller" <davem@davemloft.net>
---
drivers/net/bonding/bond_main.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 17b4dd9..8761d86 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -400,6 +400,11 @@ int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb,
{
skb->dev = slave_dev;
skb->priority = 1;
+ /*
+ *restore the origional mapping
+ */
+ skb_set_queue_mapping(skb, (u16)skb->cb[0]);
+
if (unlikely(netpoll_tx_running(slave_dev)))
bond_netpoll_send_skb(bond_get_slave_by_dev(bond, slave_dev), skb);
else
@@ -4216,6 +4221,11 @@ static u16 bond_select_queue(struct net_device *dev, struct sk_buff *skb)
*/
u16 txq = skb_rx_queue_recorded(skb) ? skb_get_rx_queue(skb) : 0;
+ /*
+ * Save the origional txq to restore before passing to the driver
+ */
+ skb->cb[0] = txq;
+
if (unlikely(txq >= dev->real_num_tx_queues)) {
do {
txq -= dev->real_num_tx_queues;
--
1.7.3.4
^ permalink raw reply related
* Re: KVM induced panic on 2.6.38[2367] & 2.6.39
From: Brad Campbell @ 2011-06-03 13:38 UTC (permalink / raw)
To: CaT
Cc: Avi Kivity, Hugh Dickins, Andrea Arcangeli, Borislav Petkov,
linux-kernel, kvm, linux-mm, netdev
In-Reply-To: <20110601230342.GC3956@zip.com.au>
On 02/06/11 07:03, CaT wrote:
> On Wed, Jun 01, 2011 at 07:52:33PM +0800, Brad Campbell wrote:
>> Unfortunately the only interface that is mentioned by name anywhere
>> in my firewall is $DMZ (which is ppp0 and not part of any bridge).
>>
>> All of the nat/dnat and other horrible hacks are based on IP addresses.
>
> Damn. Not referencing the bridge interfaces at all stopped our host from
> going down in flames when we passed it a few packets. These are two
> of the oopses we got from it. Whilst the kernel here is .35 we got the
> same issue from a range of kernels. Seems related.
Well, I tried sending an explanatory message to netdev, netfilter & cc'd
to kvm, but it appears not to have made it to kvm or netfilter, and the
cc to netdev has not elicited a response. My resend to netfilter seems
to have dropped into the bit bucket also.
Is there anyone who can point me at the appropriate cage to rattle? I
know it appears to be a netfilter issue, but I don't seem to be able to
get a message to the list (and I am subscribed to it and have been
getting mail for months) and I'm not sure who to pester. The other
alternative is I just stop doing "that" and wait for it to bite someone
else.
Cheers.
Brad
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH net-next] bonding: make 802.3ad use update lacp_rate
From: Weiping Pan @ 2011-06-03 14:35 UTC (permalink / raw)
Cc: Weiping Pan, Jay Vosburgh, Andy Gospodarek,
open list:BONDING DRIVER, open list
There is a bug that when you modify lacp_rate via sysfs,
802.3ad won't use the new value of lacp_rate to transmit packets.
That is because port->actor_oper_port_state isn't changed.
And I want to use AD_STATE_LACP_TIMEOUT,
so I move related macros from bond_3ad.c into bond_3ad.h.
Signed-off-by: Weiping Pan <panweiping3@gmail.com>
---
drivers/net/bonding/bond_3ad.c | 48 --------------------------------------
drivers/net/bonding/bond_3ad.h | 48 ++++++++++++++++++++++++++++++++++++++
drivers/net/bonding/bond_sysfs.c | 15 +++++++++++-
3 files changed, 62 insertions(+), 49 deletions(-)
diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
index c7537abc..9083258 100644
--- a/drivers/net/bonding/bond_3ad.c
+++ b/drivers/net/bonding/bond_3ad.c
@@ -34,54 +34,6 @@
#include "bonding.h"
#include "bond_3ad.h"
-// General definitions
-#define AD_SHORT_TIMEOUT 1
-#define AD_LONG_TIMEOUT 0
-#define AD_STANDBY 0x2
-#define AD_MAX_TX_IN_SECOND 3
-#define AD_COLLECTOR_MAX_DELAY 0
-
-// Timer definitions(43.4.4 in the 802.3ad standard)
-#define AD_FAST_PERIODIC_TIME 1
-#define AD_SLOW_PERIODIC_TIME 30
-#define AD_SHORT_TIMEOUT_TIME (3*AD_FAST_PERIODIC_TIME)
-#define AD_LONG_TIMEOUT_TIME (3*AD_SLOW_PERIODIC_TIME)
-#define AD_CHURN_DETECTION_TIME 60
-#define AD_AGGREGATE_WAIT_TIME 2
-
-// Port state definitions(43.4.2.2 in the 802.3ad standard)
-#define AD_STATE_LACP_ACTIVITY 0x1
-#define AD_STATE_LACP_TIMEOUT 0x2
-#define AD_STATE_AGGREGATION 0x4
-#define AD_STATE_SYNCHRONIZATION 0x8
-#define AD_STATE_COLLECTING 0x10
-#define AD_STATE_DISTRIBUTING 0x20
-#define AD_STATE_DEFAULTED 0x40
-#define AD_STATE_EXPIRED 0x80
-
-// Port Variables definitions used by the State Machines(43.4.7 in the 802.3ad standard)
-#define AD_PORT_BEGIN 0x1
-#define AD_PORT_LACP_ENABLED 0x2
-#define AD_PORT_ACTOR_CHURN 0x4
-#define AD_PORT_PARTNER_CHURN 0x8
-#define AD_PORT_READY 0x10
-#define AD_PORT_READY_N 0x20
-#define AD_PORT_MATCHED 0x40
-#define AD_PORT_STANDBY 0x80
-#define AD_PORT_SELECTED 0x100
-#define AD_PORT_MOVED 0x200
-
-// Port Key definitions
-// key is determined according to the link speed, duplex and
-// user key(which is yet not supported)
-// ------------------------------------------------------------
-// Port key : | User key | Speed |Duplex|
-// ------------------------------------------------------------
-// 16 6 1 0
-#define AD_DUPLEX_KEY_BITS 0x1
-#define AD_SPEED_KEY_BITS 0x3E
-#define AD_USER_KEY_BITS 0xFFC0
-
//dalloun
#define AD_LINK_SPEED_BITMASK_1MBPS 0x1
#define AD_LINK_SPEED_BITMASK_10MBPS 0x2
diff --git a/drivers/net/bonding/bond_3ad.h b/drivers/net/bonding/bond_3ad.h
index 0ee3f16..6ce1f6b 100644
--- a/drivers/net/bonding/bond_3ad.h
+++ b/drivers/net/bonding/bond_3ad.h
@@ -37,6 +37,54 @@
#define AD_LACP_SLOW 0
#define AD_LACP_FAST 1
+#define AD_SHORT_TIMEOUT 1
+#define AD_LONG_TIMEOUT 0
+#define AD_STANDBY 0x2
+#define AD_MAX_TX_IN_SECOND 3
+#define AD_COLLECTOR_MAX_DELAY 0
+
+// Timer definitions(43.4.4 in the 802.3ad standard)
+#define AD_FAST_PERIODIC_TIME 1
+#define AD_SLOW_PERIODIC_TIME 30
+#define AD_SHORT_TIMEOUT_TIME (3*AD_FAST_PERIODIC_TIME)
+#define AD_LONG_TIMEOUT_TIME (3*AD_SLOW_PERIODIC_TIME)
+#define AD_CHURN_DETECTION_TIME 60
+#define AD_AGGREGATE_WAIT_TIME 2
+
+// Port state definitions(43.4.2.2 in the 802.3ad standard)
+#define AD_STATE_LACP_ACTIVITY 0x1
+#define AD_STATE_LACP_TIMEOUT 0x2
+#define AD_STATE_AGGREGATION 0x4
+#define AD_STATE_SYNCHRONIZATION 0x8
+#define AD_STATE_COLLECTING 0x10
+#define AD_STATE_DISTRIBUTING 0x20
+#define AD_STATE_DEFAULTED 0x40
+#define AD_STATE_EXPIRED 0x80
+
+// Port Variables definitions used by the State Machines(43.4.7 in the 802.3ad standard)
+#define AD_PORT_BEGIN 0x1
+#define AD_PORT_LACP_ENABLED 0x2
+#define AD_PORT_ACTOR_CHURN 0x4
+#define AD_PORT_PARTNER_CHURN 0x8
+#define AD_PORT_READY 0x10
+#define AD_PORT_READY_N 0x20
+#define AD_PORT_MATCHED 0x40
+#define AD_PORT_STANDBY 0x80
+#define AD_PORT_SELECTED 0x100
+#define AD_PORT_MOVED 0x200
+
+// Port Key definitions
+// key is determined according to the link speed, duplex and
+// user key(which is yet not supported)
+// ------------------------------------------------------------
+// Port key : | User key | Speed |Duplex|
+// ------------------------------------------------------------
+// 16 6 1 0
+#define AD_DUPLEX_KEY_BITS 0x1
+#define AD_SPEED_KEY_BITS 0x3E
+#define AD_USER_KEY_BITS 0xFFC0
+
+
typedef struct mac_addr {
u8 mac_addr_value[ETH_ALEN];
} __packed mac_addr_t;
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 88fcb25..2cad514 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -783,8 +783,13 @@ static ssize_t bonding_store_lacp(struct device *d,
struct device_attribute *attr,
const char *buf, size_t count)
{
- int new_value, ret = count;
+ int new_value, i, ret = count;
struct bonding *bond = to_bond(d);
+ struct slave *slave;
+ struct port *port = NULL;
+
+ if (!rtnl_trylock())
+ return restart_syscall();
if (bond->dev->flags & IFF_UP) {
pr_err("%s: Unable to update LACP rate because interface is up.\n",
@@ -804,6 +809,13 @@ static ssize_t bonding_store_lacp(struct device *d,
if ((new_value == 1) || (new_value == 0)) {
bond->params.lacp_fast = new_value;
+ bond_for_each_slave(bond, slave, i) {
+ port = &(slave->ad_info.port);
+ if (new_value)
+ port->actor_oper_port_state |= AD_STATE_LACP_TIMEOUT;
+ else
+ port->actor_oper_port_state &= ~AD_STATE_LACP_TIMEOUT;
+ }
pr_info("%s: Setting LACP rate to %s (%d).\n",
bond->dev->name, bond_lacp_tbl[new_value].modename,
new_value);
@@ -813,6 +825,7 @@ static ssize_t bonding_store_lacp(struct device *d,
ret = -EINVAL;
}
out:
+ rtnl_unlock();
return ret;
}
static DEVICE_ATTR(lacp_rate, S_IRUGO | S_IWUSR,
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH] bonding: reset queue mapping prior to transmission to physical device (v2)
From: Ben Hutchings @ 2011-06-03 14:43 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, Jay Vosburgh, Andy Gospodarek, David S. Miller
In-Reply-To: <1307107607-3015-1-git-send-email-nhorman@tuxdriver.com>
On Fri, 2011-06-03 at 09:26 -0400, Neil Horman wrote:
> The bonding driver is multiqueue enabled, in which each queue represents a slave
> to enable optional steering of output frames to given slaves against the default
> output policy. However, it needs to reset the skb->queue_mapping prior to
> queuing to the physical device or the physical slave (if it is multiqueue) could
> wind up transmitting on an unintended tx queue
>
> Change Notes:
> v2) Based on first pass review, updated the patch to restore the origional queue
> mapping that was found in bond_select_queue, rather than simply resetting to
> zero. This preserves the value of queue_mapping when it was set on receive in
> the forwarding case which is desireable.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> CC: Jay Vosburgh <fubar@us.ibm.com>
> CC: Andy Gospodarek <andy@greyhouse.net>
> CC: "David S. Miller" <davem@davemloft.net>
> ---
> drivers/net/bonding/bond_main.c | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 17b4dd9..8761d86 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -400,6 +400,11 @@ int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb,
> {
> skb->dev = slave_dev;
> skb->priority = 1;
> + /*
> + *restore the origional mapping
> + */
> + skb_set_queue_mapping(skb, (u16)skb->cb[0]);
> +
> if (unlikely(netpoll_tx_running(slave_dev)))
> bond_netpoll_send_skb(bond_get_slave_by_dev(bond, slave_dev), skb);
> else
> @@ -4216,6 +4221,11 @@ static u16 bond_select_queue(struct net_device *dev, struct sk_buff *skb)
> */
> u16 txq = skb_rx_queue_recorded(skb) ? skb_get_rx_queue(skb) : 0;
>
> + /*
> + * Save the origional txq to restore before passing to the driver
> + */
> + skb->cb[0] = txq;
> +
This is throwing away the top 8 bits. It's unlikely to hurt in
practice, but queue numbers are currently 16-bit and we already have
hardware with >256 queues (even though we don't currently expose them
all to the kernel).
Please use ((u16 *)skb->cb)[0].
Ben.
> if (unlikely(txq >= dev->real_num_tx_queues)) {
> do {
> txq -= dev->real_num_tx_queues;
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] bonding: reset queue mapping prior to transmission to physical device (v2)
From: Vitalii Demianets @ 2011-06-03 14:59 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, Jay Vosburgh, Andy Gospodarek, David S. Miller
In-Reply-To: <1307107607-3015-1-git-send-email-nhorman@tuxdriver.com>
On Friday 03 June 2011 16:26:47 Neil Horman wrote:
[...]
> + /*
> + *restore the origional mapping
Style and spelling nits, shouldn't it be:
* Restore the original mapping
> + */
> + skb_set_queue_mapping(skb, (u16)skb->cb[0]);
As already pointed by Ben, it should be ((u16 *)skb->cb)[0]
[...]
> + /*
> + * Save the origional txq to restore before passing to the driver
Spelling: original
> + */
> + skb->cb[0] = txq;
As already pointed by Ben, it should be ((u16 *)skb->cb)[0]
--
Vitalii Demianets
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox