Red0 does not get IP address from ISP

@stevet , could you please describe your installation in more detail.

  • How is red0 connected to the fibre modem?
  • Which devices are connected also to the LAN port of the modem ( using a switch? ) ?
  • What is logged by dhcpcd in case of direct connection IPFire <–> modem?
  • Did you check the identity of red0 using the ‘identify’ functionality of setup? Are the activity LEDs blinking on your red0 NIC?
  • Are there physical or logical connections between your WAN (modem) and LAN (local devices)?
    Does your installation look like: WAN <--> modem <--> IPFire <--> LAN devices ( Sorry, but one never knows ) ?
1 Like

Hi,

I had a similar issue with my ISP (talktalk non fiber) as they assign ips via DHCP.

After following this post: Can't get DHCP address on red, 162 I was able to get the IP assigned via DHCP on red.

Not sure if this is the same issue?

Hope it helps.

–EDIT: From the logs it doesn’t appear to be the same issue.

@stevet

If that does not work, then it appears that your ISP is treating IPFire as an IPv6 device. Is it treating any other Linux machine on your LAN as IPv4 ? If so, then you might be faced with putting a SBC, running Linux as a minimal router, upstream of your IPFire, to assign red0 an IPv4 address.

Alternatively, there is a setting in Linux to have a client not seek an IPv6 offer. I can do that in openSUSE, but it is done via GUI and I’m uncertain of the config file that governs it, plus I set my workstations to static addressing, resulting in nothing relating to DHCP in the config files. /var/ipfire/ethernet/settings might have the relevant setting.

BTW, I set my red0 to “static” because I find that my ISP-supplied router is too slow making a DHCP offer and red0 meanwhile times out. Obviously you can’t do that, but the IPFire network gurus might know a way of increasing the wait time for an offer.

Summary: I was using a switch that had various other switches connected with different devices. This switch was attached to the ISP’s fiber “modem”. When I got back to this early AM (for me), enough devices had apparently shutdown that IPF had gotten an IP address from the ISP (which rather indicates they had a limit on IP addresses) and so IFP had finally gotten a connection, and WUI was working on my Linux desktop (green0). So I did fixed IP definitions and other things hanging fire…

With that done, I replugged cables so that RED0 was directly connected to the “modem” and GREEN0 was directly connected to that switch which did the fan-out to our LAN. And now things are working.

(I had thought I had posted all of this earlier today).

Glad to hear that you have resolved the issue.

As you might have gathered from earlier responses, having IPFire directly connected to modem is “normal”.

Your ISP’s apparent limit on the number of IP addresses offered is understandable. For the sake of completeness of this topic, do they offer public IPv4 addresses or run Carrier Grade NAT and offer private addresses ?

1 Like

Wow, interesting questions. I had the impression they would provide a public IPv4 to those that really need that. But since they are pushing static IPs to those using VPNs (why they claim this solves connection issues is beyond me) I’m thinking they are doing Carrier Grade NAT to, probably, CLASS B private addresses. But I do not know for sure. I asked them about how they were doing IP addressing because of a problem I had in TX with AT&T forcing me out of the CLASS B Private I was using for experimentation. And I did not recognize the comm protocols they were talking about.

I’m familiar with SNA (because of mainframes) and IPv4/6 becasue of doing development with NDM (now called Connect:Direct). I am not familiar with “ATM” (whatever that is).

And for completeness: I think they are starting to handle IPv6 because of IOT.

No, that wasn’t clear yet. I thought of a ‘straight internet gateway solution’, not of IPFire being one device besides others getting its internet connection from the modem.

@stevet , I don’t think it is a problem of ‘protocols’.
The main configuration of ‘internet access by an ISP’ is

  • the ISP has access network to the global WAN
  • the ISP sells access to this network
  • the data transport is done by some adequate technique ( broadband cable, fibre, DSL, … )
  • the endpoint on the customer side is some sort of modem or router, which serves the internet access on ethernet/IP level
  • each customer receives a certain speed and is allowed to connect a certain number of devices to the ISP endpoint. This is part of the contract between ISP and customer.

The connection to the ISP network is simple, if the connection is built by DHCP ( IPFire does exactly this on the LAN side ) and not more than the allowed devices are active.
If only one device is connected to the modem no switches are necessary. A single ethernet cable can be easily determined as bad or good.

Just my opinion.
Bernhard

See also Internet service provider - Wikipedia