Android Discussion and Support

[#1]

So I tried to report this bug to samsung, but all they did was reply with a link to teh bada developers site, so Im not really sure how to submit it.  Im posting this here in teh hopes that someone can direct me the proper channels.

Anyway, here's the issue:

When aquiring a wifi network address, the setwork stack seems to use the default class A network mask instead of the DHCP supplied mask.  For instance, Im on the 10.10.10.x network at work, and DHCP supplies a mask of 255.255.255.0.  When I check net status, the mask has defaulted to 255.0.0.0.  This causes problems for me since my DNS is on a different subnet.  When I statically address my phone, everything works as it should.  Its not an android issue since my buddy has a droid running 2.1 update 1 (same as I am) and his phone works fine.

Thanks for listening - and any info you can offer...

[#2]

I'd try to give samsung tech support a call.

I had an issue with the phone not properly trusting a godaddy certificate in the browser when it was trusted in IE and firefox fine.

AT&T support was clueless and they directed me to call samsung directly.

They were able to escalate my issue to tier 3 support and get it resolved over the phone.

[#3]

Have you tried calling Samsung support?  Worst support by far I have received in a long time, and the wait times are crazy long.  Their only solution so far has been to wipe my phone.  Really?  wipe the phone?  This is not  Windows 95, where I when crazy deleting registry entries.  When phone gets an IP, but the browser does not connect (HTTP page display accept terms of use at say Starbuck wifi) does not show up, sounds like ATT blocking free/non-ATT wifi to me.

[#4]

I have a Samsung Vibrant on T-mobile which is another version of the Samsung Galaxy S platform. It has the same issue you report. In my case it is a class B network, and it ignores the subnet mask.

Have you found a solution?

[#5]

Same issue here - system information reports a /24 mask, but the captivate (on 10.1.2.0/24) cannot communicate with 10.1.1.0/24.  Pings error, indicating that ARP requests are not being fulfilled.  Definitely a problem with the subnet mask.

[#6]

Glad to hear (well, not really) that Im not the only one experiencing this.  Repeated emails and chat conversations fall on deaf ears.  I was directed to call level 2 support, however I just dont have the time or inclination to bother at this point.

The only solution is to statically assign the IP address when Im on my employers network.  I have a shortcut to the WiFi settings, and I click menu > advanced and toggle the "static IP" check box bepending on my location.  I can deal with this until they roll out a fix.

[#7]

I have a working solution...modify the routing table with a more specific route.  My Captivate is has connectbot and has been rooted (Superuser Permissions is a  application).  This lets me modify the routing table with the "iproute" command.  With my wireless network being 10.1.2.0/24 (255.255.255.0) and my wired network being 10.1.1.0/24 (255.255.255.0), and DHCP giving my Captivate an IP address of 10.1.2.24 with a mack of 255.255.255.0 and a gateway of 10.1.2.1, running iproute in connectbot to localhost (after running su and granting superuser permissions), the output is:

#iproute

10.1.2.0/24 dev eth0 src 10.1.2.24

10.0.0.0/8 dev eth0 src 10.1.2.24

default via 10.1.2.1 dev eth0

#

The second route is the issue - it is the all encompassing classful route for 10.0.0.0/8.  This  is forcing the Captivate to ARP and not route the traffic through the gateway 10.1.2.1.    So you can either ADD a route for the MORE specific class C network (for a single network fix) or DELETE the 10.0.0.0/8 route:

# iproute add 10.1.1.0/24 via 10.1.2.1

OR

# iproute del 10.0.0.0/8

Either fixed the problem, at least until I disabled and re-enabled the Wifi again.

Mike

[#8]

Youre right.  Something seems to be adding the 10.0.0.0/8 route to the routing table.  Ive done a fair bit of searching but I cannot find whats adding it.  Anyone know how to add the iproute delete statement to a network script?

[#9]

I've have the same issue...can't connect to WIFI with a non-class subnet (CIDR) mask! It works fine with clasfull subnet.

[#10]

Called Samsung tech support and I have open a ticket with them, ATT said that they don't support wireless issues...on their phones! I will keep postings. I'm gonna to call Samsung in the next week again.

[#11]

One more update. I have configured my home wireless network to 255.255.255.248 subnet and it works great with Samsung Captivate. I have here the Linksys WRT54GS with DD-WRT frimware, at work we have a wireless based on Cisco amd ARUBA radio and it is not working.

[#12]

Have you guys tried the leaked Beta JH2 or JH3 firmware to see if it fixed your wi-fi subnet mask issue? I have JH3 installed but don't have such wireless network to test. My workplace uses Cisco VPN to secure the wi-fi access.

What is the tool to check the actual subnet mask on the phone?

[#13]

So I downloaded NetworkInfo app and tried it on my home wifi network which has typical 255.255.255.0 subnet mask. NetworkInfo showed my phone's subnet mask is the same 255.255.255.0. So I think the latest JH3 firmware definitely has the fix for wi-fi issue. You just have to wait for next firmware release to get it.

[#14]

I have a Captivate.. any tool I use always shows the netmask as 255.255.255.0, but when I log into the phone via adb it shows the netmask as 255.0.0.0 at the route level.. posted details on xda-developers, but haven't heard anything back there either:

http://ip208-100-42-21.static.xda-developers.com/showthread.php?p=7521203

So foxbat, if you are seeing it as /24 via NetworkInfo, it doesn't mean anything..  ;(

[#15]

Unfortunately, ipconfig command is not available in my abd shell session.

[#16]

I thought my university was just being slow to allow my mac address, but it turns out I'm having the same problem. I switched that joker to a static IP and it's working great, just like you said. I'll submit it to Samsung as well...hopefully they'll fix it if enough people complain.

[#17]

You should be able to run 'ifconfig eth0', IE:

nc@nc-desktop:~$ adb shell
$ ifconfig eth0
eth0: ip 10.0.55.100 mask 255.0.0.0 flags [up broadcast running multicast]

There's a display showing the wrong netmask.. this network assigns 255.255.255.0.  'Network Info' shows '255.255.255.0', as that is what the phone received from the DHCP server.

[#18]

@foxbat121

Most home routers use the 192.168.x.x network.  This defaults to a class C netmask (255.255.255.0).  This was never the problem with wifi.

Many larger school and corporate networks make use of teh 10.x.x.x network, which by default has a class A netmask (255.0.0.0), however many businesses will partition the network into several subnets using different subnet masks.  The captivate's DHCP client is overriding what the DHCP server give teh phone for a netmask value with the default.

Also, I assure you that this is still broken in JH3.

[#19]

I have done extensive testing with my rooted Samsung Captivate.

I have even tried to add custom dhcp hooks to use ifconfig to set the proper netmask. /system/etc/dhcpcd/dhcpcd-hooks/50-netmask but the netmask is not changed.

ifconfig ${interface} netmask ${new_subnet_mask}

If I do it on the adb shell, it works fine. But I don't like having to reset the netmask everytime I get a new dhcp lease.

Can anyone explain why the same command: ifconfig eth0 netmask 255.255.255.0 works on the adb shell, and connectbot shell, but not in the dhcpcd hooks?

[#20]

ive been banging my head against the wall on the exact same thing for the past 3 hours.

the only thing I can find is that dhcpcd is running as the "dhcp" user and doesn't have access to run

"ifconfig eth0 netmask 255.255.254.0" from a script.. not sure how to get around this.. and it's annoying as all get out..

on rooted phone you can see dhcpcd running with a "ps"... Still playing with it now.. will post if i find any sort of work around.

thanks,
Mike

[#21]

i was able to put the ifconfig line in a hook file for dhcpcd and got it to work by putting setuid on the ifconfig binary so dhcp user could run it.. Probably not the most secure thing to do but it works until they release a stupid bug fix...

Almost regretting getting a droid..

1) horrible exchange support

2) many broken OS related things (this as an example as well as getting wifi to work on a 802.1x network with peap authentication.. can explain how i got that to work).

Hopefully most bugs will be addressed in 2.2 .. and HOPEFULLY AT&T will implement it for the captivate... Buying a new phone for OS upgrade stinks...

Mike

[#22]

How specifically did you do that, Mike and does the phone need to be rooted?

Tks.

~CJ

[#23]

This issue appears to be fixed as of the i897UCJI6 software update - better known as FROYO.

Who knows when this will be officially released though...

[#24]

Unfortunately yes I had to root my phone.

on captivate I did:

case "${new_ip_address}" in
   111.22*)
   setprop dhcp.${interface}.mask "255.255.254.0"
   /system/bin/ifconfig eth0 netmask 255.255.254.0
   ;;
esac

in file:

/system/etc/dhcpcd/dhcpcd-hooks/95-configured

Replace 111.22 with any subnet ip address you may want to configure.. So you will need multiple entries for multiple subnets if the netmask is different.. otherwise you can do *) if all subnet masks are the same (lucky).

The last step is to enable setuid on their toolbox binary (which runs everything under the sun which is why this is a "bad" thing to do):

busybox chmod u+s /system/bin/toolbox

# busybox ls -la /system/bin/toolbox
-rwsrwsrwx    1 0        2000         77300 Jun 28 00:08 /system/bin/toolbox

I'm pretty surprised something like this made it out the door, specially for a device that's supposed to be handy for remote access.

Mike

[#25]

I think I may have found an similar alternative.

Instead of messing with the 95-configured hooks file, I did the following:

in folder:  /system/etc/dhcpcd

I created a new file called dhcpcd.exit-hook

In this file, all I did was add the following line:

/system/bin/ifconfig eth0 netmask getprop dhcp.eth0.mask

The problem appears to be that the interface is never properly configured with the correct Subnet mask from DHCP.  Adding this line takes the SM the phone got from DHCP and configures it manually on the interface.  What I like about this is that it should work on any WiFi network I connect to.  I'll test and let you know.

Of course, I still had to root the phone to do all this, and I'm fairly certain that I'd still have to do the setuid on the toolbox binary as well, but I don't feel like undoing the chmod to test it at the moment.  I'm just thrilled I got it to work at all!!

I'll post with any updates if something doesn't work right after this or if I ever get around to testing the chmod thing.

Good luck and thanks for your help!

~CJ

[#26]

I'm a little surprised you are still seeing this on the Captivate. I had the same problem on the Vibrant and it was fixed in the same update as the GPS fix. Didn't this get fixed on the Captivate with its GPS fix?

[#27]

Unfortunately not.  I've got a brand new phone and the latest updates (UCJH7 w/ firmware 2.1-update1).  Still happens for classless subnets.   Worked fine on classful subnets.

But I've got bad news.  My "fix" while working fine at work, didn't work on my home network or at my karate school, so now it seems the issue has reversed itself.

I need to do some more digging, I guess.

[#28]

What seems to be happening now is that for these Class C networks, it was assigning the mask of 255.255.255.255, even though the getprop dhcp.eth0.mask would return the correct subnet.  Don't know why that is, but it seems it'll get the correct mask if I don't do anything for Class C subnets.  But since it needs a little coaxing for the classless ones, I've had to modify my script.

I changed the dhcpcd.exit-hook file to read the following:

if getprop dhcp.eth0.mask <> 255.255.255.0; then

/system/bin/ifconfig eth0 netmask getprop dhcp.eth0.mask

fi

This seems to work at home.  I'll test at work tomorrow and post an update.

~CJ

[#29]

This is still a no go.  I think it may be my syntax.  I'm going to keep trying and will update when I find something that works completely.

[#30]

For those of you that are already rooted, consider trying out one of the two leaked froyo roms floating around on xda.  The DHCP issue is fixed, and the roms are fast and smoothe.