Tutor
•
3 Messages
3G Microcell not working behind BSD router [technical discussion]
I just moved to an area where the AT&T coverage is "1 bar" at best, and nothing inside the house. One is lucky if text messages get out from within the house. Hence, we've bought a Microcell.
When the Microcell is hooked directly to the Verizon router (FIOS) and the Verizon router is connected directly to the internet, the Microcell works fine.
When I replace the Verizon router with my OpenBSD 4.9 based router, the Microcell quits working. The Power, Internet, and GPS lights go green as expcected, but the 3G lights just flashes. Apparently this means that it's not talking to AT&T's back end.
So...... I've been doing packet captures, and I honestly cannot see where it's even trying to talk to AT&T, other than resolving dpese.wireless.att.com. Below is my capture log Perhaps someone can shed some light on this?
Sep 30 08:53:14.805534 e4:48:c7:2b:5d:18 ff:ff:ff:ff:ff:ff 0800 590: 0.0.0.0.68 > 255.255.255.255.67: xid:0xe926f609 [|bootp] Sep 30 08:53:14.806857 00:a0:c9:af:85:a2 e4:48:c7:2b:5d:18 0800 351: 192.168.100.1.67 > 192.168.100.155.68: xid:0xe926f609 Y:192.168.100.155 S:192.168.100.1 [|bootp] [tos 0x10] Sep 30 08:53:14.829527 e4:48:c7:2b:5d:18 ff:ff:ff:ff:ff:ff 0800 590: 0.0.0.0.68 > 255.255.255.255.67: xid:0xe926f609 [|bootp] Sep 30 08:53:14.832526 00:a0:c9:af:85:a2 e4:48:c7:2b:5d:18 0800 351: 192.168.100.1.67 > 192.168.100.155.68: xid:0xe926f609 Y:192.168.100.155 S:192.168.100.1 [|bootp] [tos 0x10] Sep 30 08:53:16.725605 e4:48:c7:2b:5d:18 01:00:5e:02:02:07 0800 60: 192.168.100.155 > 234.2.2.7: igmp nreport 234.2.2.7 (DF) [tos 0xc0] [ttl 1] Sep 30 08:53:22.257415 e4:48:c7:2b:5d:18 01:00:5e:02:02:07 0800 60: 192.168.100.155 > 234.2.2.7: igmp nreport 234.2.2.7 (DF) [tos 0xc0] [ttl 1] Sep 30 08:53:31.789305 e4:48:c7:2b:5d:18 01:00:5e:02:02:07 0800 60: 192.168.100.155 > 234.2.2.7: igmp nreport 234.2.2.7 (DF) [tos 0xc0] [ttl 1] Sep 30 08:55:31.035484 e4:48:c7:2b:5d:18 01:00:5e:02:02:07 0800 60: 192.168.100.155 > 234.2.2.7: igmp nreport 234.2.2.7 (DF) [tos 0xc0] [ttl 1] Sep 30 08:57:33.101671 e4:48:c7:2b:5d:18 01:00:5e:02:02:07 0800 60: 192.168.100.155 > 234.2.2.7: igmp nreport 234.2.2.7 (DF) [tos 0xc0] [ttl 1] Sep 30 08:59:43.535770 e4:48:c7:2b:5d:18 01:00:5e:02:02:07 0800 60: 192.168.100.155 > 234.2.2.7: igmp nreport 234.2.2.7 (DF) [tos 0xc0] [ttl 1] Sep 30 09:01:44.569963 e4:48:c7:2b:5d:18 01:00:5e:02:02:07 0800 60: 192.168.100.155 > 234.2.2.7: igmp nreport 234.2.2.7 (DF) [tos 0xc0] [ttl 1] Sep 30 09:01:44.981848 e4:48:c7:2b:5d:18 ff:ff:ff:ff:ff:ff 0806 60: arp who-has 192.168.100.1 tell 192.168.100.155 Sep 30 09:01:44.981889 00:a0:c9:af:85:a2 e4:48:c7:2b:5d:18 0806 60: arp reply 192.168.100.1 is-at 00:a0:c9:af:85:a2 Sep 30 09:01:44.982069 e4:48:c7:2b:5d:18 00:a0:c9:af:85:a2 0800 82: 192.168.100.155.25431 > 192.168.100.1.53: 61396+ A? dpese.wireless.att.com. (40) (DF) Sep 30 09:01:45.034835 00:a0:c9:af:85:a2 e4:48:c7:2b:5d:18 0800 114: 192.168.100.1.53 > 192.168.100.155.25431: 61396 2/0/0 A 12.230.208.67, A 12.230.208.40 (72) Sep 30 09:01:45.043234 e4:48:c7:2b:5d:18 00:a0:c9:af:85:a2 0800 86: 192.168.100.155.27061 > 192.168.100.1.53: 53392+ PTR? 67.208.230.12.in-addr.arpa. (44) (DF) Sep 30 09:01:45.045050 00:a0:c9:af:85:a2 e4:48:c7:2b:5d:18 0800 173: 192.168.100.1.53 > 192.168.100.155.27061: 53392 NXDomain 0/1/0 (131) Sep 30 09:03:48.536612 e4:48:c7:2b:5d:18 01:00:5e:02:02:07 0800 60: 192.168.100.155 > 234.2.2.7: igmp nreport 234.2.2.7 (DF) [tos 0xc0] [ttl 1] Sep 30 09:04:20.493935 00:a0:c9:af:85:a2 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.100.178 tell 192.168.100.1 Sep 30 09:05:55.426658 e4:48:c7:2b:5d:18 01:00:5e:02:02:07 0800 60: 192.168.100.155 > 234.2.2.7: igmp nreport 234.2.2.7 (DF) [tos 0xc0] [ttl 1] Sep 30 09:08:07.100674 e4:48:c7:2b:5d:18 01:00:5e:02:02:07 0800 60: 192.168.100.155 > 234.2.2.7: igmp nreport 234.2.2.7 (DF) [tos 0xc0] [ttl 1] Sep 30 09:10:06.714927 e4:48:c7:2b:5d:18 01:00:5e:02:02:07 0800 60: 192.168.100.155 > 234.2.2.7: igmp nreport 234.2.2.7 (DF) [tos 0xc0] [ttl 1] Sep 30 09:12:15.445476 e4:48:c7:2b:5d:18 01:00:5e:02:02:07 0800 60: 192.168.100.155 > 234.2.2.7: igmp nreport 234.2.2.7 (DF) [tos 0xc0] [ttl 1] Sep 30 09:14:20.395200 e4:48:c7:2b:5d:18 01:00:5e:02:02:07 0800 60: 192.168.100.155 > 234.2.2.7: igmp nreport 234.2.2.7 (DF) [tos 0xc0] [ttl 1] Sep 30 09:16:23.249246 e4:48:c7:2b:5d:18 01:00:5e:02:02:07 0800 60: 192.168.100.155 > 234.2.2.7: igmp nreport 234.2.2.7 (DF) [tos 0xc0] [ttl 1] Sep 30 09:18:26.019485 e4:48:c7:2b:5d:18 01:00:5e:02:02:07 0800 60: 192.168.100.155 > 234.2.2.7: igmp nreport 234.2.2.7 (DF) [tos 0xc0] [ttl 1] Sep 30 09:20:29.745643 e4:48:c7:2b:5d:18 01:00:5e:02:02:07 0800 60: 192.168.100.155 > 234.2.2.7: igmp nreport 234.2.2.7 (DF) [tos 0xc0] [ttl 1] Sep 30 09:22:38.535740 e4:48:c7:2b:5d:18 01:00:5e:02:02:07 0800 60: 192.168.100.155 > 234.2.2.7: igmp nreport 234.2.2.7 (DF) [tos 0xc0] [ttl 1] Sep 30 09:24:42.857917 e4:48:c7:2b:5d:18 01:00:5e:02:02:07 0800 60: 192.168.100.155 > 234.2.2.7: igmp nreport 234.2.2.7 (DF) [tos 0xc0] [ttl 1]
Comments about the captures:
Basically the thing boots up, gets an IP address via DHCP, eventually asks about dpese.wireless.att.com, get's a valid response, but never attempts to contect said server. In the mean time, it's trying to do some unknown igmp/multicast nonsense. Anyone have any ideas? Does someone have a capture of a known working Microcell that I could compare to?
One more thing..... Please don't suggest that I place the device in "Priority Mode". For MANY reasons, my firewall must come first on my network,.
Kind Regards,
Larry Wimble
Accepted Solution
Official Solution
lwimble
Tutor
•
3 Messages
13 years ago
You're not going to believe this, but......
Apparently the microcell does not like the subnet 192.168.100.0/24. I temporartily reconfigured my network to 192.168.1.0/24 and the Microcell connected right up to AT&T and started working. I suspect 192.168.100.0/24 is the subnet that they use over IPSEC. It would sure have been nice if AT&T had documented this.... It would have saved me about 25 hours of beating my head against the wall.
Larry
0
nsayer
Guru
•
808 Messages
13 years ago
Howdy. I'm a FreeBSD geek, myself.
I've sniffed my own Microcell before, and I've not seen it do IGMP / multicast stuff, ever.
At first, I was going to suggest it might be the wrong Ethernet address, because my Microcell manufacturer ID is 00:22:3a, which I sort of understood to be the traditional one. But, indeed, E4-48-C7 resolves to Cisco SPVTG, same as the other.
I would expect it to open an SSL connection to one of those IP addresses it fetched on port 443 and fetch a configuration blob. Then, it should start doing NTP and then after a while open up an IPSEC-over-UDP tunnel.
Since it's stuck after doing the DNS queries, maybe try configuring DHCP to give an external DNS server instead of your internal resolver (192.168.100.1). Maybe there's something wrong with the answers it's giving back.
0
0
lwimble
Tutor
•
3 Messages
13 years ago
nsayer,
Oddly enough I had tried this early in the game. Strangely, in 2 hours it never even attempted a DNS query. Perhaps I'll try multiple external servers and see what I get.
Any other clues?
Thanks,
Larry
0
0
nsayer
Guru
•
808 Messages
13 years ago
Paranoia may destroy ya.
0
0
nsayer
Guru
•
808 Messages
13 years ago
I'm fortunate to have avoided it because the management interface of my cable modem is on that subnet, so I couldn't pick that one if I ever wanted to check on the cable modem from the inside.
0
0
drossetti
Contributor
•
1 Message
11 years ago
Thank you, Larry. I just banged my head against the SAME wall for 2 days. It sure would have been helpful to hear about this from the AT&T call center fellow, or find it easier on the web.
Fixed and done,
- Dave R.
0
0
OttoPylot
ACE - Expert
•
24.2K Messages
11 years ago
Interesting. If must be something to do with the way BSD routers are configured because I don't recall having anyone else have to go thru this much trouble. To be fair, with so many different routers out there and LAN setups, call support can't possibly know how to configure specific routers. AT&T lists the basic router requirments but it's up to the individual user to figure out how to meet those requirements.
0
0
Avedis53
Professor
•
2.2K Messages
11 years ago
Very interesting solution. Otto, you may want to work this into your Technical Guide.
Just another example of the problems that a one-size-fits-all box (Mcell) has with the many different kinds of routers available. No doubt that Cisco designed the Mcell to interface with mainstream routers, not with BSD-based equipment.
0
0
OttoPylot
ACE - Expert
•
24.2K Messages
11 years ago
I'm thinking about it, but if I do that for BSD-based routers, then I might as well delvelop a Guide for other routers as well, which would be very difficult to keep up with and current. Notice that he responded to a two-year old post so that lends me to believe that there aren't that many people out there who use that particular router configuration.
0
0
Avedis53
Professor
•
2.2K Messages
11 years ago
I agree that BSD routers aren't used by many people. However, I would offer that you are not necessarily compelled to produce a guide for other routers but if a known solution comes up like this, it needs to be saved in a centralized place like your Tech Guide so that people don't have to read through countless threads to find it. If not in the Tech Guide, then perhaps a Known Solution list.
Just a thought.....
0
0