So it creates a DHCP reservation in a bad subnet. That's it. The only bad thing is the customer device gets a bad IP.
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Mar 9, 2015 10:57 AM, "That One Guy" <[email protected]> wrote: > me and my tinfoil hat find it suspiscious that v10 resolved the constant > overloaded billing servers and this pops up, like there is a list somewhere > and since the first one I saw was affiliated with bitcoins, Paranoid me > assumed a developer sometime in the historical chain realized there were > alot of unused cycles out there under their control. > > On Mon, Mar 9, 2015 at 9:51 AM, Josh Luthman <[email protected]> > wrote: > >> Look up variable declaration types. I'm willing to bet someone did the >> math wrong. I've seen it a couple times before but I can't recall where. >> >> While the IPs look random, they're not. >> >> Josh Luthman >> Office: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> Suite 1337 >> Troy, OH 45373 >> On Mar 9, 2015 10:47 AM, "That One Guy" <[email protected]> >> wrote: >> >>> Where are these IPs coming from. >>> >>> and this is a direct serious question, at any point in time, whether as >>> a product of bertram or the previous developers, were billing servers used >>> as a distributed bitcoin mining system? >>> >>> On Mon, Mar 9, 2015 at 9:37 AM, Simon Westlake <[email protected]> >>> wrote: >>> >>>> It's not database corruption, but it is a known bug (IP changing when >>>> MAC is edited in customer portal) and it's fixed in 10.03.32. The patch >>>> will be out this week. >>>> >>>> On 03/08/2015 10:34 PM, Jeremy wrote: >>>> >>>> Yes, it seemed like a database corruption issue to me as well. I had >>>> one customer get the redirect and I went in and looked and he was on a >>>> completely wrong IP (in a subnet that I happened to be working on earlier >>>> that day and the evening before). He hadn't even logged into the customer >>>> portal. The logs didn't show any IP change, but clearly his IP was changed >>>> in the database, as he was working fine on the same IP for months and >>>> months. That issue and the incorrect assignments when a customer enters a >>>> new MAC seemed related to me. >>>> >>>> On Sun, Mar 8, 2015 at 9:26 PM, CBB - Jay Fuller < >>>> [email protected]> wrote: >>>> >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> *From:* Jay Fuller - Cyber Broadband Inc >>>>> *To:* Powercode >>>>> *Cc:* Cyber Broadband Inc. >>>>> *Sent:* Monday, February 02, 2015 7:34 PM >>>>> *Subject:* Re: Ticket Updated [Ticket Number:5841] - weird ip changes >>>>> during customer portal equipment edits >>>>> >>>>> >>>>> Gentlemen: >>>>> >>>>> It has happened again. >>>>> >>>>> xxxxxxxxxxxxx, customer 1478, requested a public routable IP address >>>>> which is >>>>> in a different address class from what he was assigned at >>>>> installation. >>>>> Upon changing the address, he was assigned 104.152.40.91, which is an >>>>> available address in the "Cullman Public" address range. However, >>>>> when >>>>> looking at the ARP response (because the customer is bridged to our >>>>> main >>>>> router), I saw another network device already had that IP address. >>>>> >>>>> So, I searched for that MAC address, which was 78:24:AF:7B:49:38 , >>>>> using >>>>> equipment search, which came back to customer >>>>> 514, xxxxxxxxxxxxxxxxxxxxx, who had logged into the customer portal on >>>>> January 29 to >>>>> install a new router. Upon changing his MAC address, powercode >>>>> assigned him >>>>> 104.153.191.25, which is not even in any of our network address ranges. >>>>> >>>>> It belongs to: >>>>> >>>>> Source: whois.arin.net >>>>> IP Address: 104.153.191.25 >>>>> Name: IMDC-KC-LOOPBACKS >>>>> Handle: NET-104-153-191-0-1 >>>>> Registration Date: 2/2/15 >>>>> Range: 104.153.191.0-104.153.191.31 >>>>> Org: Iron Mountain Data Center >>>>> Org Handle: IMIML >>>>> Address: One Federal Street >>>>> City: Boston >>>>> State/Province: MA >>>>> Postal Code: 02111 >>>>> Country: UNITED STATES >>>>> >>>>> >>>>> This is very similar to our new public IP range which is >>>>> 104.152.40.0/22 >>>>> >>>>> Incidently, it appears this customer was assigned 104.152.40.91 before >>>>> he >>>>> attempted to edit his equipment and was changed to 104.153.191.25. >>>>> Also of >>>>> note, it appears this only affected the GUI/web interface of >>>>> powercode, and >>>>> the router/bmu continued to assign him 104.152.40.91. >>>>> >>>>> I will now have to reassign xxxxxxxxx a new IP address since the >>>>> web/gui >>>>> gave his IP address to someone else. >>>>> I hope this information helps you to figure out what is happening. >>>>> >>>>> I am still concerned we have some kind of database issue. Weird >>>>> things like >>>>> this seem to be happening a lot. >>>>> >>>>> Thanks. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: Powercode >>>>> To: Cyber Broadband >>>>> Sent: Thursday, January 22, 2015 2:15 PM >>>>> Subject: Ticket Updated [Ticket Number:5841] >>>>> >>>>> >>>>> ---------------- Please reply above this line ---------------- >>>>> Good afternoon Jay, >>>>> >>>>> We were able to test from this customer's account, and the same issue >>>>> that >>>>> was originally reported to us persisted. We logged into the customer >>>>> portal, >>>>> changed the MAC address by one digit, and immediately the customer was >>>>> issued an IP address of 192.170.241.173. After changing the MAC >>>>> address back >>>>> to his current valid one, we then had to manually clear out his IP >>>>> address >>>>> in Powercode in order for the BMU to hand out a reservation for >>>>> 192.168.3.36 >>>>> via DHCP. >>>>> >>>>> At this point, we are going to contact our network engineers for >>>>> assistance >>>>> in troubleshooting why this customer would receive a 192.170.xx.xx >>>>> reservation, as this IP does not fit within any ranges defined in >>>>> Powercode. >>>>> We will update you as soon as we've had a chance to go over this with >>>>> them. >>>>> >>>>> >>>>> >>>>> -------------------------------------------------- >>>>> >>>>> Have you visited our knowledge base? The Powercode knowledge base >>>>> contains >>>>> data on all aspects of Powercode, including the BMU. You may also find >>>>> useful information on our community forum. >>>>> We endeavor to respond to all tickets within two business days. Our >>>>> business >>>>> hours are Monday - Friday, 9AM to 5PM Central time. Please contact us >>>>> via >>>>> telephone at (920) 351-1010 or via Skype at powercode_support with >>>>> any >>>>> urgent needs. >>>>> >>>>> >>>>> -- >>>>> John Mahnke >>>>> >>>>> Powercode - The smart choice in ISP billing and OSS >>>>> powercode.com >>>>> P: 920-351-1010 >>>>> E: [email protected] >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> *From:* Jeremy <[email protected]> >>>>> *To:* [email protected] >>>>> *Sent:* Sunday, March 08, 2015 9:25 PM >>>>> *Subject:* Re: [AFMUG] Powercode oddity - Commerzbank Ip space >>>>> >>>>> I also have a ticket in about this issue. >>>>> >>>>> On Sun, Mar 8, 2015 at 2:10 PM, That One Guy < >>>>> [email protected]> wrote: >>>>> >>>>>> This is known to them? (powercode) >>>>>> >>>>>> On Sun, Mar 8, 2015 at 3:00 PM, CBB - Jay Fuller < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> >>>>>>> yes, they're aware of it. i pointed this out to them weeks ago. :( >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> *From:* That One Guy <[email protected]> >>>>>>> *To:* [email protected] >>>>>>> *Sent:* Sunday, March 08, 2015 2:06 PM >>>>>>> *Subject:* [AFMUG] Powercode oddity - Commerzbank Ip space >>>>>>> >>>>>>> I am able to replicate a small issue we are having, trying to make >>>>>>> the decision of whether it looks like a security issue or just a bug. >>>>>>> >>>>>>> Through powercode, there are two ways to update equipment, through >>>>>>> our interface, where we select all the details and through the customer >>>>>>> portal where all the customers can do is update their MAC address. >>>>>>> >>>>>>> no problems with our end. >>>>>>> >>>>>>> However, when a customer updates their MAC address, it is >>>>>>> assigning IP space that apparently belongs to this Commerzbank IP >>>>>>> space 208.74.54.100 and 208.74.54.99. >>>>>>> >>>>>>> This IP space is absolutely not in our system, and wouldnt route >>>>>>> naturally on our network >>>>>>> >>>>>>> Net Range 208.74.52.0 - 208.74.55.255 CIDR 208.74.52.0/22 >>>>>>> Name DKIB-USA Handle NET-208-74-52-0-1 Parent NET208 ( >>>>>>> NET-208-0-0-0-0 >>>>>>> <http://whois.arin.net/rest/net/NET-208-0-0-0-0.html>) Net Type Direct >>>>>>> Assignment Origin AS >>>>>>> Organization Commerzbank AG (COMMER-109 >>>>>>> <http://whois.arin.net/rest/org/COMMER-109.html>) >>>>>>> >>>>>>> My initial thoughts are this is some bug in powercode. >>>>>>> >>>>>>> Paranoid me is that our system is somehow compromised and >>>>>>> rerouting illegitimate traffic somehow. Customer is down, so not through >>>>>>> them. but something like TOR rerouting or some other magician script for >>>>>>> the axis of evil. >>>>>>> >>>>>>> Anybody have any ideas on this? I am debating taking our billing >>>>>>> server offline, but would hate to take such an extreme measure for what >>>>>>> could amount to nothing more than a fat finger from a programmer. >>>>>>> >>>>>>> -- >>>>>>> If you only see yourself as part of the team but you don't see >>>>>>> your team as part of yourself you have already failed as part of the >>>>>>> team. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> If you only see yourself as part of the team but you don't see >>>>>> your team as part of yourself you have already failed as part of the >>>>>> team. >>>>>> >>>>> >>>>> >>>> >>>> -- >>>> Simon Westlake >>>> Powercode - The smart choice in ISP billing and OSS >>>> powercode.com >>>> P: 920-351-1010 >>>> E: [email protected] >>>> >>> >>> >>> >>> -- >>> If you only see yourself as part of the team but you don't see your team >>> as part of yourself you have already failed as part of the team. >>> >> > > > -- > If you only see yourself as part of the team but you don't see your team > as part of yourself you have already failed as part of the team. >
