Issues with a Wi-fi "A" Discussion

[Burngate]

Jimmy asks for a Raspberry Pi for his birthday. Granny gets him an A.

So I thought the idea was the Foundation did the hardware, and the locked GPU & Videocore stuff, and relied on the rest of us to support it with open-source software.
Are we now being told "Hands off - that's for the Foundation and its professional friends to deal with"?

Surely Raspbian, which wasn't created by the Foundation, is the bit with the Model A / wifi set-up problem, and it's down to its creators to sort it if they think it really is a problem?
And the suggestions so far - a text file in the boot partition - don't require the Foundation to be involved, only Raspbian.

Of course if Raspbian goes down that route, it would be nice if RISC OS followed, and they could go that way even if Rapbian didn't. Still without any Foundation input required?

No Smileys

[abishur]

Why do you actually WANT Wifi on the A

A Model A make the perfect controller for a robot vehicle - just needs the WiFI to let people talk to it through ssh/vnc/samba.

Yep, and like James said:

Now of course, there are the people who want an A with net access. They are almost exclusively people who are quite capable of setting up the Raspi, the hobbyists, the enthusiasts, who have specific purposes.

Using the A over the B means automatic saving of $10 (I'm currently using stepper motors that cost £2 each so $10 is quite a significant % of total project cost)

Also, low power requirement of the Model A means longer battery life or smaller (cheaper) battery can be used.

Multiply the savings if running say 10 of them in a class.

Simon

Which is all the hobbyist crowd, except for the last line, in which case I'm not sure if you're still referring to a hobbyist club, or if you're shifting gears and talking a programming class in which case it's already been stated (on another thread at any rate), that the RPF views the net capable Model B as more internet ready, and if you're going to buy a model A just for the money savings and then have to turn around and pay for a USB hub and wifi adapter then you would have been better off buying the model B and using the NIC

Now I think the OP has a validish statement, but I also think that it was answered in the second post. You can even do it without the wifi adapter attached at the time, no need for a hub. There are certainly extra issues surrounding USB in general which are being diligently worked on (poor pluggy you seem to have knack for finding USB devices which don't work )

Beyond that if someone wants to make a script to handle it in a different manner... well that's cool! It's linux people, making a random program to do something special is what it's all about! Does it need to be easier? I don't really think so but I'm think small hurdles like this are good for a new user to overcome because it teaches them so much. Can it be easier? Sure, the R-pi is all about community effort so if you want to change this up have fun doing it

[abishur]

Jimmy asks for a Raspberry Pi for his birthday. Granny gets him an A.

So I thought the idea was the Foundation did the hardware, and the locked GPU & Videocore stuff, and relied on the rest of us to support it with open-source software.
Are we now being told "Hands off - that's for the Foundation and its professional friends to deal with"?

Surely Raspbian, which wasn't created by the Foundation, is the bit with the Model A / wifi set-up problem, and it's down to its creators to sort it if they think it really is a problem?
And the suggestions so far - a text file in the boot partition - don't require the Foundation to be involved, only Raspbian.

Of course if Raspbian goes down that route, it would be nice if RISC OS followed, and they could go that way even if Rapbian didn't. Still without any Foundation input required?

No Smileys

No you're not being told that, things went south in a different thread and it seems to be having some bleed over here with lingering snarkyness; such as the smiley's thing. Which was due to someone putting a smile with just about every carriage return, some might argue that it was to hide all caps words that basically implied the RPF were blind idiots, others would say there was over reacting. I would say he who let's a locked thread bleed into a new one will find that one locked to... but I wasn't involved it so I don't have any emotional investment in the subject one way or the other

[Burngate]

... such as the smiley's thing. Which was due to someone putting a smile with just about every carriage return, some might argue that it was to hide all caps words that basically implied the RPF were blind idiots, others would say there was over reacting. I would say he who let's a locked thread bleed into a new one will find that one locked to... but I wasn't involved it so I don't have any emotional investment in the subject one way or the other

Yes, you're right. I'm sorry.
My brain concatenated the two threads, which is strange, because it can't normally handle words with more than three syllables

My main concern here is that there appears to be a perception that the A is a hardware-hackers' device, and that otherwise it'll be in a classroom situation where "someone who knows" will be able to sort it, whereas I see it also being bought by mistake by someone who doesn't yet know, and who we should also support

[Jim JKla]

I am the OP here I set a challenge to the community with a hypothtical (thought experiment) scenario searching for an easier way to set up Wi-fi on a model "A" I have since qualified that original challenge setting stronger boundries i.e. No additional hardware solution and the fix should be implementable using a text editor in the non Linux partition.

Ever since I have faced loads of arguments from the most unlikely people trying to kill off this thought experiment on the grounds that it is not needed.

Will you please stop sniping, if it's viable some one will respond and find a solution. If it is imposible it will fade into non existence.

PLEASE It's a challenge not an atempt to displace the Foundation and absolutly all attempts to say it is not needed smack of a heresy argument.

I am looking for a simple soloution to a considered accedemicly proposed problem.

It may or may not be needed but please allow me to consider it as a problem worthy of consideration.

[simplesi]

And the suggestions so far - a text file in the boot partition - don't require the Foundation to be involved, only Raspbian.

Your quite right with this one - its just the forum seems to be the best place to keep all the ideas toehter and for people to suggest/implement these ideas.

Mabe hardlinking /etc files to /boot IS the solution (I sort of doubt this as I think the /etc file structure is probably a good one to try and stick with whatever Debian dictates/suggests) but maybe a one-off start up script that could pre-populate the correct settings in the /etc files would be a better solution

(I've got an attempt at doing something similar to set RPI name based on serial number but my lack of in-depth knowledge on Debian init.d stuff has let me down so I know I'm not the one for this job )

Simon

[jamesh]

I am the OP here I set a challenge to the community with a hypothtical (thought experiment) scenario searching for an easier way to set up Wi-fi on a model "A" I have since qualified that original challenge setting stronger boundries i.e. No additional hardware solution and the fix should be implementable using a text editor in the non Linux partition.

Ever since I have faced loads of arguments from the most unlikely people trying to kill off this thought experiment on the grounds that it is not needed.

Will you please stop sniping, if it's viable some one will respond and find a solution. If it is imposible it will fade into non existence.

PLEASE It's a challenge not an atempt to displace the Foundation and absolutly all attempts to say it is not needed smack of a heresy argument.

I am looking for a simple soloution to a considered accedemicly proposed problem.

It may or may not be needed but please allow me to consider it as a problem worthy of consideration.

It don't think anyone has said it's not needed, have they? There's an argument to be had that the use case you are answering is not a particular common one, which is how I see it. But no-one has said there isn't actually an issue here, minor though it seems to be. Which is why this thread is still going.

I can think of better things to be spending brain power on though!

[abishur]

My main concern here is that there appears to be a perception that the A is a hardware-hackers' device, and that otherwise it'll be in a classroom situation where "someone who knows" will be able to sort it, whereas I see it also being bought by mistake by someone who doesn't yet know, and who we should also support

If that's how we're coming off then we've grossly mistyped our intents! I do think that the Model A will *mainly* be a hobbyist's device or in some sort of classroom situation, but to say that something will be mainly used for a specific task means that it will at times be used for other tasks Even though the base hardware of the two models are identical (base meaning not the ethernet/USB hub), there will always be little quirks that cause them to behave differently and people will need support for it and we will ABSOLUTELY provide it

[abishur]

I am the OP here I set a challenge to the community with a hypothtical (thought experiment) scenario searching for an easier way to set up Wi-fi on a model "A" I have since qualified that original challenge setting stronger boundries i.e. No additional hardware solution and the fix should be implementable using a text editor in the non Linux partition.

Ever since I have faced loads of arguments from the most unlikely people trying to kill off this thought experiment on the grounds that it is not needed.

Will you please stop sniping, if it's viable some one will respond and find a solution. If it is imposible it will fade into non existence.

PLEASE It's a challenge not an atempt to displace the Foundation and absolutly all attempts to say it is not needed smack of a heresy argument.

I am looking for a simple soloution to a considered accedemicly proposed problem.

It may or may not be needed but please allow me to consider it as a problem worthy of consideration.

Let's step back here a little and breath, okay? I know you're the OP, I did take the time to read the thread I promise

There has been a lot of push back on the thread from the user population in general because it's hard to following a moving goal post, but no one is trying to kill of your experiment in any way other than by providing a solution to your problem with means other than the one you want. And, I think a lot of people seemed to have missed that you were discussing a thought exercise, not an actual problem you need a fix to.

No one has been insinuating that you're trying to displace the Foundation, I'm not sure where you're getting that from, but I get the feeling all sides need to stand down here and just let this thread focus on the OP rather than being drug down.

As a side note, I have no issues with someone making a thread asking what people plant to use/ have used the model A for much like the thread we had for the model B. It's all about how you word things

[simplesi]

but I get the feeling all sides need to stand down here and just let this thread focus on the OP rather than being drug down.

Simon

[simplesi]

@Jim
I'll take the proposal down the local Raspberry Jams (going to Preston on Monday and Manchester week Saturday) and see if I can interest any Debian gurus that come along.

I might even get to bump into Peter Green, half of the Raspbian team, and see what he thinks but its a bit below his pay grade and I don't like to bother him with trivial stuff

Simon

[Jim JKla]

I have it working but not by the method I have been seeking.

I built a clean image of the latest Wheezy on a 4g card put it into my model "B" RPi set upthe Wi-fi in the X window put the n150 and the SD into my "A" and it's fine but this is not an easy solution if you only have one "A" to work with.

When you consider all you want to stuff into your image is SSID a password and the security option there should be a way to cater for that information in a seperate text file accessed by a script or posibly some increased functionality added to config.txt.

We allready have loads of options in the expanded config.txt file I am open to reasons why this text file option should not be expanded to include the above and posibly fixed ip information after all it's allready used for Audio and HDMI options why not a couple of Networking ones.

I don't want an argument over weather or not this can be done by other means because thats allready the case for the Audio and HDMI but they are in the config.txt. If not in that text file then why not in the raspi-config script we allready have options in there to make keyboard selection and timezone these too could be done by digging in command line Linux. There is one that I do to make my screen more readable I change the default settings for the /etc/default/console-setup. This is quite easy to do from command line it makes raspi-config a lot easier to read. Again there are other ways but is there any harm in offering an easy option. The font changes to "Terminus" and the font size to "32x16" retain the speechmarks.

If you consider this a waste of time just walk away I don't want to argue in fact if you can think of anything else that could benifit maybe a script to set up multiple external USB sticks/pendrives or an automated way of making the minimalised SD with the bulk of the files on a mounted USB stick with the script migrating the root file system from the SD to the pendrive. OK the USB pendrive/stick option would be limited to a "B" or an "A" with a USB hub.

I do know the Rasbian install is supposed to do this sort of thing but when I tried with the n150 on the "A" it connected downloaded the image then just plain forgot about the wi-fi settings I think they get overwritten by the download which is a bit of a bummer.

Obviously thats one for the Rasbian installer not here.

If you have knowledge and are interested I would like to have a go at sorting this with software and if your insistant on solving this with hardware or consider it a waste of time please please walk away. I have done it the hardware way I know it works.

Now I want to consider software solutions that use either a text file in the windows accessable partition or an expansion to the raspi-config script or another script that works in a similar way. Note Not command line and not X window.

[abishur]

Just my two cents:

I would avoid re-using the config.txt file as everything in there relates to boot time "tweaks" to the GPU. Putting in some text about IP settings shouldn't mess anything up, but it would be better to keep them separate.

I would equally avoid modifying raspi-config simply because of the overall constraints you've set up in this scenario. If you're going to hook up a keyboard for the first boot then you might as well just let the user modify /etc/network/interfaces. On an unrelated note, a "set up wifi option" would be fairly cool in raspi-config in general, though it might prove frustrating for those who need to take special steps to get their wifi chipset operational and get confused why it doesn't work after setting it up in raspi-config

To best fit your scenario, I would say to go with adding a separate txt file in the fat32 partition. Say something like wifi.txt. Then you could make a python script that

1. Checks for the wifi.txt file
2. If found grab information from it and put it into /etc/network/interfaces (yay for grep!)
3. Delete wifi.txt. file when done (don't want to mess up future changes just because you rebooted)

[Jim JKla]

Sounds reasonable.

I was thinking the raspi-config as an option because something like a fixed ip address would probably be a one shot first time likewise adding a SSID and password because if you want to do the last step of the raspi-config surely you need that ssid and password doing before you try to update?

[abishur]

I can't believe I'm necroing this thread, but I was wondering if you ever did anything with this.

I also had a moment today where I thought, why not just put the interfaces file on the fat32 partition and do a symbolic link to it in /etc/network. This would allow you to modify your network setup from any computer with FAT32 support and would have the added benefit of not needing any special programming.

[simplesi]

Yep - that would be a good start - just needs to be "built in" on the main downloadable RPi image so that no egg is required to produce a chicken

Simon
PS I've gone as far as moving my wpa-conf file nto /boot

Code: Select all

auto lo

iface lo inet loopback
iface eth0 inet dhcp

allow-hotplug wlan0
iface wlan0 inet dhcp
  wpa-conf /boot/wifi.conf
iface default inet dhcp

[abishur]

Over the past week I've been messing around with this issue, I decided that I wanted it to be a larger solution than just for wifi issues. The end result was this program

https://github.com/abishur/rpi-conf

it's not part of the image, but it is ready for serious testing and attempts to break it.

It works by copying user defined files off the EXT4 partition and into the FAT32 partition on boot so they can be edited from a computer that can't access EXT4 partitions. The file is then copied back, and after making sure everything is working right you can set the file in the FAT32 partition to be deleted on the next boot. It's written in python simply because I thought it would be fun/funny to keep it in the language that is the Raspberry "Pi"s name sake.

[simplesi]

Great stuff
Just trying to get my head into gear over how it works

Could you post a simple example of how to setup so you can just change the wpa supplicant stuff to change wifi SSID/password settings please?

Simon

[abishur]

Great stuff
Just trying to get my head into gear over how it works

Could you post a simple example of how to setup so you can just change the wpa supplicant stuff to change wifi SSID/password settings please?

Simon

I've added the file "example" to the github which contains detailed instructions on how to use it to modify wpa_supplicant.conf. It should be detailed enough such that one can deduce how to configure it for other files

Here's a direct link to the example: https://github.com/abishur/rpi-conf/blob/master/example

[MrEngman]

If editing files in Windows, with normal Windows editors, won't there be possible problems with line endings when trying to run them on the Pi? May be a good idea to suggest a suitable editor that can produce files with Linux compatible line endings. I use an editor - notepad++, http://notepad-plus-plus.org/ - which I quite like.

On a rather different note, back in the good old days of squeeze there was a file in the /boot directory - boot_enable_ssh.rc - which if renamed to boot.rc would run and enable SSH. In those days SSH was not enabled by default. Editing this file and you can do all sorts of things including installing wifi.

Unfortunately this file is not included in images these days or it would be possible to install wifi without having to edit or install anything on the Pi by hand, it can automatically be done at boot time by installing any needed files in the boot directory and setting up boot.rc as needed when the image is created, in my case on my Windows laptop.

I have been playing with this and modified one of my SD cards to run boot.rc by editing /etc/rc.local to include a call to it. I have been able to get wifi running by setting up boot.rc to copy a suitably set up interfaces file put in the /boot directory to /etc/network/interfaces. I haven't bother with wpa_supplicant but setting up wpa_supplicant.conf should be no different I think. I have also got it to install a driver, which also included downloading it from dropbox, for a module using the realtek 8188eu and bring up the drive on the first boot of a new image on a B Pi. Would be good for getting wifi up on the model A Pi if all needed files were in the /boot directory when first booted as no connection to the internet or anything else is needed, no display, keyboard etc.

As an example here is the modified /etc/rc.local including the call to boot.rc copied from an old version of code

Code: Select all

pi@raspberrypi ~ $ cat /etc/rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

if [ -x /boot/boot.rc ]; then
    # note the user could easily try to make or edit this file in Windows
    # this will give it the wrong line endings and may result in errors
    # we try to discourage this my not making it a .txt file
    . /boot/boot.rc
fi

# Print the IP address
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
  printf "My IP address is %s\n" "$_IP"
fi

exit 0
pi@raspberrypi ~ $

and an example of boot.rc used to set up /etc/network/interfaces and stuff to download a driver module, commented out here, as an example of what is possible

Code: Select all

pi@raspberrypi ~ $ cat /boot/boot.rc
# sourced from rc.local on Raspberry Pi
#
# Name this file as "boot.rc" and put it on the boot partition if you want to run it.
# echo "Checking if interfaces is installed"
if [ -x /boot/interfaces ] ; then
    mv -f /boot/interfaces /etc/network/
#    wget https://dl.dropboxusercontent.com/u/80256631/8188eu-20130209.tar.gz
#    tar -zxvf 8188eu-20130209.tar.gz
#    install -p -m 644 8188eu.ko /lib/modules/3.6.11+/kernel/drivers/net/wireless
#    rm 8188eu*
#    insmod /lib/modules/3.6.11+/kernel/drivers/net/wireless/8188eu.ko
#    depmod -a
     reboot
fi
pi@raspberrypi ~ $

Pretty crude but it works. Now if only current images made the call to boot.rc .... Something to think about maybe.


MrEngman

[simplesi]

I so, so happy that people what know and can do have turned up to help

@MrEngman
I've had concerns as well over adding the wrong LF or CR/LF and I do use npp++ as my default editor on PCs for any text files.. But how do you tell npp++ not to treat it like a Windows file? Or does it auto-magically detect Unix line ends and just follows suit?

Simon

[MrEngman]

I so, so happy that people what know and can do have turned up to help

@MrEngman
I've had concerns as well over adding the wrong LF or CR/LF and I do use npp++ as my default editor on PCs for any text files.. But how do you tell npp++ not to treat it like a Windows file? Or does it auto-magically detect Unix line ends and just follows suit?

Simon

If npp++ is notepad++ then in the edit tab select EOL Conversion and you can set which line ending the file will use, Windows/Unix/Mac. It sets this automatically when it loads a file depending on the line endings it finds and when you select EOL Conversion the format being used is the one greyed out. You can then change it if you need to by selecting one of the other formats.


MrEngman

[simplesi]

Pretty crude but it works. Now if only current images made the call to boot.rc .... Something to think about maybe.

Well - what we need is for someone involved in the Foundation Raspbian build process to come along and add in back in

Or explain that there's a good reason for removing it and that it can't be done

Simon

[abishur]

If editing files in Windows, with normal Windows editors, won't there be possible problems with line endings when trying to run them on the Pi? May be a good idea to suggest a suitable editor that can produce files with Linux compatible line endings. I use an editor - notepad++, http://notepad-plus-plus.org/ - which I quite like.

On a rather different note, back in the good old days of squeeze there was a file in the /boot directory - boot_enable_ssh.rc - which if renamed to boot.rc would run and enable SSH. In those days SSH was not enabled by default. Editing this file and you can do all sorts of things including installing wifi.

Good point, I'll make a note to be sure to use notepad++.

This program is seeking to fill in boot.rc being gone and make it easier so people don't have to know a lot of linux to get it all working. Which is why I'd like to streamline it to be a little more simpler. On that note I'll modify things a little bit to just have list in /boot rather than having to copy it back and forth.

[MrEngman]

This program is seeking to fill in boot.rc being gone and make it easier so people don't have to know a lot of linux to get it all working. Which is why I'd like to streamline it to be a little more simpler. On that note I'll modify things a little bit to just have list in /boot rather than having to copy it back and forth.

Well it looks like our aims are pretty much the same. It just looked to me that to use your idea required some connectivity with the Pi although I could be wrong. Trying to figure out what Python does is a bit of a mystery to me. My primary programming language is Zilog Z80 assembler.

My principal aim is to be able to generate that initial connectivity or to do whatever initial setup is required without needing to connect the Pi to anything. Especially useful in getting a Pi model A up with a wifi for instance, which quite a few people have indicated they would like to do, with no need to connect a display or keyboard to be able to do it. I don't currently have a model A but have tried it with a model B and it works a treat. Instant wifi on first booting a newly installed image with nothing connected other than a wifi dongle.

Well not quite true, I had to modify /etc/rc.local to get boot.rc called but I did this by mounting the SD card and editing it on another Linux system before booting it up on the Pi. So without a call to boot.rc built in my method is something of a dream but I suppose could be useful for someone prepared to do what I did to get it running.

I have this nasty habit of trying to keep things as simple as possible, you know KISS and all that, and it seems an easy way to do it. The less you have to do the least likely it is you will have problems or make errors. So just using wifi as an example all that is needed is a copy of the interfaces file and a correctly configured boot.rc used to copy it to the right place and then bring it up.

And of course to make all this possible one other item of major importance especially for newcomers is accurate, concise and easily understandable documentation written in plain ordinary language rather than in Linux speak .


MrEngman