The problem still happens if the default gateway is removed. And just routes for the two individual subnets exist. And oddly, the problem is still there if I remove the route for the eth0 subnet. Only "ifconfig eth0 down" allows traffic out eth1. Android 6.0 works fine, too.
-
-
What I can't figure out for the life of me is why when Android knows very well that 192.168.0.0/24 traffic uses eth1, it shoves out the replies on eth0 (which in this case is for 192.168.153/0/24).pic.twitter.com/70O9RNxBVH
1 reply 0 retweets 0 likes -
Replying to @wdormann
Did you try just for the sake of testing to switch one subnet to e.g. 172.16 to rule out 192.168/16 classful issues? Can you toy with the metric to in the routing? this output doesn't show it
1 reply 0 retweets 0 likes -
Replying to @RonnyTNL
Good idea! But the results are the same. Ping requests come in eth1, and the responses are sent out eth0.pic.twitter.com/sxTThX8uGv
1 reply 0 retweets 0 likes -
Replying to @wdormann
Are these VMware interfaces? and can you compare outputs with the working v6 environment? also is this still available? /proc/sys/net/ipv4/conf/all/forwarding from the counter it seems only ARPs are TX'd on eth1
1 reply 0 retweets 0 likes -
Replying to @RonnyTNL
Yes, all interfaces are vmware. The traffic is VM-to-VM. Though I had also tried host-to-VM first, with similar results. The configurations appear to be the same as the working Android 6.0 setup. /proc/sys/net/ipv4/conf/all/forwarding is set to 0
1 reply 0 retweets 0 likes -
Replying to @wdormann
and you receive the replies on the sending machine? in that case they network seems shared and ARP/MAC might override routing? is sending MAC bound to eth0?
1 reply 0 retweets 0 likes -
Replying to @RonnyTNL
No, the whole problem is that any system that pings the android VM never gets a reply. That's what got me down the path of looking at the traffic, and realizing that Android is sending the ping reply on the wrong interface, which never gets to the originating host.
1 reply 0 retweets 0 likes -
Replying to @wdormann
Wierd, i’m about to /signoff lets see if a good night sleep brings some light ;) let me know if you find something pls
1 reply 0 retweets 0 likes -
Replying to @RonnyTNL
Yeah, I'll probably have to dig a bit more here. The simplest case that I can think of is to have it only have one entry in the routing table. And then ask it how it'd route to a host in that subnet. But it gets it wrong! There's no eth0 in the routing table, but it's used?!pic.twitter.com/tH3LoF7TbC
1 reply 0 retweets 0 likes
OK, the answer is here: https://superuser.com/questions/701956/android-devices-dont-know-route-to-a-host-located-in-the-same-network/1337904#1337904 … In particular: ip rule add from all lookup main pref 1 Once this is executed, Android routes sanely.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.