DV capture over Firewire is broken (no rights for /dev/raw1394)

mojopikon: which version of Ubuntu and kino do you use? Martin: how do we take care of /dev/raw1394? Which group is it? plugdev?

I use Ubuntu Breezy and the Kino version currently released with Breezy.

2006/1/2, Daniel Holbach <email address hidden>:
>
> Public bug report changed:
> https://launchpad.net/malone/bugs/6290
>
> Comment:
> mojopikon: which version of Ubuntu and kino do you use? Martin: how do
> we take care of /dev/raw1394? Which group is it? plugdev?
>

I remember that discussion.

/dev/raw1394 should not be accessible for normal users at all, since this would allow them to spy at/tamper with firewire network cards, firewire drives etc. as well. The proper device that should be used by applications is /dev/video1394, but from what I have heard this has some limitations.

So what should happen is: the kino guys should sit together with the kernel guys and negotiate a sensible interface for /dev/video1394, and the raw device should be left alone.

From my understanding, any device on the firewire bus has the ability to execute a powerful bytecode on the host (including the host device itself). Apparently, giving someone access to /dev/raw1394 gives them root (if they're crafty enough).

:~$ ls -al /dev/raw1394
crw-rw---- 1 root disk 171, 0 2006-04-07 22:37 /dev/raw1394

Once I added the user to 'disk' group, Kino was able to import video. This is a single (human) user laptop. What are the security implications of allowing this?

Or, is there a way to force Kino to use /dev/video1394 instead?

@Alan: adding your user to group 'disk' essentially means that you are working as root, so every program that you run can potentially tamper with your whole system (see my previous comment).

I have no idea about kino itself, but it should be fixed to use /dev/video1394.

People who have no idea what they are talking about when it comes to Linux 1394 should not be trusted as an authority in this matter. What is so difficult about creating a group named "raw1394" and assigning group ownership of /dev/raw1394 to it? Then, any user who trusts themselves on their own computer can add themself to the group and not be co-mingled with disk members. BTW, this issue not only affects Kino, but also Ekiga (through vidinput_avc), Coriander, and any up and coming editor using gstreamer such as Pitivi and Diva.

Dan,

right, I have no idea about firewire video editing, but I believe I have some idea about system security. A group 'raw1394' wouldn't change all that much, since it still leaves loopholes to get full root privileges. If you trust your computer, then people can already run kino etc. as root.

The real solution is to provide a proper interface by the kernel.

Thank you for not revolting at my tone in my earlier response. I agree we need to improve the kernel interface, and the issue has come up in the linux1394-devel mailing list. However, I do not forsee a solution coming in the near-to-mid-term. In the meantime, I was hoping to give users something more comforting than running as root or adding themself to the disk group. raw1394 group membership is a little more isolated security risk than running as root or belonging to disk. Also, it is a little more obvious. Hopefully, the fact that the user account created at install is not already a member of such group is a reminder of some of the risk.

full ack, but ATM I don't think we should allow access to /dev/raw1394 in a default installation, it's just too dangerous. The easiest way to make it work locally is to change 40-permissions.rules (change the group for 'raw1394' from 'disk' to 'video' or 'plugdev').

I know that this sucks, but I'm afraid there is no sane short-term solution :(

I think that in dapper it needs to use /dev/dv1394-0 rather than raw1394 (which is a security risk).

I had a pretty good chat with Jody McIntyre back in Montreal about the IEE1394 subsystem and what device nodes it exposes. I still think that a USB-alike device node for each interface on each device is the right solution; then we can assign groups and permissions on a per-interface or per-device level.

Hope you don´t mind me asking but could you guide me (and others) on what to
do.
Is it.
1. Low risk - leave raw1394 as disk and don´t allow kino to access raw1394
to control camcorder
2. add user to the ¨disk¨ group - is this v.bad?
3. change raw1394 to video group - " no no no ¨

I´m assuming that acually 2. is worse than 3 as your giving yourself access
to raw1394 plus other areas too. In which case 3 would be an option.

Am I correct in assuming that everyone should go with option 1?

I want to put a section on video editing on the wiki and I want to get this
right.

On 5/25/06, Scott James Remnant <email address hidden> wrote:
>
> I had a pretty good chat with Jody McIntyre back in Montreal about the
> IEE1394 subsystem and what device nodes it exposes. I still think that
> a USB-alike device node for each interface on each device is the right
> solution; then we can assign groups and permissions on a per-interface
> or per-device level.
>
> --
> use /dev/video1394, not /dev/raw1394
> https://launchpad.net/bugs/6290
>

On your own machine, you may do whatever you like -- that's why these things are configuration files. Obviously we have to ship things in a safe configuration.

If the only firewire device you own is a video camera, changing the group of the raw1394 device is probably appropriate.

Many thanks for being so helpful.

On 5/25/06, Scott James Remnant <email address hidden> wrote:
>
> On your own machine, you may do whatever you like -- that's why these
> things are configuration files. Obviously we have to ship things in a
> safe configuration.
>
> If the only firewire device you own is a video camera, changing the
> group of the raw1394 device is probably appropriate.
>
> --
> use /dev/video1394, not /dev/raw1394
> https://launchpad.net/bugs/6290
>

Kino is not able to use video1394, and usage of video1394 for DV is
deprecated. The best solution at the moment is to create a new group for
raw1394.

On Thursday 25 May 2006 07:04, preciousp wrote:
> Hope you don´t mind me asking but could you guide me (and others) on what
> to do.
> Is it.
> 1. Low risk - leave raw1394 as disk and don´t allow kino to access raw1394
> to control camcorder
> 2. add user to the ¨disk¨ group - is this v.bad?
> 3. change raw1394 to video group - " no no no ¨
>
> I´m assuming that acually 2. is worse than 3 as your giving yourself access
> to raw1394 plus other areas too. In which case 3 would be an option.
>
> Am I correct in assuming that everyone should go with option 1?
>
> I want to put a section on video editing on the wiki and I want to get this
> right.
>
> On 5/25/06, Scott James Remnant <email address hidden> wrote:
> > I had a pretty good chat with Jody McIntyre back in Montreal about the
> > IEE1394 subsystem and what device nodes it exposes. I still think that
> > a USB-alike device node for each interface on each device is the right
> > solution; then we can assign groups and permissions on a per-interface
> > or per-device level.
> >
> > --
> > use /dev/video1394, not /dev/raw1394
> > https://launchpad.net/bugs/6290

On Thursday 25 May 2006 01:59, preciousp wrote:
> I think that in dapper it needs to use /dev/dv1394-0 rather than raw1394
> (which is a security risk).

Can Ubuntu consider using "dv1394/0" rather than "dv1394-0" per the
convention attempting to be established at
http://www.linux1394.org/faq.php#udev ? That FAQ item has existed for some
time. Next kino version changes its default dv1394 device to /dev/dv1394/0
(currently using a legacy devfs name). With dv1394-0, new Kino users will
have a broken configuration out of the box. Now, if I change Kino to use
dv1394-0, then it will be broken by default for other distros.

We can consider the device name change for edgy, I suspect the only reason we don't name them that is that nobody else did at the time we froze our udev rules.

I'm against the idea of a group just for one device node, a "firewire" group could be added and all *1394 devices placed into that though; that'd fit our classful groupings

Yeah, linux1394 was late to the udev game, and I suspect the kernel name will be a popular default for udev rule makers. I believe Dapper will be a popular version for quite a while. Oh well, I will consider changing the Kino default dv1394 device name or simply try a few popular names in addition to the configured name.

On the group, while 'firewire' is an obvious, friendly name, putting all 1394 device files under that group does not help the user/admin distinguish between the safe dv1394 and insecure raw1394.

I think the issue is well discussed and understood now. Let the decision be made, and we will let nuisance be the mother of invention. :-) (Meaning, the nuisance encouraging someone to improve the 1394 kernel interface.)

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 udev bug?

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 the FireWire bus, e.g. creating a DoS situation for audio/video applications, for SBP-2 devices, or eth1394 network interfaces.

4. If another PC is attached to the FireWire bus, it may be possible to read or overwrite the entire RAM of that remote PC. This depends on the PC's configuration. Most FireWire controllers support this feature (yes, it's not a bug, or at least wasn't intended to be one...) but not all OSs enable the feature.

This feature is called physical DMA and is enabled by Linux' ohci1394 driver per default. It speeds up SBP-2. Linux' sbp2 driver does not work correctly without physical DMA at the moment. Some slides:
http://md.hudora.de/presentations/#firewire-pacsec
http://md.hudora.de/presentations/#firewire-21c3

Jody McIntyre's plans to improve raw1394's security:
http://thread.gmane.org/gmane.linux.kernel.firewire.devel/6395/focus=6395
Neither Jody nor anybody else got around to implement these ideas yet.

I hope to get sbp2 to work correctly (if slowly) without physical DMA too. Furthermore I am thinking about implementing filtered physical DMA for SBP-2.

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.

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.

So there we go ;) access to /dev/raw1394 gives you access to the entire host machine ... which is why only root can do it

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 to implement in an platform independent way.) I don't know if eth1394 works without physical DMA..

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 a long time to sort out and educate. Also, it does not address that certain address space of CSR are well-defined for specified applications and are safe to read/write.

My approach is to use Linux Capabilities to sandbox raw1394 operations. Things such as isochronous communications and asynchronous transactions against the well-defined address ranges (ConfigROM, IEC 61883-1 FCP and plug registers, IIDC) would be left as is and allow existing applications to work fine. Other operations would require CAP_SYS_RAWIO except some things like ARM and ConfigROM manipulation could be CAP_SYS_ADMIN.

What do you think? How does that deal with Stefan's issue #4? If it is not adequate, then nothing is because a protocol library in kernel space would just use the same addresses, just by proxy.

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 enable certain access only if well-known unit directories are present. But this could also be done via the capabilities based approach. It would add complexity either way; maybe actually less so if done in-kernel. However, such features could be considered later. If I look at our current track record of IEEE 1394 kernel driver maintenance, simplicity is what we need in a solution, first and foremost.

(Note, I am not familiar with a lot of IEEE 1394 applications nor with Linux Capabilities.)

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 the same setting but a different problem then please create a new bug.

Fixed in Ubuntu 7.04

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 localhost NetworkManager: <debug> [1186029397.242505] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/ieee1394_guid_850000cd334a').
Aug 2 00:36:37 localhost kernel: [18158.975811] ieee1394: raw1394: /dev/raw1394 device initialized
Aug 2 00:36:37 localhost kernel: [18158.996708] NOTE: The dv1394 driver is unsupported and may be removed in a future Linux release. Use raw1394 instead.

Aug 2 00:40:00 localhost kernel: [18361.636123] raw1394: WARNING - Program "dvgrab" uses unsupported isochronous request types which will be removed in a next kernel release
Aug 2 00:40:00 localhost kernel: [18361.636134] raw1394: Update your software to use libraw1394's newer interface

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 in Linux 2.6.22 and the respective userland support will reach maturity. The unsupported isochronous request types in raw1394 that dvgrab 1.x can use alternatively to dvgrab1394 will be unavailable from Linux 2.6.23 onwards.

Dvgrab 2.x as well as reasonably recent Kino versions use only supported libraw1394 calls.

Dan, the link to dvgrab-2.1.tgz on the Download page at www.kinodv.org is mistakenly titled "dvgrab-1.2.tar.gz".

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"

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.

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 implement filtered physical DMA as mentioned in a previous comment ( -> improved host security). Development status of these drivers is posted at wiki.linux1394.org.

> Capturing DV video over the desktop should be straightforward,

It actually is, except if ancient userspace software is used.

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 using /dev/raw1394. Now, read/write permissions can be enabled on a per node/device basis. All that is left to do is to configure udev to determine when a new node is a camera and then set the group and permissions on /dev/fwN accordingly. I believe there is still a little less stability in firewire than ieee1394 on some devices, but perhaps better in others. It is difficult to weigh that trade-off. Maybe Stefan Richter has more of a gauge of that.

I do not know the state of Ubuntu 8.10 alpha. Is the kernel using firewire or ieee1394? On your system, is raw1394 loaded and does /dev/raw1394 exist when you plug in your camera?

Sorry Dan - I meant dv1394.

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 is because someone forgot to set the flag needed during the build to enable support for /dev/dv1394/0 (in the video group) which is not enabled by default... by default there is only access to /dev/raw1394 (in the disc group) which we've agreed is not the best solution for most users.

Running Kino as root does not (strangely) get around this problem. I get the same error messages plus one about no camera being detected. It just switches between them.

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 is because someone forgot to set the flag needed during the build
> to enable support for /dev/video1394 which is not enabled by default...

No, Kino requires /dev/raw1394. Check with "lsmod" that the raw1394 and the ohci1394 drivers are loaded, and check the file permissions (or access control list) of /dev/raw1394.

PS: As mentioned in my previous comment, alternative kernel drivers are in development which allow to implement a more flexible security policy, but I suppose these drivers are not enabled in Ubuntu 8.10 --- and they probably shouldn't because of immaturity. (The wiki which I mentioned in the other comment is now located at http://ieee1394.wiki.kernel.org/.)

@Dan: I have /dev/dv1394/0 group=video and /dev/raw1394 group=dics
I'm not sure how to check if raw1394 is 'loaded'

@Dan: $ lsmod shows me that both dv1394 and raw1394 are loaded

In that case you should expect that running as root would allow it to work, but you reported it is not. If both ieee1394 and firewire subsystems are enabled in the kernel, then it may create this problem:

grep FIREWIRE /boot/config-$(uname -r)

ok... it turns out that dv1394 wasn't being created, it's there because I kicked it with $ sudo modprobe dv1394 like what's on the wiki: https://help.ubuntu.com/community/Firewire

and

duncan@duncan-laptop:~$ grep FIREWIRE /boot/config-$(uname -r)
# CONFIG_FIREWIRE is not set

Duncan:
With the camcorder attached and switched on, please save the output of "dmesg" into a file and attach it. Also, post the output of
        ls /sys/bus/ieee1394/devices/
and
        grep . /sys/bus/ieee1394/devices/fw-host0/*

Furthermore, does Ubuntu's libraw1394 package maintainer listen here? There have been modified versions of libraw1394 v1 out there which only work with the new firewire kernel drivers but not with raw1394. I hear that Debian is somewhere in the transition from the ieee1394 drivers to the firewire drivers, and in the worst case, you might have gotten an unsuitable libraw1394 version from your upstream. Make sure that you have either a libraw1394 v1 which still works with raw1394, or libraw1394 v2 which transparently works with either driver stack.

@Stefan - I will do that when I find the power cord for the camera...

@All - I assume that the long term solution is what's discussed in bug #276463. Please, anyone interested subscribe to that bug and the associated blueprint at https://blueprints.edge.launchpad.net/ubuntu/+spec/firewire-core/

Please have a look at
http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=rules/rules.d/50-udev-default.rules;h=0f27982d85df721bc5dd4bcdbe433cf786c16a05
for an example that Just Works[TM].

...lines 54...57 of upstream 50-udev-default.rules, that is.

The wiki is currently great but... I don't like the idea of running kino and kdenlive as root, so, using Ibex (8.10), I was trying solution method 2 (creating a firewire group for users and raw1396). It works okay, until reboot, when raw1396 group is set back to disk.

Is there a method to make the change permanently?

Sorry the useless question, editing "/etc/udev/rules.d/40-permissions.rules" as method 5 suggested did the trick. Also made everyone part of happy group "video". No one has access to this computer so it shouldn't pose any risk.

But really, this bug is 3 years old. Shouldn't by now some solution have been found? Or shouldn't video editing software have at least an option somewhere to be able to change the firewire port to the dv1394 one?

> this bug is 3 years old. Shouldn't by now some solution have been found?

Another distributor is sponsoring driver development. As one of its outcomes, there is a more satisfying solution to the issue of device file permissions and ownership; see comment 43. I hear a developer is currently making good progress on some of the notable remaining issues of the new drivers.

Until then, I recommend to you to use the mainline udev rules for the 1394 drivers as per comment 44.

I don't have any 50-udev-default.rules in rules.d -- should I just
add the whole file verbatim?

--
Gary Lawrence Murphy <garym at teledyn.com> =============================
Alice laughed: "There's no use trying, one can't believe impossible things."
"I daresay you haven't had much practice," said the Queen.

> I don't have any 50-udev-default.rules in rules.d -- should I just
> add the whole file verbatim?

No. If Ubuntu already has 1394 related rules in one of the rules files, replace those by the mainline 1394 rules (i.e. lines 54...57 of upstream 50-udev-default.rules). If there aren't any yet, add a rules file which contains only these four lines.

This is *still* an issue even in Ubuntu 9.04 Jaunty. Kino 1.3.0 is still being bundled with ubuntu... why on earth is this still a bug?!

Just so people know there is an Ubuntu Brainstorm entry about firewire capture: http://brainstorm.ubuntu.com/idea/19976/

Because Ubuntu security team think that it is a security problem to change group belonging to video or audio for /dev/raw1394.

This bug is a duplicate of bug #421551.

See https://help.ubuntu.com/community/UbuntuStudioPreparation to get it working in Ubuntu 9.10.

This bug is still present in Ubuntu 9.10.

I suspect they will fix it in a future Ubuntu release by replacing the kernel drivers ohci1394 + ieee1394 + raw1394 by the kernel drivers firewire-ohci + firewire-core. Presently, those newer drivers are already shipped in Ubuntu's kernel packages in parallel with the older drivers. The older ones are the default and the newer ones can be enabled by editing a respective system configuration file (kernel module blacklist, http://ieee1394.wiki.kernel.org/index.php/Juju_Migration#How_to_suppress_auto-loading) as administrator.

Well, the other possible workaround on current Ubuntu also requires editing or creating a system configuration file (udev rule file for raw1394, http://ieee1394.wiki.kernel.org/index.php/FAQ#How_to_get_access_to_raw1394_as_unprivileged_user.3F). I doubt that the Ubuntu udev maintainer will suddenly reconsider his preference and re-introduce such a raw1394 rule, therefore expect to have to wait for a next release (Lucid perhaps?) to get this bug fixed by a switch to firewire-core as default kernel driver.

This is terrible... I am not an expert what so ever, but I have choosen to run linux, as a alternative to Windows. I am looking for a SIMPLE download fix, so that I can capture movies through firewire. If linux continues to be so complicated, it will NEVER, be a alternative for the normale user. I can see that it is a safety issue, but for me we are talking about a SONY Videocamera and a cable to plug in to the computer. ( I would be better to advice me during installation, that LINUX do NOT support firewire port.

I am running Ubunto 9.10, and Kino 1.3.3 (Kino is an IEEE 1394 DV non-linear video editor.
http://www.kinodv.org/) using a Sony DCR-HC42E PAL

My error code is "raw1394 kernel module not loaded or failure to read/write /dev/raw1394"
I must use the command "sudo chmod a+rw /dev/raw1394" everytime, but the biggest problem is actually that I have to plugin the camera to use the program. So when i have copied all the scenes to the computer, you can work and edit the scenes without having the camera installed. But when you want to export it to example mpeg or what ever, you cant the following error "Error setting the IEEE 1394 port (host adaptor)"

So the fact that I went from windows to Linux was the free software, but as I can see here, this problem has been there for around 4 years now!!!!!!

Best regards Robert, Denmark

Robert Petersen wrote:
> I am running Ubunto 9.10, and Kino 1.3.3
[...]
> the biggest problem is actually that I have to plugin the camera to
> use the program. So when i have copied all the scenes to the computer,
> you can work and edit the scenes without having the camera installed.
> But when you want to export it to example mpeg or what ever, you cant
> the following error "Error setting the IEEE 1394 port (host adaptor)"

This is a different bug. You could report it separately in a new bug entry. But before that, please test the current version of Kino first (version 1.3.4), which appears to be available as a package now. (I saw that Debian packaged it, hence I guess it is also available on Ubuntu. I don't have Debian or Ubuntu myself.)

> So the fact that I went from windows to Linux was the free software,
> but as I can see here, this problem has been there for around 4 years
> now!!!!!!

Free software means, among else, that distributors and/or users can fix problems themselves if they have the necessary knowledge or experience. And indeed, the /dev/raw1394 permissions problem
   - does not exist on several other distributions than Ubuntu,
   - can be fixed by Ubuntu users by adding a local udev rule (there is guidance somewhere on the Ubuntu wiki (help.ubuntu.com) as well as on the upstream wiki, see comment 55),
   - is going to be fixed in Ubuntu as well in a future release, when Ubuntu fully switches to newer kernel drivers which implement a superior device access concept and thus address the security concerns that were brought up by Ubuntu package maintainers and many others.
On the other hand, free software does _not_ mean that everything works immediately or is being fixed for you, at no cost, in a matter of hours.

I am aware about the free software, is done many hard working idealist, and I am grateful for that. But sometimes it just get's to much.
So what you are are saying "Stefan Richter" is that I can swift to another distrubution? which one is simular to Ubunto? I am thinking Suse Linux? to be the the must user friendly?

You are also saying to upgrade Kino, and there we have the problem for me.. This is not like windows.. So i can download I file.. wauw.. noting happends...?? So reading on the that net.. "I have to compile the package" I think i stop here.. becaurse this is appantly something the a LINUX user must learn first.
By the way, it is not another bug, when typing "sudo chmod a+rw /dev/raw1394" in terminal (which also is something I have been forved to learn) that issue is also away..
But don't get me wrong, I love the idea of open source and free distributions, just hoped for a little bit more userfriendly software.
Best Regards Robert.

2010/1/9 Robert Petersen <email address hidden>:
> You are also saying to upgrade Kino, and there we have the problem for me.. This is not like windows.. So i can download I file..
> wauw.. noting happends...?? So reading on the that net.. "I have to compile the package" I think i stop here.. becaurse this is
> appantly something the a LINUX user must learn first.

You can try downloading a package from Debian Sid (aka unstable), but
I can't guarantee that it will install correctly.
http://packages.debian.org/sid/kino
Choose either i386 or amd64, depending on your type of installation
(32-bit or 64-bit).

--
## Przemysław Kulczycki <<=>> Azrael Nightwalker ##
# Jabber/XMPP/Gtalk/Tlen ID: azrael[na]jabster.pl #
# (Co to jest? Zobacz na: http://jabberfaq.info ) #
## www: http://reksio.ftj.agh.edu.pl/~azrael/ #####

Re comment 56...59:
> So when i have copied all the scenes to the computer,
> you can work and edit the scenes without having the camera installed.
> But when you want to export it to example mpeg or what ever, you cant
> the following error "Error setting the IEEE 1394 port (host adaptor)"

I tested this with Kino 1.3.3 on Gentoo Linux right now. While it is true that there is a message about failure to set the 1394 port when the "Export" mode is entered (which starts with the IEEE 1394 export tab up front), this failure does not prevent one from switching to any of the file export tabs and export to a file there. (I tried DV file export.)

If file export does not work for you, then it is _not_ related to IEEE 1394 nor to Ubuntu's permission policy. (If it were, then I would have been able to reproduce it on Gentoo Linux.) The recommendation to try Kino 1.3.4 still stands though in case of any remaining export troubles. If an update still does not help --- or if it helps but Ubuntu package repositories (Universe or whatever) do not provide Kino 1.3.4 yet --- then please open a new bug.

I had similiar problem....did all i found on the net..eg give permission rights to raw file....load the module manually...nothing worked...UNTIL>.....>>>>

I looked into blacklist-firewire.conf, thats when i realised that onchi was blacklisted

So what i did?
 1)edit /ect/modprobe.d/blacklist-firewire.conf

remove the # from blacklist firewire-ohci

eg
was
# blacklist firewire-ohci

Now
# blacklist firewire-ohci

Save and reboot system. Start Kino with admin rights and it all worked well for me...
Now i do not know what are the implications of unblocking the firewire-ohci, but that was the solution that made my kino/kdenlive worked beautifully....

cheers!

oops sorry....... <<<Read This >>>

you have to add # to blacklist firewire-ohci to prevent blacklist....

was
blacklist firewire-ohci
Now
# blacklist firewire-ohci

cheers

Re comment 61:
> Now i do not know what are the implications of unblocking the firewire-ohci, but
> that was the solution that made my kino/kdenlive worked beautifully....

The implication is that you switched from
    ohci1394 + ieee1394 + raw1394 ( /dev/raw1394 ) --- libraw1394 + libiec61883 + kino
to
    firewire-ohci + firewire-core ( /dev/fw* ) --- libraw1394 + libiec61883 + kino
i.e. to different newer FireWire kernel drivers and a different character device file interface. This is basically what the blueprint "Enable new Firewire stack in default kernel config" is about. (See box at the right side of this page.)

The new kernel drivers are simpler, better performing, more compliant to specifications, and more secure than the older drivers. In contrast to Ubuntu's raw1394 access policy, firewire-core's device files are created with more liberal access permissions for devices which need to be (and are safe to be) accessed by userspace programs such as kino.

Good to hear from you and thanks for the explaination....

As for me it stopped working for a day and it stated working beautifully
again...
well all is settled and now i can edit my videos...

Thank you and cheers!

On Sat, Feb 6, 2010 at 10:37 PM, Stefan Richter <
<email address hidden>> wrote:

> Re comment 61:
> > Now i do not know what are the implications of unblocking the
> firewire-ohci, but
> > that was the solution that made my kino/kdenlive worked beautifully....
>
> The implication is that you switched from
> ohci1394 + ieee1394 + raw1394 ( /dev/raw1394 ) --- libraw1394 +
> libiec61883 + kino
> to
> firewire-ohci + firewire-core ( /dev/fw* ) --- libraw1394 + libiec61883
> + kino
> i.e. to different newer FireWire kernel drivers and a different character
> device file interface. This is basically what the blueprint "Enable new
> Firewire stack in default kernel config" is about. (See box at the right
> side of this page.)
>
> The new kernel drivers are simpler, better performing, more compliant to
> specifications, and more secure than the older drivers. In contrast to
> Ubuntu's raw1394 access policy, firewire-core's device files are created
> with more liberal access permissions for devices which need to be (and
> are safe to be) accessed by userspace programs such as kino.
>
> --
> DV capture over Firewire is broken (no rights for /dev/raw1394)
> https://bugs.launchpad.net/bugs/6290
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “kino” package in Ubuntu: Triaged
>
> Bug description:
> Duncan Lithgow reopened this bug.
>
> In Ubuntu 8.10 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 is because someone forgot to set the flag
> needed during the build to enable support for /dev/dv1394/0 (in the video
> group) which is not enabled by default... by default there is only access to
> /dev/raw1394 (in the disc group) which we've agreed is not the best solution
> for most users.
>
> Running Kino as root does not (strangely) get around this problem. I get
> the same error messages plus one about no camera being detected. It just
> switches between them.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/kino/+bug/6290/+subscribe
>

Does anyone know if this new firewire stack is going to make it into Lucid Lynx / 10.04 to solve this problem once and for all?

Ubuntu 10.04 didn't solve the problem. Not even this trick wasn't effective any more:

you have to add # to blacklist firewire-ohci to prevent blacklist....

was
blacklist firewire-ohci
Now
# blacklist firewire-ohci

I tried this too:

In Ubuntu 10.04

Paste this in your terminal:

echo 'KERNEL=="raw1394", GROUP="video", MODE="0664"' |
sudo tee /etc/udev/rules.d/50-raw1394.rules
&& sudo restart udev

If the tips in this guide do not work please file a bug in launchpad against Kino.

https://help.ubuntu.com/community/Firewire

So, here we are.

This was uneffective as well:

http://ubuntuforums.org/showthread.php?p=9285205

By the way, this bug pops up every now and then while it is actually several years old! Ubuntu / Kino should detect the Camera and ask (for security reasons) whether this found device should be connected.

For some reason the Ubuntu team is not so eager to solve this issue. They really should while there is no simple and proposed solution for capturing video from a camcorder.

The new firewire subsystem and udev rules to enable permissions for camera devices for members of group 'video' is in the kernel package in 10.04! Unfortunately so is the legacy ieee1394 stack, and guess which one starts up by default on my box? You guessed it: ieee1394 - sigh. Can anyone locate a ticket or document that explains why ieee1394 is still preferred over firewire?

Go ahead and read /etc/modprobe.d/blacklist-firewire.conf. Then, edit it to uncomment the non-firewire lines and comment out the firewire lines.

Can anyone really blame me for no longer working on Kino? Thank god new cameras are all file-based.

According to /usr/share/doc/module-init-tools/changelog.Debian.gz, you all can go blame Andy Whitcroft and Tim Gardner for what appears to be an arbitrary decision: supposedly "backwards compatibility." Uh, nearly all applications use libraw1394, and I build backwards compatibility into that!

For more information, the changelog entry references bug
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/276463

But those comments are from 2008! Here is the current status:
http://www.ffado.org/?q=node/1316

So, basically, the multitude of camcorder owners are being sacrificed for the handful of pro-audio firewire interface users. I do not have anything against FFADO, and its maintainer is a great guy. And even though I maintain libraw1394 (as little as possible admittedly), I do not have an audio interface to work on this firsthand nor the motivation to do so. At some point, we need to decide to move on and sacrifice the few stragglers. FFADO users should have been the ones forced to change their blacklist file.

I agree with Dan's comment #68 except for the FFADO status. As the status message that Dan quotes correctly states, new kernel drivers + libraw1394 + FFADO are working together since end of 12/2009. The only issue is that a small fix in FFADO _may_ (or may not) be required that came after the FFADO release v2.0.0. (I believe that fix was not required in my own testing.) Everybody is still holding their breath for a 2.0.1 maintenance release or the much anticipated 2.1 feature release of FFADO --- except Debian who simply package current FFADO trunk which works fine. Hence Ubuntu or Ubuntu Studio et al should already have a fine FFADO package too.

I guess we as upstream need to communicate more clearly that the new drivers should be used by default now, and the old ones blacklisted or disabled entirely.

PS:
Nice work, Ubuntu maintainers. Instead of helping upstream to get the raw1394 security issue resolved, your only contribution was to create a huge support workload for the various affected upstream projects. Not to mention the damaging user experience that you provided to your users, and later to users of several other distributions too when you pushed your ill-advised udev rules upstream.

Blempis (comment 66),
I think your first attempt to fix this (comment out blacklisted firewire modules) did not work because you either did not uncomment the ieee1394-based modules (ohci1394 - video1394) or because you did not reboot. If you did not uncomment the legacy modules, then they might have started first and acquired the hardware.

Stefan, is there something wrong in the udev rules now? What is it that you are referring to?

Re comment 71:

  - If both stacks are installed but none blacklisted, then the kernel's driver core should first attempt to bind firewire-ohci before ohci1394. This is tied to the build order in the kernel's build system. However, it may go wrong for one or another reason; e.g. ohci1394 present in initrd or whatever.

  - The udev rules for firewire-core's files are fine; I referred to the missing rule for raw1394. (BTW, I hope that we as upstream stay in control of firewire udev rules now, but I'm afraid I cannot monitor udev development as closely as desirable.)

Stefan Richter [2010-05-20 22:23 -0000]:
> - The udev rules for firewire-core's files are fine; I referred to the
> missing rule for raw1394.

It's not "missing" in the "oops, forgot" sense. It just doesn't make
sense to give all users complete control for all firewire devices,
that's not how device management is supposed to work in the kernel.
There is apparently a lot of missing kernel support here, but unsafe
hacks around that won't be accepted upstream. You are of course
welcome to add one locally if you are in a trusted or single-user
environment.

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

> There is apparently a lot of missing kernel support here

There is nothing missing in the new stack. And what is missing in the old stack could have been added to it if development manpower would have been available, or better yet, development and deployment of the new stack could have been sped up with developer and tester manpower.

> unsafe hacks around that won't be accepted upstream

Do you mean upstream udev? They also accepted Ubuntu's video1394 and dv1394 rules that had typos in them such that they never matched. (Or they added the typos themselves when they merged Ubuntu's rules, I don't know. Commit 41e7f557.) The fact that they removed the raw1394 rule (commit a8cf7cf) with a mere pointer to this distro bug here but without an own analysis of costs vs. rewards or without checking back with raw1394/ libraw1394 developers also shows that upstream is not in a position to judge what is safe and unsafe. You Ubuntu developers OTOH (a) kept confusing device security with host security and raw1394 flaws with ohci1394/sbp2 flaws, (b) never analyzed the actual risks, (c) never analyzed the costs of the rule removal, (d) never researched potential alternatives. Upstream udev simply trusted your judgment, which was a mistake. (And I didn't push for a revert when I noticed this because I thought that the new firewire drivers would show up in distributions any day now or distributors would at least begin to ask for them, which was a mistaken belief on my side.)

One more word on hacks: Ubuntu's raw1394 rule removal was initially motivated by host security implications but did not in fact solve them, because that's the wrong point to go at. It's ohci1394 and a feature of it on which sbp2 relied.

> You are of course welcome to add one locally if you are in a trusted or single-user environment.

That's 1990's Linux mindset. This is an unacceptable hack too.

You OTOH were of course welcome to discuss your concerns and requirements with upstream kernel/ library/ application developers when you removed the rule in Ubuntu, or at least later when this change went upstream. I'm not even talking about contribution of tests or code.

Hmm, maybe I should have taken initiative two years ago (that's when transparent dual stack capability was implemented in libraw1394 by Dan) and should have pushed for the new stack to be provided by default in Ubuntu. The then half-working new stack might have been preferable to the mostly non-working old stack as configured in Ubuntu.

I finally got a chance to setup 10.04 on a machine with FireWire, and the changing /etc/modprobe.d/blacklist-firewire.conf has no effect! It still loads ohci1394 and not firewire-ohci. Why?

Did you blacklist dv1394 and video1394 as well?

Does an /etc/modprobe.conf exist on Ubuntu? If yes, regenerate it by "update-modules" or delete the file. modprobe ignores /etc/modprobe.d/* if /etc/modprobe.conf exists.

Does the initrd contain ohci1394? Hard to tell how to check that, as I never create and use initrd myself. Maybe dmesg gives away whether ohci1394 was loaded early. OTOH, that should lead to _both_ modules being loaded, not only ohci1394.

There is no /etc/modprobe.conf.
Yes, there is an initrd and 'mkinitramfs -v -o /dev/null | egrep '1394|firewire' shows both subsystems included. Not sure the best to resolve this.

I learned that you must update the initrd images after changing the blacklist file:
sudo update-initramfs -k all -u

Hi all,

you can count me as one user affected by the bug: I own a Panasonic NV-GS22 (a cheap, quite diffused camcorder) and I had to follow the comment/uncomment + update-initrams path, with some success in Ubuntu Lucid. However, I still cannot control my camcorder from the PC --- I start playback manually --- and sometimes the stream is not captured at all. Which was working perfectly in a previous Ubuntu release. I'll be happy to be more precise, if this is of interest in this forum, but I can survive in the current situation.

Thank you

Augusto

same bug with my panasonic NV-GS17..

Panasonic NV GS120
Affected by it as well - now working.

Samsung VP-D371W PAL
Affected by it as well - now working.

This is at least in part a Kernel related issue. There are two firewire stacks in the kernel, the old one (which this bug was originally opened against) which has serious security configurability issues, and a new one which has them resolved. For many of the recent releases both the firewire stacks have been available, but the older one selected by default. From Maverick this choice has been reversed such that the new stack is the default. This should resolve the security handling of the interfaces and resolve this issue for kino on maverick and later. Please let us know if you are testing on Maverick and this is not the case.

For Lucid the switch to the new stack by default was deemed to risky before release as it is an LTS. Therefore we went with the old stack on Lucid, but the new can be selected by switching the blacklisting in /etc/modprobe.d/blacklist-firewire.conf. Now that Lucid is released we cannot just change the default over to the new stack for everyone, the regression potential is too great for an LTS. However there are several work-arounds available, switching to the new stack, changing the group on the bluetooth devices, or running the applications with more priviledge via sudo.

Based on this I am going to close the Maverick task for the kernel Fix Released, and close the Lucid task for the kernel Won't Fix.

Thank you, Andy, for your sensible and lucid explanation. ;-)

DV Grabbing doesn't work in Maverick for me. I tried a lot to use dvgrab or kino on my Camcorder (sony VX1000E) without much success

Blacklisting didn't work reliable.

However, I googled an old thread on

However, googled an old thread:
http://osdir.com/ml/kernel.firewire.user/2005-07/msg00001.html

Disabling irm does the trick for me.

Steffen,
please open a new bug for this (this is different) and leave a short note with the new bug number here so that I can have a look. Or mail the bug description to one of <email address hidden> or <email address hidden>. These mailinglists are open for posting without prior subscription. Thanks.

Kino isn't the only important one that is broken by a lack of a thoughtful fix.

VLC is also affected for people like myself that NEED to be able to stream LIVE video from a professional DV camera over a wireless network, and finally export it several miles away at a television transmitter site for our viewers to watch.

This morning I was supposed to broadcast a parade from 5 miles away... I started on this problem at 4AM and missed the 9AM parade start.

Just because a person CAN kill others with an automobile does not mean we should all have our cars taken away for everyone else's safety.... and along the same lines raw1394 access that WAS working perfect before, should be allowed back.

Instead give users a security panel where they can check a box to disable raw1394 if they have no use for it, and they can leave it unchecked if they NEED full access.

I am writing this post because there is little else I can do, but I had to do SOMETHING.... My job at a television station depends on my being able to live stream an 8Mb/s stream from a DV camera any time there is a parade, breaking news story, or other reason to require high quality live video to be transmitted from all points across town...

Our station does not have the $300,000 for a microwave truck and astronomical yearly fees for the satellite link... I am forced to use 2 watt radios on empty 802.11 channels, employing 4 degree beam width mesh antennas, to avoid disrupting other people's wireless connections. There's no way our viewers would stand for USB web cam video without laughing us off the air.

I can technically do it in Windows... but Windows is not stable enough to trust for parade, rodeo, job fairs, auto racing, and other long duration live broadcasts.

Please don't break my ability to stream high quality video with VLC running on a laptop in a backpack for a 20Lb solution that includes the camera and everything in a portable package....

Or I should say, it's already broken... please return the functionality removed....

If the VLC team needs to help work out a suitable driver, please do work with them... I am pretty sure they are open to assistance making this work as well.

Thank you for your time,
Eric

Re comment 87:

Eric,
thanks for describing your use case. I was vaguely aware that VLC has IEEE 1394 video capture modules, but it is interesting to learn that somebody used (is using) it as a means to deliver DV over network.

There are two IEEE 1394 modules in VLC: "DC1394", implemented by modules/access/dc1394.c, for cameras which send uncompressed video over 1394 according to the IIDC a.k.a. DCAM standard (industrial cameras, some old webcams), and "DV1394" alias "dv" alias "raw1394", implemented by modules/access/dv.c, for camcorders, perhaps tape decks etc. which send DV over 1394. From VLC v1.0 to VLC v1.1, these VLC access modules have been converted to libdc1394 v2 and to libraw1394 v2, respectively.

These updates to current low-level library API versions should mean that VLC should work with current kernels and current udev, which should provide the following interface:
a) The single global /dev/raw1394 no longer exists.
b) Instead, the kernel provides /dev/fw0, fw1, fw2, ..., one file for each IEEE 1394 node (including the local node, i.e. the controller card). These device files are binary incompatible with /dev/raw1394 but are functionally 90% compatible with /dev/raw1394.
c) Udev should set group ownership or/and access control lists for the "video" group or/and the current console owner or some other suitable owner for each /dev/fw* device file which corresponds to a video device, e.g. DV camcorder.
d) libdc1394 v2 and libraw1394 v2 are able to automatically select the proper /dev/fw* device file for device control and capture.
e) libdc1394 v2 based or libraw1394 v2 based application programs don't notice any of that, since they let the libraries deal with the kernel's device files.

Currently I don't have Ubuntu myself (I have got Gentoo Linux but am subscribed to this bug because I am involved in FireWire kernel drivers maintenance and libraw1394 maintenance), and I never tried VLC's IEEE 1394 video capture modules. I will configure my VLC installation to include these modules, try if they work here (they should work in principle), and report back.

PS,
kino should work out-of-the box on recent Ubuntu versions, using libraw1394 v2.

Tested:
  - VLC 2.0.3, libraw1394 2.1.0, libdc1394 2.2.0, kernel 3.6-rc7, udev 171, Gentoo Linux
  - miniDV camcorder JVC GR-D725E
  - IIDC (DCAM) webcam Apple iSight
  - VIA VT6306 based CardBus FireWire controller
  - Texas Instruments XIO2213A/B based PCIe FireWire controller

"vlc dv://" and "vlc dc1394://" automatically pick up the camcorder or webcam respectively and display live video. Sound of the DV stream is played as well. I did not try network streaming. (Never tried it before and did not figure out how to set up stream output.)

The VT6306 controller does not work very reliably: For example, if VLC is stopped and restarted with "kill -STOP $pid" and "kill -CONT $pid", the DV stream is frozen. This is a known issue between VT6306 and current kernels which is also seen with some other capture programs; the VT6306 does not properly restart its DMA after a period of inactivity of the capture process. The Texas Instruments controller does not exhibit such a problem, as expected.

Somewhat older software revisions should work as well. libdc1394 and the VLC dc1394 are irrelevant for DV.

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".