4. Pfsense and g1 phone (android)

Pfsense and g1 phone (android)

  • A

    Hey guys, I've been a happy user of 1.2.0 release of pfsense for a while now with my wired LAN and wireless WIFI subnet playing happily together. Besides moving and being forced to switch from cablevision to the absolutely inferior time warner cable in NYC my connection is going strong.

    However now I have a new wifi device to play with. The g1 phone from Tmobile suports 802.11g and I can connect to my neighbor's (permission granted of course >;] ) wifi with no problem. However I cannot connect to MY pfsense router for some reason. Or rather, I can connect (valid IP and everything) but I cannot DO anything with this connection. All my small 802.11g (and some b) devices work flawlessly on my pfsense box including my WII, Nintendo DS, PSP, and the random laptops I have. Its just the g1 can't seem to. And yes I have MAC filtering on, yes the mac is on the whitelist like the rest and its been verified three times.

    Would there be any reason for a device to not be able to connect to a pfsense based wireless router? Is it my atheros card? Could it be something else?

    Any help would be appreciated!

    Thanks.

    0
  • S

    Same problem here. The G1 seems to think it's associated just fine, can't actually get it to do anything though. This is everything from the pfsense system log that mentions the G1's MAC:

    Dec 21 20:44:05	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: associated
Dec 21 20:44:05	hostapd: ath0: STA 00:18:41:d7:a1:6b WPA: pairwise key handshake completed (RSN)
Dec 21 20:44:26	hostapd: ath0: STA 00:18:41:d7:a1:6b WPA: group key handshake completed (RSN)
Dec 21 20:44:37	dnsmasq[7852]: reading /var/dhcpd/var/db/dhcpd.leases
Dec 21 20:45:28	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: deauthenticated due to local deauth request
Dec 21 20:45:28	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: deassociated
Dec 21 20:45:29	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: associated
Dec 21 20:45:29	hostapd: ath0: STA 00:18:41:d7:a1:6b WPA: pairwise key handshake completed (RSN)
Dec 21 20:46:28	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: deauthenticated due to local deauth request
Dec 21 20:46:28	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: deassociated
Dec 21 20:46:29	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: associated
Dec 21 20:46:29	hostapd: ath0: STA 00:18:41:d7:a1:6b WPA: pairwise key handshake completed (RSN)
Dec 21 20:47:28	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: deauthenticated due to local deauth request
Dec 21 20:47:28	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: deassociated
Dec 21 20:47:29	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: associated
Dec 21 20:47:29	hostapd: ath0: STA 00:18:41:d7:a1:6b WPA: pairwise key handshake completed (RSN)
Dec 21 20:48:28	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: deauthenticated due to local deauth request
Dec 21 20:48:28	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: deassociated
Dec 21 20:48:29	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: associated
Dec 21 20:48:29	hostapd: ath0: STA 00:18:41:d7:a1:6b WPA: pairwise key handshake completed (RSN)
Dec 21 20:49:25	hostapd: ath0: STA 00:18:41:d7:a1:6b WPA: group key handshake completed (RSN)
Dec 21 20:50:26	hostapd: ath0: STA 00:18:41:d7:a1:6b WPA: group key handshake completed (RSN)
Dec 21 20:51:28	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: deauthenticated due to local deauth request
Dec 21 20:51:28	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: deassociated
Dec 21 20:51:29	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: associated
Dec 21 20:51:29	hostapd: ath0: STA 00:18:41:d7:a1:6b WPA: pairwise key handshake completed (RSN)
Dec 21 20:52:28	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: deauthenticated due to local deauth request
Dec 21 20:52:28	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: deassociated
Dec 21 20:52:29	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: associated
Dec 21 20:52:29	hostapd: ath0: STA 00:18:41:d7:a1:6b WPA: pairwise key handshake completed (RSN)
Dec 21 20:53:27	hostapd: ath0: STA 00:18:41:d7:a1:6b WPA: group key handshake completed (RSN)
Dec 21 20:54:28	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: deauthenticated due to local deauth request
Dec 21 20:54:28	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: deassociated
Dec 21 20:54:29	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: associated
Dec 21 20:54:29	hostapd: ath0: STA 00:18:41:d7:a1:6b WPA: pairwise key handshake completed (RSN)
Dec 21 20:55:28	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: deauthenticated due to local deauth request
Dec 21 20:55:28	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: deassociated
Dec 21 20:55:29	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: associated
Dec 21 20:55:29	hostapd: ath0: STA 00:18:41:d7:a1:6b WPA: pairwise key handshake completed (RSN)
Dec 21 20:56:28	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: deauthenticated due to local deauth request
Dec 21 20:56:28	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: deassociated
Dec 21 20:56:29	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: associated
Dec 21 20:56:29	hostapd: ath0: STA 00:18:41:d7:a1:6b WPA: pairwise key handshake completed (RSN)

    Doesn't seem to indicate anything specific. I realize it's not much to go on, is there any information that could be gathered from either device which might be helpful?

    Other devices on the network have ARP entries for the phone's IP, so something is getting through.

    0
  • G

    I can confirm this problem.

    At initial connect I can ping the device for just a brief second before all packets to it begin to get lost. I have a dev model with full root access so if somebody is willing to help (I have no idea what I am doing with the thing yet) I can install tools like tcpdump and such to capture packets on both sides.

    0
  • C

    @alphis:

    absolutely inferior time warner cable in NYC my connection is going strong.

    Can I ask why TWC is inferior? I know cablevision highspeed is faster but other then that, they're services are the same. TWC basic RR is 10m/512k, but they offer turbo which is 20m/1m with speedboost up to 25mb down

    0
  • C

    If you aren't using 1.2.1, upgrade. The wireless in FreeBSD 7.0 seems to be more compatible with some devices. For one, Apple iPhones and iPods used to require specifying TKIP to connect via WPA, when every other device I have (including Macs) works fine on auto or AES. With 7.0 that isn't the case.

    0
  • S

    @cmb:

    If you aren't using 1.2.1, upgrade. The wireless in FreeBSD 7.0 seems to be more compatible with some devices. For one, Apple iPhones and iPods used to require specifying TKIP to connect via WPA, when every other device I have (including Macs) works fine on auto or AES. With 7.0 that isn't the case.

    I tried it on a friend's box who's running 1.2.1 and had the same problem (I had this happen on his wifi when he was running 1.2 as well). I will try upgrading my own device to 1.2.1 as soon as I can, to make sure. But so far it doesn't look good. :(

    0
  • S

    Forgot to mention something else - since the OP and I are both running Atheros chipsets I thought it might have something to do with that at first. But my friend's box has a RALink chipset.

    0
  • R

    Same problem here too, i've tested  with open, wep, wpa-psk with an atheros chipset card and…always the same.
    g1 connects but then suddenly disconnected by the pfsense box.

    0
  • N

    Just wanted to chime in and say that I just got a G1, and I already had pfSense 1.2.1 installed on a machine with an Atheros chip acting as B/G access point, and I'm having the same problem as the other posters in this thread.  My G1 gets an IP address from DHCP, but cannot actually connect to anything on either the local network, or the internet.  A local Belkin access point supplies internet to the G1 without issue, but the pfSense router fails.

    Any more suggestions, or any other diagnostics that you would like me to gather?  Thank you.

    0
  • C

    Sounds like this is similar to the problem I ran into recently with a Blackberry Bold. It connected and got an IP just fine, but its ARP requests were never answered.

    Someone with one of these, run this from a SSH session:

    tcpdump -ni ath0

    replacing ath0 with the name of your wireless interface if it's different, with nothing but the G1 connected to your AP. Reboot it, and see what happens. Post the output here.

    0
  • C

    Looks like we may have a solution to this.
    http://thread.gmane.org/gmane.os.freebsd.current/110707

    I think this is the same as the issue mentioned there. This patch will be going into 1.2.3 snapshots. I'll post here when that change is in the snapshots.

    0
  • C

    New snapshot with the aforementioned kernel patch is available:
    http://snapshots.pfsense.org/FreeBSD7/RELENG_1_2/pfSense-Full-Update-1.2.3-20090125-1637.tgz

    or newer will have that patch. Those of you with a G1, please test and report back.

    0
  • S

    Didn't seem to fix my problem. Having just seen this now, I am running a much newer snapshot:

    http://snapshots.pfsense.org/FreeBSD7/RELENG_1_2/pfSense-Full-Update-1.2.3-20090225-0327.tgz

    I assume the same fix is still there though. My G1 associates, then says it is trying to obtain an IP address, it never gets beyond that step. System logs show this:

    Mar 1 23:07:33 	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: associated
Mar 1 23:07:34 	hostapd: ath0: STA 00:18:41:d7:a1:6b WPA: pairwise key handshake completed (RSN)
Mar 1 23:08:03 	hostapd: ath0: STA 00:18:41:d7:a1:6b WPA: group key handshake completed (RSN)
Mar 1 23:08:05 	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: deassociated
Mar 1 23:08:09 	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: associated
Mar 1 23:08:09 	hostapd: ath0: STA 00:18:41:d7:a1:6b WPA: pairwise key handshake completed (RSN)
Mar 1 23:08:29 	dnsmasq[652]: reading /var/dhcpd/var/db/dhcpd.leases
Mar 1 23:08:40 	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: deassociated
Mar 1 23:08:44 	hostapd: ath0: STA 00:18:41:d7:a1:6b IEEE 802.11: associated
Mar 1 23:08:44 	hostapd: ath0: STA 00:18:41:d7:a1:6b WPA: pairwise key handshake completed (RSN)

    Ran packet capture while the G1 was supposedly trying to get an IP, this is all I found from its MAC:

    23:10:00.767467 00:18:41:d7:a1:6b > ff:ff:ff:ff:ff:ff Null Supervisory, Receiver not Ready, rcv seq 64, Flags [Poll], length 6

    Hope that helps. And my apologies for not testing sooner, I kinda forgot about this for a while.

    0
  • J

    Any update on this ?

    Has the kernel patch worked for someone ?

    Julian

    0
  • C

    It works fine for the one system I had access to at the time.

    0
  • S

    So…. I'd been periodically trying new builds, and other troubleshooting, changing settings around on the wifi.

    Then this past weekend I swapped out the card with the Atheros chipset for one with a RaLink chipset. However right after making the swap, I noticed the rule on the wifi interface was set to allow All TCP instead of ALL traffic, so I changed that as it probably would have been preventing DHCP (among other important things). Exactly when that rule got changed, I'm not sure. I probably screwed it up when re-adding it after initial troubleshooting.

    Bottom line for me is it does work now (especially awesome since there's no T-Mobile 3G where I live). But I don't know whether it's because of the chipset change, or because I changed the rule (possibly one of the newer builds already fixed the problem and I couldn't tell because of the incorrect rule).

    0
  • J

    Ok, so I tried 1.2.2 and it didn't work for me.
    Now, I'm running 1.2.3-RC1 and it finally works.

    FYI. Thanks,

    Julian

    0
Log in to reply
 

Products

Services

Support

News

Resources

Company

Our Mission

We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

Subscribe to our Newsletter

Product information, software announcements, and special offers. See our newsletter archive for past announcements.

© Copyright 2002 - 2019 Rubicon Communications, LLC | Privacy Policy