Bug 11282 - WebIF: Firewall log shows protocol "47" without description
Summary: WebIF: Firewall log shows protocol "47" without description
Status: CLOSED FIXED
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: all All
: Will only affect a few users Aesthetic Issue
Assignee: Stefan Schantl
QA Contact:
URL:
Keywords:
Depends on:
Blocks: FWBUGS
  Show dependency tree / graph
 
Reported: 2017-01-15 12:14 UTC by Timmothy Wilson
Modified: 2021-10-05 11:10 UTC (History)
4 users (show)

See Also:

Attachments
screenshot of the firewall log showing protocol type "47" (19.08 KB, image/png)
2017-01-15 12:14 UTC, Timmothy Wilson 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Timmothy Wilson 2017-01-15 12:14:05 UTC 
Created attachment 493 [details]
screenshot of the firewall log showing protocol type "47"

In the WebIF (Logs|Firewall Log), the page shows the protocol type, too.

However, in case of a protocol different than TCP and UDP, it only lists the protocol number (see screenshot, protocol #47 -> GRE). The log file shows that this information is parsed corretly:

Jan 15 11:55:44 firewall kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=1.34.187.[REDACTED] DST=188.[REDACTED] LEN=52 TOS=0x00 PREC=0x00 TTL=41 ID=55353 DF PROTO=47 MARK=0xd2

While this is not necessarily an error, it might be useful to display the name of the protocol, too, so the user will not have to look it up. A list of IP protocol numbers is available here: https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers
Comment 1 Alexander Marx 2017-01-21 16:13:15 UTC 
i will have a look at it.
Comment 2 Peter Müller 2017-08-30 16:50:21 UTC 
Something similar happens here with protocol number 4 (IP-in-IP encapsulation):

16:28:19 IN=ppp0 OUT= MAC=[REDACTED] SRC=87.123.XXX.XXX DST=87.173.XXX.XXX LEN=106 TOS=0x00 PREC=0x00 TTL=59 ID=0 DF PROTO=4 MARK=0xcb
Comment 3 Peter Müller 2020-04-10 11:10:02 UTC 
This is more or less a firewall bug, but not a critical one.
Comment 4 Stefan Schantl 2021-07-13 17:01:24 UTC 
I've send a patch to the development mailing list to fix this issue.

https://patchwork.ipfire.org/project/ipfire/patch/20210713165851.3261-1-stefan.schantl@ipfire.org/

Please test and provide some feedback.

Thanks in advance,

-Stefan