-
-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Syslog via TCP not synonymous to syslog via UDP #51
Comments
For the trim() problem: My suggestion would be to introduce a flag which can be invoked for the input modules, allowing you to sunset this trim code for those who already built code around its existence, or disable it to make new code work better. |
Hi Paul @systemcrash and thank you so much for the detailed report - this most definitely sounds odd and wrong - Let me try reproduce this and provide some feedback. |
Another thing I've noticed: if paStash has a receiving module active for TCP, shutting down the docker image, or CTRL+C from the console takes a lot longer. I think it's trying to cleanly close the TCP connection, but in any case it seems like the OS is waiting on the TCP, and not the TCP listening to the OS... |
paStash is standing on the shoulders of giants here, it does not handle or implement its own TCP stack or workers so I'm not sure this is induced or inherited ;) Jokes aside, I'll see if there are possible modules replacement to improve those aspects once we figure out what's really happening. |
I turned on simple (debug) logging to show what my AppSecret ingests from the syslog_tcp module. You can see how it even preserves the indented space and doesn't even trim() it. Right from the start, it (multiline and regexp) seems to have difficulty coping. Here is the corresponding recipe:
This is logged for what comes in via TCP - note Function ingested data is all one block, not separate blocks:
Comments: there are at least 3 separate 'start lines' for multi-line, but one large block is ingested. |
For comparison, this is what happens via UDP (when you look at the differences, you'll see how TCP is misbehaving) recipe
log
|
So irrespective of what regexp I have in the recipe, e.g.
or
The TCP syslog received lines are passed verbatim, and are not reduced:
Like they are via UDP:
|
So as stated in the original submission: it's like multiline is completely bypassed when using TCP for reception. UDP, fine. All things being equal, TCP is just... weird. |
Any progress on your investigations? |
If you can make any progress on this, this would promise integration of a few SBCs and PBXes. |
@systemcrash apologies for the long break - I'll get to this soon. Are you using the latest |
Pulled in the latest. Using 8b89463 Edit: No difference in behaviour |
the global version uses |
shrug like I said, I'm using 8b89463 (from this repo) I run |
Great. Mind using the branch has nothing to do with how it should be installed to work. Keep in mind, the modular version expects globally installed @pastash/plugins in order to run. Since the point is shrinking down, you might want to build your own Docker container with only the packages you want/need installed.
|
Got it - thanks. Is a pastash.conf possible in a docker-compose scenario? If you have any test branches you want me to try, post it here. This (debug) installation will be exclusively using github/docker-compose to build. |
When I try to use TCP (not TLS yet) to deliver syslog to a paStash node, it just barfs all over the place, and cannot re-assemble things very well at all.
When I switch over to UDP - everything plays nicely, regexp also. So all things being equal, TCP doesn't play nicely at the receiving end. I enable stdout and just see a mish-mash of bad re-assembly.
It boils down to the multi-line filter.
If we want to try to blame my device for doing something wrong on TCP, we would be pointing the finger at Rsyslogd, which the device uses. So we're up against a few decades of battle-tested code, which, as I see the packets and data upon closer inspection, look fully compliant.
I'm also a bit surprised to see things like trim() this and this in both UDP and TCP (which, to me, is either a bug or bad assumptions, but this is an aside). This now needs to be worked around in every 'app'. Especially since syslog rows can contain indented space:
Here is a slice of where I follow a UDP stream in Wireshark containing the above:
Here's my recipe. Ignore the commented out variants - I've been trying different things to no avail.
Tell me what you need and I'll do my best to provide it.
I'm basically at commit 4917bd7
What gives?
The text was updated successfully, but these errors were encountered: