Network reconfiguration without restart

Reconfiguration of the/a network interface should not need RISC OS to be restarted, as it does at present. Even Microsoft doesn’t require Windows to be rebooted for that.

I’m really puzzled why RISC OS requires it. Maybe it was just the easiest way. Certainly I can reconfigure an IP address, netmask and gateway by just issuing a couple of command lines.

Later RISC OS Select’s do not need a reboot after network changes. Also:
*ifconfig ex0 10.1.2.3 netmask 255.255.255.0
can be used on an A9home with a blank harddrive i.e. !Boot not having been run!

I wonder if rmreinit & *commasnds in the right order might work on RO5!

IIRC there are a bunch of ‘emergency’ network commands which get built into ResourceFS. Not sure exactly what would be necessary to use them to bring up a network connection.

Of course, what would really be useful from the POV of getting a blank machine up and running would be if DHCP & ShareFS (and NFS and Samba!) worked out of the box.

I can issue the ifconfig and route commands just fine. A solution for DHCP when the network is disconnected is being worked on.

We all know it can be done. A couple of us are working towards productionising it.

I can issue the ifconfig and route commands just fine.

Although since both these commands form part of the boot sequence, they won’t work on a ‘blank’ machine. I assume, given Chris’s comment, that ifconfig on an A9Home was built into ROM?

productionising

ewwww! :)

Of course, what would really be useful from the POV of getting a blank machine up and running would be if DHCP & ShareFS (and NFS and Samba!) worked out of the box.

In what way don’t DHCP and ShareFS work out of the box?

I’ve not used DHCP in years, since the first experiments taught me that fixed addressing is far easier, so I have no recent experience of it. I use ShareFS all the time, and I’ve always considered it as working out of the box… but it’s a very long time since I set it up, so there may be difficulties that I’ve forgotten.

NFS is only going to work out of the box if we get NFS client and/or server supplied with !Boot. Has anyone tried to agree distribution with Alex Waugh?

Samba is something I’ve tried several times, but never managed to get working reliably. I was most successful nearly 10 years ago with a Risc PC at work, but, when I put some photos of the office Christmas do on it and publicised the URL, it fell over after a while. I have utterly failed to get the recent RPi and BBxM builds to stay up on their respective platforms for even the first access. Desirable goal, yes; but I don’t know how we’re going to achieve it. In the other direction, I have found LanMan98 rock solid.

Of course, none of these is going to work out of the box just by magic; each of them needs some configuration.

I’m working under the assumption that, when a link fails for a short time, there are some DHCP servers out there that will return a different address when the device reconnects. (My BT Infinity external address is certainly like that, though of course a RISC OS computer would not see such an address directly.)

Can anyone persuade me that it can’t possibly happen in real life?

Because, if it does, a proper network setup system will have to keep probing the network state and, when the link fails, periodically attempt to renegotiate DHCP until it succeeds. IIUC that’s very different from how RISC OS has behaved previously.

And how does one probe the link state? Since it has to be done periodically, it mustn’t take significant time, or desktop response would be impacted.

a proper network setup system will have to keep probing the network state and, when the link fails, periodically attempt to renegotiate DHCP until it succeeds.

Yes, precisely. If a NIC sees a live link it attempts to obtain an IP from a DHCP server, if that fails then if configured for APIPA behaviour it will self assign an address from the 169.254.0.0 block. At intervals (about 15 mins IIRC) it will attempt to obtain an IP from a DHCP server. Or you have an alternate IP preset.

IIUC that’s very different from how RISC OS has behaved previously.

True, RO networking behaviour is a bit, erm, elderly.

BTW.

there are some DHCP servers out there that will return a different address when the device reconnects. (My BT Infinity external address is certainly like that,

DSLAM behaviour – it’s the network side of the DSLAM that has the MAC that is associated with with the IP, your subscriber line is multiplexed onto one of the MAC/IP combinations usually in a round robin fashion.

Not really typical of a network switch and DHCP client / server setup

A google search https://www.google.co.uk/?gws_rd=ssl#q=dhcp+client-server+scenario throws up decent links

Generally speaking the following should apply in these situations.

A host can send out either a DHCPREQUEST or a DHCPRENEW (DHCPREQUEST with a specified address), depending on whether or not it knows the previous DHCP-assigned address.

In the case of a DHCPREQUEST, if it is within the lease time of the last DHCP address assigned to that MAC address, a well-behaved DHCP server should re-assign the same address and reset the lease time. Once the lease has expired, however, the DHCP server is free to allocate the address to the next host that requests one and return a different address to the RENEW request from the original host, which the host should gracefully deal with.

It should, however, be trivial to allow a manual RENEW of a DHCP address, without a restart – I’m surprised this isn’t possible

For info, useful stuff (including state diagram) is here: https://www.ietf.org/rfc/rfc2131.txt

I was under the impression after the suggestions I made (that Rik Griffin then improved and coded) meant that at least DHCP worked sensibly and could be enabled out of the box on RISCOS, but that doesn’t appear to be the case, which is a shame.

Oh and addendum: Obviously being able to detect hardware state (link enabled etc.) makes things significantly easier and saves bootup time, though that didn’t seem to be possible with the Pi when the DHCP changes were made.

When, other than just after boot-up and halfway through the term of the lease, should DHCP attempt to renegotiate?

I assume that one occasion is when “the link is down” – but what condition is that, exactly? Does it mean that the Ethernet cable is unplugged?

Is there any event when the Ethernet cable is unplugged, or does it mean repeatedly asking ejinfo or equivalent?

Not really much point when the link is down – link coming back up is when your next DHCPREQUEST should go out. The hardware in the pi is certainly capable of sensing the physical link state, though whether it generates an interrupt on state change, or has to be polled, I don’t know.

And the other occasion, ideally, would be when someone hits the ‘renew DHCP lease’ button, or changes the config from non-DHCP to DHCP.