Alta Fiber Odd behavior Red Network DHCP

I just switched from Spectrum to AltaFiber (formerly Cincinnati bell) to take advantage of Fiber. I’ve been using IPFire for at least eight years and have had challenges ever since I switched to Fiber.

In a nutshell, IPFire ‘appears’ to connect successfully, but none of the devices on my network are able to browse the internet (GREEN is the only other network configured) UNTIL the Hostname listed in RED is the upstream hostname, not the IPFire hostname.

Here’s what I have observed:

IPFire reboot
Attempt connect to Red interface
DHCP starts
IP provisioned to Red interface
Hostname listed is IPFIRE (default hostname)
No bueno browsing on green.

I’m able to connect directly to the fibre modem and browse (observed a provisioned IP address, etc.).

When I am able to connect to the internet, it appears IPFire updates the default hostname with the upstream one.

What can I do to force this update? I’ve tried rebooting the fiber modem, then IPFire and the reverse order. I’ve waited hours (thinking this is a timing/request item). I’ve changed the RED interface from DHCP to static.

Any suggestions are appreciated.

Thank you in advance.

Have you checked your
DNS ?
Domain Name system
What is its status?

Thanks Shaun HVAC -

Here’s what it ‘should’ be: dsl-208-102-178-197.fuse.net. That is, when the hostname on the RED network is something like this (with the X.fuse.net) traffic flows properly

When it reads IPFIRE as the host name on the RED network, traffic does NOT flow.

Is that helpful?

It might be that your ISP has configured its dhcp server in a non-rfc compliant manner.

In /var/ipfire/dhcpc/dhcpcd.conf there are the following lines

'# A hook script is provided to lookup the hostname if not set by the DHCP
'# server, but it should not be run by default.
nohook lookup-hostname

The comment lines start with ’ as otherwise the forum code treats the # as meaning that the following line should be enlarged and bold.

It might be worth commenting out the line starting with nohook and then release and rebind the red interface

dhcpcd -k red0 ( release interface red0 )
dhcpcd -n red0 ( rebind interface red0 )

I am not certain if this will help or not but it is worth a try.

The following lines are earlier

'# Request a hostname from the network
option host_name

which is IPFire asking the ISP’s dhcp server to provide it with the defined hostname. The ISP seems to not be supplying this as requested so maybe the lookup-hostname hook will help.

If the above works then any change you make to dhcpcd.conf will survive across Core Updates as the file is backed up as standard.

Adolf - will try this approach and report back on results. Thank you.

A few quick updates and related questions.

First - rebooted IPFire to create the condition when the upstream hostname is not provided. This first screen shot is taken from the system/main page. Note the hostname (IPFIRE.aude.home).

Second - I captured this DHCP Configuration from the RED Network
(NOTE - image not allowed due to my ‘new’ user state). Can provide domain, gateway, DNS, etc. if needed.

During this time, I was unable to browse the internet with any device on the GREEN network.

Third - I edited the DHCP.conf file as noted
nohook lookup-hostname
dhcpcd -k red0
dhcpcd -n red0
option host_name

and rebooted IPFIre. Same hostname as above.

Within two hours, connection came back, and noticed the following in the system/home screen as hostname for the RED interface: fl1-dsl-72-49-246-182.fuse.net

This is consistent with prior reboots of IPFire and did NOT occur with Spectrum.

Happy to share other logs, but I ‘think’ somehow the RED network DHCP lease to my ISP is not successfully getting/setting the hostname. I’m not sure how or why, but it because it resolves on its own, it ‘seems’ like a timing issue. As such, curious if I can force the hostname set (as noted in the script above) or somehow reboot differently?

Thank you again for your help with this.

Before issuing a new lease, the provider might have a time based embargo. For example, If I change my router (with a different hardware) and try to get the RED up, my provider will not give me a new lease for two hours. Of course, if I reboot with the same hardware there is no problem to get back the old lease. Maybe it is something similar for your provider.

CFusco -

Thanks. Good insights, and am curious why when I reboot with the same hardware I still have this issue.

To clarify, say that my provider issues me now a dhcp lease. Then if I boot a new piece of equipment with a different ethernet card, I have to wait 2 hours to get a new lease. However, If I change hardware say 3 hours after I get the lease, I have my new machine running perfectly fine.

To me it looks like that this is NOT what your provider is doing. However, I am curious to know what happens when you get your dhcp lease, you wait several hours and then reboot. Do you still get nothing for several hours?

I have no idea what’s going on, but I think it is with the provider that you should try to get at the bottom of this issue. Please let us know how this story ends. I am personally really curious.

Regardless, good luck.

Thanks.

In the simplest terms, when I reboot, I get the lease, but the upstream hostname is set as my local machine. If I wait for an hour (or so), the hostname updates.

In the time between the reboot and updated lease, I have no internet connectivity.

does this happen regardless how far in time it was your last reboot? By the way, your machine name is on a reverse DNS entry of your provider. Maybe this is where the problem is, your provider does not update their rDNS system frequently enough.

This happens anytime I reboot. RED network hostname does not update for some period of time. I don’t know about the reverse DNS - is there a way to test this?

BTW - a secondary test I’ve run is to connect my laptop directly into the fiber modem and determine if I can a.) get a lease and b.) browse the internet. For both I can. If I then plug the modem back into the RED network, I do have any update to the hostname.

Ah, this is interesting. Do you have an OTO plug in your location with an optical fiber connected directly to the modem, which then connects by DHCP to the provider? Or do you have a last mile copper connection and the modem is doing a PPP authentication?

I have an optical fiber connected directly to the modem. It is a Nokia device.

This appliance is also a router? If yes, did you set it in bridge mode? It might be the modem the culprit here.

The device is simply a modem. Fiber into the modem, then ethernet cable out. Ethernet out directly to RED network card.

Ok, then if the modem does nothing more than converting the light into electricity, then when you connect your laptop it is the laptop itself sending a DHCP request. After that, any subsequent DHCP request from the IPFire machine works just fine. However, if you go from the beginning with IPFire, you have the hostname problem.

Is this summary correct?

Correct - the modem is simply converting light to electricity.

One correction -

  1. If I connect my laptop to the modem, I am able to browse the internet (on my laptop) without any issue.

If I then disconnect my laptop and connect the ethernet cable directly to the RED network lan card (instead of my laptop), IPFire does NOT successfully retrieve the upstream hostname. Further, no device on my network is able to browse the internet.

Ah, ok. Now I understand. Can you assign the ethernet card number of your laptop to ipfire ethernet card of the red zone and see if anything changes when bringing the RED interface up?

So I understand - you want me to configure the MAC address of my laptop ethernet card for the RED interface and then bring up the RED network?