RE: Can not read UDF CD

RE: Can not read UDF CD

[David Balazic]

OK, I put the ISO image and the udf checker outputs on BitTorrent,
the torrent file is avaliable at
http://lizika.pfmb.uni-mb.si/~stein/UDF_image_and_reports.torrent

In case you don't have a BitTorrent client, one can be had at
http://bitconjurer.org/BitTorrent/download.html
( even a commandline version , written in python )

Regards,
David


> ----------
> From: 	Pat LaVarre[SMTP:p.lavarre@ieee.org]
> Sent: 	29. julij 2004 19:06
> To: 	David Balazic
> Cc: 	'David Burg'; linux_udf@hpesjro.fc.hp.com;
> linux-kernel@vger.kernel.org
> Subject: 	Re: Can not read UDF CD
> 
> // David Balazic:
> 
> > I will try to see if the problem is reproducable with burning
> > more UDF CDs...
> 
> Yes please thank you.
> 
> >> I attach the "udf_test -scsi 1:0" output.
> 
> Attach did Not arrive here, sorry, please retry attach, at least to me, 
> else publish on web.
> 
> Also please say if you can easily share a .iso image of the disc.  (Of 
> course I imagine linux_udf and linux-kernel don't want that attached.)
> 
> >> -	   Main: length,location: 32768, 30654 expected:  32768, 32
> >> -	Reserve: length,location: 32768, 30670 expected:  32768, 48
> 
> I likewise find these interesting.  Don't know yet what they mean - 
> again I say "Ben wrote udf.ko, not I".
> 
> I'll try to hunt for relevant claims in the 
> udfct/src/udf_tester/udf_test (aka phgfsck) output when I receive it.
> 
> // David Burg:
> 
> >> Let me know if you ... think ... Nero has a mistake
> 
> Wow.  Will do with pleasure thank you for your interest.
> 
> Pat LaVarre
> 

BitTorrent and iptables (was: Can not read UDF CD)

[Bill Davidsen]

David Balazic wrote:
> OK, I put the ISO image and the udf checker outputs on BitTorrent,
> the torrent file is avaliable at
> http://lizika.pfmb.uni-mb.si/~stein/UDF_image_and_reports.torrent
> 
> In case you don't have a BitTorrent client, one can be had at
> http://bitconjurer.org/BitTorrent/download.html
> ( even a commandline version , written in python )

I used torrent to pull something the other day, and while I could pull, 
no one could connect to get data from me. I have my iptables set to 
ESTABLISHED,RELATED so iptables may not know about torrent.

Just a thought, since you have set up this way.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: BitTorrent and iptables (was: Can not read UDF CD)

[Jan Knutar]

On Thursday 12 August 2004 23:33, Bill Davidsen wrote:

> I used torrent to pull something the other day, and while I could pull, 
> no one could connect to get data from me. I have my iptables set to 
> ESTABLISHED,RELATED so iptables may not know about torrent.

You probably need to explicitly ACCEPT incoming to the port that Bittorrent
uses. A tracker module to sniff traffic to known outbound tracker ports, to
detect which port Bittorrent is using, and allow that inbound, seems a little
bit excessive to me, not to mention that people set up trackers on the most
varying range of seemingly random ports :-)

Either way, common sane principles of TCP/IP apply with Bittorrent too,
if both parties are firewalled, you wont transfer any data between eachother.
If one party (out of two) is unfirewalled, data can be transfered both ways
between them, the firewalled party will established connection to the unfirewalled
to get communication going.

Re: BitTorrent and iptables (was: Can not read UDF CD)

[Bill Davidsen]

Jan Knutar wrote:
> On Thursday 12 August 2004 23:33, Bill Davidsen wrote:
> 
> 
>>I used torrent to pull something the other day, and while I could pull, 
>>no one could connect to get data from me. I have my iptables set to 
>>ESTABLISHED,RELATED so iptables may not know about torrent.
> 
> 
> You probably need to explicitly ACCEPT incoming to the port that Bittorrent
> uses. A tracker module to sniff traffic to known outbound tracker ports, to
> detect which port Bittorrent is using, and allow that inbound, seems a little
> bit excessive to me, not to mention that people set up trackers on the most
> varying range of seemingly random ports :-)
> 
> Either way, common sane principles of TCP/IP apply with Bittorrent too,
> if both parties are firewalled, you wont transfer any data between eachother.
> If one party (out of two) is unfirewalled, data can be transfered both ways
> between them, the firewalled party will established connection to the unfirewalled
> to get communication going.

The desired behaviour is that incoming BT connections would be accepted 
while an outgoing BT connection is in place. You can't open the port at 
any other time, there's no (legitimate) process listening and the 
firewall wouldn't know where to forward the socket in any case.

This belongs on another list.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me