Message from @devpav

Discord ID: 495662237399121921


2018-09-29 17:58:17 UTC  

Otherwise you will have modem acting as router and router being router, you will get 2 routers

2018-09-29 17:58:32 UTC  

It does look like a DHCP client issue involving eth0.

2018-09-29 17:58:49 UTC  

Not really

2018-09-29 17:59:20 UTC  

Their modem gives a private ip on startup, then gives a public ip on link establish with internet

2018-09-29 17:59:35 UTC  

"?Looks like the dhcp client under eth0 made zebra thinking the broadcast address wasn't right. If WAN/Internet access is fine then there isn't much to worry about. You can try renew dhcp for eth0 see if the message would occur again, also you can check "show interface ethernet eth0", "show ip route", and "show ip route forward" outputs see if anything doesn't look right"

2018-09-29 17:59:42 UTC  

It is still routing fine since internet worked for days on end

2018-09-29 17:59:43 UTC  

that was from the post i linked earlier

2018-09-29 18:00:29 UTC  

but on a different note, have you tried power cycling the modem?

2018-09-29 18:00:52 UTC  

and any other routers on the network

2018-09-29 18:04:31 UTC  

Yes

2018-09-29 18:04:51 UTC  

The error was after the power cycle, about 1 hr after

2018-09-29 18:06:59 UTC  

Where on earth is it getting '255.255.255.255/24 != 82.xx.xxx.xxx'? The IP settings on eth0 must be jacked up.

2018-09-29 18:18:26 UTC  

Dhcp from isp is stupid

2018-09-29 18:18:34 UTC  

It goes from private to public

2018-09-29 18:18:39 UTC  

I read that as ICP

2018-09-29 18:18:43 UTC  

I'm like

2018-09-29 18:18:48 UTC  

the fuck do juggalos have to do with this

2018-09-29 18:19:11 UTC  

DHCP is standard for ISP's.

2018-09-29 18:22:39 UTC  

Not when they go from private ip to public ip

2018-09-29 18:24:00 UTC  

That doesn't matter for the DHCP configuration of the public interface on the home router.

2018-09-29 18:24:46 UTC  

NAT lies above the physical interface configuration.

2018-09-29 18:26:03 UTC  

Nat is layer 3, issue is at layer 2

2018-09-29 18:26:08 UTC  

Or at layer 1

2018-09-29 18:26:28 UTC  

I'd say the issue is at the DHCP server on the ISP side.

2018-09-29 18:26:33 UTC  

So how does a potential misconfig at L3 affect L2

2018-09-29 18:26:41 UTC  

Most likely

2018-09-29 18:26:54 UTC  

But isp playing me by saying they dont see an issue

2018-09-29 18:27:08 UTC  

The L3 misconfig is in the DHCP configuration being sent by the ISP's DHCP server.

2018-09-29 18:27:53 UTC  

But ip i recognize is fine, so even if the dhcp is misconfig, i got the right routing

2018-09-29 18:28:15 UTC  

This that misconfig is equivalent to spam log, since it does not affect routing

2018-09-29 18:28:39 UTC  

At least for me

2018-09-29 18:29:27 UTC  

I already asked this with the devs that made the router, i showed my routing, they concluded it is spam log sonce routing in routing table is fine

2018-09-29 18:29:28 UTC  

255.255.255.255/24 sounds like garbage sent by the DHCP server.

2018-09-29 18:32:00 UTC  

Ok, well, if the eth0 config actually shows valid address and network and broadcast for what I assume is an 82.x.x.x/24 address then it's the log message that's garbage.

2018-09-29 18:32:07 UTC  

I'm not esp knowledgeable with routing but I was under the impression broadcasting is handled by the router @ the local subnet. How would 255.255.255.255 be a misconfiguration if that address is supposed to be resolved to that subnets broadcast ip? Or do I just not know what I am talking about here

2018-09-29 18:33:51 UTC  

I'm probably wrong here, just curious and I studied a little bit of routing once upon a time

2018-09-29 18:34:11 UTC  

255.255.255.255 wouldn't occur anywhere in the IP config for an interface with a /24 adddress.

2018-09-29 18:35:06 UTC  

It would only occur in the routing table for a routing entry pointing to a specific host.

2018-09-29 18:36:19 UTC  

Are there any lines in the routing table with a mask of 255.255.255.255?

2018-09-29 18:37:57 UTC  

And with that my knowledge is exhausted. I was under the impression that addresses like 127.0.0.1 and 255.255.255.255 were treated as special addresses that were valid regardless of the mask