You know right now the only thing keeping me from bothering the BTU login password, is any future TM's "update"

Out of curiosity, can we track the culprit down with the SIP ID that it was changed to?

just curious, if it is not ur IP why bother censored it.  Hope the non censored version is sent to TM

Don't worry about it. As long as you're behind NAT and you haven't set any matching port forwarding rules, the router will always drop those connections.

under the router. where we insert username and password of unifi for WAN connection, there is 1 textbox for service (name) optional, what do we need to put there?

original setting and the router given by TM

This kind of action is "normal" for the Internet.
With the whole world connected, there's bound to be a few thousand hackers out there scanning ports and IPs, and your bound to get hit by some of them.....

I only detected those consistent unknown random ports try to comes in my WHR-G300N router through vlan.500 for internet only, yes that's why I'm concern ...

Guess what, they just called me, they confirmed that IP 110.159.xxx.248 is actually belongs to them 
The CS staff can't explain why anymore and now is escalating to his superior to call me to explain further .....

I think I'm in for surprises, again ...

you are transfered to "Abuse team"  

Fiberhome BTUs only have 1 profile and if I recall when I logged into pr0d1gy's Huawei when we were figuring out how to do the PPPoE stuff.. I never saw a 'jack' account in there.

But you can ask him to reconfirm seeing as he's probably the first guy on LYN to make the BTU settings backup when he wrote his guide.

Really? That's weird.. I don't remember seeing it when I accessed pr0d's but I could be mistaken. The only thing I noticed within the XML config file itself was the existence of two accounts to access the Huawei BTU.. one with admin privs and another without.

I have to do some testing at this point, would be cool if you can let me access your Huawei BTU seet ;D

now i got another problem.. VOIP back on on tues... but today im getting calls since 2pm.. every 5-10 mins once... answered... only beeping sound... beep.. beep... beep...

driving me nuts!

I hope TM really need to look in to the big security issue in Unifi, if continue like this all our privacy will broken out. All unifi user are under risk now, please someone write the email to newspaer bring up this issue. and let TM look in to it. As we are user not much we can do.

Anyway, I'm done checking out the Huawei Echolife (thanks seet!).

Obtained some really useful information.. the Echolife has 4 basic ports which are open at all times (and listening), TCP 80, 22, 23 and 8011. TCP 80, 22 and 23 and blocked from WAN/LAN access using an inbuilt iptables firewall. TCP 8011 however, is open at all times and I'm not sure what it's being used for.

As for this security issue, there's no real way to change the telecomadmin and root account passwords through the GUI... you have to download the config file, modify the password and reupload it. Haven't tested it myself but it should work. You also want to look at the 'services' passwords such as the telnet and SSH pass which is root/admin and change that too.

I did however get some info regarding how we can use our own SIP devices with Unifi Will be working on that in a bit.

Guys, good news.
I have confirmed HP Procurve 1700-8G can replace The Dlink for VLAN tagging and bridging work.
Now I can really put the Dlink to rest.

*now to test the IPTV thing...*

Just fyi, if you remove the 'jack' @ screen no4, the 'jack' 8765000 number should not be appear on screen no3 anymore.(at least on my case because i remove earlier b4 this guide) However i still puzzled why we got 2 SIP entries, 0 and 1 (@ screen no3)

Yeah, if your checksum is 10bec11e0ab5a9c195289b861b71e51e the file is correct. On mine, I got different checksums and the file is corrupted.

Packet loss is a slightly different issue than the corrupted downloads ... With packet loss it means that some of the packets being sent from one side to another didn't make it. It could either be a router along the way dropped it due to being overloaded, or it got corrupted along the line and the receiving network equipment detected the corruption and dropped the packet. Packet loss is "not too bad an issue" as the higher level of the network stack (TCP) will request the other end to retransmit missing packets. So at the end of the day when it reaches your application (browser, ftp, whatever) you will see "perfect" data. The only downside to packet loss is that slows your transfer, as the receiver has to re-request packets when it sees something missing.

The data corruption issue is a bit more sinister though ... in a proper network, the TCP level checks the integrity of the data and requests re-transmission of bad packets, so the application level sees perfect data. Yet those facing the data corruption problem are not seeing any errors ... but still getting bad data. It means somewhere along the path from the two ends, the network stack is not doing the right thing.

I can live with some packet loss but not data corruption!

I'm trying to figure out the spread of those facing the data corruption issue and if there is any common denominator. It seems though that only SOME users are seeing it, not all. I'm also wondering if it is something at the home side or the center.

I asked klseet to test as I thought he was using the RB250, if you get data corruption problems on that it means the dlink is innocent. 8-) Since i have the problem, I guess I have to wait till I get hold of a RB250 to prove that.

regards,
.sha

Still bad....