- edited 05-13-2014 10:07 PM
I figured it was worth posting here so I have yet to have success with anything else.
I live in an area almost exactly inbetween three AT&T cell phone towers, so subsequently my phone is constantly switching singnals from one tower to the other giving me very inconsistent service. After diagnosing the problem with AT&T about six months ago they sent me a micro cell free of charge, and it worked absolutely fantastic until....
About a week ago my microcell's 3g light started flashing, this had happened once or twice before so I performed a simple reset but it did not fix the problem like before.
and none of these fixed the problems.
My current internet is about 30mbps DL and 10mbps upload so that isn't the problem
The ports on my router are all opened, and nothing has changed to effect that
After going extensively through the forums I am kind of at a loss of what to try next. Any suggestions from people on the forums?
I am currently located in the East Bay of California (Alameda, CA)
Thanks very much.
Solved by: Go to Solution.
- edited 10-30-2014 8:54 AM
The standard port used for SIP is 5060 UDP (some SIP provider's use others, just above and below this, but 5060 UDP is common) RIP is audio channel for VOIP portion of a VOIP phone normal area as I understand is around 7000 to 7300 UDP, but this can vary greatly depending on VOIP provider.
Not sure if this would really affect the Mcell as none of AT&T literature or information I've come across on Net indicates any port higher than 4500 UDP being used.....but maybe your provider has blocked SIP to "prevent unauthorized VOIP phones" on their network and they went wild with the UDP blocking and got into the 4500 range...............Run Gibson Research port scan, it would tell you if your blocked at either your ISP provider back towards you or your router end, it WON'T be able to scan back the other way. Not sure why partymonkey's fix worked, normal MTU is 1492....but glad it did. Wouldn't hurt to try it, if it doesn't help just set it back to 1492 and punt.
The reason, as I understand it, that fragmented packets is a problem is the possible addition (4 to 24 bytes is sometimes added to packet header's for various things, such as VLAN ID's, thus creating "Jumbo packets") of bytes to a packet. The Mcell is apparently Unable to reassemble these type packets and most (not all, but most) routers will just totally drop a packet if it is received fragmented, making no effort to reassemble it...
The T.38 is a particular VOIP protocol I believe..............one of many that I understand VOIP provider's use. This too is not mentioned anywhere in reference to the Mcell that I have ever come across.......Avedis53 is the guru on things VOIP, maybe he can throw more light on this subject.
Now one thing I HAVE come across is that many people have various types of Problems with certain Belkin Router's, but as yours worked previously it doesn't APPEAR that it is problem.........................................unless your ISP or AT&T has changed something in their systems that might be incompatible with your model Belkin....a model number and some Googling might turn up something.
For those that have found Workarounds, it seems that the workaround fixes follow little set patterns and are hit and miss.
Your bandwidth is now quite decent....to the house... and will help in that area of troubleshooting (you've eliminated ONE area possible issue's), but not sure you will get the full advantage of it unless you are running a Gigabit system (ie a Gigabit modem and/or router)......Watching my WAN port in my Router System system logs I am averaging (with Roku streaming video and 2-3 add'l devices active) that I average 2.5 - 3 gigabit of average traffic, with occasional peaks to almost 6 gigabits.
But hooking the Mcell directly to you internet line before the Router would probably eliminate this issue.............unless.....it is possible that your older modem is only 10-100 mb (Avedis53 mentioned your modem is an older model....).......possibly your ISP upped their system trunks speeds/line amplifier's (and maybe some packet characteristic's, and your older modem and/or your Router is now "dropping packets" , as it may be unable to handle the added speeds/packets properly.........now. That's definitely a question for your ISP...........have they upgraded OR changed their distribution trunks equipment recently?
I'd hang with your new higher speeds awhile.......at least until you can definitely pin down the issue.....maybe you can talk your ISP into Loaning you a newer modem to try for a few days......Being as old as it is you MAY be sniffing the right tree...it's a logical move.
10-30-2014 11:10 AM
@partymonkey - Having to lower your MTU setting in order to make your Mcell work properly is typically an indication of the presence of communication errors. Perhaps the initial handshake to the Mcell from the AT&T servers on port 443 wasn't able to communicate properly at the recommended MTU setting of 1492 since that communication is occurring on a TCP port that requires packets to be retransmitted if they are not received in the proper order.
If the retransmission rate is high enough due to issues with the quality of your internet connection, it could cause a communication error in the Mcell and the connection is not made to the servers. The rest of the ports communicate using the UDP protocol which is more of a "fire and forget" method. If the packets don't arrive or arrive out of order on a UDP port, no retransmission is requested. If the packet loss/corruption is great enough, then the Mcell won't connect either.
Changing your MTU setting from 1492 to 1480 isn't much of a change and I would agree that the data transfer rate wouldn't be appreciably affected. If that worked for you then that is great.
@fun2drive - Based on my understanding of the Motorola SB5101U, that modem is not capable of blocking ports. It's basically a dumb modem, therefore I don't think your modem is the problem. I think your next step is to take the Belkin N600NB out of your LAN and try temporarily connecting the Mcell directly to your modem as previously suggested. This should help narrow down where the problem may be.
I am not an AT&T employee.
10-30-2014 1:51 PM
Direct connection to the modem didn't work at all. I will be investigating if something is blocking some of these ports but Cox states they don't block those ports but lower numbered ports in the hundreds to protect from getting attacks.
I have not run the GRC.com software but will be looking into that when I have time...
Thanks to all that are trying to help me out here.
10-30-2014 1:56 PM
When you connected the MicroCell via the alternate connection (MicroCell -> modem, single ethernet cable, no switches) what did the light pattern look like on the MicroCell? If the power, ethernet, and GPS lights were solid green and only the 3G light was blinking, I'd try a hard reset and see if that works.
10-31-2014 7:49 PM
I unplugged the Microcell last night and plugged it in tonight and it is working. I have no idea why but it is working fine. I also have Magicjack and did some port forwarding for it 5060 and 5070 to improve what quality there is.
Wish I could tell you why it is working now but I can't but it is reaching the AT&T servers fine now. Tomorrow who knows. The Microcell was connected before I did the port forwarding by the way.
10-31-2014 7:52 PM
Didn't see this until I had already posted
"When you connected the MicroCell via the alternate connection (MicroCell -> modem, single ethernet cable, no switches) what did the light pattern look like on the MicroCell? If the power, ethernet, and GPS lights were solid green and only the 3G light was blinking, I'd try a hard reset and see if that works."
To answer your question it looked exactly the same. AT&T server connection light blinking on and off. Did hard reset a couple times no joy. Left it unplugged for a long while like a day and now it works. No idea why...
10-31-2014 8:27 PM
If the 3G light is blinking then there is no connection to the AT&T Mobility servers. Something may be off with your connection. It could be with your ISP, router, or whatever.
10-31-2014 10:17 PM
Like Otto said...this is "normally" an indication that the Mcell is not connecting to the AT&T servers....
But...........depends on what you consider connected. Mine was doing the same thing (3G light flashing). One time I was on the phone with the Network Engineer and he was watching my Mcell "connecting" to their servers. He observed it communicating and it appeared to be authorizing......then after a 10-15 min wait (he was on the line still) it errored out...."Failure to complete IPSEC tunnel".
So I was connecting to AT&T servers in San Antonio......but something on their end was not finishing the "connection" process........they never did figure out Why.
That your up and running is Great!
But they most likely were having issue's at their end ( or as I said somewhere on the Route to them something was down) and finally got whatever was your problem finally fixed........server reload, server updates, bad OS update that went bad (may have gone bad and took a few days to sort out..), etc. But also if you note on the Mcell Page...it may take up to 24hrs to authorize in some case's (gives them time to fix small issue's...this issue must have bit them).
So count your blessings and good luck from here on out..................(just don't uncross ALL your fingers....yet)
11-02-2014 9:41 AM
Hi @avedis53, on the MTU, true, but not necessarily. You can have any piece of equipment in the chain that is using a lower mtu (potentially incorrectly), and that will he case. Since I don't have time to muck around w/ this stuff, and try to solve the problem for any of the equipment manufacturers or ISPs in the middle, I found the optimal MTU for my network and applied that. As you say, it could be communication errors, it could be misconfigured equipment, or it could be unknown firmware bugs on any piece. My suspicion on the packet fragmentation hickup that gets fixed by the MTU tweak is that it's a bug in either my modem in bridge mode (because regular mode works fine), or my Netgear router in router (regular) mode.
BTW, just another tidbit for all other folks who indicate that MTU 1492 is the standard, to be clear, that is the appropriate size in IPV4 when operating PPP connections over Ethernet (PPPoE), which is the most common for US DSL or Cable broadband. There are other applications that require adjustments. And I know ATT indicates the MTU must be set at 1492, but I believe that the number is stated to differentiate from the 1500 MTU that many routers/modems have set as the default, although most are getting better at setting it to 1492 for pppoe interfaces.
Anyway, if nothing else is working on the microcell troubleshooting, it's pretty easy and quick to test it out by pinging for example ping www.att.com -f -l 1464 (assuming that you PC and OS has a standard MTU of 1500 on its network interface). If you do not get a message that indicates Packet needs to be fragmented, then 1492 is your optimal MTU (you have to add 28 to the ping number to account for ip and icmp). Anyway, you get the point....
11-15-2014 3:51 PM
Hello, I have the exact same problem as many of the people here do. The 3G light was working perfectly fine for years until a couple months ago. I don't how it started but when I got home from the movies one night, the 3G light just began blinking. I've tried suggestions such as reseting the MicroCell to forwarding ports. After a week of trying to fix it, it just started to work again like no issues had ever occured. However, only a couple days after it suddenly began to blink once again. I hoped that in due time it'll start up like it did previously. It has been over a month and nothing has changed. Is there anything that I'm doing wrong?
I live in Southern California -- Diamond Bar, CA. Towers do not reach the residential area where I live. I currently have 162 mbps download and 3.58 mbps upload (Time Warner Cable internet).
11-15-2014 10:53 PM
Do you know if TWC upgraded anything? We've seen this before with TWC when they upgraded network switches. The blinking green 3G light usually means that something has interrupted the secure VPN connection that is necessary for the MicroCell to work correctly.
Your speeds are fine. All the MicroCell needs is a sustained 3.0Mbps download speed to maintain voice. You need to run a VoIP test to see if your line quality is sufficient for VoIP. Your internet may be fine but VoIP has some very specific requirements.
12-19-2014 6:34 PM
As a pfSense user, I just wanted to add that if you are using an older version of pfSense, such as 1.2.3 (what I use), you need to tick the following option:
VPN: IPsec: Tunnels: Enable IPsec
I discovered this only after hours of messing around with port forwarding and other settings that made no difference in my failed efforts to activate the MicroCell. Until I enabled IPsec per the above (which I suspect also turns on IPsec passthrough), the MicroCell was not able to set up a tunnel and could not complete its activation. I knew something was really screwy when I could actually see the 172.x.x.x private range traffic the MicroCell was generating in the pfSense state table. That traffic should not have been visible to pfSense at all. I can only assume that when the MicroCell failed to establish the tunnel, some of the traffic was getting sent up to the default gateway (the pfSense box), where I could see it in the state table.
12-19-2014 7:59 PM
- edited 12-20-2014 3:05 PM
DV glad that worked for you.....Tried that several times on mine just in case and left it set for a couple of weeks like that, (ver 2.15, latest one) but that didn't cure my particular problem.....
I even set Mcell up on a standard router (with Ipsec and all allowed), as a matter of fact my Mcell quit working while on a Netgear router (where it had been working previously over a year). I didn't put the Pfsense box online until 4-5 months after the Mcell quit, left it off line until it was (painfully) obvious whatever was the problem wasn't on my end..
The IPSEC setting also brings up a tab under the firewall rules and you need to make sure to set up EDIT:Manual NAT
inbound Outbound rules on the WAN for Ipsec as (with 2.xxx versions), with the 1.xxx versions Ipsec NAT inbound Outbound was turned with the Automatic (Default Setting) Rules NAT setting....that behavior was one of the several tweaks and changes made when they went to 2.xxxx and requires turning on the Manual rules setup of NAT now. ---- FYI.....that behavior is not documented very well, if at all, I came across it in a Post by one of the Dev's to a user.
So if you upgrade...beware there are a few changes and some new functions from 1.xxxx
Thanks for the input.
12-20-2014 2:47 PM
Interesting. Here is where I am at with my configuration:
At this point, I have killed all of the MicroCell-specific firewall rules. Outbound (LAN tab), I allow all traffic, so that "just works". Inbound (WAN tab), there are no rules for 500/udp, 4500/udp, etc. There are no rules present on the IPsec tab.
For NAT, I use manual outbound rules, with one rule for regular many-to-one NAPT and another to prevent NAT between my privately-addressed LAN and publicly-addressed DMZ (a /29). I have no port forwarding rules.
The only "special" setting, at this point, is the 1:1 NAT (an IP in another /29) that I set up for the MicroCell when I first started to have trouble getting it activated. It may well be that I am avoiding some issues that would otherwise crop up if the MicroCell traffic was part of the NAPT scheme being used for the other hosts on my LAN. As you can see below, the outbound IPsec is not being remapped to a different source port:
udp 188.8.131.52:4500 <- 192.168.1.171:4500 MULTIPLE:MULTIPLE
udp 192.168.1.171:4500 -> x.x.x.242:4500 -> 184.108.40.206:4500 MULTIPLE:MULTIPLE
I may just leave it this way until I get to a point where I need to free up that public IP for some other application.