[Bluez-users] Mysterious problem with l2test on Coldfire 5282

[Bluez-users] Mysterious problem with l2test on Coldfire 5282

[Jeff Sutherland]

Using the l2test program on Motorola 5282 (uClinux) I have a strange behaviour 
when using l2test -s from the Moto board.  Using the -d (dump) mode to 
receive packets from a PC running l2test I see what appears to be the packet 
sequence number in the first 4 bytes of data (little endian), followed by a 2 
byte packet length, then data payload.  When dumping data from the PC the 
packet sequence number increments by 1 each time, which, I believe, is the 
expected behaviour.  However, when sending from the Moto board to the PC, the 
packet sequence number increments by 4 each time. ?????  L2test send looks 
ok, the sequence number is just seq++; so something must be going on in hcid, 
right?  Or maybe it's dropping 3 out of 4 send packets for some reason.  
Maybe something cocked up with the socket ops in l2test?  ?????  Debugging 
pointers, please...

-Jeff
-- 
Secure your email with Gnu Privacy Guard and Mozilla, the open source
cross platform solution for Windows, Linux, and Mac OS X.
See http://enigmail.mozdev.org/



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Mysterious problem with l2test on Coldfire 5282

[Marcel Holtmann]

Hi Jeff,

> Using the l2test program on Motorola 5282 (uClinux) I have a strange behaviour 
> when using l2test -s from the Moto board.  Using the -d (dump) mode to 
> receive packets from a PC running l2test I see what appears to be the packet 
> sequence number in the first 4 bytes of data (little endian), followed by a 2 
> byte packet length, then data payload.  When dumping data from the PC the 
> packet sequence number increments by 1 each time, which, I believe, is the 
> expected behaviour.  However, when sending from the Moto board to the PC, the 
> packet sequence number increments by 4 each time. ?????  L2test send looks 
> ok, the sequence number is just seq++; so something must be going on in hcid, 
> right?  Or maybe it's dropping 3 out of 4 send packets for some reason.  
> Maybe something cocked up with the socket ops in l2test?  ?????  Debugging 
> pointers, please...

maybe this code in send_mode() is the problem

	*(uint32_t *) buf = htobl(seq++);
	*(uint16_t *)(buf+4) = htobs(data_size);

Replace it with

	*(uint32_t *) buf = htobl(seq);
	*(uint16_t *)(buf+4) = htobs(data_size);
	seq++;

I am not a uClinux or compiler expert, so this is only guess.

Regards

Marcel




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Mysterious problem with l2test on Coldfire 5282

[Jeff Sutherland]

On Tuesday 17 February 2004 10:43, Marcel Holtmann wrote:
> Hi Jeff,
>
> > Using the l2test program on Motorola 5282 (uClinux) I have a strange
> > behaviour when using l2test -s from the Moto board.  Using the -d (dump)
> > mode to receive packets from a PC running l2test I see what appears to be
> > the packet sequence number in the first 4 bytes of data (little endian),
> > followed by a 2 byte packet length, then data payload.  When dumping data
> > from the PC the packet sequence number increments by 1 each time, which,
> > I believe, is the expected behaviour.  However, when sending from the
> > Moto board to the PC, the packet sequence number increments by 4 each
> > time. ?????  L2test send looks ok, the sequence number is just seq++; so
> > something must be going on in hcid, right?  Or maybe it's dropping 3 out
> > of 4 send packets for some reason. Maybe something cocked up with the
> > socket ops in l2test?  ?????  Debugging pointers, please...
>
> maybe this code in send_mode() is the problem
>
> 	*(uint32_t *) buf = htobl(seq++);
> 	*(uint16_t *)(buf+4) = htobs(data_size);
>
> Replace it with
>
> 	*(uint32_t *) buf = htobl(seq);
> 	*(uint16_t *)(buf+4) = htobs(data_size);
> 	seq++;
>
> I am not a uClinux or compiler expert, so this is only guess.

Oh, Doh!  I'm sure this is it (haven't tried it yet, though) because of the 
way the byteswap_32() macro expands!  No fair doing increment/decrement ops 
on variables inside macros :-)

-Jeff 
-- 
Secure your email with Gnu Privacy Guard and Mozilla, the open source
cross platform solution for Windows, Linux, and Mac OS X.
See http://enigmail.mozdev.org/

Re: [Bluez-users] Mysterious problem with l2test on Coldfire 5282

[Marcel Holtmann]

Hi Jeff,

> > maybe this code in send_mode() is the problem
> >
> > 	*(uint32_t *) buf = htobl(seq++);
> > 	*(uint16_t *)(buf+4) = htobs(data_size);
> >
> > Replace it with
> >
> > 	*(uint32_t *) buf = htobl(seq);
> > 	*(uint16_t *)(buf+4) = htobs(data_size);
> > 	seq++;
> >
> > I am not a uClinux or compiler expert, so this is only guess.
> 
> Oh, Doh!  I'm sure this is it (haven't tried it yet, though) because of the 
> way the byteswap_32() macro expands!  No fair doing increment/decrement ops 
> on variables inside macros :-)

I applied the fix for l2test, rctest and scotest. Should be in CVS now.

Regards

Marcel




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Mysterious problem with l2test on Coldfire 5282

[Jeff Sutherland]

On Tuesday 17 February 2004 13:35, Marcel Holtmann wrote:
> Hi Jeff,
>
> > > maybe this code in send_mode() is the problem
> > >
> > > 	*(uint32_t *) buf = htobl(seq++);
> > > 	*(uint16_t *)(buf+4) = htobs(data_size);
> > >
> > > Replace it with
> > >
> > > 	*(uint32_t *) buf = htobl(seq);
> > > 	*(uint16_t *)(buf+4) = htobs(data_size);
> > > 	seq++;
> > >
> > > I am not a uClinux or compiler expert, so this is only guess.
> >
> > Oh, Doh!  I'm sure this is it (haven't tried it yet, though) because of
> > the way the byteswap_32() macro expands!  No fair doing
> > increment/decrement ops on variables inside macros :-)
>
> I applied the fix for l2test, rctest and scotest. Should be in CVS now.

I confirmed that this fixed the problem.  I think that this was maybe the last 
of my major issues, thanks for all the help.  rfcomm seems to work, now I 
just need to make use of the connection.  Due to limited resources on my 
Coldfire board I'll probably just use ppp to establish a tcp/ip connection.

Regards,
-Jeff
-- 
Secure your email with Gnu Privacy Guard and Mozilla, the open source
cross platform solution for Windows, Linux, and Mac OS X.
See http://enigmail.mozdev.org/