Barnyard2 and MariaDB
-
I keep telling you what to do and you keep ignoring my advice... . Build it within the pfSense builder environment using the
build.sh
script and the various arguments I gave you in the previous post farther up above.Yes, DEVEL in pfSense is based on FreeBSD 12.0 which has a slightly different version of various libraries. pfSense-2.4.4_3 is based on FreeBSD 11.2.
You can probably switch to the RELENG_2_4_4 branch within the pfSense builder environment and build Barnyard2 from there. That is the current RELEASE branch. The initial build of any package is going to take a while because all of the dependencies have to built first. Subsequent builds of just the Barnyard2 module will be much faster.
-
I know I looks like an idiot. When in Rome, do as the Romans do. I will definitely follow your advice later.
Before you give me your detailed instruction for pfsense, I can't find any documents from pfsense so I have to figure this out by myself. It is kind of painful.
As a lazy developer, I look for an easy and quick way to build thing for pfSense.
Because I'm more familiar with
make
command andautoconf
way. So I tried this approach first and then hit the wall when do cross compiling.Later I tried 2nd approach: use poudriere jail. I have to read poudriere user guide. I figured out it is slow ARM emulation rather than cross compile. The pfsense build.sh use poudriere jail as well. So I'm very close to what Romans do now.
I bet most Linux developer who wants to contribute to pfSense will go through the same path like me. I wish we could publish this in our forum so that people can avoid wasting time on build problem and focus on contributing.
-
I create a patch and build the port successfully targeting to ARM platform by using poudriere arm jail.
Barnyard passed the SQL syntax road block. But the daemon crashed after 2+ hours with no log message to indicate why.
I checked the tables in MariaDB. The patched Barnyard2 did populate all meta data table like detail, encoding, reference, reference_system and sensor. However, the alert logging information like event and data table are empty even there were alerts popping up during that time.
I haven't deep dived into how SNORT notifies Barnyard2 to log alert. That may be a rabbit hole to patch it further. I will call it stop.
In any case, if anyone are interested in fixing it, I shared my stuffs below:
-
Fix checksum for texinfo port and SQL syntax for Barnyard2 port in my Github repo. The commit is based on pfSense v2.4.4-p3 release.
-
My notes on how to jump start FreeBSD port development, poudriere port build and port patching.
Thanks @bmeeks for sharing your wisdom!
Aug 7 15:50:26 pfsense.localdomain barnyard2[49355]: --== Initializing Barnyard2 ==-- Aug 7 15:50:26 pfsense.localdomain barnyard2[49355]: Initializing Output Plugins! Aug 7 15:50:26 pfsense.localdomain barnyard2[49355]: Running in Continuous mode Aug 7 15:50:26 pfsense.localdomain barnyard2[49355]: Aug 7 15:50:26 pfsense.localdomain barnyard2[49355]: Initializing Input Plugins! Aug 7 15:50:26 pfsense.localdomain barnyard2[49355]: Parsing config file "/usr/local/etc/snort/snort_55529_mvneta2/barnyard2.conf" Aug 7 15:50:26 pfsense.localdomain barnyard2[49355]: +[ Signature Suppress list ]+ ---------------------------- Aug 7 15:50:26 pfsense.localdomain barnyard2[49355]: Found pid path directive (/var/run) Aug 7 15:50:26 pfsense.localdomain barnyard2[49355]: +[No entry in Signature Suppress List]+ Aug 7 15:50:26 pfsense.localdomain barnyard2[49355]: ---------------------------- +[ Signature Suppress list ]+ Aug 7 15:50:28 pfsense.localdomain barnyard2[49355]: Barnyard2 spooler: Event cache size set to [8192] Aug 7 15:50:28 pfsense.localdomain barnyard2[49355]: Log directory = /var/log/snort/snort_mvneta255529 Aug 7 15:50:28 pfsense.localdomain barnyard2[49355]: INFO database: Defaulting Reconnect/Transaction Error limit to 10 Aug 7 15:50:28 pfsense.localdomain barnyard2[49355]: INFO database: Defaulting Reconnect sleep time to 5 second Aug 7 15:50:28 pfsense.localdomain barnyard2[49355]: Initializing daemon mode Aug 7 15:50:28 pfsense.localdomain barnyard2[50346]: Daemon initialized, signaled parent pid: 49355 Aug 7 15:50:28 pfsense.localdomain barnyard2[49355]: Daemon parent exiting Aug 7 15:50:28 pfsense.localdomain barnyard2[50346]: PID path stat checked out ok, PID path set to /var/run Aug 7 15:50:28 pfsense.localdomain barnyard2[50346]: Writing PID "50346" to file "/var/run/barnyard2_mvneta255529.pid" Aug 7 15:52:11 pfsense.localdomain barnyard2[50346]: database: configured to use mysql Aug 7 15:52:11 pfsense.localdomain barnyard2[50346]: database: compiled support for (mysql) Aug 7 15:52:11 pfsense.localdomain barnyard2[50346]: database: schema version = 107 Aug 7 15:52:11 pfsense.localdomain barnyard2[50346]: database: host = 192.168.2.30 Aug 7 15:52:11 pfsense.localdomain barnyard2[50346]: database: user = snort Aug 7 15:52:11 pfsense.localdomain barnyard2[50346]: database: database name = snort_db_wan Aug 7 15:52:11 pfsense.localdomain barnyard2[50346]: database: sensor name = pfSense.localdomain:mvneta2 Aug 7 15:52:11 pfsense.localdomain barnyard2[50346]: database: sensor cid = 2 Aug 7 15:52:11 pfsense.localdomain barnyard2[50346]: database: sensor id = 1 Aug 7 15:52:11 pfsense.localdomain barnyard2[50346]: database: data encoding = hex Aug 7 15:52:11 pfsense.localdomain barnyard2[50346]: database: detail level = full Aug 7 15:52:11 pfsense.localdomain barnyard2[50346]: database: ignore_bpf = no Aug 7 15:52:11 pfsense.localdomain barnyard2[50346]: database: using the "log" facility Aug 7 15:52:11 pfsense.localdomain barnyard2[50346]: --== Initialization Complete ==-- Aug 7 15:52:11 pfsense.localdomain barnyard2[50346]: Aug 7 15:52:11 pfsense.localdomain barnyard2[50346]: Barnyard2 initialization completed successfully (pid=50346) Aug 7 15:52:11 pfsense.localdomain barnyard2[50346]: WARNING: Ignoring corrupt/truncated waldofile '/var/log/snort/snort_mvneta255529/barnyard2/55529_mvneta2.waldo' Aug 7 15:52:11 pfsense.localdomain barnyard2[50346]: Opened spool file '/var/log/snort/snort_mvneta255529/snort_55529_mvneta2.u2.1565207426'
-
-
Snort simply writes records to the unified2 log file for each event. Barnyard2 constantly monitors that file to see when something new comes in and then writes the alert data to the configured DB. There are some configuration options within the Barnyard2 tab of Snort to control exactly what gets written to where.
There is a command line utility included with Snort that can dump the contents of the U2 log. The utility path and filename is
/usr/local/bin/u2spewfoo
. You could use that to see what events, if any, Snort recorded to the unified2 log file that Barnyard2 is monitoring.When the Barnyard2 daemon crashed, did you look to see if anything related was in the pfSense system log? Since you are running on ARM hardware, my first suspicion would be perhaps a Signal 10 Bus Error message in the system log. If you see that, it means the Barnyard2 binary attempted to access unaligned data in memory.
-
@bmeeks said in Barnyard2 and MariaDB:
u2spewfoo
I used rsyslog to receive stream logging from pfsense. I found the error in kernel.log
233 Aug 7 18:26:42 pfsense.localdomain kernel: pid 50346 (barnyard2), uid 0: exited on signal 10 (core dumped)
According to FreeBSD signal error, signal 10 is bus error just as your described.
I can't find the core dump anywhere. How can I enable core dump or access the dump file?
-
@rickyzhang said in Barnyard2 and MariaDB:
@bmeeks said in Barnyard2 and MariaDB:
u2spewfoo
I used rsyslog to receive stream logging from pfsense. I found the error in kernel.log
233 Aug 7 18:26:42 pfsense.localdomain kernel: pid 50346 (barnyard2), uid 0: exited on signal 10 (core dumped)
According to FreeBSD signal error, signal 10 is bus error just as your described.
I can't find the core dump anywhere. How can I enable core dump or access the dump file?
Right off hand I don't recall where pfSense will store the dump.
I have/had this same issue with both Snort and Suricata on the Netgate ARM appliances. It is a long story about why, but I will try and condense it a bit.
Intel CPUs have basically forever performed something called an "automatic fix-up" when program code attempted to access unaligned data in memory. You can do some Google research on the term "unaligned access", but it basically has to do with the actual hardwired logic within the CPU design that governs how data is dumped from memory addresses. As a programmer, you should always pay careful attention to insure data is stored and retrieved on word-aligned boundaries. However, the details of this get sketchy because of differences in hardware design among various CPUs. It gets even more sketchy when you start talking about higher level languages such as C and C++. This is because the compilers for these languages hide a lot things from the programmer when converting say a C source file into binary executable code for a given architecture.
So back to what Intel's design choice has produced in today's software. Intel decided long ago to have the internal microcode inside their CPUs perform an automatic fix-up if a programmer attempted to access a memory location that is not word-aligned (that is, the address of the desired data was not evenly divisible by 2). The hardware of the CPU would actually perform a word-aligned access and then throw away the unneeded portion of the data. For example, you are trying to read a single byte of data but you can only read and write to memory in 16-bit, or word-aligned, chunks. The hardware would read a 16-bit data value from memory but then compute which half (upper or lower 8 bits) to ignore. This is a bit oversimplified, but you can get the basic point. Thus programmers got lazy and never really worried about unaligned access in their code because even if they performed such a "bad" move, the CPU would fix it for them under the covers. I would even venture so far as to say there is a large number of C programmers out there who have no idea what unaligned access even is!
Non-Intel CPUs will frequently choose not to perform an auto-fixup operation. Instead, they throw a hardware exception interrupt and terminate the offending process. The ARM CPU used in the SG-3100 appliance is such a device. It has some instructions for loading registers with data from memory that will cause auto-fixups of unaligned acccess; but it also has other instructions that will not. Now is where the vagaries of compilers come into play. The llvm compiler used by default in FreeBSD will, when optimization is enabled, choose to use the ever so slightly faster CPU instructions for loading data from memory that do NOT perform an auto-fixup. This can lead to a Signal 10 crash using C code that works perfectly fine on Intel hardware (because Intel hardware will always perform an auto-fixup). So now consider you wrote Snort or Suricata or Barnyard2 or whatever piece of software, and that software runs just fine as is on all Intel hardware out there. But it does once in a while choke on say someone's ARM hardware. Is it worth your time and effort to scour thousands of lines of C source code to find the places where unaligned access might happen? By the way, this usually happens in code sections where the C programmer is casting one variable type to another - and that is usually a lot of places! You can see where this is going ... the folks who maintain the upstream binary portions of these packages don't want to put in the necessary time and effort to ferret out all the little casting problems that cause the Signal 10 issue because, frankly, there is no problem on any of the Intel-based hardware out there, and Intel has by far the largest market share anyway.
So long story to say don't expect an immediate fix for the Signal 10 problem. This is just me talking, but the folks out there who are making these little hardware appliances should really think long and hard about the unintentional consequences of choosing non-Intel hardware when you also want to run a lot of commonly available compiled software on the device (meaning popular C source code programs). It is very likely that such software (most commonly C source code based) has hidden unaligned access time bombs hiding in it. In the case here of pfSense and the ARM appliances, I know of at least four and maybe five packages that crash for this very reason on the ARM-based appliances (Snort, Suricata, clamav and now Barnyard2). I think there was maybe one other one that would be five. I've partially worked around this in Snort and Suricata by telling the llvm compiler to switch off all optimizations when creating the binary executable for ARM platforms. This results in a slower binary on ARM hardware, but without that workaround Snort would not even start up on the SG-3100. So for your Barnyard2 Signal 10 crash, try turning off optimizations in llvm. You can do that either by enabling the DEBUG build of the package or by changing some compile time arguments to the compiler. Look at the patch files for Snort on ARM to get a hint on what to do.
-
This is very good pieces of educational reading. I read some alignment code in C struct in Linux kernel. But I never knew why until now. Thanks!
As you said, this memory access alignment problem can be mitigated by a compiler (Perhaps, it is not ideal to disable optimization). I ported some C/C++ file from Intel to iOS which runs on ARM. But I haven't heard of the alignment issue. The build tool like XCode will flag this during development. See doc here.
Can all memory misalignment access be caught at compile time? If yes, compiler can generate correct machine code or IDE can flag it.
In any case, I will give a try and see how you address this in Suricata or Snort port.
-
I added a CFLAGS
-Wpadded
which flags memory misalignment in struct. I got 543 red flags from the build log:grep "\[\-Wpadded\]" barnyard2-1.13_1.log | wc -l 543
I will give a try on adding a CFLAGS like
-fpack-struct
to see if it can automatically pad them. -
@rickyzhang said in Barnyard2 and MariaDB:
I added a CFLAGS
-Wpadded
which flags memory misalignment in struct. I got 543 red flags from the build log:grep "\[\-Wpadded\]" barnyard2-1.13_1.log | wc -l 543
I will give a try on adding a CFLAGS like
-fpack-struct
to see if it can automatically pad them.That may cause more bugs. There are many places within the Snort code where certain functions make assumptions about the alignment of data in structures. For instance, code may assume bytes are immediately adjacent to each other in a given structure. Having the compiler add padding behind the scenes can create more bugs. Would not be surprised to see the same issue exist in Barnyard2.
This is why fixing these issues is a major pain. If it was really as simple as adding a compiler directive the upstream maintainers would have already done that. It's not that simple in practice.
-
You are correct. With the CFLAGS
-fpack-struct
enabled, Barnyard2 crashed immediately with signal 11 segmentation fault.I replaced it with
-mno-unaligned-access
. It crashed with signal 10 again. It seem to be a clang bug because the no unaligned access flag doesn't work.Any suggestion? I can't find the fix commit in snort's Makefile under your name. How can you address it?
-
@rickyzhang said in Barnyard2 and MariaDB:
This is very good pieces of educational reading. I read some alignment code in C struct in Linux kernel. But I never knew why until now. Thanks!
As you said, this memory access alignment problem can be mitigated by a compiler (Perhaps, it is not ideal to disable optimization).
No, disabling optimization is not ideal, but the choice was that or no Snort on the SG-3100 (or any other ARM-based appliance running pfSense). So we (me and the pfSense developer team) chose the "at least make it work" option.
The real fix for this is to never have the error within the source code to start with. This unaligned access problem almost always happens when "casting" a pointer variable from one type to another. But this is frequently required in C programming in order to stop the compiler from complaining about mismatched or wrong type function arguments. Going through C source code that you didn't write and trying to figure out where casting problems exist and then determine if fixing them will break something else or not is a tall order.
-
@rickyzhang said in Barnyard2 and MariaDB:
You are correct. With the CFLAGS
-fpack-struct
enabled, Barnyard2 crashed immediately with signal 11 segmentation fault.I replaced it with
-mno-unaligned-access
. It crashed with signal 10 again. It seem to be a clang bug because the no unaligned access flag doesn't work.Any suggestion? I can't find the fix commit in snort's Makefile under your name. How can you address it?
As you see, those flags are basically worthless because the compiler cannot reliably detect when unaligned access will occur - especially when the programmer is using nested casting. Also, on FreeBSD the actual compiler used is llvm. I actually disassembled the machine code and verified at least one place in Snort where the Signal 10 was happening. It is caused by the llvm compiler's choice of which of two register load instructions to use: LDR or LDM. LDR supports unaligned access while LDM does not. Same thing for STR and STM. Some details can be found in this post: https://medium.com/@iLevex/the-curious-case-of-unaligned-access-on-arm-5dd0ebe24965.
When optimizations are disabled, the llvm compiler will always use the LDR and STR instructions which do support unaligned access auto-fixup. With optimizations enabled, the compiler will choose to use the LDM and STM instructions instead. I saw this behavior during my Snort testing on the SG-3100 a couple of years ago.
The file we produced to take care of disabling optimizations when compiling for ARM is contained in the patch file
patch-pfSense-ARM317.diff
located in the files sub-directory of the Snort binary port. The patch adds additional code to theconfigure
script for the project which detects an ARM build and disables compiler optimizations. -
I admit I abused the CFLAGS
-fpack-struct
. I thought those struct flagged by clang struct padding warning comes from network protocol header for parsing the packet. It turns out they are not. Turning on packing made the matter worse.The CFLAGS
-mno-unaligned-access
supposed to do as the flag instructed by llvm/Clang (We are talking about the same thing). But it didn't do that intelligently.Note that SG-3100 is ARMv7 architecture. But we compile binary in ARMv6. In your quoted medium article, it stated that:
Beginning with ARMv7, however, unaligned access began to be supported. It now does the expected, i.e. breaking up the access into multiple smaller reads and builds up the value as a “traditional” x86 CPU would do it.
In FreeBSD 12.0, it starts to support ARMv7. We can actually build ARMv7 binary. Perhaps, that can mitigate your pain to patch.
I wonder when you said "nested casting" in your previous thread. Do you refer to int* pointer cast to char* pointer and you access memory through char* pointer cause memory misaligned access?
Thanks!
-
The documentation is sort of misleading. True, the ARMv7 chips can and will do the auto-fixup of unaligned access, but NOT when the LDM or STM opcodes are used. Those opcodes never support unaligned access. The llvm compiler will use those opcodes when optimizing the generated binary code because they are faster than their counterparts (LDR and STR) which DO support unaligned access. That's why we fixed it in the Snort and Suricata binaries the way we did. You have to get the compiler to not use those problematic opcodes. You can read more about that here: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html.
Your example of defining a pointer as an integer pointer (int*) and then casting it to a char* is one method of causing unaligned access to happen. This can also happen when you are casting struct pointers (struct*) as well. By "nesting" I am using my own definition of casting a cast, or in other words wrapping multiple casts inside nested parentheses. Not a great piece of coding, but you will find it frequently in C source code.
You need to be versed in the internal microcode sequencing of a CPU to fully understand all about unaligned access. Back in my olden days I went to a school on an industrial mainframe where we actually walked through and had to learn in class exactly how the flip-flops and logic gates were wired together to produce shift registers, adders and address decoders to produce the CPU of the computer. The circuit boards of that mainframe were actually constructed using perf-boards with wirewrap connections (no printed circuits at all). The CPU of this mainframe was actually about a dozen wirewrapped circuit boards all connected via a backplane. This taught me in great detail how modern CPUs actually work. In fact, I could troubleshoot that processor and fix it by replacing a faulty DTL (predecessor to TTL logic) chip in a socket. The hardware was certainly primitive by today's standards, but learning in exquisite detail how it all worked to shift bits around and move them to and from memory (which was a whopping 16K magnetic core, by the way) was very helpful. I've built on that training ever since then.
-
For sure, the more you know, the better off you will be.
But the cornerstone of computer science is abstraction and isolation. The less you depend on, the more portable your code is. The things like memory alignment access which relates to target platform code generation should be handled by compiler. So I'd expect in ARMv6 or later architecture when compiler is not sure if memory misalign access happen or not, it should use LDR/STR by default. But if the compiler knows memory access is aligned in sure case, it can use LDM/STM to do multiple registers load/store to speed things up. IMO, it is compiler's fault to do early optimization to duck this up. Premature optimization is the root of all evil.
I can NOT find any document from clang regarding to their CFLAGS
-mno-unaligned-access
but I did find the doc in GCC. clang wants to be compatible with GCC. I think this might be a bug in clang which does not fulfill the promise.BTW, the medium blog is misleading, according the ARM document. I don't like those leftist blogging from medium in general.
OK. I stop my ranting. Now I want to know how to enable core dump in FreeBSD. I double check parameters from sysctl:
[2.4.4-RELEASE][admin@pfSense.localdomain]/root/.ssh: sysctl -a | grep core kern.corefile: /root/%N.core kern.coredump_devctl: 0 kern.nodump_coredump: 0 kern.coredump: 1 kern.capmode_coredump: 0 kern.sugid_coredump: 0 kern.coredump_pack_vmmapinfo: 1 kern.coredump_pack_fileinfo: 1 debug.ncores: 5 debug.elf32_legacy_coredump: 0
The
kern.coredump
has been enabled and/root
folder is R/W by root. But I still doesn't see core dump file. I'm scratching my head. I want to know exactly where cause bus error. I'm sure it is not the struct padding. I read those code in Qt Creator IDE which use clang to flag struct padding. The padding happen only in the last struct member, which is harmless in parsing protocol header.Thanks!
-
I found this information relative to the
-mno-unaligned-access
option for clang/llvm:https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207096
Where the take-home message for me was in Comment 4:While options like -mno-unaligned-access will make the compiled code
avoid adding new misalignments as "optimizations" when the original
code does not misalign it will not repair code that directly generates
misalignments. (The alignment fixes to clang++ were all source code
fixes, not compiler option changes.)So that option does not appear to be there to "fix" source code. It's just there to make sure the compiler itself does not generate an unaligned access operation while optimizing.
-
I got that both code and compiler needs to work hand in hand to address memory misaligned access.
I found this article from Linux kernel development: https://www.kernel.org/doc/Documentation/unaligned-memory-access.txt
There two different types of memory misaligned access source in C code:
- struct member.
- pointer casting.
I have confident that Barnyard2 is free from the 1st source. I use Qt Creator to flag struct padding. Only two are flagged. They are flagged because of the last member need to be padded in the end. It seems harmless. I also eyeball 10 of random struct by grep
typedef struct
. They looks OK to me.So it might be pointer casting. I think I need the core dump to find them out and fix it. I have no better idea how to get the core dump in FreeBSD. It seem that it didn't work as expected in my SG-3100. Did pfsense customize kernel?
-
I found three possible ways to find the misaligned memory access from Barnyard2 source code:
-
Us the CFLAGS ‘’’-Wcast-align’’’ to flag potential ones. Hope there are few false positives.
-
Create a XCode project and let XCode’s clang does flagging. I have done several C porting to iOS. But I have never encountered the misaligned memory access. See: https://developer.apple.com/documentation/code_diagnostics/undefined_behavior_sanitizer/misaligned_pointer#overview
-
Run the binary and get the core dump like waiting a random bomb exploding.
-
-
@rickyzhang said in Barnyard2 and MariaDB:
I found three possible ways to find the misaligned memory access from Barnyard2 source code:
-
Us the CFLAGS ‘’’-Wcast-align’’’ to flag potential ones. Hope there are few false positives.
-
Create a XCode project and let XCode’s clang does flagging. I have done several C porting to iOS. But I have never encountered the misaligned memory access. See: https://developer.apple.com/documentation/code_diagnostics/undefined_behavior_sanitizer/misaligned_pointer#overview
-
Run the binary and get the core dump like waiting a random bomb exploding.
I suspect there are many places in the source code where it could happen. And the hard thing about unaligned access is that it can be sort of random as it can be triggered when certain data combinations happen in some piece of code. For example, consider an "if-then" test that is rarely "true", but when it is "true" the code executed within the "then" portion triggers an unaligned access. Makes finding all the bugs very hard since they don't reliably reproduce.
I have an email relationship with the Snort developer team, and I have corresponded with them about the Snort issues on ARM hardware. They acknowledged that the Snort 2.9.x source code has a number of potential bug spots with unaligned access. I suspect Barnyard2 may have many as well.
My suggestion is to turn off compiler optimizations so that clang/llvm will not use the problematic LDM/STM opcodes. Yes, the code might be a teeny tiny bit slower, but at least it will work. Then concentrate on fixing the other SQL bugs you started out working on.
-
-
First of all, SQL syntax bug has been patched. Bus error is a road block now.
There are 169 pointer pointer casting places got flagged by clang's
-Wcast-align
analysis. It is a lot as you expected.I take a close look into the first one
sf_iph.c:132:16: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'IP6Frag *' (aka 'struct _IP6Frag *') increases required alignment from 1 to 4
.The pointer casting looks normal/common use case when you cast a pointer to a generic buffer into a pointer to a struct .
I first tried
--pointer_alignment=1
compiler flag from ARM document. Ideally, it forces the compiler to treat all pointer casting is unaligned. But unfortunately clang doesn't support this compiler option. It failed to compile.Then, I tried to add
__packed
qualifier in pointer casting. It can compile but I'm not sure if it takes effect or not. It still flagged this casting is unaligned by-Wcast-align
.For now, I give it up. I will try your approach to disable optimization tomorrow. You added a architecture check in configure and an option(?) optimization=NO for ARM. It looks like specific to snort build rather than a generic fix for others. Should I use
-O0
flag or debug flag-g
?Thanks!
See
-Wcast-align
log:132 frag_hdr = (IP6Frag*)p->ip6_extensions[p->ip6_frag_index].data;
Ricky@gtx-freebsd ~ $ grep "\[\-Wcast\-align\]" /usr/local/poudriere/data/logs/bulk/pfsense-port-11-2-armv6-pfsense-v2-4-4-3/latest/logs/barnyard2-1.13_1.log sf_iph.c:132:16: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'IP6Frag *' (aka 'struct _IP6Frag *') increases required alignment from 1 to 4 [-Wcast-align] sf_iph.c:161:16: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'IP6Frag *' (aka 'struct _IP6Frag *') increases required alignment from 1 to 4 [-Wcast-align] spo_alert_fwsam.c:477:25: warning: cast from 'char *' to 'unsigned long *' increases required alignment from 1 to 4 [-Wcast-align] decode.c:336:13: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'EtherHdr *' (aka 'struct _EtherHdr *') increases required alignment from 1 to 2 [-Wcast-align] decode.c:473:16: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'WifiHdr *' (aka 'struct _WifiHdr *') increases required alignment from 1 to 2 [-Wcast-align] log_text.c:634:43: warning: cast from 'u_char *' (aka 'unsigned char *') to 'u_short *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] decode.c:549:33: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'EthLlcOther *' (aka 'struct _EthLlcOther *') increases required alignment from 1 to 2 [-Wcast-align] log_text.c:634:43: warning: cast from 'u_char *' (aka 'unsigned char *') to 'u_short *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] decode.c:715:18: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:634:43: warning: cast from 'u_char *' (aka 'unsigned char *') to 'u_short *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] log_text.c:634:43: warning: cast from 'u_char *' (aka 'unsigned char *') to 'u_short *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] decode.c:825:13: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'EtherHdr *' (aka 'struct _EtherHdr *') increases required alignment from 1 to 2 [-Wcast-align] log_text.c:655:49: warning: cast from 'u_char *' (aka 'unsigned char *') to 'u_short *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] log_text.c:655:49: warning: cast from 'u_char *' (aka 'unsigned char *') to 'u_short *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] decode.c:911:13: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'VlanTagHdr *' (aka 'struct _VlanTagHdr *') increases required alignment from 1 to 2 [-Wcast-align] decode.c:969:29: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'EthLlcOther *' (aka 'struct _EthLlcOther *') increases required alignment from 1 to 2 [-Wcast-align] log_text.c:655:49: warning: cast from 'u_char *' (aka 'unsigned char *') to 'u_short *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] log_text.c:655:49: warning: cast from 'u_char *' (aka 'unsigned char *') to 'u_short *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] log_text.c:659:43: warning: cast from 'u_char *' (aka 'unsigned char *') to 'u_short *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] log_text.c:659:43: warning: cast from 'u_char *' (aka 'unsigned char *') to 'u_short *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] log_text.c:659:43: warning: cast from 'u_char *' (aka 'unsigned char *') to 'u_short *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] decode.c:1305:17: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'Trh_llc *' (aka 'struct _Trh_llc *') increases required alignment from 1 to 2 [-Wcast-align] decode.c:1325:20: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'Trh_mr *' (aka 'struct _Trh_mr *') increases required alignment from 1 to 2 [-Wcast-align] decode.c:1339:21: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'Trh_llc *' (aka 'struct _Trh_llc *') increases required alignment from 1 to 2 [-Wcast-align] log_text.c:659:43: warning: cast from 'u_char *' (aka 'unsigned char *') to 'u_short *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] decode.c:1345:21: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'Trh_llc *' (aka 'struct _Trh_llc *') increases required alignment from 1 to 2 [-Wcast-align] decode.c:1473:24: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'Fddi_llc_iparp *' (aka 'struct _Fddi_llc_iparp *') increases required alignment from 1 to 2 [-Wcast-align] log_text.c:670:49: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:670:49: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:670:49: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:670:49: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:670:49: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:670:49: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:677:53: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:677:53: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:677:53: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:1608:15: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'SLLHdr *' (aka 'struct _SLLHdr *') increases required alignment from 1 to 2 [-Wcast-align] log_text.c:677:53: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:677:53: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:1712:15: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'Pflog1Hdr *' (aka 'struct _Pflog1_hdr *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:1791:19: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'Pflog2Hdr *' (aka 'struct _Pflog2_hdr *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:1798:19: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'Pflog3Hdr *' (aka 'struct _Pflog3_hdr *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:1918:27: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'PPPoEHdr *' (aka 'struct _PPPoEHdr *') increases required alignment from 1 to 2 [-Wcast-align] log.c:1725:36: warning: cast from 'u_char *' (aka 'unsigned char *') to 'u_short *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] log_text.c:677:53: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:2213:28: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'uint16_t *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] decode.c:2213:28: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'uint16_t *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] log.c:1725:36: warning: cast from 'u_char *' (aka 'unsigned char *') to 'u_short *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] log_text.c:684:47: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:2213:28: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'uint16_t *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] log.c:1725:36: warning: cast from 'u_char *' (aka 'unsigned char *') to 'u_short *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] log_text.c:684:47: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:2213:28: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'uint16_t *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] log.c:1725:36: warning: cast from 'u_char *' (aka 'unsigned char *') to 'u_short *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] log_text.c:684:47: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:2240:14: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'IPHdr *' (aka 'struct _IPHdr *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:2421:24: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'IP4Hdr *' (aka 'struct _IPv4Hdr *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:2422:27: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'IP6RawHdr *' (aka 'struct _IP6RawHdr *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1747:42: warning: cast from 'u_char *' (aka 'unsigned char *') to 'u_short *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] log_text.c:684:47: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:2549:14: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'uint16_t *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] decode.c:2549:14: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'uint16_t *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] log.c:1747:42: warning: cast from 'u_char *' (aka 'unsigned char *') to 'u_short *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] log_text.c:684:47: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:2549:14: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'uint16_t *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] log.c:1747:42: warning: cast from 'u_char *' (aka 'unsigned char *') to 'u_short *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] log_text.c:684:47: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:2549:14: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'uint16_t *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] log.c:1747:42: warning: cast from 'u_char *' (aka 'unsigned char *') to 'u_short *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] log_text.c:688:43: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:2621:13: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'struct enc_header *' increases required alignment from 1 to 4 [-Wcast-align] decode.c:2687:22: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'IPHdr *' (aka 'struct _IPHdr *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:2712:29: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'IPHdr *' (aka 'struct _IPHdr *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1751:36: warning: cast from 'u_char *' (aka 'unsigned char *') to 'u_short *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] log_text.c:688:43: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:3030:15: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'TCPHdr *' (aka 'struct _TCPHdr *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1751:36: warning: cast from 'u_char *' (aka 'unsigned char *') to 'u_short *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] log_text.c:688:43: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1751:36: warning: cast from 'u_char *' (aka 'unsigned char *') to 'u_short *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] log_text.c:688:43: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1751:36: warning: cast from 'u_char *' (aka 'unsigned char *') to 'u_short *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] log_text.c:688:43: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1762:42: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:688:43: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1762:42: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:695:46: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1762:42: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:695:46: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1762:42: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:695:46: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1762:42: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:695:46: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1762:42: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:695:46: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1769:46: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:695:46: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1769:46: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:702:50: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1769:46: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:702:50: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1769:46: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:702:50: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1769:46: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:702:50: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1769:46: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:702:50: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1776:40: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1776:40: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:702:50: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1776:40: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:709:51: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1776:40: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:709:51: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1776:40: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:709:51: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1776:40: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:709:51: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1780:36: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:709:51: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1780:36: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log_text.c:709:51: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1780:36: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1780:36: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:3211:15: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'UDPHdr *' (aka 'struct _UDPHdr *') increases required alignment from 1 to 2 [-Wcast-align] log.c:1780:36: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1780:36: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1787:39: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:3397:16: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'ICMPHdr *' (aka 'struct _ICMPHdr *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:3554:19: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'IPHdr *' (aka 'struct _IPHdr *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:3645:28: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'TCPHdr *' (aka 'struct _TCPHdr *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:3654:28: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'UDPHdr *' (aka 'struct _UDPHdr *') increases required alignment from 1 to 2 [-Wcast-align] log.c:1787:39: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:3663:29: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'ICMPHdr *' (aka 'struct _ICMPHdr *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1787:39: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1787:39: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1787:39: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:3690:13: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'EtherARP *' (aka 'struct _EtherARP *') increases required alignment from 1 to 2 [-Wcast-align] decode.c:3718:15: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'EtherEapol *' (aka 'struct _EtherEapol *') increases required alignment from 1 to 2 [-Wcast-align] decode.c:3776:15: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'EAPHdr *' (aka 'struct _EAPHdr *') increases required alignment from 1 to 2 [-Wcast-align] decode.c:3814:20: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'IP6Hdr *' (aka 'struct _IPv6Hdr *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1787:39: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:3916:28: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'TCPHdr *' (aka 'struct _TCPHdr *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:3925:28: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'UDPHdr *' (aka 'struct _UDPHdr *') increases required alignment from 1 to 2 [-Wcast-align] decode.c:3934:29: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'ICMPHdr *' (aka 'struct _ICMPHdr *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1794:43: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:3955:16: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'ICMPHdr *' (aka 'struct _ICMPHdr *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:3993:29: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'ICMP6Hdr *' (aka 'struct _ICMP6 *') increases required alignment from 1 to 2 [-Wcast-align] decode.c:4022:29: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'ICMP6Hdr *' (aka 'struct _ICMP6 *') increases required alignment from 1 to 2 [-Wcast-align] decode.c:4135:44: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'IP6Frag *' (aka 'struct _IP6Frag *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1794:43: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:4382:11: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'IP6RawHdr *' (aka 'struct _IP6RawHdr *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:4427:26: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'IP6RawHdr *' (aka 'struct _IP6RawHdr *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:4449:29: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'IPHdr *' (aka 'struct _IPHdr *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:4631:15: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'GREHdr *' (aka 'struct _GREHdr *') increases required alignment from 1 to 2 [-Wcast-align] log.c:1794:43: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:4672:46: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'uint16_t *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] decode.c:4672:46: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'uint16_t *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] log.c:1794:43: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:4672:46: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'uint16_t *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] log.c:1794:43: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:4672:46: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'uint16_t *' (aka 'unsigned short *') increases required alignment from 1 to 2 [-Wcast-align] log.c:1794:43: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] decode.c:4835:13: warning: cast from 'const uint8_t *' (aka 'const unsigned char *') to 'EtherHdr *' (aka 'struct _EtherHdr *') increases required alignment from 1 to 2 [-Wcast-align] log.c:1801:44: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1801:44: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1801:44: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1801:44: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1801:44: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] log.c:1801:44: warning: cast from 'u_char *' (aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align]