Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

freebsd-net Digest, Vol 366, Issue 2

4 views
Skip to first unread message

freebsd-n...@freebsd.org

unread,
Apr 6, 2010, 8:00:19 AM4/6/10
to freeb...@freebsd.org
Send freebsd-net mailing list submissions to
freeb...@freebsd.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-net
or, via email, send a message with subject or body 'help' to
freebsd-n...@freebsd.org

You can reach the person managing the list at
freebsd-...@freebsd.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-net digest..."


Today's Topics:

1. Re: kern/144529: commit references a PR (dfilter service)
2. Re: net80211 ratectl proof of concept (Rui Paulo)
3. [if_cdce][ue] can't setup network communication via usb
network interface (Andrey Kosachenko)


----------------------------------------------------------------------

Message: 1
Date: Mon, 5 Apr 2010 13:50:05 GMT
From: dfi...@FreeBSD.ORG (dfilter service)
Subject: Re: kern/144529: commit references a PR
To: freeb...@FreeBSD.org
Message-ID: <201004051350....@freefall.freebsd.org>

The following reply was made to PR kern/144529; it has been noted by GNATS.

From: dfi...@FreeBSD.ORG (dfilter service)
To: bug-fo...@FreeBSD.org
Cc:
Subject: Re: kern/144529: commit references a PR
Date: Mon, 5 Apr 2010 13:48:32 +0000 (UTC)

Author: rrs
Date: Mon Apr 5 13:48:23 2010
New Revision: 206181
URL: http://svn.freebsd.org/changeset/base/206181

Log:
MFC of 2 items to fix the csum for v6 issue:
Revision 205075 and 205104:

---------205075----------
With the recent change of the sctp checksum to support offload,
no delayed checksum was added to the ip6 output code. This
causes cards that do not support SCTP checksum offload to
have SCTP packets that are IPv6 NOT have the sctp checksum
performed. Thus you could not communicate with a peer. This
adds the missing bits to make the checksum happen for these cards.
-------------------------
---------205104----------
The proper fix for the delayed SCTP checksum is to
have the delayed function take an argument as to the offset
to the SCTP header. This allows it to work for V4 and V6.
This of course means changing all callers of the function
to either pass the header len, if they have it, or create
it (ip_hl << 2 or sizeof(ip6_hdr)).
-------------------------
PR: 144529

Modified:
stable/8/sys/dev/xen/netback/netback.c
stable/8/sys/netinet/ip_divert.c
stable/8/sys/netinet/ip_ipsec.c
stable/8/sys/netinet/ip_output.c
stable/8/sys/netinet/sctp_crc32.c
stable/8/sys/netinet/sctp_crc32.h
stable/8/sys/netinet6/ip6_output.c
Directory Properties:
stable/8/sys/ (props changed)
stable/8/sys/amd64/include/xen/ (props changed)
stable/8/sys/cddl/contrib/opensolaris/ (props changed)
stable/8/sys/contrib/dev/acpica/ (props changed)
stable/8/sys/contrib/pf/ (props changed)
stable/8/sys/dev/xen/xenpci/ (props changed)

Modified: stable/8/sys/dev/xen/netback/netback.c
==============================================================================
--- stable/8/sys/dev/xen/netback/netback.c Mon Apr 5 13:33:54 2010 (r206180)
+++ stable/8/sys/dev/xen/netback/netback.c Mon Apr 5 13:48:23 2010 (r206181)
@@ -302,7 +302,7 @@ fixup_checksum(struct mbuf *m)
m->m_pkthdr.csum_flags &= ~CSUM_TCP;
#ifdef SCTP
} else if (sw_csum & CSUM_SCTP) {
- sctp_delayed_cksum(m);
+ sctp_delayed_cksum(m, iphlen);
sw_csum &= ~CSUM_SCTP;
#endif
} else {

Modified: stable/8/sys/netinet/ip_divert.c
==============================================================================
--- stable/8/sys/netinet/ip_divert.c Mon Apr 5 13:33:54 2010 (r206180)
+++ stable/8/sys/netinet/ip_divert.c Mon Apr 5 13:48:23 2010 (r206181)
@@ -234,7 +234,7 @@ divert_packet(struct mbuf *m, int incomi
#ifdef SCTP
if (m->m_pkthdr.csum_flags & CSUM_SCTP) {
ip->ip_len = ntohs(ip->ip_len);
- sctp_delayed_cksum(m);
+ sctp_delayed_cksum(m, (uint32_t)(ip->ip_hl << 2));
m->m_pkthdr.csum_flags &= ~CSUM_SCTP;
ip->ip_len = htons(ip->ip_len);
}

Modified: stable/8/sys/netinet/ip_ipsec.c
==============================================================================
--- stable/8/sys/netinet/ip_ipsec.c Mon Apr 5 13:33:54 2010 (r206180)
+++ stable/8/sys/netinet/ip_ipsec.c Mon Apr 5 13:48:23 2010 (r206181)
@@ -343,7 +343,7 @@ ip_ipsec_output(struct mbuf **m, struct
}
#ifdef SCTP
if ((*m)->m_pkthdr.csum_flags & CSUM_SCTP) {
- sctp_delayed_cksum(*m);
+ sctp_delayed_cksum(*m, (uint32_t)(ip->ip_hl << 2));
(*m)->m_pkthdr.csum_flags &= ~CSUM_SCTP;
}
#endif

Modified: stable/8/sys/netinet/ip_output.c
==============================================================================
--- stable/8/sys/netinet/ip_output.c Mon Apr 5 13:33:54 2010 (r206180)
+++ stable/8/sys/netinet/ip_output.c Mon Apr 5 13:48:23 2010 (r206181)
@@ -589,7 +589,7 @@ passout:
}
#ifdef SCTP
if (sw_csum & CSUM_SCTP) {
- sctp_delayed_cksum(m);
+ sctp_delayed_cksum(m, (uint32_t)(ip->ip_hl << 2));
sw_csum &= ~CSUM_SCTP;
}
#endif
@@ -731,7 +731,7 @@ ip_fragment(struct ip *ip, struct mbuf *
#ifdef SCTP
if (m0->m_pkthdr.csum_flags & CSUM_SCTP &&
(if_hwassist_flags & CSUM_IP_FRAGS) == 0) {
- sctp_delayed_cksum(m0);
+ sctp_delayed_cksum(m0, hlen);
m0->m_pkthdr.csum_flags &= ~CSUM_SCTP;
}
#endif

Modified: stable/8/sys/netinet/sctp_crc32.c
==============================================================================
--- stable/8/sys/netinet/sctp_crc32.c Mon Apr 5 13:33:54 2010 (r206180)
+++ stable/8/sys/netinet/sctp_crc32.c Mon Apr 5 13:48:23 2010 (r206181)
@@ -127,14 +127,12 @@ sctp_calculate_cksum(struct mbuf *m, uin


void
-sctp_delayed_cksum(struct mbuf *m)
+sctp_delayed_cksum(struct mbuf *m, uint32_t offset)
{
struct ip *ip;
uint32_t checksum;
- uint32_t offset;

ip = mtod(m, struct ip *);
- offset = ip->ip_hl << 2;
checksum = sctp_calculate_cksum(m, offset);
SCTP_STAT_DECR(sctps_sendhwcrc);
SCTP_STAT_INCR(sctps_sendswcrc);

Modified: stable/8/sys/netinet/sctp_crc32.h
==============================================================================
--- stable/8/sys/netinet/sctp_crc32.h Mon Apr 5 13:33:54 2010 (r206180)
+++ stable/8/sys/netinet/sctp_crc32.h Mon Apr 5 13:48:23 2010 (r206181)
@@ -39,7 +39,7 @@ __FBSDID("$FreeBSD$");
#if defined(_KERNEL) || defined(__Userspace__)

uint32_t sctp_calculate_cksum(struct mbuf *, uint32_t);
-void sctp_delayed_cksum(struct mbuf *);
+void sctp_delayed_cksum(struct mbuf *, uint32_t offset);

#endif /* _KERNEL */


Modified: stable/8/sys/netinet6/ip6_output.c
==============================================================================
--- stable/8/sys/netinet6/ip6_output.c Mon Apr 5 13:33:54 2010 (r206180)
+++ stable/8/sys/netinet6/ip6_output.c Mon Apr 5 13:48:23 2010 (r206181)
@@ -66,6 +66,7 @@ __FBSDID("$FreeBSD$");
#include "opt_inet.h"
#include "opt_inet6.h"
#include "opt_ipsec.h"
+#include "opt_sctp.h"

#include <sys/param.h>
#include <sys/kernel.h>
@@ -102,6 +103,10 @@ __FBSDID("$FreeBSD$");
#include <netipsec/key.h>
#include <netinet6/ip6_ipsec.h>
#endif /* IPSEC */
+#ifdef SCTP
+#include <netinet/sctp.h>
+#include <netinet/sctp_crc32.h>
+#endif

#include <netinet6/ip6protosw.h>
#include <netinet6/scope6_var.h>
@@ -208,6 +213,9 @@ ip6_output(struct mbuf *m0, struct ip6_p
struct route_in6 *ro_pmtu = NULL;
int hdrsplit = 0;
int needipsec = 0;
+#ifdef SCTP
+ int sw_csum;
+#endif
#ifdef IPSEC
struct ipsec_output_state state;
struct ip6_rthdr *rh = NULL;
@@ -829,6 +837,10 @@ again:
}
m->m_pkthdr.csum_flags |=
CSUM_IP_CHECKED | CSUM_IP_VALID;
+#ifdef SCTP
+ if (m->m_pkthdr.csum_flags & CSUM_SCTP)
+ m->m_pkthdr.csum_flags |= CSUM_SCTP_VALID;
+#endif
error = netisr_queue(NETISR_IPV6, m);
goto done;
} else
@@ -857,6 +869,13 @@ passout:
* 4: if dontfrag == 1 && alwaysfrag == 1
* error, as we cannot handle this conflicting request
*/
+#ifdef SCTP
+ sw_csum = m->m_pkthdr.csum_flags & ~ifp->if_hwassist;
+ if (sw_csum & CSUM_SCTP) {
+ sctp_delayed_cksum(m, sizeof(struct ip6_hdr));
+ sw_csum &= ~CSUM_SCTP;
+ }
+#endif
tlen = m->m_pkthdr.len;

if (opt && (opt->ip6po_flags & IP6PO_DONTFRAG))
_______________________________________________
svn-s...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all...@freebsd.org"


------------------------------

Message: 2
Date: Mon, 5 Apr 2010 17:54:20 +0100
From: Rui Paulo <rpa...@freebsd.org>
Subject: Re: net80211 ratectl proof of concept
To: Rui Paulo <rpa...@gmail.com>
Cc: freebsd-net <freeb...@freebsd.org>, Weongyo Jeong
<weo...@freebsd.org>, Andrew Thompson <tho...@freebsd.org>, Bernhard
Schmidt <bsch...@techwires.net>
Message-ID: <E40F1E78-782B-402C...@freebsd.org>
Content-Type: text/plain; charset=us-ascii


On 31 Mar 2010, at 14:05, Rui Paulo wrote:

> Hi,
> I've started developing a ratectl framework for net80211, loosely based on what DragonFly has. Right now only one driver has been ported, but I would like your feedback before continuing.
>
> The objective is to, eventually, have all the ratectl stuff (amrr, sample, onoe(?) and rssadapt) in net80211 so all drivers can use it. We can also select which ratectl modules are built in the kernel config file.
> The framework support changing the current ratectl is out of scope for this patch.
>
> You can find the patch here:
> * http://people.freebsd.org/~rpaulo/ratectl.diff
>
> Only the ral driver and the AMRR rate control algorithms were ported.
>
> Some comments:
> o The rate control calls now dereferences several pointers and some inline functions are now real functions. I wonder how much this impacts performance and what we can do to solve it.
>
> o I wished there was a better way to do the IEEE80211_AMRR_SUCCESS / IEEE80211_AMRR_FAILURe call.
>
> o Some other stuff can also be `const'
>
> o I create ieee80211_ratect.[ch] to avoid polluting other files
>
> o I moved the AMRR parameters inside amrr_init() on purpose. The drivers we have now only specify a different interval and I plan to add export amrr_set_interval() via the ratectl framework later.
>
>
> I would like very much to see this in, unless there's a strong impending argument.

I've ported all the drivers but I can't test them all. You can read the patch at the same URL.

I would like to commit this soon, though.

Regards,
--
Rui Paulo

------------------------------

Message: 3
Date: Mon, 05 Apr 2010 22:18:57 +0300
From: Andrey Kosachenko <andrey.k...@gmail.com>
Subject: [if_cdce][ue] can't setup network communication via usb
network interface
To: freeb...@freebsd.org
Message-ID: <4BBA37A1...@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed

Hi,

there is a mobile device attached to laptop (with FreeBSD 9-Current) via
USB cable.

The goal is to provide access to internet for mobile device via laptop.

device is recognized as ue0 (but seems requires an additional quirk to
function properly)
# usbconfig -u 6 -a 2
ugen6.2: <RNDIS/Ethernet Gadget Linux 2.6.28-omap1 with musb_hdrc> at
usbus6, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON
# usbconfig -u 6 -a 2 set_config 1
# usbconfig -u 6 -a 2
ugen6.2: <RNDIS/Ethernet Gadget Linux 2.6.28-omap1 with musb_hdrc> at
usbus6, cfg=1 md=HOST spd=HIGH (480Mbps) pwr=ON

# dmesg
...
cdce0: <CDC Ethernet Control Model (ECM)> on usbus6
cdce0: No valid alternate setting found
device_attach: cdce0 attach returned 6
cdce0: <CDC Ethernet Control Model (ECM)> on usbus6
cdce0: No valid alternate setting found
device_attach: cdce0 attach returned 6
cdce0: <Linux 2.6.28-omap1 with musb_hdrc RNDIS/Ethernet Gadget, class
2/0, rev 2.00/3.16, addr 2> on usbus6
cdce0: faking MAC address
ue0: <USB Ethernet> on cdce0
ue0: Ethernet address: 2a:ec:22:0b:00:00
...

Mobile device settings: 192.168.2.15/24 (gw: 192.168.2.14)
BSD box's settings: 192.168.2.14/24 (iface: ue0)

# ifconfig -m ue0
ue0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0
mtu 1500
ether 2a:ec:22:0b:00:00
inet 192.168.2.14 netmask 0xffffff00 broadcast 192.168.2.255

The issue is that for some reason network connection is not established
(neither mobile device nor BSD box see each other).
The only strange thing that tcpdump (launched on BSD box (192.168.2.14))
exposed the folowing (while BSD box is ping'ed from mobile device):

# tcpdump -n -i ue0
21:55:45.781154 IP 192.168.2.15 > 192.168.2.14: ICMP echo request, id
14361, seq 0, length 64
21:55:46.781660 IP 192.168.2.15 > 192.168.2.14: ICMP echo request, id
14361, seq 1, length 64
21:55:47.782218 IP 192.168.2.15 > 192.168.2.14: ICMP echo request, id
14361, seq 2, length 64
21:55:48.782530 IP 192.168.2.15 > 192.168.2.14: ICMP echo request, id
14361, seq 3, length 64
21:55:49.782905 IP 192.168.2.15 > 192.168.2.14: ICMP echo request, id
14361, seq 4, length 64
21:55:50.781029 ARP, Request who-has 192.168.2.14 tell 192.168.2.15,
length 28
21:55:50.781049 ARP, Reply 192.168.2.14 is-at 2a:ec:22:0b:00:00 (oui
Unknown), length 28
21:55:50.783263 IP 192.168.2.15 > 192.168.2.14: ICMP echo request, id
14361, seq 5, length 64
21:55:51.783656 IP 192.168.2.15 > 192.168.2.14: ICMP echo request, id
14361, seq 6, length 64

attempt to ping mobile device (192.168.2.14) from BSD box outputs the
following:
# ping 192.168.2.15
PING 192.168.2.15 (192.168.2.15): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host

whereas everything seems to be OK with routing:
# route get 192.168.2.15
route to: 192.168.2.15
destination: 192.168.2.0
mask: 255.255.255.0
interface: ue0
flags: <UP,DONE>
recvpipe sendpipe ssthresh rtt,msec mtu weight expire
0 0 0 0 1500 1 0

There have already been tried many means (more or less relevant) to
combat this issue... however still no luck.
Could smb., please, suggest how to deal with it.

Thanks!

--
WBR,
Andrey Kosachenko


------------------------------


End of freebsd-net Digest, Vol 366, Issue 2
*******************************************

0 new messages