Jump to content

ndemou

Members
  • Posts

    171
  • Joined

  • Last visited

Recent Profile Visitors

8,794 profile views

ndemou's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. BTW, checked today and it works. Thanks again
  2. I'm going to a random domain, verify that its time zone is default, then go to a random service flag, verify the timezone is default again and at the top I see this: Current time for this account: 9:19:05 I then verify that the operating system is displaying the correct time (8:19:34) and timezone (EET)
  3. Hi, when selecting "Greece, Athens" timezone the time is off by +1Hr, i.e. it displays 10:45 (GMT+3) when the actual time is 9:45(GMT+2). It doesn't matter how you set the timezone (at the system level, domain level or account level). Also the OS displays time correctly (9:45 EET). My workaround was to use Central "African time (GMT+2)".
  4. Apparently the web password is now as important as the SIP password. Right? I mean that a hacker with a domain a user name and a web password can make any external calls the user is allowed to make.
  5. I need a switch in front of my 2 PBX's mainly for 2 reasons: Route incoming calls to one or the other PBX and outgoing calls to the best trunk (Least Cost Routing) Do some some clever mangling of SIP headers to conform with the expectations of my trunks I'm looking at free soft-switches with commercial support. Is anybody having experience with this? Any thoughts or suggestions? Freeswitch looks suitable but I'm not sure.
  6. First of all many thanks for the help Now, regarding the correlation between the output of lsof and the contents of /proc/`pidof pbxctrl`/fd: No they don't match and the difference is clearly on the IP sockets (see [3]).The reason for the difference is that lsof gives 7 lines of output for each socket. So if I count only unique socket ids then both outputs match: $ lsof -nP | grep 'pbxctrl' | grep 'IPv' | awk -F' ' '{print $7 }' | sort -n | uniq | wc -l 116 $ ls -l /proc/`pidof pbxctrl`/fd | grep 'socket' | wc -l 116 A quick check[1] on my saved lsof outputs during the past few weeks reveals that this factor (x7) is constant. And another check [2] reveals that: The unique socket ids at the output of lsof (that match the number of sockets in /proc/.../fd) are increasing with the pattern mentioned in my previous post (i.e. ~4% increase during working days and no increase during weekends and holidays). By the way: when you exclude sockets the number of "files" left is more-or-less constant during these weeks that I'm testing (97 open "files" with a rare peak to at most 137 now and then). Here's a plot of unique socket ids per hour for two weeks. Weekends are colored green (it's of-course the same as above but scaled down by a factor of 7 but I like pictures :-) ______________________________ [1] ls lsof.2019-0*|sort | while read FILE; do cat $FILE | grep 'IPv' | awk -F' ' '{print $7 }' | grep -v '0t0' | sort -n | uniq -c | awk -F' ' '{print $1 }' | uniq -c | sort -nr | head -1; done [2] ls lsof.2019-0*|sort | while read FILE; do echo -n "$FILE "; cat $FILE | grep 'IPv' | awk -F' ' '{print $7 }' | grep -v '0t0' | sort -n | uniq | wc -l; done [3] $ ls -l /proc/`pidof pbxctrl`/fd | grep 'socket'|wc -l 125 $ lsof -nP | grep 'pbxctrl' | grep 'IPv'|wc -l 992
  7. I'm logging the output of lsof for the pbxctrl process every hour for about a month. It is clear that the number of lines of output grows by about 20% per week. I've just restarted pbxctrl as a precaution. I'm attaching a graph. The y-axis is the number of lines of the output of the command: lsof | grep pbxctrl . Weekends and holidays are painted in green color. Most of my customers are businesses so I have many calls with a peak at about midday during working days and very few calls during weekends and holidays. I confess I haven't dived into the details of the output of lsof. However I'm almost sure that no matter the exact meaning it doesn't seem right for the number of these lines to grow by ~4% every working day. Most likely a bug in pbxctrl and less likely one in lsof. I need your help for further debugging though. I have kept all the log files and the full output of lsof for this period. Anything else I can do?
  8. Hmmm good thinking. I'll have to read a bit more on lsof and linux internals. Will let you know
  9. They certainly belong to the same process: pbxctrl with PID 1486. But that's to be expected since I'm looking specifically for pbxctrl. Not sure what you're asking here so I'll provide anything I can think of: "man lsof" reads: "TID is the task (thread) IDentification number". In the example output above the 3rd column is the TID column (empty for the first line and 1530 to 1536 for the next 7 lines). B.T.W. I see the same pattern for almost all other ports: each port appears 8 times, once for the main process and another 7 times for threads. I've restarted pbxctrl and now I'm running lsof -nP | grep pbxctrl every hour and logging the full output on a series of timestamped files. Just in case it helps.
  10. We have a few hundred extensions in small companies. Nothing unusual I would guess (some inter-domain, plenty external calls and a conference call from time to time). Surely no multicast paging. Regarding attacks, I've run for a few minutes ngrep (a packet sniffer) looking for SIP replies that are not "SIP 200 OK" and I see nothing unusual. Regarding IPv6 ports in lsof's output they account for1352 out of 3300 lines. But I should note that they contain only 169 unique port numbers. E.g.: lsof -n| grep ^pbxctrl | grep -i ipv6 |grep 49460 pbxctrl 1486 root 456u IPv6 18445566 0t0 UDP *:49460 pbxctrl 1486 1530 root 456u IPv6 18445566 0t0 UDP *:49460 pbxctrl 1486 1531 root 456u IPv6 18445566 0t0 UDP *:49460 pbxctrl 1486 1532 root 456u IPv6 18445566 0t0 UDP *:49460 pbxctrl 1486 1533 root 456u IPv6 18445566 0t0 UDP *:49460 pbxctrl 1486 1534 root 456u IPv6 18445566 0t0 UDP *:49460 pbxctrl 1486 1535 root 456u IPv6 18445566 0t0 UDP *:49460 pbxctrl 1486 1536 root 456u IPv6 18445566 0t0 UDP *:49460 Should I send you log files or anything else?
  11. Unfortunately within a week 'lsof -n | grep pbxctrl' did give more than 4000 lines of output. Usage of the system is stable so I don't like that this number keeps climbing up week by week and I'm afraid of the system crashing again. Looking at today's graphs I see these PEAKS: ~770 Registrations+Subscriptions, 52 call legs 112 http(s) 112. ~ 10 for TFTP & LDAP together In case it helps: Examining the output of ngrep on port 5060 I see that I'm sending packets to 310 IP:port couples. The output of lsof | grep pbxctrl is along the lines of this: pbxctrl 1486 1536 root 442u IPv4 18445564 0t0 UDP *:49460 pbxctrl 1486 1536 root 443u IPv4 18437010 0t0 TCP 1.2.3.4:https->9.10.11.12:53054 (ESTABLISHED) pbxctrl 1486 1536 root 444u IPv4 18445565 0t0 UDP *:49461 pbxctrl 1486 1536 root 452u IPv6 18472707 0t0 UDP *:49869 pbxctrl 1486 1536 root 453u IPv4 18506734 0t0 UDP *:62612 pbxctrl 1486 1536 root 456u IPv6 18445566 0t0 UDP *:49460 pbxctrl 1486 1536 root 457u IPv6 18445567 0t0 UDP *:49461 pbxctrl 1486 1536 root 458u IPv4 18472815 0t0 TCP 1.2.3.4:https->5.6.7.8:34917 (ESTABLISHED) pbxctrl 1486 1536 root 461u IPv4 18506735 0t0 UDP *:62613 pbxctrl 1486 1536 root 472u IPv4 18505204 0t0 UDP *:52692 pbxctrl 1486 1536 root 473u IPv4 18505205 0t0 UDP *:52693 pbxctrl 1486 1536 root 478u IPv4 18505208 0t0 UDP *:52192 pbxctrl 1486 1536 root 479u IPv4 18505209 0t0 UDP *:52193 pbxctrl 1486 1536 root 482u IPv4 18505038 0t0 UDP *:58870 pbxctrl 1486 1536 root 483u IPv4 18505039 0t0 UDP *:58871 pbxctrl 1486 1536 root 484u IPv4 18505042 0t0 UDP *:61862 pbxctrl 1486 1536 root 485u IPv4 18505043 0t0 UDP *:61863 What's your opinion? Would you like more data?
  12. I've upgraded to 63.0.1 about 12 days ago and the output of lsof -n | grep pbxctrl has grown from about ~2000 lines to about ~3300 lines (IPv4 and IPv6 connections). I've set a new warning level at 4000 lines and will let you know if/when I'll hit it
  13. Thanks that was it! I had to temporarily firewall one IP with a lot of TCP connections in order to let me connect to the webUI.
×
×
  • Create New...