RE: CDCether.c

[Michael Duane]

Think I found the problem.  The following patch is generated on the
2.5.36 code base.  Seems that the ^ will only work where skb->len
is <= ether_dev->data_ep_out_size. (ether_dev->data_ep_out_size is
64 on my modem).

Mike

--- linux-2.5.36/drivers/usb/net/cdc-ether.c	Tue Sep 17 17:58:43 2002
+++ patched/drivers/usb/net/cdc-ether.c	Tue Sep 24 14:24:55 2002
@@ -276,7 +276,7 @@
 	// into an integer number of USB packets, we force it to send one 
 	// more byte so the device will get a runt USB packet signalling the 
 	// end of the ethernet frame
-	if ( (skb->len) ^ (ether_dev->data_ep_out_size) ) {
+	if ( (skb->len) % (ether_dev->data_ep_out_size) ) {
 		// It was not an exact multiple
 		// no need to add anything extra
 		count = skb->len;

> -----Original Message-----
> From: Brad Hards [mailto:[e-mail]]
> Sent: Thursday, September 19, 2002 2:12 PM
> To: Michael Duane; [e-mail]
> Subject: Re: CDCether.c
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Fri, 20 Sep 2002 01:22, Michael Duane wrote:
> > No, this is quite different. It appears to be a function of packet
> > size. ping -s <size> <host> will generate packet loss up to 100
> > percent with any size of (86+(64*n)).  All other values work fine.
> > tcpdump on the linux side sees multiple packet retries with
> > correct back-off timeing, but the network side never sees the
> > packet. Now for the odd part - any network activity on another
> > session to the same box will free the "wedged" packet and the
> > network will recieve the last packet sent in the linux retry
> > sequence.
> Ahh, maybe a missing zero length packet problem.  I'll take 
> another look.
> 
> Brad
> 
> 
> - -- 
> http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. 
> Birds in Black.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iD8DBQE9ij2RW6pHgIdAuOMRAmgqAJwPPipMhYxO2QQ0L1VB6yXJtbX8GQCdGpvw
> mWRRiqjOTJUmYWsXLyghSgo=
> =LRBZ
> -----END PGP SIGNATURE-----
> 
>