Raspberry Pi (B rev 2 & B+), Vonets VAR11N WiFi Bridge, Motorola Lapdock 100

I have been successfully using the Vonets VAR11N to connect my Pi to my WiFi. It’s a tricky beast to set up but works well enough once sorted out.

Up until now I was using this on a Model B rev 2.0 with a Suptronics X100 Expansion Board which powered the Pi over GPIO, and connecting either to a VGA monitor via the X100 or to the TV through Composite Out.

I got a Motorola Lapdock 100 for Christmas – and apart from an issue with the keyboard not working with RiscOS (see here) I am liking it. I also got a model B+.

Now for the weirdness.

As stated in many places online, the Lapdock is just not simply plug and play. It needs special cables/adapaters and different models behave differently.

For example, my 100 “seems” to need to have the microUSB connector attached otherwise it shuts down after a few seconds. It also reportedly (I cannot confirm this as I have the correct cable) needs pin 17 on the HDMI connecting cable/adapter to be properly connected.

I should mention here that the network settings in RiscOS are set to DHCP – but with manually entered DNS servers – for some reason I just couldn’t get these to resolve without manual entry.

So, with my Br2/X100 powered by the X100 I booted RC12a – Internet working without errors.

Next I try the Br2 powered via the microUSB from the Lapdock (power jack to the X100 removed) – USB hub on X100 now not getting any power – presumably to do with the way it is connected (USB A-A bridging adapter).

So I remove the bridging adapter to free up the second USB port on Br2 and connect the power cable for the VAR11N – the Lapdock boots for a few seconds and then shuts down!!! This cycle repeats so I remove the VAR11N power cable to test and the lapdock boots without issue – USB Weirdness here.

Connecting the VAR11N power to the USB Hub in the Lapdock resulted in the boot getting much further, but then the Lapdock shutting down whilst the RiscOS boot process was “Contacting DHCP server for Ethernet over USB interface” – More USB weirdness.

I removed the bridge adapter to the unpowered X100 and tried again – RiscOS booted but now I get a DNS error in when trying to use the search box on the NetSurf welcome page – “Could resolve host ”http://www.google.co.uk">www.google.co.uk (Could not contact DNS servers)"

Rigging up the B+ I connect the USB cables exactly the same way as I did with the Br2 – Lapdock in bottom USB port (closest to the Ethernet socket) and the VAR11N power lead above it. Leaving the 2 USB ports on the right untouched. The Lapdock boots without issue – but I get the same DNS error.

Removing the DNS servers from !Configure > Network > Internet > Host Names > Uncheck “Try name server too (after the hosts file)” causes an error immediately when running NetSurf – “No domain name servers are configured, so only browsing local files will be possible. Use Configure to set your name server(s).”

adding “192.168.0.1 gateway” to the hosts file didn’t work, so I put it back in the domain name boxes. this stops the error on running NetSurf, but not the DNS error inside.

Setting it all manually just causes a “Resolving timed out 30000 milliseconds” error – besides, I want this to be portable so setting the IP manually to whatever the host network is pushing out is not really an option.

Finally a question

Is there anyway to re-initiate the DHCP within RiscOS without rebooting. Unless I power the VAR11N externally I can’t get an internet connection – which means I need to get an alternative power supply (even if it is a battery pack) to give it a head start.

Hope this hasn’t rambled too much.

Is there anyway to re-initiate the DHCP within RiscOS without rebooting.

Hear, hear!

My Pi starts up faster than the Vonets (mines a VAP11N) does.

And you can configure the VAP11N/R directly from RISC OS (with Netsurf)?

Is there anyway to re-initiate the DHCP within RiscOS without rebooting.

Pretty please. ;-)

And you can configure the VAP11N/R directly from RISC OS (with Netsurf)?

So far, only if the Pi has successfully negotiated DHCP.

If it had failed DHCP then much black magic is needed as the Vonets are not intuitive beasts.

Generally you configure them by going to http://vonets.cfg

However, even with a Windows or Linux machine that doesn’t always work.

If you have previously configured the device it’s a guessing game as to what IP to use to access it if it is forwarding your routers subnet.

Other than that general options are 192.168.1.254 or 192.168.253.254

But as yet I have had no luck as any manual configuration always comes up a timeout.

Is there anyway to re-initiate the DHCP within RiscOS without rebooting.

Pretty please. ;-)

AOL! (Is it AOL? Senior moment. Anyway, me too!)

My RPC drops power to the TP-Link at the wrong moment on a first boot.

So far, only if the Pi has successfully negotiated DHCP.

And as the adaptor is a bit slow to wake up, that can be a problem :)

Assuming that the IP is hard coded in RiscOS one it has negotiated DHCP, I wonder if it is possible to play a trick.

Let us assume we have a USB battery pack. Let’s power the Vonets/TP-Link/&c. from the battery pack, bout RiscOS, disconnect the battery and connect the adapter to the pi, let it talk to the router, and see if RiscOS thinks it had been connected all along.

I will try this later when I get home using another laptop as a power source.

Is there anyway to re-initiate the DHCP within RiscOS without rebooting.

There was a similar question in the newsgroups recently, so I had a bit of a play. It is certainly possible to reinitiate the DHCP module. However, this is nothing like the whole story.

When DHCP fails during boot, it means the internet stack is never set up correctly, so you would still not have any connection. I did manage to boot my machine with the ethernet cable unplugged, replug it, reinit the dhcp module and manually set up the internet stack, resulting in a fully operational network connection. I was going to see if it was possible to do it all from one obey file script, but became sidetracked, and then forgot about it.

Is it worth pursuing?

Yes, because:
- Ethernet can go wrong
- DHCP can renew IP address
- … of devices like Vonets :)

- DHCP can renew IP address

Not can but will renew at 50% of the lease time.

However, normally that is just a renewal of the same.
If you set a reservation in the server the same client will get that IP every time irrespective of switch offs, crowded scopes etc.

My machine at work is assigned an IP by DHCP – it’s had the same IP since I first got it^{1 2} and actually took over the IP of the previous machine because I changed the reservation MAC.

People seem to misunderstand DHCP.

¹ The firewall management system only talks to certain IP’s and the firewalls only allow ICMP traffic from certain IP’s

² Thinking about it it’s the same IP from the machine before the machine before. There’s two temperature sensors on 2.54.and .253 my machine is on .252 – who designed this schema? :)

As I understand DHCP – which isn’t a lot – I believe that unless there are no available IP’s for a new machine, then any machine reconnecting will usually be given the same IP on a release/renew or reconnect.

Let us assume we have a USB battery pack. Let’s power the Vonets/TP-Link/&c. from the battery pack, boot RiscOS, disconnect the battery and connect the adapter to the pi, let it talk to the router, and see if RiscOS thinks it had been connected all along.

I will try this later when I get home using another laptop as a power source.

That worked – I connected the Vonets to my PC to provide power, left it a couple of minutes to connect up. Booted the Pi, RiscOS booted ran NetSurf – web search worked.

Disconnected the power cable from my PC and connected it to the Pi, allowed it to reconnect and tried another search….

Bang – it worked.

So this is a work around, although an ugly one.

As I understand DHCP – which isn’t a lot – I believe that unless there are no available IP’s for a new machine, then any machine reconnecting will usually be given the same IP on a release/renew or reconnect.

Usually, the client asks to use the same IP. For the duration of the lease period this is exactly what it gets. From the server viewpoint it can’t, generally, tell the difference between a switched off and restarted machine requesting an IP or the same machine requesting a renewal at half duration when it has remained powered all the time.