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?

Kaleem Ullah

Posted 2016-04-26T13:16:12.080

Reputation: 61

Confirm that your linux client is set up for ZeroConfNetworking (AVAHI) https://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 – 2016-04-26T14:11:48.050

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 – 2016-04-26T19:24:48.580

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. https://en.wikipedia.org/wiki/Avahi_%28software%29 https://en.wikipedia.org/wiki/Zeroconf#support

– Frank Thomas – 2016-04-27T12:19:11.610

Answers

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.

Spiff

Posted 2016-04-26T13:16:12.080

Reputation: 84 656

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.

Tetsujin

Posted 2016-04-26T13:16:12.080

Reputation: 22 456

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 – 2016-04-26T13:30:56.523

does it means no linux machine is gonna get an internet access from this network? – Kaleem Ullah – 2016-04-26T13:32:13.917

2Whoever 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 – 2016-04-26T13:33:21.580

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 – 2016-04-26T13:41:26.087

1tbh, 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 – 2016-04-26T13:44:01.243

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

This solution has a major drawback in using static address. It does not fit well with hostel's LANs and DHCP..
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.
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.
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.
It's interesting to know, what makes this replace. If I knew this, I'd find the answer to the item 2.
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.

tsul

Posted 2016-04-26T13:16:12.080

Reputation: 123

all outgoing tcp packets have source IP address 0.0.0.0

Answers

Summary

Example

Notes