Hi! I tried TableConvert on tables downloaded with bitorrent (one of them). When make partition without file system and run ./TableConvert ds 100.dlt /dev/sdb2 index.dat I get message: /dev/sdb2 allready exist, will not overwrite.
Can anybody help? Thanks in advance! On Wed, Sep 15, 2010 at 12:00 PM, <[email protected]> wrote: > Send A51 mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51 > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of A51 digest..." > > > Today's Topics: > > 1. Several ARFCNs at once ? (??????? ????????) > 2. Re: Please seed tables (Konrad Meier) > 3. Re: Several ARFCNs at once ? (sascha) > 4. Re: Traffic dump (Georg Hofstetter) > 5. Re: Traffic dump (Karsten Nohl) > 6. Re: Traffic dump (Harald Welte) > 7. Re: Traffic dump (Sylvain Munaut) > 8. Re: Several ARFCNs at once ? (Fabio Pietrosanti (naif)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 14 Sep 2010 12:49:29 +0200 > From: ??????? ???????? <[email protected]> > Subject: [A51] Several ARFCNs at once ? > To: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > Hello people, > > Is it possible to record several ARFCNs at once? Or record some narrow band > (5 - 10 Mhz wide) and extract offline data for specific frequency from > band? > > I'm reading about frequency hopping and USRP/USRP2, and everybody speaks > about following up a MAIO and HSN parameters in real time. My question is, > if BST publicly says that it serves certain ARFCNs (for example 40 of > them), > is there a chance to record a traffic from all of them and reconstruct > hopping and traffic data offline? > > Cheers, > LjubeX > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.lists.reflextor.com/pipermail/a51/attachments/20100914/ed24f8ba/attachment.html > > ------------------------------ > > Message: 2 > Date: Tue, 14 Sep 2010 16:10:04 +0200 > From: Konrad Meier <[email protected]> > Subject: Re: [A51] Please seed tables > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Am 12.09.2010 10:52, schrieb Karsten Nohl: > > Hallo list, > > > > Many of you have received copies of the 'Berlin set' of rainbow tables > > in the mail. We would appreciate if you would contribute to the spread > > of the data through seeding the data in Bittorrent. To do that, please > > open the .torrent files available on the disk with any Bittorrent > > client, 'rtorrent' for instance if you are on a Linux command line. > > Hello Karsten, > > I added a machine to seed the torrents at the University of Freiburg > Germany. Uplink is 1GBit. I hope this helps. > > Regards > Konrad > > > ------------------------------ > > Message: 3 > Date: Tue, 14 Sep 2010 16:15:13 +0200 > From: sascha <[email protected]> > Subject: Re: [A51] Several ARFCNs at once ? > To: [email protected] > Message-ID: <20100914141513.gc4...@test> > Content-Type: text/plain; charset=utf-8 > > On Tue, Sep 14, 2010 at 12:49:29PM +0200, ??????? ???????? wrote: > > Hello people, > > > > Is it possible to record several ARFCNs at once? Or record some narrow > band > > (5 - 10 Mhz wide) and extract offline data for specific frequency from > band? > > yes its possible but airprobe currently does not support hopping. It is > on the todo list, though. > > > > > I'm reading about frequency hopping and USRP/USRP2, and everybody speaks > > about following up a MAIO and HSN parameters in real time. My question > is, > > if BST publicly says that it serves certain ARFCNs (for example 40 of > them), > > is there a chance to record a traffic from all of them and reconstruct > > hopping and traffic data offline? > > Yes, as long as they are confined to an 8Mhz or 25 Mhz band (for USRP and > USRP2 respectively). Or if you have many USRPs, then you can of course > scan a wider band. The amount of data is quite large: 32mbyte/sek for USRP1 > with 16bit I/Q samples. A real time demodulator is on the TODO list, and > it would reduce that by a factor of ~ 32. > > > > > ------------------------------ > > Message: 4 > Date: Wed, 15 Sep 2010 01:49:24 +0200 > From: Georg Hofstetter <[email protected]> > Subject: Re: [A51] Traffic dump > Cc: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=UTF-8 > > Am 13.09.2010 18:12, schrieb sascha: > > reflextor.com/galileo1_a725_d174_g5_KcC07D6E4269C70BB3.cfile.gz > > reflextor.com/vf_call6_a725_d174_g5_Kc1EF00BAB3BAC7002.cfile.gz > > > Hey, thanks a lot! > > I am sure, Veshna and Tim in the galileo1 dump were aware of the USRP > running nearby ;) > > These dumps helped me to test my own tool with fully encrypted call > setups. Didnt have the chance yet to get hands on a dump with > hopping-free TCH-assignment. > > I previously just tested SDCCH decryption and SMS decoding etc., but > only with my own SIM card which answered the auth request in a replay > session. > > > Some question that is aimed more towards the other readers: > Isn't it quite more comfortable not to share the whole raw 32bit float > IQ stream, but a reduced burst dump file? > > First I thought about pcap, but I think that format would be too > limiting if it comes to multi-ARFCN recording etc. > Also embedding metadata (Kc etc) is an interesting feature. > > Even when using a simple XML file, this will reduce the size by factor > ~100 uncompressed and factor ~500 compressed, which is way better to > backup, stream or record :) > Here an example containing bursts starting from TN 0 in FN 860910 on > ARFCN 761. Skipping dummy bursts (here TN 1) reduces the file size again. > > <b d="00000000000000000000000000000000000000" a="761" f="860910" t="0"/> > <b d="15CA2EA70716AF812E112E33369ECC4D22A100" t="2"/> > <b d="0CCB71F49C4AB8A12E112EB79F97C83ABAFF00"/> > > > Your thoughts on this? > Maybe there is an even better alternative already available? > > > BR, > Georg > > > ------------------------------ > > Message: 5 > Date: Wed, 15 Sep 2010 02:36:21 +0200 > From: Karsten Nohl <[email protected]> > Subject: Re: [A51] Traffic dump > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Georg, > > On 15-Sep-10 01:49, Georg Hofstetter wrote: > > Am 13.09.2010 18:12, schrieb sascha: > > Some question that is aimed more towards the other readers: > > Isn't it quite more comfortable not to share the whole raw 32bit float > > IQ stream, but a reduced burst dump file? > > > > First I thought about pcap, but I think that format would be too > > limiting if it comes to multi-ARFCN recording etc. > > Also embedding metadata (Kc etc) is an interesting feature. > > > > Even when using a simple XML file, this will reduce the size by factor > > ~100 uncompressed and factor ~500 compressed, which is way better to > > backup, stream or record :) > > Here an example containing bursts starting from TN 0 in FN 860910 on > > ARFCN 761. Skipping dummy bursts (here TN 1) reduces the file size again. > > > > <b d="00000000000000000000000000000000000000" a="761" f="860910" t="0"/> > > <b d="15CA2EA70716AF812E112E33369ECC4D22A100" t="2"/> > > <b d="0CCB71F49C4AB8A12E112EB79F97C83ABAFF00"/> > > I like the idea of having the stream pre-decoded for exchange. > Preferably the raw data would still be kept at the sender espacially for > noisy transmission with lots of errors in case better decoders become > available. > > > Your thoughts on this? > > Maybe there is an even better alternative already available? > > I think it should be implemented as close to gsmtap packets as possible. > Who is available to do this? > > Cheers, > > -Karsten > > > ------------------------------ > > Message: 6 > Date: Wed, 15 Sep 2010 10:11:51 +0200 > From: Harald Welte <[email protected]> > Subject: Re: [A51] Traffic dump > To: Karsten Nohl <[email protected]>,[email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=utf-8 > > Jfyi: GSMTAP already has a provision for carrying raw burst bits. This was > used early on in its history. Just look at the header file and look at all > the constants that are named BURST in there. > Also, as every gsmtap message has an ARFCN in the header, there is no > problem in having the data of multiple ARFCN in one gsmtap stream or file. > > -- > Sent from a mobile device, excuse my short response > > > ------------------------------ > > Message: 7 > Date: Wed, 15 Sep 2010 10:36:21 +0200 > From: Sylvain Munaut <[email protected]> > Subject: Re: [A51] Traffic dump > To: Harald Welte <[email protected]> > Cc: Karsten Nohl <[email protected]>, [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=UTF-8 > > > Jfyi: GSMTAP already has a provision for carrying raw burst bits. This > was used early on in its history. Just look at the header file and look at > all the constants that are named BURST in there. > > My latest experience with gsmtap to carry burst data wasn't very good. > (when working on passive listening with calypso). > > Some of the problems I encountered: > - No support for different data format > (soft/hard bits, with/without the TSC) > - sub_type field is re-used for the type of burst. But then you can't > set to what type of channel/subchannel this burst came from > (SDCCH/TCH/...) > - Can't give the number of the burst (0,1,2,3), so you have to > guess/reconstruct it > > I think it maybe time for a gsmtap v3 ... > Something more flexible > > I was thinking something with: > > [header] > [opt header 0] > .. > [opt header n-1] > [payload] > > with: > - header having a direct offset pointer to data > - Then each header having a pointer to the next header > > This way you could have > - Data Format header > - Cipher parameter header > - Physical channel description header > - Logical channel description header > - ... > > And we could add new meta data information without having to rewrite > each tool each time. Sure the generation / parsing would be slighly > more complex than now. > > But I think that with appropriate helpers in libosmocore, that > wouldn't be an issue. > > Writing precise/defined spec on the wiki would also be a requirement > because some fields are rather obscure right now ... (format of snr / > signal_dbm ?). > > If there is interest in such a new format, I can start drafting some specs. > > > Cheers, > > Sylvain > > > ------------------------------ > > Message: 8 > Date: Wed, 15 Sep 2010 10:42:22 +0200 > From: "Fabio Pietrosanti (naif)" <[email protected]> > Subject: Re: [A51] Several ARFCNs at once ? > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=UTF-8 > > On 14/09/10 16.15, sascha wrote: > > On Tue, Sep 14, 2010 at 12:49:29PM +0200, ??????? ???????? wrote: > > > >> Hello people, > >> > >> Is it possible to record several ARFCNs at once? Or record some narrow > band > >> (5 - 10 Mhz wide) and extract offline data for specific frequency from > band? > >> > > yes its possible but airprobe currently does not support hopping. It is > > on the todo list, though. > > > > mmmm but frequency hopping would mean following the ARFCN after the > information into the paging request. > So the listening would still be on a 200khz single channel. > > Instead would be very useful to be able to get the whole spectrum > available from the USRP (so multi-ARFCN) being it 8mhz or 25mhz. > > The ability of airprobe to decode a single capture file that include > more tha one ARFCN would open the capability to get immediately > multiple-ARFC (without freq hopping) and stacking-up multiple USRP2 to > catch the whole GSM spectrum. > > Does it sounds more simpler something like that? > > Fabio > > > ------------------------------ > > _______________________________________________ > A51 mailing list > [email protected] > http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51 > > > End of A51 Digest, Vol 16, Issue 8 > ********************************** >
_______________________________________________ A51 mailing list [email protected] http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51
