1 |
On 03/10/2014 5:55 AM, Samuli Suominen wrote: |
2 |
> |
3 |
> On 10/03/14 10:48, Joshua Kinard wrote: |
4 |
>> On 03/10/2014 2:59 AM, Alexandre Rostovtsev wrote: |
5 |
>>> On Mon, 2014-03-10 at 01:45 -0400, Alexandre Rostovtsev wrote: |
6 |
>>>> On Sun, 2014-03-09 at 23:22 -0400, Joshua Kinard wrote: |
7 |
>>>>> On 03/08/2014 9:55 PM, Alexandre Rostovtsev wrote: |
8 |
>>>>>> On Sat, 2014-03-08 at 21:23 -0500, Joshua Kinard wrote: |
9 |
>>>>>>> So I want to try and play around with a particular network domination tool |
10 |
>>>>>>> on my home network, Omphalos. However, its current configure script has a |
11 |
>>>>>>> hard dependency on bluetooth.h, part of the net-wireless/bluez package. |
12 |
>>>>>>> |
13 |
>>>>>>> Currently, net-wireless/bluez has a harddep on virtual/udev, which works |
14 |
>>>>>>> great if you use either udev or eudev. I'm using busybox's mdev instead, so |
15 |
>>>>>>> the logic of the bluez ebuild needs some changes: |
16 |
>>>>>> [...] |
17 |
>>>>>>> Thoughts on this? |
18 |
>>>>>> Does mdev have any API which is equivalent to libudev's hwdb? See |
19 |
>>>>>> http://www.freedesktop.org/software/systemd/libudev/libudev-udev-hwdb.html |
20 |
>>>>>> |
21 |
>>>>>> If yes, then optimal solution would be to patch bluez to allow using |
22 |
>>>>>> mdev's hwdb support, and get the patch upstreamed :) |
23 |
>>>>> It's actually not a matter of the hwdb support, it's just the fact that |
24 |
>>>>> bluez currently has a harddep on a specific device manager, either udev or |
25 |
>>>>> eudev. |
26 |
>>>> Bluez does not require an abstract device manager. It requires the |
27 |
>>>> libudev library. Or rather, it requires some kind of library which |
28 |
>>>> provides the following API: |
29 |
>>>> |
30 |
>>>> 1. querying hwdb (given a kernel modalias for a device, retrieve |
31 |
>>>> corresponding oui, vendor, and model data); and |
32 |
>>>> 2. querying the device tree (manually traversing /sys is of course |
33 |
>>>> possible, but not very easy to do correctly, so bluez developers are |
34 |
>>>> relying on libudev). |
35 |
>>> And by "requires", I mean that without libudev, a variety of bluetooth |
36 |
>>> devices and adapters will simply fail to work. |
37 |
>>> |
38 |
>>> So if mdev does not have some equivalent of libudev, a reasonable |
39 |
>>> solution would probably be the following: |
40 |
>>> |
41 |
>>> @@ -14,19 +14,19 @@ |
42 |
>>> LICENSE="GPL-2+ LGPL-2.1+" |
43 |
>>> SLOT="0/3" |
44 |
>>> KEYWORDS="~amd64 ~arm ~hppa ~ppc ~ppc64 ~x86" |
45 |
>>> -IUSE="cups debug +obex readline selinux systemd test" |
46 |
>>> +IUSE="cups debug +obex readline selinux systemd test +udev" |
47 |
>>> REQUIRED_USE="test? ( ${PYTHON_REQUIRED_USE} )" |
48 |
>>> |
49 |
>>> RDEPEND=" |
50 |
>>> >=dev-libs/glib-2.28:2 |
51 |
>>> >=sys-apps/dbus-1.6:= |
52 |
>>> >=sys-apps/hwids-20121202.2 |
53 |
>>> - >=virtual/udev-171 |
54 |
>>> cups? ( net-print/cups:= ) |
55 |
>>> obex? ( dev-libs/libical ) |
56 |
>>> readline? ( sys-libs/readline:= ) |
57 |
>>> selinux? ( sec-policy/selinux-bluetooth ) |
58 |
>>> systemd? ( sys-apps/systemd ) |
59 |
>>> + udev? ( >=virtual/udev-171 ) |
60 |
>>> " |
61 |
>>> DEPEND="${RDEPEND} |
62 |
>>> virtual/pkgconfig |
63 |
>>> @@ -46,6 +46,11 @@ |
64 |
>>> pkg_setup() { |
65 |
>>> enewgroup plugdev |
66 |
>>> use test && python-any-r1_pkg_setup |
67 |
>>> + |
68 |
>>> + if ! use udev; then |
69 |
>>> + ewarn "You are installing ${P} with USE=-udev. This means various bluetooth" |
70 |
>>> + ewarn "devices and adapters from Apple, Dell, Logitech etc. will fail to work." |
71 |
>>> + fi |
72 |
>>> } |
73 |
>>> |
74 |
>>> src_prepare() { |
75 |
>>> @@ -92,13 +97,13 @@ |
76 |
>>> $(use_enable test) \ |
77 |
>>> --enable-tools \ |
78 |
>>> --enable-monitor \ |
79 |
>>> - --enable-udev \ |
80 |
>>> + $(use_enable udev) \ |
81 |
>>> $(use_enable cups) \ |
82 |
>>> $(use_enable obex) \ |
83 |
>>> --enable-client \ |
84 |
>>> $(use_enable systemd) \ |
85 |
>>> $(systemd_with_unitdir) \ |
86 |
>>> - --enable-sixaxis |
87 |
>>> + $(use_enable udev sixaxis) |
88 |
>>> } |
89 |
>>> |
90 |
>>> src_install() { |
91 |
>>> @@ -134,7 +139,7 @@ |
92 |
>>> pkg_postinst() { |
93 |
>>> readme.gentoo_print_elog |
94 |
>>> |
95 |
>>> - udev_reload |
96 |
>>> + use udev && udev_reload |
97 |
>>> |
98 |
>>> has_version net-dialup/ppp || elog "To use dial up networking you must install net-dialup/ppp." |
99 |
>>> |
100 |
>> Hey, this sounds like it'll work in my case :) |
101 |
>> |
102 |
>> I don't use bluetooth, nor udev, so the issues surrounding making udev |
103 |
>> optional in bluez or not isn't really my concern. Making udev optional was |
104 |
>> the easier solution than trying to figure out how to cut out the lib/ folder |
105 |
>> from bluez and wrapping it in a separate libbluetooth package. Thought I'd |
106 |
>> just suggest the solution to the list for input. |
107 |
>> |
108 |
> |
109 |
> You know, you can have udev installed (to have libudev installed) but |
110 |
> still run something else, like mdev |
111 |
> It would likely still work for this case even if udevd daemon isn't running |
112 |
> |
113 |
> And yes, I realize it's not perfect for some embedded systems |
114 |
|
115 |
Except the tool I wanted to test out, Omphalos, doesn't need _anything_ from |
116 |
udev or libudev. It wants bluetooth.h and probably whatever .so/.a files |
117 |
are tied to that specific header: |
118 |
|
119 |
""" |
120 |
A tool for network enumeration, protection, observation and domination. |
121 |
Omphalos makes use of passive and active portscanning, DNS/DHCP/Zeroconf |
122 |
server interrogation, portknock detection, covert channel detection and |
123 |
establishment, ARP scanning, automatic WEP cracking, man-in-the-middling, |
124 |
and a whole host of other tricks. GPS integration? Oh yes. Coordination |
125 |
across multiple interfaces? Of course. Use of Linux's MMAP_RX_SOCKET and |
126 |
MMAP_TX_SOCKET? Wouldn't have it any other way. Userspace networking is made |
127 |
visible to the host via a TUN/TAP device. While designed as an offensive |
128 |
tool, omphalos has proven useful for network debugging and troubleshooting, |
129 |
as well as experimentation. |
130 |
|
131 |
Omphalos is not a "point-and-click" tool so much as "pull the pin" or |
132 |
perhaps "spray the area". Default behavior is to redirect and seize all |
133 |
traffic, attack weak cryptosystems, archive authentication materials, and |
134 |
learn everything that can be learned. |
135 |
""" |
136 |
|
137 |
It's bluez that wants to invite the entire udev/systemd party in, because of |
138 |
the virtual/udev harddep. So, I modded a local copy of bluez to not need |
139 |
virtual/udev initially so I could get past Omphalos' bluetooth build |
140 |
requirement. But I got stopped by the need for wireless, which is not in |
141 |
the kernel running on my main Linux machine (Ethernet II only, weee). |
142 |
|
143 |
I thought I'd at least make the udev hacks to my bluez ebuild a little |
144 |
cleaner and submit them for inclusion in the tree, cause generally, there's |
145 |
nothing wrong about making udev optional where it's supported to be optional |
146 |
(as evidenced by bluez's --enable-udev switch to configure). |
147 |
|
148 |
|
149 |
The other option is to split the files in bluez's lib/ directory off into |
150 |
their own libbluetooth package. Maybe there's other packages in the tree |
151 |
that just need bluetooth.h and not the entire kitten kaboodle that is bluez. |
152 |
Then bluez can keep its udev harddep and have bluez/libbluetooth block each |
153 |
other and call it a day. |
154 |
|
155 |
Or we can just do nothing. I'll just keep my modded bluez ebuild around for |
156 |
testing things locally. |
157 |
|
158 |
-- |
159 |
Joshua Kinard |
160 |
Gentoo/MIPS |
161 |
kumba@g.o |
162 |
4096R/D25D95E3 2011-03-28 |
163 |
|
164 |
"The past tempts us, the present confuses us, the future frightens us. And |
165 |
our lives slip away, moment by moment, lost in that vast, terrible in-between." |
166 |
|
167 |
--Emperor Turhan, Centauri Republic |