[Bluez-devel] [PATCH] pand/main.c, restore signals for dev-up script

[Bluez-devel] [PATCH] pand/main.c, restore signals for dev-up script

[James Cameron]

[-- Attachment #1.1: Type: text/plain, Size: 2363 bytes --]

Problem: pand dev-up script on Debian fails to "ifup bnep0", the error
is "Failed to bring up bnep0".

Diagnosis: dev-up script inherits the SIG_IGN of SIGCHLD and SIGPIPE
done by pand/main.c, in addition to some open sockets.  The ifup program
requires signals in default state.

Solution: restore signals to SIG_DFL, close some of the sockets.  A
patch for this is attached, less comments.  The patch applies cleanly to
both the Debian revision of pand/main.c 1.3, and to the current revision
1.4 in CVS.


Discussion:

Restoring the signals takes a call to sigaction() after fork() but
before exec().  This call undoes the initialisation call in main().

Closing the sockets can be done automatically on fork(), or manually.
My patch does it manually.

Closing the sockets automatically would require setting FD_CLOEXEC on
them after they are created.  fcntl(sk, F_SETFD, FD_CLOEXEC);

Closing the sockets manually requires the socket file descriptors to be
sent to run_devup(); this seems ugly to me, I'm not altogether happy
with the way I've done it and I hope the maintainer will rethink this
for me.  Perhaps making the socket numbers global would make more sense.

Even then, tests show that there are *three* file descriptors inherited
by the dev-up script, and I've only been able to find two.  Hopefully
the maintainer knows where the other one is; bnep_init()?

Here's how I found the open sockets ... (a) place a "sleep 30m" in
dev-up, (b) cause pand to run dev-up, (c) find pid of sleep, (d) run
lsof -p ...

sleep   16393 root    0u   CHR    1,3         163834 /dev/null
sleep   16393 root    1w   REG    3,4     258  48965 /tmp/dev-up.16391.log
sleep   16393 root    2w   REG    3,4     258  48965 /tmp/dev-up.16391.log
sleep   16393 root    3u  sock    0,4           4477 can't identify protocol
sleep   16393 root    5u  sock    0,4           4480 can't identify protocol
sleep   16393 root    6u  sock    0,4          27277 can't identify protocol

The signals were found using "cat /proc/${pid}/status", and confirmed
with strace.

Please let me know if my patch is applied.  Thanks!

-- 
James Cameron                         http://quozl.netrek.org/
HP Open Source, Volunteer             http://opensource.hp.com/
PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/

[-- Attachment #1.2: pand-256436.patch --]
[-- Type: text/plain, Size: 1132 bytes --]

--- bluez-utils-2.7/pand/main.c	2004-05-09 20:39:43.000000000 +1000
+++ bluez-utils-2.7-4-jc1/pand/main.c	2004-06-27 23:02:00.000000000 +1000
@@ -84,9 +84,10 @@
 	KILL
 } modes;
 
-static void run_devup(char *dev, char *dst)
+static void run_devup(char *dev, char *dst, int sk, int nsk)
 {
 	char *argv[4], prog[40];
+	struct sigaction sa;
 
 	sprintf(prog, "%s/%s", PAND_CONFIG_DIR, PAND_DEVUP_CMD);
 
@@ -96,6 +97,15 @@
 	if (fork())
 		return;
 
+	close(sk);
+	if (nsk != -1)
+		close(nsk);
+	
+	memset(&sa, 0, sizeof(sa));
+	sa.sa_handler = SIG_DFL;
+	sigaction(SIGCHLD, &sa, NULL);
+	sigaction(SIGPIPE, &sa, NULL);
+
 	argv[0] = prog;
 	argv[1] = dev;
 	argv[2] = dst;
@@ -184,7 +194,7 @@
 
 			syslog(LOG_INFO, "New connection from %s %s", str, netdev);
 
-			run_devup(netdev, str);
+			run_devup(netdev, str, sk, nsk);
 		} else {
 			syslog(LOG_ERR, "Connection failed. %s(%d)",
 					strerror(errno), errno);
@@ -274,7 +284,7 @@
 
 		syslog(LOG_INFO, "%s connected", netdev);
 
-		run_devup(netdev, dst);
+		run_devup(netdev, dst, sk, -1);
 
 		if (persist)
 			w4_hup(sk);

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Bluez-devel] [PATCH] pand/main.c, restore signals for dev-up script

[Marcel Holtmann]

Hi James,

> Problem: pand dev-up script on Debian fails to "ifup bnep0", the error
> is "Failed to bring up bnep0".

what about removing that code from pand? We can use the net.agent script
from hotplug to actually do the same job.

Regards

Marcel




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] [PATCH] pand/main.c, restore signals for dev-up script

[James Cameron]

G'day Marcel,

Thanks for the reply.  I wasn't aware of the net.agent script in
hotplug.  Now that you've drawn my attention to it, I see it should
work.  The Debian package provides /usr/share/doc/hotplug/README.Debian
which explains how to use it.  I'll give it a try.

As for removing the code in order to rely on hotplug, I don't like that
because I've got some small disk and small memory systems that I'd like
to configure statically.

-- 
James Cameron

Re: [Bluez-devel] [PATCH] pand/main.c, restore signals for dev-up script

[Marcel Holtmann]

Hi James,

> As for removing the code in order to rely on hotplug, I don't like that
> because I've got some small disk and small memory systems that I'd like
> to configure statically.

you can do this by replacing net.agent script or using some other
hotplug implementations like dietHotplug. I never used the dev-up script
and as you wrote that you had problems with it, I better should remove
that code. However I also don't have a problem with applying your patch
at the moment to close the bug.

Regards

Marcel




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] [PATCH] pand/main.c, restore signals for dev-up script

[James Cameron]

Just a quick followup question, now that I've read the net.agent script
and the README.Debian in the hotplug package ... doesn't this only
address the creation of the bnep0 interface when a Bluetooth dongle is
plugged in?

In my situation, the dongle is always plugged in, but without a network
interface most of the time.

pand is running --listen --role NAP, and receives a call from one of my
other computers.  pand accepts the connection, and invokes dev-up which
brings up bnep0 with "ifup $1".

-- 
James Cameron

Re: [Bluez-devel] [PATCH] pand/main.c, restore signals for dev-up script

[Marcel Holtmann]

Hi James,

> Just a quick followup question, now that I've read the net.agent script
> and the README.Debian in the hotplug package ... doesn't this only
> address the creation of the bnep0 interface when a Bluetooth dongle is
> plugged in?
> 
> In my situation, the dongle is always plugged in, but without a network
> interface most of the time.
> 
> pand is running --listen --role NAP, and receives a call from one of my
> other computers.  pand accepts the connection, and invokes dev-up which
> brings up bnep0 with "ifup $1".

No. The bnep0 interface is only created when there is a PAN connection
between two devices. No connection, no network interface.

Regards

Marcel




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] [PATCH] pand/main.c, restore signals for dev-up script

[James Cameron]

On Mon, Jun 28, 2004 at 11:05:18AM +0200, Marcel Holtmann wrote:
> > Just a quick followup question, now that I've read the net.agent script
> > and the README.Debian in the hotplug package ... doesn't this only
> > address the creation of the bnep0 interface when a Bluetooth dongle is
> > plugged in? [...]
> 
> No. The bnep0 interface is only created when there is a PAN connection
> between two devices. No connection, no network interface.

What I didn't know and have now learned was that pand's creation of the
bnep0 interface is a hotplug event, despite there being no actual
physical action.

I've got it working using net.agent and not using dev-up.  Now the
Debian /etc/network/interfaces file looks like this;

mapping hotplug
	script echo

and I had to create a file so that it would take bnep0 down afterwards;

# touch /etc/hotplug/net.enable


But dev-up is given the peer's Bluetooth device address.  net.agent is not
given this.  Can it be determined from just the interface name?  I could
do a "hcitool con" if I knew what the right hci device number was, but
it seems sensible to have the dev-up script provide the knowledge.

-- 
James Cameron

Re: [Bluez-devel] [PATCH] pand/main.c, restore signals for dev-up script

[Marcel Holtmann]

Hi James,

> But dev-up is given the peer's Bluetooth device address.  net.agent is not
> given this.  Can it be determined from just the interface name?  I could
> do a "hcitool con" if I knew what the right hci device number was, but
> it seems sensible to have the dev-up script provide the knowledge.

it is the same as the ethernet address of the bnep0 interfaces.

Regards

Marcel




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] [PATCH] pand/main.c, restore signals for dev-up script

[James Cameron]

On Mon, Jun 28, 2004 at 12:13:49PM +0200, Marcel Holtmann wrote:
> > But dev-up is given the peer's Bluetooth device address.  net.agent is not
> > given this.  Can it be determined from just the interface name?  I could
> > do a "hcitool con" if I knew what the right hci device number was, but
> > it seems sensible to have the dev-up script provide the knowledge.
> 
> it is the same as the ethernet address of the bnep0 interfaces.

No, it isn't.  You're thinking of the local device address.  I'm talking
about the peer's address, which is passed to dev-up by pand.

While the bnep0 interface on the peer has the address, that doesn't
help the local host get it.

Here's output that demonstrates the difference:

# ifconfig bnep0
bnep0     Link encap:Ethernet  HWaddr 00:02:72:01:E5:FF  
          inet addr:10.2.0.1  Bcast:10.255.255.255  Mask:255.255.255.0
          inet6 addr: fe80::202:72ff:fe01:e5ff/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11 errors:0 dropped:0 overruns:0 frame:0
          TX packets:17 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:761 (761.0 b)  TX bytes:1100 (1.0 KiB)

# hcitool dev
Devices:
        hci0    00:02:72:01:E5:FF
# hcitool con
Connections:
        > ACL 00:02:72:01:E5:F5 handle 42 state 1 lm SLAVE 
#  

-- 
James Cameron

Re: [Bluez-devel] [PATCH] pand/main.c, restore signals for dev-up script

[Marcel Holtmann]

Hi James,

> > > But dev-up is given the peer's Bluetooth device address.  net.agent is not
> > > given this.  Can it be determined from just the interface name?  I could
> > > do a "hcitool con" if I knew what the right hci device number was, but
> > > it seems sensible to have the dev-up script provide the knowledge.
> > 
> > it is the same as the ethernet address of the bnep0 interfaces.
> 
> No, it isn't.  You're thinking of the local device address.  I'm talking
> about the peer's address, which is passed to dev-up by pand.
> 
> While the bnep0 interface on the peer has the address, that doesn't
> help the local host get it.

sorry. I mixed them up. The remote address is available via "pand -l".

Regards

Marcel




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] [PATCH] pand/main.c, restore signals for dev-up script

[James Cameron]

On Mon, Jun 28, 2004 at 12:39:57PM +0200, Marcel Holtmann wrote:
> [...] The remote address is available via "pand -l".

Neat.  Another way to get it.  ;-)  But this way activates pand again,
so dev-up remains the most efficient way to get this address.

-- 
James Cameron

Re: [Bluez-devel] [PATCH] pand/main.c, restore signals for dev-up script

[Marcel Holtmann]

Hi James,

> > [...] The remote address is available via "pand -l".
> 
> Neat.  Another way to get it.  ;-)  But this way activates pand again,
> so dev-up remains the most efficient way to get this address.

what do you wanna do with that information? Actually I never needed it.

Regards

Marcel




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] [PATCH] pand/main.c, restore signals for dev-up script

[James Cameron]

On Mon, Jun 28, 2004 at 02:54:31PM +0200, Marcel Holtmann wrote:
> what do you wanna do with that information? Actually I never needed it.

Select access policies.  Probably not a terribly reliable access
control, but at least ringing alarms if I sight a connection from an
unexpected address would be useful.

I'm using 100m range modules in a rural environment, on top of a
mountain.

See http://quozl.netrek.org/bluetooth/ for the coverage mapping that I
did; it was quite enjoyable.  Some of the configuration information
there is out of date; I haven't reviewed it in light of the current
Debian package versions.

-- 
James Cameron

Re: [Bluez-devel] [PATCH] pand/main.c, restore signals for dev-up script

[Marcel Holtmann]

Hi James,

> > what do you wanna do with that information? Actually I never needed it.
> 
> Select access policies.  Probably not a terribly reliable access
> control, but at least ringing alarms if I sight a connection from an
> unexpected address would be useful.

from my view it is better to use "net.agent" and "pand -l" for this job.
If it gets to complex then you should integrate it directly into pand.

Regards

Marcel




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] [PATCH] pand/main.c, restore signals for dev-up script

[James Cameron]

On Tue, Jun 29, 2004 at 01:26:17AM +0200, Marcel Holtmann wrote:
> from my view it is better to use "net.agent" and "pand -l" for this job.

Yes, I know.  I don't know why you think that though, since using dev-up
costs less in dependencies and execution time.  You've proposed removing
dev-up on the grounds that I had problems with it, and that you've never
used it; which suggests that you think that cost of maintenance is more
critical.  I'm just guessing.

> If it gets to complex then you should integrate it directly into pand.

dev-up is integrated directly into pand.  ;-)

-- 
James Cameron

Re: [Bluez-devel] [PATCH] pand/main.c, restore signals for dev-up script

[Marcel Holtmann]

Hi James,

> > from my view it is better to use "net.agent" and "pand -l" for this job.
> 
> Yes, I know.  I don't know why you think that though, since using dev-up
> costs less in dependencies and execution time.  You've proposed removing
> dev-up on the grounds that I had problems with it, and that you've never
> used it; which suggests that you think that cost of maintenance is more
> critical.  I'm just guessing.

I like to have only one and clear way to achieve a goal. And this is the
Linux hotplug mechanism from my view. However dev-up is in pand and
there was a bug, so I applied your patch. But be aware of that I might
remove it in a new major release, now I know of it ;)

Regards

Marcel




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] [PATCH] pand/main.c, restore signals for dev-up script

[James Cameron]

On Tue, Jun 29, 2004 at 10:58:01AM +0200, Marcel Holtmann wrote:
> I like to have only one and clear way to achieve a goal. And this is the
> Linux hotplug mechanism from my view. However dev-up is in pand and
> there was a bug, so I applied your patch.

It's not in CVS yet.  An update of main.c takes me to revision 1.5,
which was the "olen = sizeof(l2o);" addition.

> But be aware of that I might remove it in a new major release, now I
> know of it ;)

Oh dear.  I'll keep watch then, and fork if I have to.  ;-)

-- 
James Cameron

Re: [Bluez-devel] [PATCH] pand/main.c, restore signals for dev-up script

[Marcel Holtmann]

Hi James,

> > I like to have only one and clear way to achieve a goal. And this is the
> > Linux hotplug mechanism from my view. However dev-up is in pand and
> > there was a bug, so I applied your patch.
> 
> It's not in CVS yet.  An update of main.c takes me to revision 1.5,
> which was the "olen = sizeof(l2o);" addition.

the anonymous CVS is not updated in real time. It is a Sourceforge
problem and the only thing you can do is wait :(

> > But be aware of that I might remove it in a new major release, now I
> > know of it ;)
> 
> Oh dear.  I'll keep watch then, and fork if I have to.  ;-)

Or come up with a solution that makes the peer address available through
hotplug and net.agent.

Regards

Marcel




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] [PATCH] pand/main.c, restore signals for dev-up script

[James Cameron]

On Tue, Jun 29, 2004 at 01:26:43PM +0200, Marcel Holtmann wrote:
> the anonymous CVS is not updated in real time. It is a Sourceforge
> problem and the only thing you can do is wait :(

Ah, okay, I see your commit now, on 1.6 08:53:29 UTC.  SourceForge had
told me they were updating anonymous CVS in real-time, and I thought I
had observed it on my projects (pptpclient, poptop).  Maybe they haven't
finished enabling it.

I cross checked your patch and it looks fine.  When's the next release?
;-)

> Or come up with a solution that makes the peer address available through
> hotplug and net.agent.

Is the peer ba kept in bnep0 structure somewhere?  Isn't bnep0
effectively a point to point link?  ppp0 for example, shows the peer IP
address yet bnep0 doesn't.

Yes, I can get the ba from "pand -l|grep bnep0", or broadcast pinging
the bnep0 subnet and using "arp" to read the ba.

-- 
James Cameron

Re: [Bluez-devel] [PATCH] pand/main.c, restore signals for dev-up script

[Marcel Holtmann]

Hi James,

> I cross checked your patch and it looks fine.  When's the next release?
> ;-)

actually it is your patch. I only changed the check for a "non-valid"
socket descriptor. It is a little bit more general this way.

Depends on how fast I am able to implement a quirk for the EPoX HID
keyboard.

> Is the peer ba kept in bnep0 structure somewhere?  Isn't bnep0
> effectively a point to point link?  ppp0 for example, shows the peer IP
> address yet bnep0 doesn't.

It is in dst[] in the ioctl structures and we store it in eh.h_source of
the session structure.

The BNEP connections are really point-to-point, but they are still an
ethernet emulation. So they must look like an ethernet card.

Regards

Marcel




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel