3

Currently I am connected to a network whose subnet mask is 169.254.0.0 and Gateway is 169.254.20.1.

From a Windows machine I can access both Internet and LAN on this network.

But whenever I connect to this network from a Linux machine I can’t access internet but can access LAN only.

In a Wireshark capture I saw all IP packets, going outside of LAN have source IP set to 0.0.0.0, I believe that’s the reason why I don’t receive any reply.

I used kali.

Can somebody tell me what might be wrong?

Improve this question
3
  • Confirm that your linux client is set up for ZeroConfNetworking (AVAHI) wiki.ubuntu.com/ZeroConfNetworking . This is how linux systems participate in zero-conf networks. Windows just uses a default fallback IP configuration that is triggered for a DHCP-configured interface that cannot retrieve a DHCP address.
    – Frank Thomas
    Commented Apr 26, 2016 at 14:11
  • 2
    @FrankThomas There's no way to justify sending frames from 0.0.0.0 (other than BOOTP/DHCP traffic). Surely the Linux IP stack knows how to follow the IPv4 Link-Local RFC just like any other decent OS since the mid-1990's.
    – Spiff
    Commented Apr 26, 2016 at 19:24
  • Zero-conf networking (defined in RFC 3927) does in fact use broadcasts for discovery, but that doesn't seem to jive with what you are saying about IP broadcast traffic, so I'm likely misunderstanding. AVAHI is the zero-conf implementation for many/most modern linuxes. en.wikipedia.org/wiki/Avahi_%28software%29 en.wikipedia.org/wiki/Zeroconf#support
    – Frank Thomas
    Commented Apr 27, 2016 at 12:19

3 Answers 3

Reset to default
5

Whoever set up that hostel's network made the mistake of using the RFC 3927 IPv4 Link-Local subnet (169.254.0.0/16) where it should have used an RFC 1918 private subnet (192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8) as the NAT private subnet.

This violates the "1.6 Alternate Use Prohibition" provision of RFC 3927.

So it's no surprise that some clients have problems with this configuration. You might try statically configuring your Linux box for an address in either the 169.254.0.[1-255] address range or the 169.254.255.[0-254] address range, still with a /16 (255.255.0.0) subnet mask. Those two ranges within the subnet are generally reserved for when you really need to statically configure something on the IPv4 Link-Local subnet. Statically configure one of the known NAT gateway routers (e.g. 169.254.10.1) as your default gateway.

I make no guarantees that that suggestion will work. For everyone's sake, it would be better if you helped this hostel configure their network to better comply with the relevant standards.

Improve this answer
0
3

Summary

You should check the scope of IP address of your network interface. If it is link, the source IP addresses of your non-local outgoing packets will be substituted with 0.0.0.0. If it is global, you will get into the Internet as usual.

The IP address scope can be found in the ip address show command output, in the section of your network interface.

To change the scope, you can use ip address del to delete the IP address of your host, and then use ip address add to re-add it with the right scope. If you do that, the default gateway would be removed from the routing table. So then you should add it manually.

That's all. After the steps listed above the Internet should work.

Example

Here is an example (some unrelevant output is truncated, some other is (un)indented):

# ip addr
    2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:0c:29:d1:09:56 brd ff:ff:ff:ff:ff:ff
    inet 169.254.55.3/16 brd 169.254.255.255 scope link dynamic ens33
       valid_lft 1596sec preferred_lft 1596sec
# ip addr del 169.254.55.3/16 dev ens33
# ip addr add 169.254.55.3/16 dev ens33 scope global
# ip addr
    2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:0c:29:d1:09:56 brd ff:ff:ff:ff:ff:ff
    inet 169.254.55.3/16 scope global ens33
       valid_lft forever preferred_lft forever
# ip route add default via 169.254.0.34 dev ens33
# ip route
    default via 169.254.0.34 dev ens33 
    169.254.0.0/16 dev ens33  proto kernel  scope link  src 169.254.55.3

Tested on Fedora 23 and Centos 7.2 Live CDs.

Notes

  1. This solution has a major drawback in using static address. It does not fit well with hostel's LANs and DHCP..
  2. I am pretty sure that there is one simple configuration line somewhere to instruct the system to give scope global to link-local addresses (169.254.0.0/16). But I haven't found it yet. Let me know, please, if you do.
  3. Note that some old and just mature distros don't have this issue. For instance, Fedora 12 and new Centos 6.8 (all of them have old kernel 2.6.32) give scope global to link-local addresses.
  4. If one changed scope to link with those distors, he'd run into the issue discussed: the source IP addresses of all the non-local outgoing IP packets would be replaced by 0.0.0.0.
  5. It's interesting to know, what makes this replace. If I knew this, I'd find the answer to the item 2.
  6. With scope global, non-local outgoing IP packets are routed perfectly by the NAT router built in the recent VMWare Workstation and by a Linux machine with Fedora 12 working as a router, despite of RFCs.
Improve this answer
0
2

169.254.x.x is unroutable, it's designed to not pass a router, it can only stay within its own subnet.

It can be routed, but it oughtn't to be.

From RFC 5735

This is the "link local" block. As described in RFC3927, it is allocated for communication between hosts on a single link. Hosts obtain these addresses by auto-configuration, such as when a DHCP server cannot be found.

Also, from RFC 3927

The host MUST NOT send a packet with an IPv4 Link-Local destination address to any router for forwarding.

Improve this answer
5
  • While this is useful information, it doesn't answer the question. Windows works, Linux doesn't. So this isn't a "it doesn't route" problem because it does in the case of Windows.
    – Paul
    Commented Apr 26, 2016 at 13:30
  • does it means no linux machine is gonna get an internet access from this network?
    – Kaleem Ullah
    Commented Apr 26, 2016 at 13:32
  • 2
    Whoever set the network up needs to learn some lessons. It should not route. They should not have used that address space for any communication intended for the 'outside world. Adding another para from RFC 3927...
    – Tetsujin
    Commented Apr 26, 2016 at 13:33
  • isn't there any way to get internet access without changing this address space because admin is not gonna change the address space for just me as its a hostel network with around 300 hosts and everyone uses windows so no one faces any problem .
    – Kaleem Ullah
    Commented Apr 26, 2016 at 13:41
  • 1
    tbh, I don't know why Windows can get through but not nix. Your machine is seeing the correct behaviour:( The network admin at least ought to be told that he's breaking all accepted practices & he would be far better off swapping to the regular 192.168 space; then everybody would be happy. As it stands, there's not even any protection against a simple IP conflict, so idk what else it's breaking.
    – Tetsujin
    Commented Apr 26, 2016 at 13:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .