[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bluetooth-dev] Connection management problem : modifications + bug corrected



These are the changes :

In rfcomm.c around line 1240, when we receive a DISConnect packet :


	case DISC:
		D_CTRL(FNC"DISC packet received\n");
		if (crc_check(data, LONG_CRC_CHECK, short_pkt->data[0]) < 0) {
			break;
		}
		rfcomm = ((rfcomm_con*) l2cap->upper_con);
		/* When the serverchannel is closing the whole connection
		   should be removed */
		if (rfcomm->dlci[tmp_dlci].state == DISCONNECTED) {
			send_dm(rfcomm, tmp_dlci);
		} else if ((short_pkt->h.addr.server_chn) == 0) {
			rfcomm->dlci[0].state = DISCONNECTED;
			/* FIXME:
			   Tell the tty that the link is down */
			printk("RFCOMM control ch disconnected (remotely)\n");
			send_ua(rfcomm, 0);
#ifdef __KERNEL__
			bt_unregister_rfcomm(rfcomm->line);
#endif
		} else {
			rfcomm->dlci[tmp_dlci].state = DISCONNECTED;
			send_ua(rfcomm, tmp_dlci);
			D_CTRL("dlci %d was disconnected\n", tmp_dlci);
			bt_disconnect_ind(CREATE_RFCOMM_ID(rfcomm->line, 
							   tmp_dlci));
//dli
#ifdef __KERNEL__
			bt_unregister_rfcomm(rfcomm->line);
#endif
		}
		D_CTRL(FNC"DISC, sending back UA\n");
    
		break;

in bluetooth.c around line 2741 :

s32
bt_unregister_rfcomm(s32 line)
{
	BT_DRIVER("bt_unregister_rfcomm : line %d\n", line);	

	if (SESSIONSTATE(line) == BT_ACTIVE) {
		bt_ctrl.session[line].rfcomm = 0; 
		bt_ctrl.session[line].dlci = 0;

		/* FIXME -- should rfcomm always send bt_hangupline 
		   when disconnecting ? */

                BT_DRIVER("Upper tty still open...\n");
                SESSIONSTATE(line) = BT_UPPERCONNECTED;
		NBR_ACTIVE--;
        } else if (SESSIONSTATE(line) == BT_LOWERCONNECTED) {
		bt_reset_session(line);		
        } else {
		D_WARN("bt_unregister_rfcomm : inactive session\n");
		return -1;
	}

	/* notify upper tty that this rfcomm connection is down */
#ifdef __KERNEL__
	bt_hangupline(line);
#endif
	return 0;
}

In bluetooth.c around line 2818 :

s32
bt_unregister_tty(struct tty_struct *tty, s32 line)
{
	BT_DRIVER("Unregistering tty on line %d\n", line);

	if (line == BT_NBR_PORTS-BT_NBR_CTRLPORTS) {
		if (--NBR_CTRL_FDS != 0)
			return 0; /* still more open fd:s on ttyBTC */
	}

	/* Check that the pid closing is the one that opened the tty */
//dli why ?
/*
	if (current->pid != bt_ctrl.session[line].pid)
	{
		BT_DRIVER(__FUNCTION__" invalid pid\n");
		return -1;
	}
*/
	/* Check that it is ok to close this line ... 
	   (flush buffers etc etc etc) */

	if ((SESSIONSTATE(line) == BT_ACTIVE) || 
	    (SESSIONSTATE(line) == BT_UPPERCONNECTED)) 
  {
    if (SESSIONSTATE(line) == BT_ACTIVE) 
    {
			SESSIONSTATE(line) = BT_LOWERCONNECTED;
			NBR_ACTIVE--;
		}
    else
      bt_reset_session(line);

		NBR_UPPER--;
	}
	else 
  {
		D_WARN("bt_unregister_tty : tty not prev registered\n");
		return -ENODEV;
	}
	return 0; /* Until the above is fixed */
}

Remark on this last modification :

Why should the pid be the same ? On my application, this test fails causing 
the kernel to crash when the tty is tried to be opened...

This has been tested opening and closing RFCOMM and ppp in anyorder in 
point-to-multipoint with three terminals connected simultaneously.

David.


Le Mardi 31 Juillet 2001 11:28, Mattias Ågren a écrit :
> > I think we should modify the way the SESSIONSTATE is handled
> > in the kernel
> > part of the stack. When the stack receives an RFCOMM
> > connection/disconnection
> > request on a non 0 dlci, it should call
> > bt_register_rfcomm/bt_unregister_rfcomm. These functions
> > should not be called
> > when dlci == 0 because anyway, no tty data will ever go thru
> > this rfcomm
> > connection.
>
> True, however bt_register_rfcomm... is only called when a data
> dlci is connected. However, we should change the unregister part
> to when the data channel disconnects instead. David, can you try
> this out and post a patch ?
>
> > David.
> > -
>
> brgds
> Mattias
> -
> To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
> the body of a message to majordomo@xxxxxxx.com
-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com