tcpdump shows packets going from 0.0.0.0.0 0.0.0.0.0, what does this mean?
Hi misc,
I have been playing around with pf lately, and have noticed a bunch of
packets going from 0.0.0.0.0 to 0.0.0.0.0. I know 0.0.0.0 sometimes
means the network address, but am not sure why these packets are getting
through the firewall, or even if they are.
Also, when tcpdump says (for example) rule 8 does that mean the 8th
line in the output of pfctl -sr?
I cannot find an explanation on website or man pages.
Cheers,
Brett.
PS Happy birthday, Theo, I will buy a tshirt and a cd set (once I've got
a new job!)
-
Output from tcpdump:
tcpdump -n -e -ttt -i pflog0
May 21 23:47:37.376825 rule 8/(match) pass out on athn0: 0.0.0.0.0
0.0.0.0.0: . ack 743779200 win 1927 nop,nop,timestamp 514120164 0 (DF)
May 21 23:47:37.540667 rule 8/(match) pass in on athn0: 0.0.0.0.0
0.0.0.0.0: . 12584:14032(1448) ack 462 win 2172 nop,nop,timestamp
3845107508 514120164 (DF)
May 21 23:47:37.544679 rule 8/(match) pass in on athn0: 0.0.0.0.0
0.0.0.0.0: P 14032:15065(1033) ack 462 win 2172 nop,nop,timestamp
3845107508 514120164 (DF)
May 21 23:47:37.544701 rule 8/(match) pass out on athn0: 0.0.0.0.0
0.0.0.0.0: . ack 743781681 win 1918 nop,nop,timestamp 514120165 0 (DF)
May 21 23:47:37.544708 rule 8/(match) pass in on athn0: 0.0.0.0.0
0.0.0.0.0: P 15065:15070(5) ack 462 win 2172 nop,nop,timestamp
3845107508 514120164 (DF)
May 21 23:47:37.742617 rule 8/(match) pass out on athn0: 0.0.0.0.0
0.0.0.0.0: . ack 743781686 win 2048 nop,nop,timestamp 514120165 0 (DF)
^C
29 packets received by filter
0 packets dropped by kernel
---
My pf.conf file (I know there is overlap/over-redundency here):
set block-policy drop
block in log (all, to pflog0) on ! lo0 proto tcp to port 6000:6010
block in quick from urpf-failed
antispoof quick for athn0 inet
block in log (all, to pflog0) all
block out log (all, to pflog0) all
match in all scrub (no-df)
block in log (all, to pflog0) on athn0
pass out log (all, to pflog0) on athn0 proto { tcp udp icmp icmp6 } all
modulate state
--
# pfctl -sr
block drop in log (all) on ! lo0 proto tcp from any to any port 6000:6010
block drop in quick on ! athn0 inet from 192.168.1.0/24 to any
block drop in quick inet from 192.168.1.134 to any
block drop in quick from urpf-failed to any
block drop in log (all) all
block drop out log (all) all
match in all scrub (no-df)
block drop in log (all) on athn0 all
pass out log (all) on athn0 proto tcp all flags S/SA modulate state
pass out log (all) on athn0 proto udp all keep state
pass out log (all) on athn0 proto icmp all keep state
pass out log (all) on athn0 proto ipv6-icmp all keep state
--
Re: tcpdump shows packets going from 0.0.0.0.0 0.0.0.0.0, what does this mean?
Hello Brett, On 05/22/11 09:02, Brett Mahar wrote: Hi misc, I have been playing around with pf lately, and have noticed a bunch of packets going from 0.0.0.0.0 to 0.0.0.0.0. I know 0.0.0.0 sometimes means the network address, but am not sure why these packets are getting through the firewall, or even if they are. Also, when tcpdump says (for example) rule 8 does that mean the 8th line in the output of pfctl -sr? I cannot find an explanation on website or man pages. I'm also seeing this for my pass in log (all to pflog0) ... rules. If you remove the all keyword, you'll see the the correct IP addresses at session initialization in the logs. Best regards Andreas
Re: hot zones (temperatures) on Lemote Yeeloong
On Sat, May 21, 2011 at 02:45:01AM +0200, gilbert.fernan...@orange.fr wrote: Launched a build with apmd -A and then measured temperatures using a multimeter and a metal rod temperature sensor. Yeeloong does not have CPU throttling yet. So the CPU will not run on a lower clock if there is not much work. In current there is suspend/resume. But what I see is that the temperaure slowly rises while the machine is suspended. I suspect some circuits are left in a switched on state. ON a addition note, the fan control is done by hardware or firmware, and is not very subtle. At one point the fan will hit it's maximum RPM, and never slow down after that, even if the machine is idle. At least that is what appears to be going on. -Otto internal temperatures as reported by sysctl and sensors : hw.sensors.ykbec0.temp0=61.00 degC (Internal temperature) hw.sensors.ykbec0.temp1=36.00 degC (Battery temperature) hw.sensors.ykbec0.fan0=4660 RPM Here is a picture of the keyboard and the two hot zones after two hours heavily working on a build of openbsd sources : http://bit.ly/jktqwV (short link to a picture in the picasa album i posted a few days ago) If you cannot display the picture (eg. in console) the two hot zones are left side of keyboard, centered on the S key for medium temperature : 31.3 degrees celcius, 88.34 degrees farenheit And the hottest area is lower right of keyboard, centered on the right ALT key : 34.5 degrees celcius, 94.1 degrees farenheit Ambiant temperature being 25 degrees celcius, 77 degrees farenheit (46.5 % RH, 1007 hPa). The two hot zones are quite close in temperature, but the right one you can feel it's the hottest area of the whole netbook. -- Gilbert Fernandes
Re: Asus acpi panic on boot ( was: dmesg for notebooks useful?)
On Sun, May 22, 2011 at 11:56:20AM +1200, Paul M wrote: On 21/05/2011, at 8:01 PM, Stuart Henderson wrote: I've tried such a laptop, booting from usb stick does indeed fail as you describe, however booting from the install cd (4.9 release) works just fine. Disabling acpi will allow the system to boot from the usb stick. Thanks for the info. I'll try disabling ACPI the next time I encounter one of these. You need the information in the panic message and trace. If you want to help get the problems with those machines tracked down, you need to get that information, maybe take a photo and type it in from there. If the panic message itself has scrolled off show panic should show it again. The only way disabling ACPI is helpful, is if the machine saves the dmesg buffer between boots, then you may be able to get the panic, boot -c, disable acpi, and save the information. Turns out it does, so here it is: Could you try a recent kernel on that machine and see if it works? If it doesn't please send the same information, but from the new kernel. Better yet, use sendbug(1) and attach the AML as well. Thanks!
cpuspeed: getting a list of available freq's
hello, is there an API or syscall to get a list of available cpu frequencies, that the CPU supports? greetings, David
Re: cpuspeed: getting a list of available freq's
is there an API or syscall to get a list of available cpu frequencies, that the CPU supports? No. Not all rate/power adjustments are done in terms of frequencies. Some are done based on bus clock adjustment, or how the memory controller works, or other tricks that are processor specific. Mapping those into a set of sequential numbers would be hard. The relationships of those numbers do not translate into performance values for all workloads evenly. We punted on that crazy problem and instead only supply a knob choosing 0-100 percentage scale in the hw.setperf sysctl; different machines then pick different methods of speed adjustment at different points on the line, and if it is convenient for them they also report the cpu clock rate in hw.cpuspeed (however as I have said, this value is not the final story).
Installing Puffy on boot display of Lemote Leeyong
After checking my PMON version, I found out I was using version 1.4.5 of Lemote's PMON. This email will show two things : how to upgrade your Lemote 8101B to PMON's version 1.4.9 and, this is a special gift for Miod, how to install Puffy as boot picture so each time you turn on your Lemote, Puffy (or the picture of your choice) appears. That's why you bought a Lemote right, to be able to hack it from the very BIOS no ? Part I : upgrade to PMON 1.4.9 As you know, the 8089 and 8101B share the same PMON. Explanations here will work for both models. Boot your machine, and press C to get into PMON's prompt. You can use the env Version to check what is your PMON version. Latest one for 8089 and 8101B being 1.4.9 : Mine answers this : BEV in SR set to zero. PMON env Version Version = LM8089-1.4.5 PMON -- On this web page, you can check the status of the PMON according to your Lemote model : dev.lemote.com/cgit/pmon.git/ Latest version being : Here is the link to the sources to build version 1.4.9 (that does require a Linux, and setting it for cross-building and, to make things easier, you need a specific gcc version too) : http://dev.lemote.com/cgit/pmon.git/snapshot/pmon-LM8089-1.4.9.tar.gz So here I'm going to be nice and directly distribute the compiled PMON binary :) Here it is : http://perso.orange.fr/gilbert.fernandes/pmon_149_8081b.bin.gz This file contains the binary form of PMON, ready to burn into flash, for the Lemote 8089 and 8101B. If you do not have one of those two models, please, please, don't go further : you will brick your unit. Download the file, gzip -d it and check the SHA1 is valid : dfb2f9854aa986e123f23e5ac04f4036f9ad0c43 * * * * * * * * * * DANGER ! DANGER ! I have to warn you. Seriously. If you are burning a PMON update, you MUST be sure the SHA1 for the file is good and you MUST be sure you are typing the commands I give exactly, especially the memory addresses. If you screw up in the SHA1 or the commands, there is a high risk of bricking your netbook and you will have to send it back to Lemote for repairs. This warning is also valid for the Part 2 where I show you how to burn a new boot-up picture in PMON. Please be cautious * * * * * * * * * * Follow the instructions here to install version 1.4.9 of PMON. Only for 8089 and 8101B models. 1. Grab an USB key and format it using ext2. 2. Fsck the USB key. Please do it. Make sure the key has NO problem at all. 3. Download my PMON 1.4.9 file and copy it at the root of the USB key. 4. Check the SHA1 for the file. DO NOT burn anything that doesn't give you the exact SHA1 displayed below : dfb2f9854aa986e123f23e5ac04f4036f9ad0c43 5. If you did the SHA1 of the file before moving it to the USB key, cd to the USB key and check the SHA1 _again_ Make sure the file on the USB key that will be burned into the machine Flash has the good SHA1. 6. Now, plug the USB key on the Lemote and reboot it. Press c at display to get into PMON and first, check the USB key is seen properly : devls the usb0 should be visible. 7. Command to burn the PMON : load -r -f bfc0 /dev/fs/ext2@usb0/pmon_149_8081b.bin Be sure to type the command exactly as seen here. Make sure there is no mistake in the memory address : bfc0 It's b f c followed by five zeroes You will get this on the display : Erasing all FLASH blocks, Done. Programming FLASH, Done. verifying FLASH. No Errors Found. 8. Now you can type reboot to finish. 9. Upgrading PMON will reset the default variables as if the machine was new. We must go back to PMON's prompt on reboot to set up the two variables required : set moresz 30 set bsd /bsd If you did use more commands from INSTALL.loongson (like setting ShowBootMenu to no or using the autload al function) you need to type them again. - * - * - * - * Part 2 : Putting the Puffy as boot picture (yeah baby !) Running OpenBSD is not enough. From the very first few seconds you do power up the machine, everyone must see the Puffy on screen. Girls will dig you, the ground will shake, and an aura of light will appear... well. Around the LED power indicator of your machine. Let's spice it ! As you know, the machine loads a picture on start. And this picture can be modified. This picture must be modified. PUFFY WANTS YOU TO MODIFY THAT PICTURE ! Puffy talks to me. Really. The PMON documentation from Lemote says we can load a picture into PMON in compressed bitmap form. It will use the function video_display_bitmap of fb/cfb_console.c of the Lemote PMON sources. The default picture is 448 x 224 pixels, 8 bits per pixel, in bmp format (the Windows one, yes). So we can replace it with a new 448 x 224 picture The PMON is burned at address bfc0 while the picture displayed at boot is burned at address bfc6. The image can be greater than 448 x 224. According to the doc, the image size can be up to 1024 x 600 in either bmp or
Re: cpuspeed: getting a list of available freq's
On Sun, May 22, 2011 at 11:09:21AM -0600, Theo de Raadt wrote: is there an API or syscall to get a list of available cpu frequencies, that the CPU supports? No. Not all rate/power adjustments are done in terms of frequencies. Some are done based on bus clock adjustment, or how the memory controller works, or other tricks that are processor specific. Mapping those into a set of sequential numbers would be hard. The relationships of those numbers do not translate into performance values for all workloads evenly. We punted on that crazy problem and instead only supply a knob choosing 0-100 percentage scale in the hw.setperf sysctl; different machines then pick different methods of speed adjustment at different points on the line, and if it is convenient for them they also report the cpu clock rate in hw.cpuspeed (however as I have said, this value is not the final story). thank you for the detailed answer. i'll try to find a workaround: either probing hw.cpuspeed with different hw.setperf values, or monitoring hw.cpuspeed on demand.
Re: smtpd and no DH parameters found in
On Thu, May 19, 2011 at 07:58:55PM +, Kevin Chadwick wrote: On Thu, 19 May 2011 01:06:49 +0100 Mikolaj Kucharski wrote: On Thu, May 19, 2011 at 12:42:57AM +0200, Gilles Chehade wrote: smtpd is just telling you that you did not generate Diffie-Hellman parameters [see smtpd.conf(5) / starttls(8)], and that it will use its own builtin parameters. It is safe to ignore the message, but it is safer to actually take the time to generate your very own parameters. We don't do it when booting or starting smtpd for the first time because it can take a very looong time :-) Interestingly on the same unloaded system, sometimes it takes absolutely ages and sometimes it takes seconds. Okay, but how big (long) DH parameters file I should generate? Is this something simple as: openssl dhparam -outform PEM -out dh.pem size I didn't really get that after reading smtpd.conf(5) and starttls(8). I do 1024 and regenerate it every so often (early morning, once a week or twice a year, depending on usage/preference) Does length of DH parameters matter for different sizes or types of private key? If I'm using 4096-bit RSA key, do I need to use 4096-bit size DH parameters file? Do they need to match? Is it okay to have DH smaller or even bigger? I'm happy to read about it more, but openssl(1) man page wasn't too helpful for me (unless I've missed something). -- best regards q#
Votre Carte Bancaire est suspendue
S'il vous plant confirmer vos donnies personnellesDans le cadre de nos mesures de sicuriti, chaque 12 moiss'il vous plant mettre ` jour vos informations personnelles afin de faciliter votre Carte banquaire protiger et d'amiliorer notre sicuriti.La procidure est trhs simple: 1. Cliquez sur le lien ci-dessous pour ouvrir un navigateur sicurisi 2. Confirmez que vous jtes le propriitaire du compte et suivez les instructions. Mise ` jour Note: le refus de mettre ` jour vos informations nous serons obligis de bloquer votre carte de cridit. Aide | Zone de sicuriti Copyright ) 1999-2011 Verified by Visa. Tous droits riservis.
Re: smtpd and no DH parameters found in
On Sun, 22 May 2011 23:12:21 +0100 Mikolaj Kucharski wrote: If I'm using 4096-bit RSA key, do I need to use 4096-bit size DH parameters file? No Do they need to match? No Is it okay to have DH smaller or even bigger? Yes, some programs like dovecot manage it automatically so maybe? there's more info in the source code.
