pand/main.c, restore signals for dev-up script

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/

@@ -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);

Hi James,

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 [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

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

Hi James,

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 [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

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

Hi James,

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 [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

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

Hi James,

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 [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

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

Hi James,

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 [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

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

Hi James,

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 [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

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

Hi James,

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 [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

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.

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

James Cameron

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. 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 [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

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

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

James Cameron

Hi James,

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

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 [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

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? ;-)

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

Hi James,

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.

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 [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel