Forcing static address in 12.04

rikona rikona at sonic.net
Sat Jun 13 05:43:18 UTC 2015


Hello Joel,

Friday, June 12, 2015, 6:17:31 PM, Joel wrote:

> 2015/06/13 7:45 "rikona" <rikona at sonic.net>:
>>
>> Hello Joel,
>>
>> Thursday, June 11, 2015, 6:09:00 AM, Joel wrote:
>>
>>
>> >>> > network 192.168.0.0
>> >>
>> >> Nope, not at all. That combination will work just fine, though the
>> >> network statement is misleading and unnecessary.
>>
>> > But don't you think it odd that he is back on-line after getting rid
>> > of that "misleading" definition of the base address of his network
>> > segment?
>>
>> That line was there in only one of several tries, none of which
>> worked. Probably not the thing that fixed it.

> IP is pretty simple, but the best kind of simplicity hides some
> complexities.

Sure does with networks... :-)

> I'm guessing, but I won't go beyond guessing, that getting that line
> out of that file was part of the process of getting the network
> definitions sane.

There were multiple things going on. When I corrected a mistake in
setting up the new router fixed addresses by MAC, it might be that
finally assigning the correct IPs from that point on might have made a
significant difference.

> Anyway, it helps you understand the structure of IP addresses.

>> It was, though, in the
>> blow-up try. :-) Could that have caused the blow-up? If so, how?

> Not highly likely, but not impossible.

> Sometimes, when I'm working on a function, I go down a wrong path with
> more than one error in my thinking, and in the code. And, when I get
> my thinking straightened out, I discover that it doesn't make sense to
> try to point at every possible wrong turn I made. You had lots of
> things that were in conflict.

> I have had a mis-configured nic drag a box into the tarpits, such that
> it was necessary to manually force a re-boot. Consider that the nic,
> being a high-bandwidth device, has the ability to interrupt the CPU at
> a very high rate. That doesn't leave a lot of CPU time for other jobs,
> including refreshing the display at a timely rate. Interrupt rates too
> high can even drag all the cores of a multi-core CPU into the mud. And
> slow screen updates can appear to be a screen gone crazy.

> If interrupts occur so fast that one interrupt handler is not finished
> before the CPU tries to handle the next, memory can be walked on, etc.

Interesting...

> Theoretically, yeah, it could have been part of the cause. Maybe. Or
> it could have been something else, which is something you want to
> consider carefully. (Check for unwanted software?)

>> > Well, I must admit, I am wondering whether the factory settings of
>> > the ASUS RT-N65R would have the router in the same network as the
>> > box in question if he used a /24.
>>
>> It is not the default - I input the address to use.

> It did not look like a factory setting. Which is kind of unfortunate.

> If I made routers, I hope that I would have the ambition to figure
> out a way to randomly set the default network to something other
> than the common 192.168.0.0 or 192.168.1.0 networks, among other
> things designed to reduce the profitability of attacking the routers
> I made.

Exactly. :-))

>> > Not that I'm interested enough to download the manual PDF to find
>> > out.
>>
>> Saved you a bit of work. :-)

> :)

> I do hope you have the manual handy.

I do - only a fair manual - much too oriented to win/apple. Uses a
guided setup which doesn't work well for significant differences from
a simple pure vanilla install. I went to custom settings right away -
needed to set up a dmz, for example. Lots of stuff on features - usb,
ftp, sharing, cloud, etc. which I am not using [yet? :-) ].

> Most manuals these days seem to be overweighted with advertizing,
> but they still have some important information in them.

Agreed. Nice to know where the tiny, well hidden factory reset is when
it gets really messed up. :-))

-- 

 rikona        




More information about the ubuntu-users mailing list