What's new

SS Gal S7 Android phone tethering not working (384.3_beta3 RT-AC3100) with partial solution

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

BobSp

New Around Here
Hi, all,

I've had serious issues getting my Samsung Galaxy S7 to work via the WAN Android phone tethering option. The only place where I've seen it work out of the box is on the Asus RT-N16 with stock firmware, but I couldn't log into linux and see what it did differently. Today I purchased a RT-AC3100 to try it in the merlin firmware, and it is not working out of the box.

I finally found a path that gets it to work.

First the symptoms:
With either dual-wan or just USB wan enabled, the router assigns "eth3" to the phone when I enable usb tethering (via hotplug?). "ip link" shows this for eth3:

21: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff

It will never give it an IP address, either automatically or if I manually try and run udhcpc. I see errors like this in syslog:
  • miniupnpd[20116]: ioctl(s, SIOCGIFADDR, ...): Cannot assign requested address
  • miniupnpd[20116]: Failed to get IP for interface eth3
I tried running "ip" command to manually assign an IP address and bring up the adapter, and I ran into similar errors, "Cannot assign requested address".

It seems that the various network commands really do not like that the MAC address is 00:00:00:00:00:00.

Now, for my partial workaround. I change the MAC address to 01 and started a new dhcp client, and it magically started working!
  • ip link set dev eth3 address 00:00:00:00:00:01
  • /sbin/udhcpc -v -i eth3 -p /var/run/udhcpc3.pid -s /tmp/udhcpc -t2 -T5 -A160 -O33 -O249
Of course, as soon as I toggle the android usb tethering option or restart the router, it's back to broken, and I have to login and run these 2 commands again, but this is a major step forward!

Now, for my fundamental question to the group: How can I make this "stick" either as a work around or as a real fix to the issue?
  1. Is there something I can set in nvram (usb_wan_hwaddr_x, usb_wan_hwaddr, other) to tell it to use a different mac address?
  2. Is there something I can set in hotplug or miniupnpd to set a different mac address?
  3. I'm still investigating the various "user scripts" that are offered in merlin. Does anyone have a suggestion as to where I could insert the "ip link set dev eth3 address" command in there?
Many thanks for any pointers!
 
would dhcp event work? I know it's a new interface and not a dhcp lease, but doesnt hurt to try.

If you get a hit, you are 90% done!

dhcpc-event
Called whenever a DHCP event occurs on the WAN interface. The type of event is passed as an argument which can be used in the script using $1; possible event types in the version of udhcpcin ASUSWRT are deconfig (when udhcpc starts and when a lease is lost), bound (when a lease and new IP address are acquired), and renew (when a lease is renewed, but the IP did not change).

Try to see if a dhcp event is triggered with the following

Code:
echo "#!/bin/sh" > /jffs/scripts/dhcpc-event
echo 'logger "script triggered here with param $1" ' >> /jffs/scripts/dhcpc-event
chmod 0755 /jffs/scripts/dhcpc-event

If you see nothing in system log then clear the created file with

Code:
rm /jffs/scripts/dhcpc-event

This assumes you do not have anything present inside dhcpc-event beforehand, or the commands will delete it!

--

If that doesn't work, just create a cron job that polls interface devices and their associated mac addresses. If that catches your 00:00:00:00:00 mac, then issue the commands to fix it.

Just throwing ideas out.
 
Last edited:
The dhcpc-event did not get triggered, so I went with the crontab route:

Code:
crontab entry:

* * * * * /jffs/fix-s7-hwaddr.sh

Code:
fix-s7-hwaddr.sh:

#!/bin/sh
DEV=eth3
if [[ $(ip addr show dev $DEV | grep 00:00:00:00:00:00 | wc -l) -eq 1 ]]; then
  # fix it
  ip link set dev $DEV address 00:00:00:00:00:01
  if [[ $(ps | grep udhcpc | grep $DEV | wc -l) -ge 1 ]]; then
    kill `cat /var/run/udhcpc_$DEV.pid`
  fi
  /sbin/udhcpc -i $DEV -p /var/run/udhcpc_$DEV.pid -s /tmp/udhcpc -t2 -T5 -A160 -O33 -O249 &
fi

It works! Great idea! I didn't know that the router had cron installed on it.

Thank you so much!

I think I'll try the path of building a dev environment in a VM and making the minor code change to the kernel module to report a valid MAC address. I see other references to this issue in google searches now that I know what I'm looking for, and it looks like a bug in the Android OS on the S7.
 
I've got a new method without using cron.

"hotplug2" is what sets up the ethernet interface, but I can't append/replace the rules file using the normal jffs/config methods because hotplug2 is not supported for configs. Also, if I change the hotplug2.rules file in init-start, that's too late because hotplug2 is already started by then, so I'm replacing the config file and killing (it automatically restarts) the service with /jffs/scripts/init-start as follows:

Code:
#!/bin/sh
cp -f /etc/hotplug2.rules /jffs/configs/hotplug2.rules
rm -f /etc/hotplug2.rules
ln -s /jffs/configs/hotplug2.rules /etc/hotplug2.rules

echo "SUBSYSTEM == net, DEVICENAME == eth3, ACTION == add { exec /usr/sbin/ip link set dev eth3 address 00:00:00:00:00:01 ; }" >> /etc/hotplug2.rules

# restart hotplug because it won't use this config file without restart
kill `ps | grep hotplug2 | grep -v grep | awk '{print $1}'`

It works instantly when I enable USB tethering on my Samsung Galaxy S7, it toggles off and on cleanly, and it survives reboots of the router.
 
Nice, even better!

Thanks for sharing.

Who is your cellular provider (just out of curiosity). They must hate you.

Are you not worried about getting terminated from abuse of service?

I know T-mobile inspects both TTL (mobile devices use 64 while computers use 128) and deep packet inspection to read the user-agent.

If one of the two does not conform to the device, they take it out of your "hotspot" allotment. There may be other checks I dont know of.

Besides network level checks, the cellphone itself flags "hotspot" traffic by routing it through a different APN. The only way to bypass that is root.
 
Last edited:

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top