Project

General

Profile

Actions

Bug #2370

closed

syslog.conf requires IPv6 literal

Added by Cyrill B about 12 years ago. Updated almost 12 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
04/11/2012
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:

Description

If I remember correctly syslogd uses literal IPv6 addresses (e.g. in square brackets) in its configuration file (also when no port is given).

For consistency reasons it might be appropriate to accept either literal IPv6 with ports or non-literal without ports. Those without port would need to be transformed internally (e.g. in /etc/inc/system.inc)


Files

syslogd.zip (21.9 KB) syslogd.zip syslogd binary (i386) Cyrill B, 04/14/2012 02:17 PM
Actions #1

Updated by Jim Pingle about 12 years ago

Unfortunately it appears that syslogd can only send to IPv6 when using a hostname that resolves to a quad A. I have tried with and without brackets and syslogd simply never sends the frames out when specifying an IPv6 address.

It's still an open issue on FreeBSD, so nothing we can really do here.
http://www.freebsd.org/cgi/query-pr.cgi?pr=150530&cat=misc

I'll commit a fix to place the address in brackets before writing the config, so that whenever that does get patched, it will work.

Actions #2

Updated by Jim Pingle about 12 years ago

IPv6 IP fixed up in bd29bb7baa068cb92828461207ea35f74b6c2383

Looking at the patch in the FreeBSD PR to see if we can use it somehow...

Actions #3

Updated by Jim Pingle about 12 years ago

Included the patch from the PR in snapshots to test it, and it doesn't seem to work. Like the other guy who posted on the PR, I receive an error:

syslogd: servname not supported for ai_socktype: Bad file descriptor

Actions #4

Updated by Cyrill B about 12 years ago

No error here, it's working for me. I couldn't test it with an actual IPv6 capable syslog server but I captured the packets on the router itself. I'm using the nanobsd snapshot dated "Tue Apr 10 21:44:04 EDT 2012" where I manually applied the configuration patch and replaced the syslogd binary with one I just built using the usual pfsense.ova way.

What platform are you using?

Actions #5

Updated by Jim Pingle about 12 years ago

Using a full install on the latest snapshot.

I thought perhaps the formatting was throwing it off, so I tried it with a short IPv6 IP, an uncompressed IP, and then one fully expanded, and then each variation using the literal syntax with a port number. All generated the same error:

syslogd: servname not supported for ai_socktype: Bad file descriptor

And with tcpdump I get no data leaving on the syslog port.

It would be interesting to see if you still see success with the latest snapshot instead of with things manually applied.

Actions #6

Updated by Cyrill B about 12 years ago

No success with the current snapshot (Fri Apr 13 22:04:24 EDT 2012 / i386). Just tested it and it seems the syslogd binary does not have the patch applied. I attached the working binary that I built which is around 10% bigger.

Actions #7

Updated by Jim Pingle about 12 years ago

Yours is larger because the binary is not stripped. I inspected the source and found that the patch was applied even on mine that does not work.

So there must be something else going on that's making it work for you and not me. Out of curiosity, do you mind sharing what exact IPv6 IP you used as the target?

Actions #8

Updated by Cyrill B about 12 years ago

It's not the configured IPv6 IP as one binary is working and the other one is not. But I noticed that I may have used the "wrong" binary, e.g. not the one which is shipped in the image.

I'm not yet too familiar how pfSense is built but the working binary that I manually copied was located in "/usr/obj.pfSense/i386/usr/pfSensesrc/src/usr.sbin/syslogd". A comparison showed that its source code (/usr/pfSensesrc/src/usr.sbin/syslogd) is newer than the one in pfPorts (syslogd-r222550).

Does that information help?

Actions #9

Updated by Jim Pingle about 12 years ago

That may be the difference, as I don't remember it being pfPorts before. Somewhere along the way we may have switched to that one, and it doesn't include the right patches yet. I'll poke at that when I get some time (probably not today)

Actions #10

Updated by Jim Pingle about 12 years ago

I added a patch to the pfPort and rebuilt it on the snapshot servers, we'll see how it goes.

Actions #11

Updated by Jim Pingle about 12 years ago

Copied one of the resulting binaries to a VM and that does seem to have done the trick, I'm getting messages to my server (now to sort out reverse DNS there so it actually goes to the right file...)

Actions #12

Updated by Jim Pingle about 12 years ago

The binary is correct now but for whatever reason at bootup it does not send logs over IPv6. If you save the syslog settings or restart syslogd, it works. If I enable syslogd's debug mode (-d) in system.inc to see why, it sends them, but leaving debug enabled isn't viable long-term. No errors are produced that I can see.

IPv4 remote logging works at bootup, so who knows what the real difference is there.

Actions #13

Updated by Jim Pingle about 12 years ago

I added a cheap fix, if we have an ipv6 forwarding IP for syslog, it restarts syslog at the end of the boot cycle, which makes forwarding work.

Actions #14

Updated by Jim Pingle about 12 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100
Actions #15

Updated by Jim Pingle almost 12 years ago

  • Status changed from Feedback to Resolved

This has been working fine for me since that last commit. Logs are coming across IPv6 and are targeted at an IPv6 IP address, not a hostname.

Actions

Also available in: Atom PDF