Contacting DHCP - a second chance?

As Risc OS boots up, it runs SetupNet to contact the DHCP server, but sometimes (for external reasons) this doesn’t work and a broadbandless computer is the result.

Is it possible (say when the line isn’t busy or you’ve switched the router on) to have a second chance at contacting the DHCP server without resetting the machine?

I’ve tried clicking on SetupNet, but it just ignores me.

Is it possible to have a second chance at contacting the DHCP server without resetting the machine?

The command that does the work is *dhcpexecute, see if that (or its help) helps

Press F12 and type

*DHCPExecute

This should reinit the DHCP process.

Okay, thanks for that – however, I get the error message:

Syntax: *DHCPExecute [-e] [-block] [-p] [-w] “interface”

*HELP says:

*DHCPExecute instructs the DHCP module to control the configuration of the specified interface.
        -e places any error message into Inet$Error
        -b blocks until the interface is bound
        -w waits for “interface” to appear
        -p assigns a private IP address if DHCP request times out

So what would be appropriate values for e, block, p, w, and interface?

Note that in the above post, quotation marks represent pointy brackets.

The parameters are optional, apart from the interface name.

So do: dhcpexecute x

Where x is the interface. I think inetinfo will list them.

So what would be appropriate values for e, block, p, w, and interface?

DHCPExecute -e -b -w -p EtherWibble

would appear to be a reasonable command string to configure interface EtherWibble to place any error in the variable Inet$Error, block until the interface is bound, wait for the interface to appear and assign a private IP (APIPA style) if the DHCP request times out.

*DHCPExecute -e -b -w -p EtherWibble

locked up the machine, until an Alt-Break invited me to stop Netsurf. So I did that then tried to restart Netsurf, which promptly blew up with more errors.

I then repeated the DHCPExecute command, which locked up the machine again, until an Alt-Break invited me to stop the next task, and then more DHCPExecute/Alt-Break cycles just sent the whole thing downhill.

I think inetinfo will list them.

*InetInfo (or *InetInfo r) produces…

Resource Usage: Sockets Active 9
Packet forwarding not in operation

*InetInfo i produces…

Name Mtu    Flags         (ifp)
lo0   16384  00008049  201479d4
ej0   1500    00018843  201684f4
Packet forwarding not in operation

..so which of those is the interface?

ej0. That is the usb ethernet interface – the other is a loopback interface. !Boot.Choices.Internet.Startup shows the obey file used when the internet starts up – if it’s any help

Yes, as Colin says, the interface is ej0 (lo0 is the loopback interface – a ‘virtual’ interface to your own computer). So, do: ‘dhcpexecute ej0’.

I couldn’t remember off-hand if the network setup screen in Boot showed any of this stuff, or even provided access to DHCP renew functionality. If not, there’s an idea for someone… :)

Okay, so I tried…

*DHCPExecute -e -b -w -p ej0

..and at first I thought it had locked up the machine like before, but no it hadn’t – and the broadband was working too! :-)

 
So many thanks to everybody for all their help, but why does DHCPExecute work instantly, while the boot-up command takes ages as it attempts to contact the DHCP server?

but why does DHCPExecute work instantly

Probably because at boot up it may be waiting for ej0 or some other dependency to start working. I tend to find if it doesn’t start within about 5secs it will time out.

Strange. As an experiment I unplugged my Iyonix (RO5.20) network cable and rebooted. After 10 minutes waiting to contact the DHCP server I gave up and pressed Escape. Big mistake! Although the boot seemed to progress normally, at the end I received the ‘Boot has failed’ message with options for a ‘Floppy Boot’ !!, a Retry or something else.

I am sure the timeout on my Pi is much shorter, but I cannot check as it is packed up for the show!

In my wanderings I have discovered the *DHCPInfo command, which now says:

DHCP 0.23  (20 Jul 2012)
Interface     : ek0
State         : BOUND
IP address    : 10.0.0.12
DHCP server   : 10.0.0.2
Renew lease   @ Sat Apr 25 04:18:31 2015
Rebind lease  @ Sat Apr 25 13:18:31 2015
Lease expires @ Sat Apr 25 16:18:31 2015

I’m running DHCP 0.26 and it times out in about 40secs. According to CVS the timeout was changed from 10mins to 20secs in version 0.22 so its odd that your 0.23 version takes 10 mins