thin client is the second choice here, but all advice is appreciated

to youre question adam, i need the whole network traffic, not only the pbx
traffic. I think its a hardware issue, but the vendor will try to blame the
vlan configuration on the switch or some such madness

On Mon, Nov 13, 2017 at 12:09 PM, Josh Reynolds <[email protected]>
wrote:

> Used thin clients running Linux can work well for this. You can catch
> quad-core boxes on eBay with power supplies for $25-$50 with a little
> luck.
>
> Just make sure you can replace the internal storage with whatever meets
> your needs.
>
> Note: NICs on this are sometimes great, and sometimes shit. YMMV, and
> could influence the quality of your packet captures.
>
> On Nov 13, 2017 12:06 PM, "Adam Moffett" <[email protected]> wrote:
>
>> The Pi will probably work fine if the traffic is light.
>>
>> Dumb question though for Steve:  Is the VoIP system the only machine in
>> the room?  Why not mirror the port to a secondary ethernet port on one of
>> the other servers nearby?
>>
>> Eric may seem like kind of a killjoy today, but he's right that you'll
>> have more uses for a mini-itx box.
>> http://www.mini-box.com
>> For a couple hundred bucks you can get an 8" square computer that runs on
>> 12V DC.  You can slap in internal SATA disks or external USB disks to your
>> hearts' content and it will have several times the balls of a Rasberry Pi.
>>
>> ------ Original Message ------
>> From: "Eric Kuhnke" <[email protected]>
>> To: "[email protected]" <[email protected]>
>> Sent: 11/13/2017 12:56:26 PM
>> Subject: Re: [AFMUG] rasberry pi packetsniffer
>>
>> IMHO if you want a 100/1000 Mbps Ethernet port that you can actually rely
>> on for production use you don't hang it off a USB2 bus...  First,
>> latency/jitter issues with timestamping and logging (as compared to
>> something on a PCI-Express x8 2.0/3.0 bus), which can be crucial when
>> diagnosing voip/SIP issues. Also reliability and speed. Others have
>> commented that it's a quick way to kill the "disk" on a microSDHC card by
>> writing a lot of logging/debug data on a raspberry pi. You could connect a
>> cheap real SSD or 2.5" HDD in a USB3 external enclosure and use it for
>> logs, or send logs offsite (NFS, sshfs, etc) to another system, but at that
>> point you're better off with a "real" server.
>>
>>
>> On Mon, Nov 13, 2017 at 9:53 AM, Steve Jones <[email protected]>
>> wrote:
>>
>>> as a mirrored port capture though that shouldnt be an issue
>>>
>>> On Mon, Nov 13, 2017 at 11:42 AM, Eric Kuhnke <[email protected]>
>>> wrote:
>>>
>>>> People keep using raspberry Pi for things they're not suited for. The
>>>> 100 Mbps Ethernet interface is attached to a USB2 bus. And it only has one
>>>> ethernet port. Yes I suppose you could add a second interface by another
>>>> USB dongle. If you really want to run wireshark and other stuff you're much
>>>> better off with a really 1RU small x86-64 system that has two real Intel
>>>> 1000BaseT NICs on board, and a couple of PCI-Express slots. Or a really
>>>> small desktop thing if it's a non rack environment, like a mini-itx
>>>> motherboard in a cube shaped case with an Intel-chipset 4x1000BaseT port
>>>> card.
>>>>
>>>>
>>>> On Mon, Nov 13, 2017 at 9:28 AM, Steve Jones <[email protected]
>>>> > wrote:
>>>>
>>>>> I have a voip  pbx system issue im going to have to drop a long term
>>>>> packet sniffer onto the network to catch an issue that only happens like
>>>>> once in a month. So thats going to be alot of traffic (we have to capture
>>>>> everything to see if the issue has to do with other network traffic, so I
>>>>> cant even filter it out.
>>>>> I was thinking about making a pi a sniffer and just hang a  usb drive
>>>>> off of it for the archive.
>>>>>
>>>>> I dont see running a sniffer would be all that great a resource drain.
>>>>>
>>>>> Any reason this would be a bad idea, i could see it being a good tool
>>>>> to keep in our toolset. I just envision a little binder full of SD cards
>>>>> with purpose builds and a handful of pis for a handy toolbox
>>>>>
>>>>
>>>>
>>>
>>

Reply via email to