[cc'd to current_at_freebsd.org for archive purposes ] Hello Victor, > I hope you don't mind me asking you directly: maybe the -current > mailing list is more appropriate? no, i do not mind, but cc to -current or -net is a good idea. > I'm trying to use a FreeBSD PC (5.1-CURRENT, with the bluetooth software > from http://www.geocities.com/m_evmenkin/ngbt-fbsd-20030908.tar.gz) > as a gateway for network traffic over bluetooth, with my iPaq 3970. > I can l2ping my iPaq, query both ways, create a bond, but ppp refuses > to work, and the error is a strange one. well, let's take a look... > The sequence of actions/commands is: > > kldload ng_ubt > - insert USB bluetooth stick > /etc/rc.bluetooth start ubt0 > - Returns BD_ADDR of bluetooth stick: 00:04:61:80:81:fc > sdpd > sdptool add --channel=7 LAN > rfcomm_pppd -a 00:04:61:80:81:fc -s -C 7 -l rfcomm-server this looks right, one thing in that you do not really have to specify BD_ADDR (-a option) when running rfcomm_pppd(8) in server mode. you only need to do that if you have more than one Bluetooth device connected to the system and you want only one of them provide RFCOMM service. by default rfcomm_pppd(8) will listen on ANY (wildcard) address. > After this, I get an extra entry in the 'Actions' menu on my iPaq after > clicking on the icon of the FreeBSD PC: "Connect to LAN Access over PPP" > If I try this, I get a window saying "Status: Connecting to host. > Retry 1..2..3..4", and then: > "The computer you are dialing is not answering. Try again later" > "Network Access connection to p2.vcc.local (ubt0) was terminated" > (p2.vcc.local is my FreeBSD PC). > If I create a bond with hcsecd in advance, I get exactly the same result. hmm... pretty strange... let's take a look at the logs and the dump. > ppp.log says: > > Sep 11 00:12:38 p2 ppp[949]: Phase: Using interface: tun0 > Sep 11 00:12:38 p2 ppp[949]: Phase: deflink: Created in closed state > Sep 11 00:12:38 p2 ppp[949]: Phase: PPP Started (direct mode). > Sep 11 00:12:38 p2 ppp[949]: Phase: bundle: Establish > Sep 11 00:12:38 p2 ppp[949]: Phase: deflink: closed -> opening > Sep 11 00:12:38 p2 ppp[949]: Phase: deflink: Connected! > Sep 11 00:12:38 p2 ppp[949]: Phase: deflink: opening -> carrier > Sep 11 00:12:38 p2 ppp[949]: Phase: deflink: carrier -> lcp > Sep 11 00:12:49 p2 ppp[949]: Phase: deflink: read (0): Got zero bytes > Sep 11 00:12:49 p2 ppp[949]: Phase: deflink: Disconnected! > Sep 11 00:12:49 p2 ppp[949]: Phase: deflink: Connect time: 11 secs: 24 > octets in, 260 octets out > Sep 11 00:12:49 p2 ppp[949]: Phase: deflink: 4 packets in, 4 packets out > Sep 11 00:12:49 p2 ppp[949]: Phase: total 25 bytes/sec, peak 29 bytes/sec > on Thu Sep 11 00:12:43 2003 > Sep 11 00:12:49 p2 ppp[949]: Phase: deflink: lcp -> closed > Sep 11 00:12:49 p2 ppp[949]: Phase: bundle: Dead > Sep 11 00:12:49 p2 ppp[949]: Phase: PPP Terminated (normal). > > The "Got zero bytes" is what worries me. right, it seems to me that Bluetooth/RFCOMM connection was established, but the error was actually at PPP level. for whatever reason iPaq and FreeBSD could not talk PPP. > I have a hcidump output of just this ppp-request, but I can't read it...: > > HCIDump - HCI packet analyzer ver 1.4 > > HCI Event: Connect Request(0x04) plen 10 > 39 6E 11 C7 02 00 10 01 00 01 > < HCI Command: Accept Connection Request(0x01|0x0009) plen 7 > 39 6E 11 C7 02 00 00 > > HCI Event: Command Status(0x0f) plen 4 > 00 01 09 04 here is your iPaq BD_ADDR 00:02:c7:11:6e:39 is requesting incoming baseband connection and FreeBSD agreed to accept it. > > HCI Event: Role Change(0x12) plen 8 > 00 39 6E 11 C7 02 00 00 > > HCI Event: Connect Complete(0x03) plen 11 > 00 28 00 39 6E 11 C7 02 00 01 00 here FreeBSD changed the role (became master) and got confirmation from the device - connection is established (handle 0x0029) > < HCI Command: Write Link Policy Settings(0x02|0x000d) plen 4 > 28 00 0F 00 > > HCI Event: Page Scan Repetition Mode Change(0x20) plen 7 > 39 6E 11 C7 02 00 01 > > HCI Event: Max Slots Change(0x1b) plen 3 > 28 00 05 > > HCI Event: Command Complete(0x0e) plen 6 > 01 0D 08 00 28 00 here FreeBSD changes the link policy, Scan Repetition Mode and both systems agreed to use Slot-5 packet (the biggest one). so far so good. > > ACL data: handle 0x0028 flags 0x02 dlen 12 > L2CAP(s): Connect req: psm 1 scid 0x0045 > < ACL data: handle 0x0028 flags 0x02 dlen 16 > L2CAP(s): Connect rsp: dcid 0x0055 scid 0x0045 result 0 status 0 > > HCI Event: Number of Completed Packets(0x13) plen 5 > 01 28 00 01 00 here is iPaq requesting incoming L2CAP channel PSM 1 (SDP). FreeBSD accepts the request. > > ACL data: handle 0x0028 flags 0x02 dlen 17 > > ACL data: handle 0x0028 flags 0x01 dlen 3 > L2CAP(s): Config req: dcid 0x0055 flags 0x0000 clen 8 > MTU 256 FlushTO 65535 > < ACL data: handle 0x0028 flags 0x02 dlen 14 > L2CAP(s): Config rsp: scid 0x0045 flags 0x0000 result 0 clen 0 here is iPaq configures its side of L2CAP channel and sets MTU 256 bytes and FlushTO to 65535 (no timeout). FeeBSD accepts these parameters. > < ACL data: handle 0x0028 flags 0x02 dlen 12 > L2CAP(s): Config req: dcid 0x0045 flags 0x0000 clen 0 > > HCI Event: Number of Completed Packets(0x13) plen 5 > 01 28 00 01 00 > > HCI Event: Number of Completed Packets(0x13) plen 5 > 01 28 00 01 00 > > ACL data: handle 0x0028 flags 0x02 dlen 14 > L2CAP(s): Config rsp: scid 0x0055 flags 0x0000 result 0 clen 0 here is FreeBSD configures its side of L2CAP channel with default settings. iPaq accepts these parameters. > > ACL data: handle 0x0028 flags 0x02 dlen 17 > L2CAP(d): cid 0x55 len 13 [psm 1] > SDP SS Req: tid 0x0 len 0x8 > pat uuid-16 0x1102 (LAN) > max 0x14 > cont 00 > < ACL data: handle 0x0028 flags 0x02 dlen 18 > L2CAP(d): cid 0x45 len 14 [psm 1] > SDP SS Rsp: tid 0x0 len 0x9 > tot 0x1 cur 0x1 hndl 0x80541f0 > cont 00 > > HCI Event: Number of Completed Packets(0x13) plen 5 > 01 28 00 01 00 here is iPaq performs SDP Service Search request and it is looking for LAN service. FreeBSD says that is has SDP records for LAN service and record handle is 0x80541f0. > > ACL data: handle 0x0028 flags 0x02 dlen 17 > > ACL data: handle 0x0028 flags 0x01 dlen 6 > L2CAP(d): cid 0x55 len 19 [psm 1] > SDP SA Req: tid 0x1 len 0xe > hndl 0x80541f0 > max 0xf0 > aid(s) 0x0000 - 0xffff > cont 00 > < ACL data: handle 0x0028 flags 0x02 dlen 92 > L2CAP(d): cid 0x45 len 88 [psm 1] > SDP SA Rsp: tid 0x1 len 0x53 > cnt 0x50 > aid 0x0000 (SrvRecHndl) > uint 0x80541f0 > aid 0x0001 (SrvClassIDList) > < uuid-16 0x1102 (LAN) > > aid 0x0004 (ProtocolDescList) > < < uuid-16 0x0100 (L2CAP) > < > uuid-16 0x0003 (RFCOMM) uint 0x7 > > > aid 0x0005 (BrwGrpList) > < uuid-16 0x1002 (PubBrwsGrp) > > aid 0x0009 (BTProfileDescList) > < < uuid-16 0x1102 (LAN) uint 0x100 > > > aid 0x0100 (SrvName) > str "LAN Access over PPP" > > cont 00 > > HCI Event: Number of Completed Packets(0x13) plen 5 > 01 28 00 01 00 here is iPaq performs SDP Service Attribute Request for handle 0x80541f0. it is looking for all attributes (range 0x0000 - 0xffff). FreeBSD send back a bunch of SDP attributes. here iPaq really wants to know RFCOMM channel number which is the first protocol specific parameter for RFCOMM protocol in Protocol Descriptor List attribute. > > ACL data: handle 0x0028 flags 0x02 dlen 12 > L2CAP(s): Disconn req: dcid 0x0055 scid 0x0045 > < ACL data: handle 0x0028 flags 0x02 dlen 12 > L2CAP(s): Disconn rsp: dcid 0x0055 scid 0x0045 > > HCI Event: Number of Completed Packets(0x13) plen 5 > 01 28 00 01 00 here is iPaq disconnects the channel and FreeBSD agrees to disconnect it too. SDP transaction is complete. so no problem here. > > ACL data: handle 0x0028 flags 0x02 dlen 12 > L2CAP(s): Connect req: psm 3 scid 0x0047 > < ACL data: handle 0x0028 flags 0x02 dlen 16 > L2CAP(s): Connect rsp: dcid 0x0056 scid 0x0047 result 0 status 0 > > HCI Event: Number of Completed Packets(0x13) plen 5 > 01 28 00 01 00 now iPaw requests incomming L2CAP channel on PSM 3 (RFCOMM) and FreeBSD agreed to create the channel. > > ACL data: handle 0x0028 flags 0x02 dlen 16 > L2CAP(s): Config req: dcid 0x0056 flags 0x0000 clen 4 > MTU 672 > < ACL data: handle 0x0028 flags 0x02 dlen 14 > L2CAP(s): Config rsp: scid 0x0047 flags 0x0000 result 0 clen 0 iPaq configures its side of L2CAP channel. FreeBSD agrees. > < ACL data: handle 0x0028 flags 0x02 dlen 16 > L2CAP(s): Config req: dcid 0x0047 flags 0x0000 clen 4 > MTU 132 > > HCI Event: Number of Completed Packets(0x13) plen 5 > 01 28 00 01 00 > > HCI Event: Number of Completed Packets(0x13) plen 5 > 01 28 00 01 00 > > ACL data: handle 0x0028 flags 0x02 dlen 14 > L2CAP(s): Config rsp: scid 0x0056 flags 0x0000 result 0 clen 0 FreeBSD configures its side of L2CAP channel. iPaq agrees. > > ACL data: handle 0x0028 flags 0x02 dlen 8 > L2CAP(d): cid 0x56 len 4 [psm 3] > RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c > < ACL data: handle 0x0028 flags 0x02 dlen 8 > L2CAP(d): cid 0x47 len 4 [psm 3] > RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7 > > HCI Event: Number of Completed Packets(0x13) plen 5 > 01 28 00 01 00 here is iPaq requests to open multiplexor RFCOMM channel (dlci 0). FreeBSD agreed to open it. > > ACL data: handle 0x0028 flags 0x02 dlen 17 > > ACL data: handle 0x0028 flags 0x01 dlen 1 > L2CAP(d): cid 0x56 len 14 [psm 3] > RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8 > dlci 14 frame_type 0 credit_flow 15 pri 0 ack_timer 0 frame_size 660 > max_retrans 0 credits 4 > < ACL data: handle 0x0028 flags 0x02 dlen 18 > L2CAP(d): cid 0x47 len 14 [psm 3] > RFCOMM(s): PN RSP: cr 0 dlci 0 pf 0 ilen 10 fcs 0xaa mcc_len 8 > dlci 14 frame_type 0 credit_flow 14 pri 0 ack_timer 0 frame_size 660 > max_retrans 0 credits 7 > > HCI Event: Number of Completed Packets(0x13) plen 5 > 01 28 00 01 00 here is iPaq and FreeBSD negotiate parameters for multiplexor RFCOMM channel. both systems areed to use credit based flow control. so far so good. > > ACL data: handle 0x0028 flags 0x02 dlen 8 > L2CAP(d): cid 0x56 len 4 [psm 3] > RFCOMM(s): SABM: cr 1 dlci 14 pf 1 ilen 0 fcs 0x6 > < ACL data: handle 0x0028 flags 0x02 dlen 8 > L2CAP(d): cid 0x47 len 4 [psm 3] > RFCOMM(s): UA: cr 1 dlci 14 pf 1 ilen 0 fcs 0xcd here is iPaq finally opens RFCOMM connection on dlci 14 (RFCOMM channel 7). FreeBSD agreed to open RFCOMM channel. > < ACL data: handle 0x0028 flags 0x02 dlen 12 > L2CAP(d): cid 0x47 len 8 [psm 3] > RFCOMM(s): MSC CMD: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2 > dlci 14 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0 > > HCI Event: Number of Completed Packets(0x13) plen 5 > 01 28 00 01 00 > > HCI Event: Number of Completed Packets(0x13) plen 5 > 01 28 00 01 00 > > ACL data: handle 0x0028 flags 0x02 dlen 12 > L2CAP(d): cid 0x56 len 8 [psm 3] > RFCOMM(s): MSC CMD: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2 > dlci 14 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0 > < ACL data: handle 0x0028 flags 0x02 dlen 12 > L2CAP(d): cid 0x47 len 8 [psm 3] > RFCOMM(s): MSC RSP: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2 > dlci 14 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0 > > ACL data: handle 0x0028 flags 0x02 dlen 12 > L2CAP(d): cid 0x56 len 8 [psm 3] > RFCOMM(s): MSC RSP: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2 > dlci 14 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0 > > HCI Event: Number of Completed Packets(0x13) plen 5 > 01 28 00 01 00 this is a sequence of MSC (modem status commands). both system send MSC request and receive MSC responce. so at this point i do not see any problem. RFCOMM connection is established and both system are ready to talk PPP. > > ACL data: handle 0x0028 flags 0x02 dlen 12 > L2CAP(s): Connect req: psm 1 scid 0x0046 > < ACL data: handle 0x0028 flags 0x02 dlen 16 > L2CAP(s): Connect rsp: dcid 0x0057 scid 0x0046 result 0 status 0 > > HCI Event: Number of Completed Packets(0x13) plen 5 > 01 28 00 01 00 now iPaq desides that it wants to open another L2CAP channel to PSM 1 (SDP). FreeBSD agreed to open the channel. > > ACL data: handle 0x0028 flags 0x02 dlen 17 > > ACL data: handle 0x0028 flags 0x01 dlen 3 > L2CAP(s): Config req: dcid 0x0057 flags 0x0000 clen 8 > MTU 256 FlushTO 65535 > < ACL data: handle 0x0028 flags 0x02 dlen 14 > L2CAP(s): Config rsp: scid 0x0046 flags 0x0000 result 0 clen 0 > < ACL data: handle 0x0028 flags 0x02 dlen 12 > L2CAP(s): Config req: dcid 0x0046 flags 0x0000 clen 0 > > HCI Event: Number of Completed Packets(0x13) plen 5 > 01 28 00 01 00 > > HCI Event: Number of Completed Packets(0x13) plen 5 > 01 28 00 01 00 > > ACL data: handle 0x0028 flags 0x02 dlen 14 > L2CAP(s): Config rsp: scid 0x0057 flags 0x0000 result 0 clen 0 yet another sequence where both systems configure new L2CAP channel. everything looks fine to me. > > ACL data: handle 0x0028 flags 0x02 dlen 17 > L2CAP(d): cid 0x57 len 13 [psm 1] > SDP SS Req: tid 0x0 len 0x8 > pat uuid-16 0x1002 (PubBrwsGrp) > max 0x14 > cont 00 > < ACL data: handle 0x0028 flags 0x02 dlen 26 > L2CAP(d): cid 0x46 len 22 [psm 1] > SDP SS Rsp: tid 0x0 len 0x11 > tot 0x3 cur 0x3 hndl 0x0 0x8054030 0x80541f0 > cont 00 now iPaq send another SDP Service Search request. this time iPaq decided to "browse" add SDP services available on the FreeBSD. FreeBSD says there are three records in Public Browse Group. > > HCI Event: Number of Completed Packets(0x13) plen 5 > 01 28 00 01 00 > > ACL data: handle 0x0028 flags 0x02 dlen 17 > > ACL data: handle 0x0028 flags 0x01 dlen 6 > L2CAP(d): cid 0x57 len 19 [psm 1] > SDP SA Req: tid 0x1 len 0xe > hndl 0x0 > max 0xf0 > aid(s) 0x0000 - 0xffff > cont 00 > < ACL data: handle 0x0028 flags 0x02 dlen 154 > L2CAP(d): cid 0x46 len 150 [psm 1] > SDP SA Rsp: tid 0x1 len 0x91 > cnt 0x8e > aid 0x0000 (SrvRecHndl) > uint 0x0 > aid 0x0001 (SrvClassIDList) > < uuid-16 0x1000 (SDServer) > > aid 0x0003 (SrvID) > uuid-16 0x0001 (SDP) > aid 0x0004 (ProtocolDescList) > < < uuid-16 0x0100 (L2CAP) uint 0x1 uint 0x1 > > > aid 0x0005 (BrwGrpList) > < uuid-16 0x1002 (PubBrwsGrp) > > aid 0x0006 (LangBaseAttrIDList) > < uint 0x656e uint 0x6a uint 0x100 > > aid 0x0100 (SrvName) > str "SDP Server" > aid 0x0101 (SrvDesc) > str "Bluetooth service discovery server" > aid 0x0102 (ProviderName) > str "BlueZ" > aid 0x0200 (VersionNumList) > < uint 0x100 > > aid 0x0201 (SrvDBState) > uint 0x3f5f9cc2 > > cont 00 > > HCI Event: Number of Completed Packets(0x13) plen 5 > 01 28 00 01 00 here is iPaq requests add SDP attribute for record with handle 0x0. FreeBSD sends SDP attributes back. > > ACL data: handle 0x0028 flags 0x02 dlen 23 > L2CAP(d): cid 0x57 len 19 [psm 1] > SDP SA Req: tid 0x2 len 0xe > hndl 0x8054030 > max 0xf0 > aid(s) 0x0000 - 0xffff > cont 00 > < ACL data: handle 0x0028 flags 0x02 dlen 125 > L2CAP(d): cid 0x46 len 121 [psm 1] > SDP SA Rsp: tid 0x2 len 0x74 > cnt 0x71 > aid 0x0000 (SrvRecHndl) > uint 0x8054030 > aid 0x0001 (SrvClassIDList) > < uuid-16 0x1001 (BrwsGrpDesc) > > aid 0x0006 (LangBaseAttrIDList) > < uint 0x656e uint 0x6a uint 0x100 > > aid 0x0100 (SrvName) > str "Public Browse Group Root" > aid 0x0101 (SrvDesc) > str "Root of public browse hierarchy" > aid 0x0102 (ProviderName) > str "BlueZ" > aid 0x0200 (VersionNumList) > uuid-16 0x1002 (PubBrwsGrp) > > cont 00 > > HCI Event: Number of Completed Packets(0x13) plen 5 > 01 28 00 01 00 there is iPaq requests SDP attributes for record handle 0x8054030. FreeBSD sends attribues back. > > ACL data: handle 0x0028 flags 0x02 dlen 23 > L2CAP(d): cid 0x57 len 19 [psm 1] > SDP SA Req: tid 0x3 len 0xe > hndl 0x80541f0 > max 0xf0 > aid(s) 0x0000 - 0xffff > cont 00 > < ACL data: handle 0x0028 flags 0x02 dlen 92 > L2CAP(d): cid 0x46 len 88 [psm 1] > SDP SA Rsp: tid 0x3 len 0x53 > cnt 0x50 > aid 0x0000 (SrvRecHndl) > uint 0x80541f0 > aid 0x0001 (SrvClassIDList) > < uuid-16 0x1102 (LAN) > > aid 0x0004 (ProtocolDescList) > < < uuid-16 0x0100 (L2CAP) > < > uuid-16 0x0003 (RFCOMM) uint 0x7 > > > aid 0x0005 (BrwGrpList) > < uuid-16 0x1002 (PubBrwsGrp) > > aid 0x0009 (BTProfileDescList) > < < uuid-16 0x1102 (LAN) uint 0x100 > > > aid 0x0100 (SrvName) > str "LAN Access over PPP" > > cont 00 > > HCI Event: Number of Completed Packets(0x13) plen 5 > 01 28 00 01 00 and finnaly the same for the last record 0x80541f0. so far so good. remeber we still have open RFCOMM connection. > > ACL data: handle 0x0028 flags 0x02 dlen 12 > L2CAP(s): Disconn req: dcid 0x0057 scid 0x0046 > < ACL data: handle 0x0028 flags 0x02 dlen 12 > L2CAP(s): Disconn rsp: dcid 0x0057 scid 0x0046 > > HCI Event: Number of Completed Packets(0x13) plen 5 > 01 28 00 01 00 here is iPaq disconnects L2CAP channel for SDP. RFCOMM connection is still open. iPaq was clearly looking for something, but what it was looking for? > > ACL data: handle 0x0028 flags 0x02 dlen 14 > L2CAP(d): cid 0x56 len 10 [psm 3] > RFCOMM(d): UIH: cr 1 dlci 14 pf 0 ilen 6 fcs 0xa5 > 43 4C 49 45 4E 54 ok, now we are back to RFCOMM connection. here is iPaq sends a RFCOMM data packet. the sequence is "0x43 0x4C 0x49 0x45 0x4E 0x54", which is a word "CLIENT" > < ACL data: handle 0x0028 flags 0x02 dlen 9 > L2CAP(d): cid 0x47 len 5 [psm 3] > RFCOMM(d): UIH: cr 0 dlci 14 pf 1 ilen 0 fcs 0x63 credits 34 > > HCI Event: Number of Completed Packets(0x13) plen 5 > 01 28 00 01 00 > < ACL data: handle 0x0028 flags 0x02 dlen 73 > L2CAP(d): cid 0x47 len 69 [psm 3] > RFCOMM(d): UIH: cr 0 dlci 14 pf 0 ilen 65 fcs 0x7f > 7E FF 7D 23 C0 21 7D 21 7D 21 7D 20 20 7D 28 7D 22 7D 27 7D > 22 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 21 7D 24 7D 25 DC > 7D 25 7D 26 22 85 2E 69 7D 24 7D 28 C0 25 7D 20 7D 20 7D 23 > E8 7D 36 B4 7E here is FreeBSD gives more RFCOMM credits to iPaq and send RFCOMM data packet with "0x7E 0xFF 0x7D ..." which is clearly a PPP frame. > > HCI Event: Number of Completed Packets(0x13) plen 5 > 01 28 00 01 00 > > ACL data: handle 0x0028 flags 0x02 dlen 9 > L2CAP(d): cid 0x56 len 5 [psm 3] > RFCOMM(d): UIH: cr 1 dlci 14 pf 1 ilen 0 fcs 0xb9 credits 1 > > ACL data: handle 0x0028 flags 0x02 dlen 14 > L2CAP(d): cid 0x56 len 10 [psm 3] > RFCOMM(d): UIH: cr 1 dlci 14 pf 0 ilen 6 fcs 0xa5 > 43 4C 49 45 4E 54 here we receive more RFCOMM credits from iPaq, and iPaq again sends us word "CLIENT" etc. [ i skipped the rest of the dump and PPP config ] > I'm clueless... I hope you might find some time to ponder this! well, from what i can see iPaq is trying to use Windows RAS service, where FreeBSD is configured to use PPP. is iPaq runs on WinCE? you should tell your iPaq to use Unix/PPP *not* Windows/RAS (Remote Access Service). please try this and let me know if it works. thank you very much for your time, help with testing and very good dumps. max __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.comReceived on Fri Sep 12 2003 - 09:47:42 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:22 UTC