I am interested in working on this project. I would like to know if any work is being done with respect to this project?
Any response and pointers would be greatly appreciated!
the GRex mystery is solved.
You have to use the first memorywindow (BAR) for the XROMBAR.
After activating (here at $8000.0000 with a Radeon9250 256MB) you could copy the ROM to somwhere in the RAM.
Next step, deactivate XROMBAR and reactivate the old BAR.
Andre "Ratte" Pfeiffer
It is not finished. Ask on tech-kern for more information about the
Please provide the source code the for the below question.
There are totally 7 messages - Syntax/Structure is as below. 1. LOGIN 2. NEEDAUTH - randomly generated 3. AUTH 4. LOGINOK - no value sent. O byte length 5. ERROR - can be 0 byte length or contain an error string 6. GETFILE 7. DATA - x bytes indicating size + x bytes of data Note: x can be 0. which means empty file! A Sample Messaging
C - Client; S - Server
C: LOGIN rajesh S: NEEDAUTH aa1123 C: AUTH <Hash(Password + aa1123)> S: LOGINOK C: GETFILE detail.txt S: ERROR "No Such file" C: GETFILE details.txt S: DATA 100 "some data ... of 100 bytes" Client closes the connection after receiving the DATA and stores the data received into a file.
Using NetBSD based sockets, implement a TCP client and TCP Server to demonstrate trivially secure file download from server.
Linux RHEL4/5/6 and gcc/g++ compiler and vi editor
Windows XP/Vista/7/8 with Visual studio.
Note about Auth Mechanism:
Any 2-way auth mechanism can be employed, trivially a
Salted Password hash based mechanism can be employed.
This avoids replay attacks!
* If the environment chosen is Linux, it comes with a tool called
'md5sum' which can be used to generate the Hashes
on both client side and server side.
* The server can store the list of passwords in some file.
(Bad! Not secure, but ok for this barebones version)
* Both the server and client programs may run in the same machine
during development, but for testing it would be ideal to
run them in different machines, to see how a client/server reacts
when network goes away. ( Intentionally pull out the ethernet cable
when the client is downloading a big file!)
There are totally 7 messages - Syntax/Structure is as below.
2. NEEDAUTH - randomly generated
- no value sent. O byte length
- can be 0 byte length or contain an error string
7. DATA - x bytes indicating size + x bytes of data
Note: x can be 0. which means empty file!
A Sample Messaging
C: LOGIN rajesh
S: NEEDAUTH aa1123
C: AUTH <Hash(Password + aa1123)>
C: GETFILE detail.txt
S: ERROR "No Such file"
C: GETFILE details.txt
S: DATA 100 "some data ... of 100 bytes"
Client closes the connection after receiving the DATA
and stores the data received into a file.
Server side :
1. Server can timeout an idle connection, where the idle timeout can be
set as a command line argument.
2. Server can close the connection if client sends 'x' number of bad
GETFILE messages. 'x' can be made configurable.
3. Server side handling of BAD Clients sending
BAD/Invalid Messages/Out-of-Sequence Messages
eg. A Client connecting and trying to send GETFILE Message without sending LOGIN
4. Implementing a simple Server side log with timestamp.
5. Server support for parallel multiple client connections
with select() and FDSET mechanism of checking socket data availability
or truly parallel threaded server!
1. Supporting Parallel Connections to download multiple files from the server
at a same time. eg. Via the UI can get the list of files as input from the user
and open multiple parallel connections to the server
send it to the server and start downloading the files at the same time.
- Will need to reuse the connections as well.
2. Implementing a simple Client side download log with timestamp.
3. Take a download folder as a command line argument and
all downloaded files with unique names to be stored in this folder.
eg. if same file is downloaded twice, each filename will be unique
by suffixing it with a timestamp.
Note: As can be seen, the filesize in this barebones mechanism
is restricted to 232 bytes - 4GB as the length field is only 4 Bytes.
Extras (needs both server and client side co-operative changes)
- Ability to support better Authentication schemes.
- Ability to support big files on server side and client side
- Ability to support RANGE where the server can send a portion of the file.
RANGE start end --- Value field has delimiter as CRLF "\r\n"
eg. RANGE details.txt
When server receives a RANGE message it reads the file only the range requested
i.e. 20 to 300 bytes (both inclusive) and returns that data.
so data size will be typically end-start+1 bytes
in this case 300-20+1 = 281 bytes
Of course, if the file is much smaller than 300 bytes,
server can only send the available bytes.
Server should not choke on invalid RANGE values sent by a client,
if 'start' is greater than 'end', etc.
nice to see a more updated Xen how to.
But I am curious on that: why not use /usr/pkg/etc/rc.d instead of polluting /etc/rc.d with third part scripts?
you may want to remove or rewrite "During the partitioning process, do not delete or format the first MSDOS (FAT) partition, as the Raspberry pi firmware" ---> this is the Beaglebone webpage, not the RPI.
According to http://wiki.beyondlogic.org/ the boot sequence is : "By default, the ROM in the Sitara AM3359 will boot from the MMC1 interface first (the onboard eMMC), followed by MMC0 (MicroSD), UART0 and USB0..."