I started to use OpenWrt a bit ago, and I configured it with success to suit my needs. When I got my new WiFi enabled Blackberry, I successfully peered it with my router but almost no packets were going through. Even disabling all security protocols didn't help. My laptop was not having this issue. I re-flashed my Asus router to stock firmware to see if it was hardware problem, and it worked flawlessly then. Discussing this trouble with my colleagues I found a strange link between those using *NIX based AP and this trouble. (PFSense, Gigafast WF719-CAPR, OpenWrt) Anybody aware of this trouble ?
Topic: Using Blackberry Bold with OpenWrt (on Asus WL-520GU)
The content of this topic has been archived on 4 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.
Page 1 of 1
Same here. I 'm using a DD-WRT-based router right now, works with no problems.
OpenWRT and Blackberry WiFi won't work.
I'm trying to drill into this problem, but found no solution so far.
I once had a problem with my Nokia N800 simply not working with an atheros-based router I made. It's probably the Blackberry's fault.
OK, Atheros may be a hint: I'm testing with a Netgear WGT634U.
I'll try to test with a Broadcom in the next days.
My BB Bold does work with my asus WL 500g deluxe using kernel 2.4 with wpa psk.
The wifi network is connected and i can even connect to ssh.
What happen when you try to connect?
Either I obtain a DHCP succesfully or set a static IP, I manage to reach (ping) my BB from another station of the network one time out of 100 ... So it's mostly packet loss but it's connected to the router. It's not a signal quality problem, I made sure of that.
While neither here nor there, I will point out that the Iphone successfully peers with a WGT634U running 8.09RC1 that utilizes an Atheros chipset (IE Madwifi)
Could this be a limitation of the blackberry's wifi chipset?
To test the all *nix theory, find a WGT634U with stock firmware and see if it peers, IIRC even the stock firmware in linux based. Or better, try to peer with a stock WNR netgear device based off of OpenWRT.
Just to let you know:
- I use Asus 500gP with Kamikaze 7.XX and my Blackberry works fine even with WPA/PSK enabled on the router.
- I also use Alix board with CM9 Wifi card and Kamikaze 8.09 and it works fine with iPod, PSP and several notebooks, but not with Blackberry Bold - the phone obtains IP address, but is not able to communicate. I will attach a tcpdump later, because it seems to be a bit strange - like dialog of two deaf sides - both sides (Blackberry and rcp.eu.blackberry.com) are repeating still the same TCP packet (sequence numbers, size, ... are still the same).
Any hint welcomed
The promised tcpdump from Alix Kamikaze box with CM9 card. The Brebera is the Blackberry Bold...
root@ry2lRouter:~# tcpdump -i br-lan host brebera
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), capture size 96 bytes
14:28:40.240808 IP 192.168.7.1.67 > brebera.68: BOOTP/DHCP, Reply, length 301
14:28:40.310841 IP 192.168.7.1.67 > brebera.68: BOOTP/DHCP, Reply, length 301
14:28:41.323861 IP 192.168.7.1.67 > brebera.68: BOOTP/DHCP, Reply, length 301
14:28:41.662327 arp who-has 192.168.7.1 (Broadcast) tell brebera
14:28:41.662392 arp reply 192.168.7.1 is-at 00:0b:6b:de:56:74 (oui Unknown)
... BES server connection attempt deleted...
14:29:22.298095 arp who-has brebera tell 192.168.7.1
14:29:36.338566 IP brebera > 192.168.7.1: ICMP echo request, id 41537, seq 0, length 9
14:29:36.348096 arp who-has brebera tell 192.168.7.1
14:29:36.353049 arp reply brebera is-at 192.168.7.107
14:29:36.353076 IP 192.168.7.1 > brebera: ICMP echo reply, id 41537, seq 0, length 9
14:29:46.297104 IP brebera.50084 > rcp.eu.blackberry.com.443: S 1285441758:1285441758(0) win 65535 <mss 1360>
14:29:46.359047 IP rcp.eu.blackberry.com.443 > brebera.50084: S 3720499773:3720499773(0) ack 1285441759 win 4080 <mss 1380>
14:29:48.319571 IP brebera.50084 > rcp.eu.blackberry.com.443: S 1285441758:1285441758(0) win 65535 <mss 1360>
14:29:49.358010 IP rcp.eu.blackberry.com.443 > brebera.50084: S 3720499773:3720499773(0) ack 1285441759 win 4080 <mss 1380>
14:29:50.362008 IP brebera.50084 > rcp.eu.blackberry.com.443: S 1285441758:1285441758(0) win 65535 <mss 1360>
14:29:54.439585 IP brebera.50084 > rcp.eu.blackberry.com.443: S 1285441758:1285441758(0) win 65535 <mss 1360>
14:29:55.353671 IP rcp.eu.blackberry.com.443 > brebera.50084: S 3720499773:3720499773(0) ack 1285441759 win 4080 <mss 1380>
14:29:58.543452 IP brebera.50084 > rcp.eu.blackberry.com.443: S 1285441758:1285441758(0) win 65535 <mss 1360>
14:30:02.348083 arp who-has brebera tell 192.168.7.1
14:30:06.737296 IP brebera.50084 > rcp.eu.blackberry.com.443: S 1285441758:1285441758(0) win 65535 <mss 1360>
...now it reached a timeout or number of re-tries and tries to establish new connection...
14:30:24.750692 IP brebera.49852 > rcp.eu.blackberry.com.443: S 318644347:318644347(0) win 65535 <mss 1360>
14:30:24.818090 arp who-has brebera tell 192.168.7.1
14:30:26.772759 IP brebera.49852 > rcp.eu.blackberry.com.443: S 318644347:318644347(0) win 65535 <mss 1360>
14:30:26.818089 arp who-has brebera tell 192.168.7.1
14:30:28.810776 IP brebera.49852 > rcp.eu.blackberry.com.443: S 318644347:318644347(0) win 65535 <mss 1360>
14:30:31.349358 IP brebera > 192.168.7.1: ICMP echo request, id 41537, seq 256, length 9
14:30:31.358095 arp who-has brebera tell 192.168.7.1
14:30:31.362318 arp reply brebera is-at 192.168.7.107
14:30:31.362344 IP 192.168.7.1 > brebera: ICMP echo reply, id 41537, seq 256, length 9
14:30:32.894293 IP brebera.49852 > rcp.eu.blackberry.com.443: S 318644347:318644347(0) win 65535 <mss 1360>
14:30:36.994291 IP brebera.49852 > rcp.eu.blackberry.com.443: S 318644347:318644347(0) win 65535 <mss 1360>
14:30:45.196248 IP brebera.49852 > rcp.eu.blackberry.com.443: S 318644347:318644347(0) win 65535 <mss 1360>Is there an oracle who is able to guess the problem from this sniplet?
Update:
I also tried to switch off encryption and surprise, surprise - it works ok. So problem is probably in an encryption compatibility issue...
(Last edited by jrydval on 30 Apr 2009, 18:00)
The discussion might have continued from here.
Page 1 of 1