Re: bluetoothd-service-network fails to execute ifup scripts from network.conf after repeated connection attempts (Patched)

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

 





On Wed, Apr 30, 2008 at 5:06 AM, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote:
Hello,

On Tue, Apr 29, 2008 at 5:42 PM, Valmantas <walmis@xxxxxxxxx> wrote:
> After connecting to a server once, the relevent scripts in network.conf
>  are executed, and pan* and bnep* interfaces come up, but when you
>  disconnect and
>  reconnect the second time, neither the script gets executed, nor the
>  interface comes up and this makes the connection unusable. (You would
>  have to manually bring it up with "ifconfig bnep0 up" )

The bridge on server side was already up I supposed, so it is pointless to
execute the script again and again, but you may have found a bug on
client side if what you are saying is that the bnep interface does not
come up a second time.

Yes, bridges should come up only once and nope, not on the client side, the server side, the bnepX in the bridge does not come up after the first reconnect. Spent hours figuring out why there was no network with my PDA, and ifconfig bnep0 up done the trick.


>  Correct behaviour:
>  Connection 1 ( server pan0 (GN) )
>   my-ifup gets executed with pan0 argument
>   my-ifup gets executed with bnep0 argument
>
>  Disconnect / Connect 2 ( server pan0 (GN) )
>   my-ifup gets executed with bnep0 argument
>
>  Disconnect / Connect 3 ( server pan0 (GN) )
>   my-ifup gets executed with bnep0 argument
>

No need to execute any script on bnepX at all, you seems to actually
misunderstood the way it should goes, each bnepX interface always
execute the PANU script on client side, on server it is the same if the
role is PANU, GN and NAP uses bridges so the bnepX doesn't need any
configuration besides bring them up, thats why there is a bnep_if_up(dev, 0)
where 0 means do not execute any script as this interface will be added
to a bridge.

There's a bonus, this way you can know when a client has connected and do some stuff. To my knowledge this is the only way. Unless someone develops dbus signals for this. Well, it's not THAT necessary, but fixing the bug i mentioned above in this email is.
 


ps: it really helps if you include what version are you testing and what network
service is printing.

Sorry i forgot, it's bluez-utils 3.26 and i'll provide output later



--
Luiz Augusto von Dentz
Engenheiro de Computação
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Bluez-devel mailing list
Bluez-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/bluez-devel

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Bluez-devel mailing list
Bluez-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/bluez-devel

[Index of Archives]     [Linux Bluetooth Devel]     [Linux USB Devel]     [Network Devel]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux