Are you certain that the NIC for red0 is sound ? Old NIC have a fairly high failure rate.
I generally use the on mainboard NIC for red0, because USB NIC can fail to be recognised.
Just got the system up after a fresh install.
Does this mean anything significant? :
starting dhcpcd on red0 interface…
Error: ipv4: FIB table does not exist. / / [ERROR] << all in RED
New out of the box, dual port ethernet card. It had been working. So now that I have it pointed at the fiber optic modem, it should still work.
Probably, but not at a level that I understand. IPFire requires IPv4 for Internet. Does the ISP support only IPv6 ?
Indications are that the switch is not suitable. Can you bypass it and connect red0 directly to modem ?
1 Like
I have several IPFire boxes. When I want to change the active box, I have to power down the switch first. It appears that the FIB table in the switch gets confused.
Try:
- power down IPFire
- then power down switch
- power up switch
- power up IPFire
1 Like
I had no idea that a switch had a table like that. But then, I don’t work on those things, I work on Mainframes and used to work on printers and the like, back in the day. It is no wonder that doing network stuff gives me a headache.
And to the other question that was asked about IPv6: This ISP allows IPv6, but they do not force it. I generally do not run anything IPv6 in my LAN. Not until I can finally digest all the RCFs for IPV6. And don’t hold your breath. It is only if I have to do IPv6 for product development again that I will start reading them.
This is a standard error message that everyone will see. It occurs because IPFire does not use the FIB table and since an update of both the kernel and iproute2 about a year ago an error message is shown if a default table is not present even if the reason it is not present is because it is not needed and therefore not created in the first place.
There is a previous thread about this
https://community.ipfire.org/t/error-ipv4-fib-tables-does-not-exist/6766
and a bug has been raised to try and see if the error message can be stopped but it appears that iproute2 would need to be re-written to stop it doing it and the iproute2 developers decided to close the issue without fixing it as they said that the error message is correct, that the FIB table does not exist
https://bugzilla.ipfire.org/show_bug.cgi?id=12763
This error message does not have anything to do with not getting an IP address from your ISP.
Wgat does the RED log show when the request for an IP is made. The log is in the menu Logs - System Logs and then select RED in the drop down box and then press the update button.
3 Likes
Quite informative, thanks.
OP has a switch on the red0, as do I effectively, with my modem in routing mode. I have no problems with that switch. I might be on a different ISP (iiNet). I get a single, public IP address from the ISP and red0 gets a private IP from my router.
I have a switch connected to green0, as would many users. That is the one that loses the plot when I change the upstream IPFire box.
RED0 is attempting to use DHCP (dhcpcd-9.4.1 starting)
DUID 00:04:25:12:ed:29:a6:…
red0: IAID 4c:38:49:25
red0: adding address fe80::2e0:4cff:fe38:4925
upv6_addaddr1: Permission denied
red0 carrier lost
timed out
dhcpcd-9.4.1 starting
DUID 00:04:25:12:ed:… (same as above)
:
:
ipv6_addaddr1:Permission denied
timed out
It seem from the above that something is not right. I do not have the system set up for IPv6, at least not on purpose. Everything else going through the switch is using DHCP and getting IPv4 addresses from all that I’ve seen (2 windows laptops, 1 Linux desktop).
I’m going to redo setup and see if somehow red0 is set for IPv6.
I do not see how to set this when running “setup”. Hmmmm.
IPFire2.x is only set up for IPv4. It has no ability or code to deal with IPv6.
This message from the dhcpc package is just saying that it tried to add an IPv6 address and was not able to do that as IPFire does not recognise or deal with IPv6.
The issue is in the section
This is saying that the signal from your modem disappeared and dhcpcd timed out waiting for it to come back. (The timeout is set at 60 secs). It is even not clear to me that dhcpcd ever got any signal from your modem.
The following is the RED connection log on my system.
|05:00:06|dhcpcd[8017]|: dhcpcd-9.4.1 starting|
|05:00:06|dhcpcd[8020]|: DUID 00:01:00:01:2a:59…|
|05:00:06|dhcpcd[8020]|: red0: waiting for carrier|
|05:00:08|dhcpcd[8020]|: red0: carrier acquired|
|05:00:08|dhcpcd[8020]|: red0: IAID b9:5e:aa:dc|
|05:00:08|dhcpcd[8020]|: red0: adding address fe80::30d:b4ff:yyyy:xxxx|
|05:00:08|dhcpcd[8020]|: ipv6_addaddr1: Permission denied|
|05:00:09|dhcpcd[8020]|: red0: soliciting a DHCP lease|
|05:00:09|dhcpcd[8020]|: red0: soliciting an IPv6 router|
|05:00:12|dhcpcd[8020]|: red0: offered xxx.xxx.xxx.xxx from yyy.yyy.yyy.yyy|
|05:00:13|dhcpcd[8020]|: red0: probing address xxx.xxx.xxx.xxx/22|
|05:00:18|dhcpcd[8020]|: red0: leased xxx.xxx.xxx.xxx for 3600 seconds|
|05:00:18|dhcpcd[8020]|: red0: adding route to zzz.zzz.zzz.zzz/22|
There is a message “waiting for carrier” followed by “acquired carrier” which I don’t see in your log message. Are those present but were not included in your copy/paste?
Without acquiring a carrier signal dhcpcd will not be able to do the solicitation for a DHCP lease. If the carrier is never acquired then there is some connection issue between your IPFire system and the Fibre Modem.
My connection is also to a Fibre system.
Are you certain that you have the network cable from the Fibre modem connected to the correct NIC on your IPFire box.
1 Like
@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.
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