btpand example

Daniel O'Connor doconnor at gsoft.com.au
Sat May 16 05:46:09 UTC 2009


On Thu, 14 May 2009, Iain Hibbert wrote:
> > I found that pinging worked and I could connect to an SSH port but
> > they SSH key exchange stalled so I guessed MTU and got lucky.
>
> Hm, I do manage to use ssh successfully over a btpand/winmobile
> link..
>
> > I later tried l2ping -s 1500 -a pda and it worked so I'm not sure
> > what's going on.
>
> probably better to try actual ping with larger packet sizes..? 
> l2ping only tests the bluetooth link.

Sorry, I missed a step before, I did try ICMP pings when trying to work 
it out.

600 was the largest I found (650 was too large)

> If you also added a log_debug() to the end of bnep_send() to display
> the nw and pkt->len values you might see if lossage was happening at
> any particular packet size. There is already a check that the packet
> doesn't exceed the MTU of the link though.

I can't reproduce the problem now.. Perhaps my phone was out of RAM or 
something.

> > I have done the same operation on the same hardware in Linux and it
> > worked without MTU tweaks, however I haven't looked to see what MTU
> > it used or anything.
>
> I do get a weird problem sometimes where incoming ethernet packet
> payload is rejected by tap for being oversized. I've never tracked it
> down but I'm blaming windows mobile for that because the ethernet
> packet probably originates there rather than at the other end of the
> GPRS link (I could be wrong)
>
> eg
>
> May  2 11:06:36 galant btpand[820]: bnep_recv: received long packet
> (type=0x02, proto=0x0800, len=1568) May  2 11:06:36 galant /netbsd:
> tap0: discarding oversize frame (len=1582)

I haven't seen that [yet] but I've barely used it.

> I find this will cause a HTTP transfer to stall but I think ssh
> recovers from the lost packet ok.

OK.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-bluetooth/attachments/20090516/991dc1ee/attachment.pgp


More information about the freebsd-bluetooth mailing list