FreeBSD 15-CURRENT static ip cant connect to internet

GlitchyDot

GlitchyDot

Installed FreeBSD15-CURRENT.
Noted one thing during installation - No Network config like in previous versions.
Automatically sets up DHCP.
tried to replicate from my laptop but use wired:
Code: 
ifconfig_igb0="inet 192.168.1.100 netmask 255.255.255.0"
ifconfig_igb0_ipv6="inet6 accept_rtadv"
ip6addrctl_enable="YES"
ip6addrctl_policy="ipv6_prefer"
defaultrouter="192.168.1.1"


/etc/resolv.conf
Code: 
nameserver 1.1.1.1
nameserver 1.0.0.1
nameserver 2606:4700:4700:1111
nameserver 2606:4700:4700:1001


ifconfig with DHCP
Code: 
igb0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        options=4e527bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
        ether 2c:fd:a1:34:33:8f
        inet 192.168.1.52 netmask 0xffffff00 broadcast 192.168.1.255
        inet6 fe80::2efd:a1ff:fe34:338f%igb0 prefixlen 64 scopeid 0x1
        inet6 2a00:f502:150:531e:2efd:a1ff:fe34:338f prefixlen 64 autoconf
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
igb1: flags=1008c02<BROADCAST,DRV_OACTIVE,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        options=4e527bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
        ether 2c:fd:a1:34:33:90
        inet6 fe80::2efd:a1ff:fe34:3390%igb1 prefixlen 64 tentative scopeid 0x2
        inet6 2a00:f502:150:531e:2efd:a1ff:fe34:3390 prefixlen 64 tentative autoconf
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384
        options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
        groups: lo
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>


<service netif restart && service routing restart
This settings have no internet ... and command routing not found
if i change inet back to dhcp - i have internet.
 
This is the sort of thing you should be discussing on the mailinglist, or better yet: try to fix it (or at least try finding a logical / probable cause for all this), and then present all that to make your case about possible issues in CURRENT. It's not something you can ask for help about on this place, for obvious reasons... I'm not necessarily talking about the rules (which I'm about to share), but more so about the highly unstable nature of CURRENT; it's in full on active development so anything can go wrong at any given time, that's the nature of the beast.

If you don't know how you'd cope with all this then you probably shouldn't be messing with CURRENT (and maybe not even STABLE) but instead stick to an official & supported release:

DutchDaemon

Thread 'Topics about unsupported FreeBSD versions'

The FreeBSD Forums cater primarily to end-users and systems administrators. As such, the Forums focus almost exclusively on FreeBSD versions that are officially supported according to the official FreeBSD website. Since resources are scarce, the FreeBSD Forums strongly suggest that anyone asking questions on the forums run one of the officially supported versions (see the links at the end of this post), for which the installed user base is logically the broadest.

In terms of 'unsupported versions' we make the following distinction:

  1. FreeBSD versions that are...
  • Thanks
  • Like

(edit)

If you want the latest & greatest of FreeBSD then you're better off sticking with an officially supported version. At the time of writing that's 14.2, or you can pick a so called legacy release: 13.4 and/or 13.5. But editions like CURRENT & STABLE are only useful if you have a solid understanding of FreeBSD's inner workings and can work your way out of messes like the ones you described.

At the risk of going a little offtopic here... but IMO this is a very good example as to why the above rule exitsts in the first place:

Having 15.0 on my own VM I figured I'd look into the Git log and... well a35f24c9055d90b409eede861b7dc6defa01a118 looks peculiar to me:

Code: 
    sendfile: factor out socket send buffer space sensing into a method

    Move a block of code that works with the socket send buffer from the main
    sendfile loop into a separate function.  Make it a protocol method, so
    that protocols may provide a different one.

    While here, provide a long comment explaining why we modify sb_lowat and
    why we can't just remove that hack.

    No functional change intended.
Notice that last line?

Please note: I don't claim to be an expert on this matter, but going by the Git logs it's obvious to me that there has been active development within several core network functions. Meaning so much that there's always a chance that some functionality changes, though unintended (!), still found their way into the system.

Which could theoretically be a possible cause for your issues.

Of course that's pure speculation, but still a very good example (IMO) why you shouldn't be casual about running CURRENT.

Just my 2 cents of course.
 
ShelLuser said:
This is the sort of thing you should be discussing on the mailinglist, or better yet: try to fix it (or at least try finding a logical / probable cause for all this), and then present all that to make your case about possible issues in CURRENT. It's not something you can ask for help about on this place, for obvious reasons... I'm not necessarily talking about the rules (which I'm about to share), but more so about the highly unstable nature of CURRENT; it's in full on active development so anything can go wrong at any given time, that's the nature of the beast.

If you don't know how you'd cope with all this then you probably shouldn't be messing with CURRENT (and maybe not even STABLE) but instead stick to an official & supported release:

DutchDaemon

Thread 'Topics about unsupported FreeBSD versions'

The FreeBSD Forums cater primarily to end-users and systems administrators. As such, the Forums focus almost exclusively on FreeBSD versions that are officially supported according to the official FreeBSD website. Since resources are scarce, the FreeBSD Forums strongly suggest that anyone asking questions on the forums run one of the officially supported versions (see the links at the end of this post), for which the installed user base is logically the broadest.

In terms of 'unsupported versions' we make the following distinction:

  1. FreeBSD versions that are...
  • Thanks
  • Like

(edit)

If you want the latest & greatest of FreeBSD then you're better off sticking with an officially supported version. At the time of writing that's 14.2, or you can pick a so called legacy release: 13.4 and/or 13.5. But editions like CURRENT & STABLE are only useful if you have a solid understanding of FreeBSD's inner workings and can work your way out of messes like the ones you described.

At the risk of going a little offtopic here... but IMO this is a very good example as to why the above rule exitsts in the first place:

Having 15.0 on my own VM I figured I'd look into the Git log and... well a35f24c9055d90b409eede861b7dc6defa01a118 looks peculiar to me:

Code: 
    sendfile: factor out socket send buffer space sensing into a method

    Move a block of code that works with the socket send buffer from the main
    sendfile loop into a separate function.  Make it a protocol method, so
    that protocols may provide a different one.

    While here, provide a long comment explaining why we modify sb_lowat and
    why we can't just remove that hack.

    No functional change intended.
Notice that last line?

Please note: I don't claim to be an expert on this matter, but going by the Git logs it's obvious to me that there has been active development within several core network functions. Meaning so much that there's always a chance that some functionality changes, though unintended (!), still found their way into the system.

Which could theoretically be a possible cause for your issues.

Of course that's pure speculation, but still a very good example (IMO) why you shouldn't be casual about running CURRENT.

Just my 2 cents of course.
Click to expand...
There are very few developers on the forums, and the amount of 'regular users' routinely running -CURRENT who are willing and able to lend support is likely in the single digits.
So im betting on these single digits :)

bakul said:
Try the freebsd-current mailing list or may be discord .
Click to expand...
I just now registered to mailing list but have no idea how to deal with and dont have discord ( i do , but dont remmeber logins ) and as my reply to ShelLuser - im betting on single digit users :)
 
The static IP and its subnet has to be registered on the router you're connected to. If the router is unaware, and doesn't expect the IP address to try and connect, that IP address won't be routed. For example, if the router only knows about 192.168.1.0/24 IP addresses, it won't route if you try to connect with a 10.0.0.0/8 IP address...

Just comment out the line in /etc/rc.conf that says ifconfig_igb0="inet 192.168.1.100 netmask 255.255.255.0", or at least use DHCP....

Another idea to try is to define a static, permanent lease in your router for the 192.168.1.100 IPv4 address.
 
Though you can set up packet filtering rules where only specific IP addresses can have internet access, typically on a home router a packet filter will allow all outgoing connections from any local IP address. This "lease" nonsense is only for DHCP (or should be).

Many things that can go wrong when you "cant connect to internet". Discord or some IM channel would be better for remote interactive debugging. At least tell the OP should tell us what was tried "exactly* and what *specific* *exact* messages was seen. Also, one can use tcpdump to see where the problem may be.
 
You must log in or register to reply here.
Back
Top