Internet not working. sharing from linux computer via ethernet

It’s not quite as simple as “just grey out the field” because then if someone’s previously entered a value in there then they won’t be able to remove it again.

Nulling out the saved value is what is needed

Meanwhile you also don’t want to automatically clear the field, because then if the user accidentally enables DHCP and hasn’t made a note of the previous gateway setting, then they’ll lose it.

DHCP will have picked up the correct gateway value, along with other correct values

That’s how, if I remember correctly, XP does it. It’s the acceptance of the given settings that determines what is retained or discarded.

You can always save settings in a script form in Windows. Well, lift the skirts, see the hairy legs:

netsh int ipv4 dump >myIPsettings
then
netsh exec myIPsettings

to restore things. You can of course keep several script variants to do swift fixed IP settings, although in a network with DHCP, why bother?

in a network with DHCP, why bother?

Because elsewhere on your network you might have a bloody Apple device that takes it into its stupid head to think that an address it was given the day before yesterday is still valid, regardless of clear information to the contrary. Or three or four of the little b****rs.

(I may be misunderstanding what’s going on there; if there’s a better explanation of the random lock-ups of the network that can be resolved by giving everything normally present a fixed address I’d be very interested to understand better.)

although in a network with DHCP, why bother?

Because traditional RISC OS handles DHCP only at boot time.

Pi (any RISC OS machine, really) boots in a few seconds.

Network router and broadband box boots in a few minutes.

See the problem here?

Resolved in two ways:

1, give the primary machines (RISC OS, Windows, printers) fixed IP addresses and mark them as reserved (associated with a MAC) in the Livebox NAT settings.

2, buy a mini UPS to maintain the 12V into the Livebox so it can keep on going through power glitches. This is important as a minor glitch that the Pi wouldn’t notice (the PC would!) is enough to reboot the router. Now no more.

misunderstanding what’s going on there

Apple does what Apple does regardless of what the rest of the world is doing. Some Apple services splatter so much crap on random ports that people on support forums will tell you that “the correct setting for the firewall on your router is OFF” because that’s so much simpler than describing what ports to open.

Not to mention, if you ever decide to remove site data and cookies on a one by one basis from something life iOS (rather than deleting all of it at once), then be prepared for a good third of the list to be endless <gibberish>.apple.com domains. Why?

So the fact that Apple doesn’t seem to bother with IP address expiry doesn’t surprise me. My old iPad Mini (iOS 7.something) has about 5GB of mail ¹ on it because it didn’t seem to understand the whole IMAP concept of “keep X days worth of messages”. Instead it downloaded and kept everything.

One of the richest companies in the world, making such ridiculous and basic errors (like Siri on a device without GPS complaining it doesn’t know where you are when you ask what the weather will be like, with no way of telling it where you, in fact, are), it does rather make you wonder about the coding environment within the company. Seems to me like they spend a lot more time polishing the shiny instead of making stuff work properly. [I found iOS 7 to be a bit of a downgrade compared to 6] ¹

¹ When the keyboard on her netbook gave up, mom took over the iPad for emails, Amazon, and looking at websites; so I didn’t want to touch it, didn’t want to do anything that might change how it behaved.

Because elsewhere on your network you might have a bloody Apple device that takes it into its stupid head to think that an address it was given the day before yesterday is still valid, regardless of clear information to the contrary.

It feels like a surrender, but reserve an IP for the MAC of the Apple device(s) – after you’ve turned off the “Private Address” setting to stop it chucking random MACs at your router “to reduce tracking across networks”

Resolved in two ways:

Option 2 :)

then be prepared for a good third of the list to be endless .apple.com domains. Why?

Probably the same reason they claim the whole 17.0.0.0/8, claim that critical URLs like mesu.apple.com can be on any of those and then start spewing URLs onto totally different IP ranges.

It feels like a surrender, but reserve an IP for the MAC of the Apple device(s) –

That’s the surrender I’ve already implemented. Reserving an IP for the Pi as well avoids the “Pi starts quicker than the NAS or the router” problem too.

after you’ve turned off the “Private Address” setting to stop it chucking random MACs

Bl**dy h**l – it does that? I don’t think that’s bitten me yet. Where is this “Private Address” setting? I’ve not come across that one.

Reserving an IP for the Pi as well avoids the “Pi starts quicker than the NAS or the router” problem too.

Sounds like you’re setting a manual IP on the Pi, rather than just a reservation that allows DHCP to allows hand out the same IP to the same MAC

Where is this “Private Address” setting?

Each SSID you’ve connected to has a set of config. Hit the (i) and look at the bottom of the screen that appears. Just below “Auto-Join”.

Sounds like you’re setting a manual IP on the Pi, rather than just a reservation that allows DHCP to allows hand out the same IP to the same MAC

Both, and matching. That seems to work!

Each SSID you’ve connected to has a set of config.

I know where the config for SSIDs is – but I see no “Private Address” below “Automatically Join this Network,” nor anywhere in the “Advanced” screen (where I can see all the other available networks). This is on the old (High Sierra) MacBook Air – I’m away from home, won’t be with the Pi and the Mac Mini (Mojave) until late Tuesday. (They’re both wired into the router, Mac’s WiFi disabled.)

I do like the idea of a UPS. I would like to have one for my internet modem, router, and the pi, as DSL internet usually doesn’t cut in the face of a localized power outage, at least it used to work like that (might have changed). Even so, one for the pi would be nice with its mere 5W of power it pulls.

This is on the old (High Sierra) MacBook Air

iPhone, 14.8, but the setting was there in the previous OS version or few. Apple probably expect it to be used across silly large numbers of different locations, whereas the MacBook is less so.

Re. changes to the network configuration interfaces:

At home, everything possible is on fixed IP addresses. When I take my RasPi to RONWUG meetings, I have to change it over to DHCP.

When I take it back home again, I have to put the gateway address in again.

Now that’s OK for me, because I know my networking and my network well enough to remember the gateway’s IP address, but it’s a reminder that destroying the gateway field’s content when switching to DHCP is not friendly.

When DHCP is selected, the gateway field’s entry:

• should not be used;
• should not be editable;
• should be visibly disabled;
• should be preserved, so when switching away from DHCP, it’s still there;
• if you think that a greyed-out but visible entry is confusing, then it should either be displayed like a password, be blanked, or be replaced by a message saying “DHCP in use” or some such.

I’ll go with Dave’s suggestion, as it based a common real world usage.

I think, rather than expecting the configuration tool to retain potentially stale data, that this is something better handled by profiles.

For example, holding down a key during boot will pop up a list of active profiles on the machine, which when selected will fire the Choices (and Scrap?) to point to a profile specific set of options.
Hold nothing during boot, it’ll carry on as normal.

should be preserved

Where?

As far as I am aware, the config tool reads the setup script to determine what to populate in its various fields.

Plus, there’s a better way to do this sort of thing, as I outlined above.

There’s nothing wrong with holding onto the unused value for later reuse. It should just be a case of – if DHCP is set then use the Gateway value obtained via DHCP, otherwise use the one stored in the config file.

Is there a valid use case for having a different Gateway address, and if so, is it “experts only” and would be better catered for outside the GUI?

At the moment, I would suggest – for the GUI – that if DHCP is active, the Gateway field should be disabled and a text like “automatically via DHCP” should be shown inside.

If there is a need for GUI support for the use case “Gateway address not given by DHCP, but manually defined” probably a red warning label in the “via DHCP” dialog as well as in the “Routing” dialog.

Is there a good reason to NOT have the DNS and the Gateway and the IP stuff in one place? Can RISC OS handle different name servers per interface? Can any other OS? Never thought about setting that up anywhere.

DHCP does not aleays use the gateway address from DHCP, sometimes it uses the ‘gateway’ value from the last manual set up. It is very annoying.

It is very annoying.

It is also very broken. If you’re using DHCP, there shouldn’t be any trace of a gateway (or any other setting) from a previous manual setup. The DHCP server assigns these things.

That’s why I would prefer !Boot to be extended to support some sort of user profile, rather than having the network setup tool “remember” previous settings. If it’s necessary to have multiple settings, they should be kept distinct and separate.

If the setup gizmo can’t entirely be trusted to do the current setup correctly, god help us if we further complicate things…

Beyond IP allocation, I view DHCP more as ‘here are some good suggestions for you to use’ and if you want to provide manual overrides for some of these, e.g. different DNS servers, then why not?

Is the real issue here that users type in their gateway address etc. and that manual configuration isn’t melded with that received from DHCP before applying those settings?

Is there a good reason to NOT have the DNS and the Gateway and the IP stuff in one place?

Yeah, I always felt it was potentially error prone to have settings in various different places.

Ideally, there would be a tabbed window which can switch the pane in the middle for IP, DNS, etc to keep everything together.

Can RISC OS handle different name servers per interface? Can any other OS?

Yes. Android. I’m walking around with the cats and when I’m near the house WiFi gets picked up on, DNS and gateway are the router (192.168.1.1) and when I’m further away it loses WiFi and switches to mobile comms. Currently 4G is with the IP address 10.155.175.139. There doesn’t seem to be a way to retrieve name server or DNS as this information is under About device → Status rather than Network Connections, suffice to say, it will no longer be using my router. ;)

Never thought about setting that up anywhere.

Given how mobile comms works, and the poor reception in parts the countryside, it’s quite possible to walk around the house, bounce between E (useless), 3G, H+, 4G, and 4G+ and incidentally end up with five different IP addresses in less than that number of minutes (which means this forum will expect me to log in all over again). This may or may not involve changes to name servers and gateways too. ¹

Quite normal for a phone. I’m just not entirely sure how RISC OS would cope with something like that.

It’ll be fun when IPv6 rolls around. You’ll have an IPv4 address and at least two IPv6 ones, one of which is randomised and changes every so often (but the previous will remain active so long as there’s an active connection, and be dropped once that closes).

¹ I have non root command line access via VX Connectbot (terminal app) so if anybody knows the magic incantation to read this sort of information, please let me know…

I’ve just been looking at the code. All the settings are indeed stored in !Boot.Choices.Internet.Startup It would be a doddle to change how it worked so as to load/store the gateway commented out to represent inactive, along with a boolean internally to note active status. From there it’s just a case of swapping the state of the boolean according to the GUI selection “Obtain IP address”. And of course what to display on the Gateway icon.

And it’s already all in C.

So it would appear to be easy to change the present GUI and data storage to work as I suggested above.

There is a case for altering the GUI so it’s all in one place, though I don’t feel the gain would be very significant. YMMV of course.

Beyond IP allocation, I view DHCP more as ‘here are some good suggestions for you to use’ and if you want to provide manual overrides for some of these, e.g. different DNS servers, then why not?

+1 I agree with Stuart. BTW this is how it works on Linux, BSD, macOS and also modern Windows.

Is the real issue here that users type in their gateway address etc. and that manual configuration isn’t melded with that received from DHCP before applying those settings?

Yes, basically most of the discussion seems to be related to that.

Edit: Don’t download this, except possibly to look at how the GUI works; it is buggy.

Edit 2: I’ve uploaded a new version that fixes all the bugs I’ve found.

On a temporary basis (and I’m not predicting for how long), a modified version of the RunImage file of the InetSetup application is available from my web site: https://davehigton.me.uk/Progs/inetsetup.zip

This implements the ideas discussed above. Please:

• Keep a copy of the original RunImage file that you can revert to if necessary;
• Let me know whether it works, and what you think.

If it turns out to be useful, I’ll submit the changes to ROOL.

At some future date I’ll remove the file and amend this posting accordingly.

The InetSetup app itself is at !Boot.Resources.Configure.

Thanks Dave, just tried it on my ARMX6 and it works.

It does throw up an error if you go in to Configuration>Network>Internet>Interfaces>Configure and then cancel the operation.

It says Internet setup may have gone wrong…clicking on describe gives Invalid Object id (0×0) (0×0) (0×1)

But if you just save what is already there and then reset it works so perhaps some validation issues on initial run?