Duncan Lithgow wrote:
> Reopening this bug.
>
> In Ubuntu 8.10 (Alpha 6) importing dv over firewire does not "just work" with
> Kino 1.3.0
>
> I'm back at the familiar message: "WARNING: raw1394 kernel module not loaded
> or failure to > read/write /dev/raw1394
>
> My first guess is that this
Kino has not supported video1394 for years. You are meaning dv1394 when
you write "video1394." Also, why do you think I did not enable that
option by default? The answer is that it imposes major usability issues.
The new firewire subsystem and libraw1394 2.0 have resolved the security
issue with u
** Description changed:
- Deleted my post, it was incorrect.
+ Reopening this bug.
+
+ In Ubuntu 8.10 (Alpha 6) importing dv over firewire does not "just work"
+ with Kino 1.3.0
+
+ I'm back at the familiar message: "WARNING: raw1394 kernel module not
+ loaded or failure to read/write /dev/raw13
Security enhanced replacement drivers are being worked on since last
year, but not yet ready for prime time. It is possible with these
drivers to let scripts assign different device file permissions based on
the type of FireWire device ( -> finer grained device security). These
drivers also imple
Capturing DV video over the desktop should be straightforward, just like
downloading pictures from a camera. This is directly related to bug #1, the
Firewire port should be used by applications just like USB port.
--
use /dev/video1394, not /dev/raw1394
https://bugs.launchpad.net/bugs/6290
You
I wrote:
> The unsupported isochronous request types in raw1394 that
> dvgrab 1.x can use alternatively to dvgrab1394
should read "...to dv1394"
> dvgrab-2.1.tgz
should read "dvgrab-2.1.tar.gz"
--
use /dev/video1394, not /dev/raw1394
https://bugs.launchpad.net/bugs/6290
You received this bug n
Jeff, that's evidently a very old version of dvgrab. File a bug for the
dvgrab package --- it should be updated to version 2.1.
Yes, the dv1394 driver will eventually vanish. But there is no date set
for its removal yet; it depends on how fast the new alternative FireWire
stack which was merged
Syslog tells me this (I'm capturing in gutsy using dvgrab), which makes
me wonder if the thing is really fixed. From what I understand, it tells
me that the dv1394 device is not to be used in the near future, making
the whole thing break again? Does this bug need to be reopened?
Aug 2 00:36:37 lo
Fixed in Ubuntu 7.04
** Changed in: kino (Ubuntu)
Status: Confirmed => Fix Released
--
use /dev/video1394, not /dev/raw1394
https://launchpad.net/bugs/6290
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Ubuntu 7.04 and Kino 0.9.2 both use /dev/dv1394/0 which means that this
bug can be closed - so that's what I'm doing. It works fine for me with
my DV Camera capturing over firewire so I guess it works generally. If
you're settings are not using /dev/dv1394/0 then please reopen this bug.
If you have
As I understood it, address based filtering could/would have been done
with the multiple files approach too. However the capabilities based
approach sounds really good. AFAICS it achieves basically the same in a
simpler way. Simpler = more secure.
I think the multi-file approach would allow to ena
I have developed a simple patch for raw1394 that I am just beginning to
test that addresses the raw1394 security issue in a way completely
different than Jody's proposal. One drawback to using many different
device files is the impact of that change on the libraries and
applications that will take
Except if you don't load ohci1394 or load ohci1394 with the parameter
phys_dma=0. Switching physical DMA off will work fine with raw1394,
dv1394, video1394... It will just break sbp2 until I get
http://bugzilla.kernel.org/show_bug.cgi?id=6393 fixed. (It's not high on
my list, and it is a nuisance t
So there we go ;) access to /dev/raw1394 gives you access to the entire
host machine ... which is why only root can do it
--
use /dev/video1394, not /dev/raw1394
https://launchpad.net/bugs/6290
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/u
Yes, you are right. Actually, a cheap setup to achieve #1 by #4 is to
have two FireWire controllers in the PC and connect them.
--
use /dev/video1394, not /dev/raw1394
https://launchpad.net/bugs/6290
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listi
As it was explained to me, it's possible to construct a Firewire device
that "loops back" #4, providing access to the RAM of the machine that
originated the requests.
--
use /dev/video1394, not /dev/raw1394
https://launchpad.net/bugs/6290
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
A note on /dev/raw1394's security implications:
1. You cannot access local memory through raw1394, except for ROMs and
CSRs that are exposed to other nodes any way.
2. It is extremely hard to manipulate data on attached SBP-2 devices
(FireWire storage devices).
3. You can disturb operation of th
** Description changed:
- When trying to import video from an iee1394 device, kino is not able to
- access /dev/raw1394, so by default, if a user wants to import video from
- him/her camera, he/she needs to run kino with sudo o gsudo.
-
- I think that apt should print a warning like "You should d
Using 6.06 with Kino 0.9 the only thing giving me problems is that udev
doesn't seem to create any device node for ieee1394. At least neither
raw1394 nor dv1394 are created until I modprobe them.
Other than that small glitch with udev I can capture with dv1394 without
being root.
Should I file a
19 matches
Mail list logo
