I have successfully installed NetBSD to my pi from the supplied images, but it is just the core system with no X server. I am a relative newby to Linux, let alone BSD and am slowly working my way around it, but I am struggling with pkg_add because I can't find a source file to match...
I downloaded rpi.img.gz from here:
I followed the instructions on this page, but fall down when trying to add packages
but when following the instructions here: https://www.netbsd.org/docs/pkgsrc/using.html
and here: http://www.netbsd.org/docs/guide/en/chap-boot.html
I cannot find a matching distribution.
uname -a reports:
NetBSD rpi 7.0_BETA NetBSD 7.0_BETA (RPI_201501031030Z) evbarm
but the closest I can get is
Should I be looking elsewhere for the repository?
The example code at
has a bug. It skips the first file in the directory of files it's supposed to monitor.
I was able to fix this by changeing line 51 to
while(cnt++ < 2 && (pdent = readdir(pdir)) != NULL)
Some of the links in the "Additional Info" section refer to wiki.netbsd.org, whereas they should refer to www.netbsd.org.
is a broken link.
But changing wiki to www works:
Links I've noticed that need correcting include:
Notes on System Models
I succeeded to connect via the serial port, but I have a first problems, the root partition exceeds the maximum capacity of the partition:
beagleboard# df -h
Filesystem Size Used Avail %Cap Mounted on
/dev/ld0a 434M 434M -21M 105% /
I could make some changes and I do not know if it came from there, but it is impossible to create user the database is apparently corrupt:
beagleboard# pwd_mkdb /etc/master.passwd
pwd_mkdb: Cannot open `/etc/spwd.db.tmp': File exists
in order to properly operate the cubietruck, I set up a fex/bin file to the root of my SD card.
I tried without the script, with a script modified to display on a VGA screen, as well as an original script for display on HDMI display, but none work.
I feel that the script is not even read it.
the LED display does not do properly. However, I checked several times, I put exactly what was stated in the wiki.
This is a really nice page, thank you. I just installed NetBSD 6.1.5 onto the notoriously quirky iMac G4 (take a look at some of the Debian/MintPPC/Ubuntu posts to see how nicely it plays with the nouveau driver) and I needed some workarounds, but otherwise these instructions worked well. I wanted to add this comment for people with that system, since it doesn't play nice.
follow these instructions closely, except alter the following:
don't bother trying to set up networking with sysinst- it doesn't do dhcp on this computer
pdisk is included on the 6.1.5 cd, so it doesn't need downloaded
newfs won't work on this setup with the command listed above, use #newfs /dev/rwd0c
(r for raw)
after installing the sets quit sysinst and chroot into the new installation
edit the rc.conf
change configured to YES,
add a root password
add a user and put her in group wheel
give them a password too.
edit fstab one more time to enable pty (needed to ssh in, at least on my computer)
add the line
ptyfs /dev/pts ptyfs rw 0 0
save, exit, reboot, boot cd:,ofwboot.xcf hd:3,/netbsd
and when the computer comes back up, it will show the kernel messages and then nothing. the messages will then scroll off the screen and there'll be an invisible console present. hence the need for ssh
ssh in from another computer, and do whatever configuration you want from that console
or, hit enter a few times to specify terminal type, etc, type your name, hit enter, password, hit enter, and then startx. x will load with twm as the window manager.
I can't get hformat to work with this version or this computer. It compiled correctly, but it will not format my boot partition. So I just use the cd to boot.
Thanks for your work putting this together! NetBSD was my savior when the Debian family switched from nv to nouveau. the iMac G4 needs nv.
Using NetBSD based sockets, implement a TCP client and TCP Server to demonstrate trivially secure file download from server.
Environment/Tools required: Linux RHEL4/5/6 and gcc/g++ compiler and vi editor (recommended) OR Windows XP/Vista/7/8 with Visual studio.
Learning Objective for student:
Understand Protocol messaging and parsing.
Manage multiple connections at a server side
Manage the state of a connection at both client and server side.
Ability to use NetBSD Sockets via C API.
Binary vs Text and practical issues with Endianness !
Ability to effectively use fread, fwrite APIs for file management
can also use read/write system calls.
Understanding Standards and compatibility (and the inherent difficulty!) between different (not differing!) implementations. Note: This is a group assignment. Each group can have maximum of 10 students.
If group of 10 students is opted, 5 students may contribute to the client and another 5 students may contribute to the server. but put together at a minimum, the expected result is a group's server should work with its own client.
If a group's server/client are compatible with other group's client/servers, it will receive more credit. ** Each group is expected to write both the client and a server." -1- Details:
The messaging mechanism is based on Type-Length-Value (TLV) The Message Format is TYPE Field ---- Length Field --- Value field --------------- ---- 8 bytes --- 4 Bytes int ---- buffer of length bytes ---- Note: If Length Field is ZERO, then the Value field is empty which is still a perfectly valid message.
eg. LOGINOK message - See details below.
All types are of size 8 chars and always uppercase. Valid Types for Client messages are: LOGIN, AUTH, GETFILE Valid Types for Server messages are: NEEDAUTH, LOGINOK, DATA, ERROR As Type field is 8 bytes, it will employ 'SPACE' as padding. i.e. LOGIN will be sent as "LOGIN "
The message exchange details are as below: Client connects to the server. LOGIN is the first message sent by the client. If server requires authentication, it replies with NEEDAUTH message. If server does not require authentication, it replies with LOGINOK message. Client sends back AUTH message as a reply to NEEDAUTH message Server replies with LOGINOK if authentication successful, else replies will reply with ERROR and close the connection. Client if login was ok, i.e. received LOGINOK message, can send at any time, a file download request by sending the message GETFILE. Note: Only outgoing request must be in the network pipe. Upon receiving a GETFILE message, if server finds a matching file it can send the file contents back in the DATA message. If no matching file, it may send back an ERROR message.
Note, any time the client can close the connection and go away,
server needs to detect this and close the connection on its side as well. eg. if while server is sending a file, the client goes away, server needs to stop then and there. -2-
The Client upon receiving the DATA message should store the contents appropriately into a file for later viewing.
Server never advertises the file list on the server (unlike SCP/SFTP/FTP !)
so clients need to know the file names
a simple way is to query the user Note: A fancy UI is not required, rather a basic working UI with scanf() or fgets() should suffice. Note about GETFILE: The GETFILE message can send as value a full path name (absolute) or a relative path name. with "/" as directory separator. eg. If "hello/details.txt" is sent, server is supposed to look in its working directory the given path of the file. So in this case "hello/details.txt" and "details.txt" may refer to completely different files. Command Line arguments:
./TSServer ./TSClient 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! NOTE: * 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!) -3-
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.
Extras/Optional: (Attempting will lead to Extra credit)
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! -4- Client side: 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 message syntax:
RANGE start end --- Value field has delimiter as CRLF "\r\n" eg. RANGE details.txt 20 300 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.