July 2011 - Arch-general - lists.archlinux.org

Re: [arch-general] iptables not working well?
by Javier Vasquez 12 Jul '11

12 Jul '11

On Sun, Jul 10, 2011 at 6:35 PM, Robert Marmorstein <rmmarm(a)sdf.org> wrote: > ... > > It might help you to LOG packets that are REJECTED. Then if you continue to > have issues, you should be able to see more directly what's going on. > > To do that, add rules like directly before the ones with -J REJECT: > > iptables -A INPUT -j LOG -m limit --limit 3/minute > iptables -A FORWARD -j LOG -m limit --limit 3/minute > > Then you should look in /var/log/messages or /var/log/syslog (depending on > which logger you have installed) to see which packets are being dropped. > > You probably don't want these rules enabled all the time -- the log files > can get pretty big quickly -- but they are very helpful for debugging. > > If you continue to have issues, posting the LOG messages would help us know > more about what's going on. > > Robert Hi Robert, I tried the loging rules, but they didn't work as proposed: % sudo iptables -A INPUT -j LOG -m limit --limit 3/minute Password: iptables: Invalid argument. Run `dmesg' for more information. % sudo iptables -A FORWARD -j LOG -m limit --limit 3/minute iptables: Invalid argument. Run `dmesg' for more information. What dmesg shows is: x_tables: ip_tables: limit.0 match: invalid size 40 (kernel) != (user) 48 x_tables: ip_tables: limit.0 match: invalid size 40 (kernel) != (user) 48 I didn't find anything under: /var/log/messages.log /var/log/syslog.log The dmesg messages come from: /var/log/kernel.log Not sure if that helps any way to get some light, :-) Thanks, -- Javier.

1 1

[arch-general] iptables not working well?
by Javier Vasquez 12 Jul '11

12 Jul '11

Hi, I've configured a 2-nics gateway (one internal nic and an external usb nic hooked to the adsl modem). I configured iptables as I'm used to do: ++++++ iptables-restore < /etc/iptables/empty.rules iptables -P INPUT ACCEPT iptables -P FORWARD ACCEPT iptables -P OUTPUT ACCEPT iptables -F iptables -t nat -F iptables -t mangle -F iptables -X iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -m state --state NEW ! -i ppp0 -j ACCEPT iptables -A FORWARD -m state --state ESTABLISHED,RELATED -i ppp0 -o eth0 -j ACCEPT iptables -A FORWARD -i eth0 -o ppp0 -j ACCEPT iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE iptables -A FORWARD -i ppp0 -o ppp0 -j REJECT /etc/rc.d/iptables save /etc/rc.d/iptables restart ++++++ Notice that I have IP forwarding enabled through: ++++++ % 'grep' forward /etc/sysctl.conf net.ipv4.ip_forward=1 net.ipv6.conf.all.forwarding=1 ++++++ And also through: ++++++ % 'grep' FORWARD /etc/conf.d/iptables IPTABLES_FORWARD=1 ++++++ But I can confirm by: +++++++ % cat /proc/sys/net/ipv4/ip_forward 1 +++++++ This is based upon: http://www.debian-administration.org/articles/23 And it's working on a debian box. I remember some time back it also worked on a arch box, only thing I was not using pppd directly but wvdial instead... OK, on machines at the internal side of my LAN, I can ping everywhere. But I can not use the browser with all addresses, for example I can't get to www.archlinux.org through frirefox or midori, neither www.debian.org. Weird thing www.google.com, and some other sites can be reached through firefox on machines inside the LAN. When I try accessing those sites on the gateway (not the machines inside the LAN) of course I have no problem. I checked /etc/resolv.con, and it's OK, besides ping has clear access everywhere. I have no clue what's going on. I noticed the following under /var/log/messages.log: +++++++ Jul 9 23:32:33 mini-0 pppd[1974]: Plugin rp-pppoe.so loaded. Jul 9 23:32:33 mini-0 pppd[1974]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.5 Jul 9 23:32:34 mini-0 kernel: NET: Registered protocol family 10 Jul 9 23:32:34 mini-0 pppd[1974]: pppd 2.4.5 started by root, uid 0 Jul 9 23:32:34 mini-0 pppd[1974]: PPP session is 45128 Jul 9 23:32:34 mini-0 pppd[1974]: Connected to 00:12:7f:33:eb:3c via interface eth1 Jul 9 23:32:34 mini-0 pppd[1974]: Using interface ppp0 Jul 9 23:32:34 mini-0 pppd[1974]: Connect: ppp0 <--> eth1 Jul 9 23:32:34 mini-0 pppd[1974]: PAP authentication succeeded Jul 9 23:32:34 mini-0 pppd[1974]: peer from calling number 00:12:7F:33:EB:3C authorized Jul 9 23:32:34 mini-0 pppd[1974]: kernel does not support PPP filtering Jul 9 23:32:34 mini-0 pppd[1974]: local IP address 201.200.139.27 Jul 9 23:32:34 mini-0 pppd[1974]: remote IP address 200.91.104.9 Jul 9 23:32:34 mini-0 pppd[1974]: primary DNS address 200.91.75.6 Jul 9 23:32:34 mini-0 pppd[1974]: secondary DNS address 200.91.75.5 Jul 9 23:32:35 mini-0 kernel: ip_tables: (C) 2000-2006 Netfilter Core Team Jul 9 23:32:35 mini-0 kernel: nf_conntrack version 0.5.0 (7628 buckets, 30512 max) +++++++ It sounded curious that kernel does not support PPP filtering, but I'm almost certain that's not the issue, given that on the gateway (not the forwarded internal LAN), I can access all pages through firefox... Any help you can provide is very welcome... It might be the iptables is not working well. I missed to indicate this is running on a lemote mini-pc (archloong on mipsel), which of course has no official support, but I wanted to see first if I'm missing any configuration particular to arch (as I said this worked before also on a x86 arch box, but things change), so just in case perhaps someone identified the miss... Thanks, -- Javier.

2 3

[arch-general] Xorg not working on AMD C-50 Fusion (Radeon HD 6250)
by Nicolás Adamo 11 Jul '11

11 Jul '11

Hi all! I'm having trouble installing xorg on a Gateway Netbook which has a fusion AMD processor model "C-50". It has micro+graphics in one chip. I've googled that many people succeded with catalyst drivers, though I haven't been that lucky. I added the [catalyst] repo mentioned at the arch wiki, installed all xorg, xorg-utils, catalyst, catalyst-utils, etc. but I can't start x When running startx, nothing happens. It shows the prompt again. fglrxinfo returns "unable to open display (null)" /var/log/Xorg.0.log is empty , however, the same file with .old is at http://pastebin.archlinux.fr/433086 If helps, /etc/X11/xorg.conf is at http://pastebin.archlinux.fr/433085 Removing it makes no change. Well, any clue will be appreciated. Regards, Nicolás

3 8

[arch-general] Still perl issues
by Joel Hatsch 11 Jul '11

11 Jul '11

Hello *, still having perl issues after update. Saw on the mailing list that I'm not the first, but the suggested workarounds don't work for me. Code : #!/usr/bin/perl use strict; use GD::Graph::lines; results in the already known Not a CODE reference at /usr/lib/perl5/core_perl/DynaLoader.pm line 213. END failed--call queue aborted at /usr/lib/perl5/vendor_perl/GD.pm line 213. Compilation failed in require at /usr/share/perl5/vendor_perl/GD/Graph/lines.pm line 18. BEGIN failed--compilation aborted at /usr/share/perl5/vendor_perl/GD/Graph/lines.pm line 18. Compilation failed in require at ./test.pl line 6. BEGIN failed--compilation aborted at ./test.pl line 6. 1) adding push (@INC,"/usr/lib/perl5/vendor_perl"); didn't help 2) renaming vendor_perl to vendor_perl-old didn't help (was suggested in june) 3) remove perl/gd/perl-gd & reinstall didn't help neither I was hoping that a subsequent update of the packages would help, but in the meantime it's more or less 1 month that I can't execute perl programs and it's getting annoying Any hints/pointers for future investigation ? Thanks Joel

1 0

[arch-general] Arch base system snapshot available?
by Herb Miller Jr. 11 Jul '11

11 Jul '11

Where can I find a snapshot of the Arch base system to facilitate deployment in a chrooted environment? Is such a thing available? Thank you, Herb

4 4

[arch-general] Outdated install media (2010-05)
by Darkbyte 11 Jul '11

11 Jul '11

Is there anything we could do about the extremely outdated install media? I right now got used to installing systems with the most recent iso's from http://releng.archlinux.org/isos/2011.06.10/ and they worked for me. Is there any tests that need to be performed? - Armin

2 2

[arch-general] Alsa buffer_size without dmix?
by Sven-Hendrik Haase 11 Jul '11

11 Jul '11

Hello everypony, I want to increase my default alsa buffer_size of 8192 to 32768 because I'm sometimes getting small skips in my audio. Now, usually people use dmix for this. I'm using the upmix plugin, however, to listen to stereo music on my 7.1 system. Could any alsa wizards share the wisdom on how to increase the buffer_size without dmix or how to chain dmix into this? My also asound.conf: pcm.upmix71 { type upmix slave.pcm "surround71" channels 8 } pcm.!default "plug:upmix71" Now, I tried something along these lines: pcm.upmix71 { type upmix slave.pcm "buffer" channels 8 } pcm.buffer { type dmix slave { pcm "surround71" period_time 0 buffer_time 0 period_size 2028 buffer_size 32768 } } pcm.!default "plug:upmix71" but apparently I don't grok alsa configuration syntax. It doesn't help that alsa-project.org is down (which is why I'm posting here rather than on their mailing list). I don't even need dmix itself, I just want to increase the buffer size but apparently dmix is the only plugin capable of doing just that. Help appreciated. -- Sven-Hendrik

1 0

Re: [arch-general] iptables not working well?
by Javier Vasquez 11 Jul '11

11 Jul '11

On Sun, Jul 10, 2011 at 5:02 PM, Dr. Robert Marmorstein <robert(a)narnia.homeunix.com> wrote: > If you have a static IP address on your ethernet card, you probably want to > use SNAT rather than MASQUERADE. > > Also, I find it odd that you are using MASQUERADE on traffic TO the ppp0 > interface. Usually, ou MASQUERADE traffic FROM the ppp0 address. You might try > "-i" instead of "-o" in that rule and see if it makes a difference It's workin like I showed on a debian box. But I'll try of course. > > Your state rules also look a little odd to me. On your INPUT chain, you are > accepting traffic that is established or related. But you only accept new > connections if they are not from ppp0. I think I would delete the "! -i ppp0" > from that line unless you have a very good reason for it to be there. ppp0 is my connection to the external world (ISP through PPPoE), so the idea is not to accept new connections from the outside. That seemed logical to me. And has been working on the debian box for quiet a while. However I'll remove conditional acceptance, just plain accept new connections both from inside as from outside. > > Furthermore, there should be an equivalent line that alow the FORWARD chain to > accept NEW connections, but that seems to be missing. > > Since you don't seem to really have any real security rules in your firewall > anyway, I suggest something like this: > > iptables -P INPUT ACCEPT > iptables -P FORWARD ACCEPT > iptables -P OUTPUT ACCEPT > iptables -F > iptales -t nat -F > iptales -t mangle -F > iptales -X > > iptables -A INPUT -i lo -j ACCEPT > iptables -A INPUT -m state --state ESTABLISHED, RELATED -j ACCEPT > iptables -A FORWARD -m state --state ESTABLISHED, RELATED -j ACCEPT > iptables -A INPUT -i ppp0 -m state --state NEW -j ACCEPT > iptables -A FORWARD -ippp0 -m state --state NEW -j ACCEPT > iptables -t nat -A POSTROUTING -i ppp0 -o eth0 -j MASQUERADE > iptables -A INPUT -j REJECT > iptables -A FORWARD -j REJECT > > Of course, since I'm not on your system, I can't test these. But I think this > is more or less what you're trying to do. I'll experiment a bit with your settings, I hope you're right, :-) Notice that even though my setting look a bit dated, they're still working for me on an old debian box (which I'm trying to replace)... > > In terms of security stuff, I strongly recommend you think about adding some > limit matches -- at least for SSH and HTTP ports if you have them open. Yes, I haven't set a firewall, just a transparent gateway, I mean a plane router between my ISP and my internal LAN. So far I don't have any service, like web or mail, so it hadn't been much of a constrain, but I can learn how to do things and implement them. Perhaps you can share later on more on your suggestions for more security, :-) > > Hope this helps, Yeap, I'll try, and then will let you and the list know... > > Robert Thanks a lot, -- Javier.

2 1

[arch-general] Nvidia?? (About to do pacman -Syu but:)
by Joe(theWordy)Philbrook 10 Jul '11

10 Jul '11

In preparation for a pacman -Syu I peeked at the "main page" and read: > The nvidia-173xx and nvidia-96xx driver packages have been removed from > our repositories as they are incompatible with newer xorg servers. This > can only be fixed by an upstream update, which has not happened yet. > > For most video cards, the best alternative should be xf86-video-nouveau Since I know for a fact that my integrated Nvidia GeForce 6150 LE is very incompatible with the nouveau driver I'm suddenly concerned... according to pacman -Q nvidia I got: nvidia 270.41.19-1 Should I worry about it? That is should I find out how to prevent pacman from messing with the video driver, or does the "270.41.19-1" mean the above will have no effect on my nvidia driver? Thanks -- | ~^~ ~^~ | <?> <?> Joe (theWordy) Philbrook | ^ J(tWdy)P | \___/ <<jtwdyp(a)ttlc.net>>

2 3

[arch-general] grub-legacy-fedora-git package
by KESHAV P.R. 10 Jul '11

10 Jul '11

Hi all, I have created a PKGBUILD for Fedora's GRUB Legacy fork, grub-legacy-fedora-git https://aur.archlinux.org/packages.php?ID=47959 . It includes support for GPT boot (not tested) and supports ext4 /boot (tested using the UEFI package). It does not include any of the patches used in core/grub package. It compiles fine with the binutils in Arch repos (unlike the current core/grub and aur/grub-gfx packages). It also supports splashimage (gfx) option. Although I maintain that package, I do not use it. I use grub2-bios-bzr which I maintain). Important info :- 1. The menu config file is /boot/grub/grub.conf, not /boot/grub/menu.lst . 2. The syntax for splashimage is (for example) - splashimage (hd0,0)/boot/grub/image.xpm.gz 3. The package builds fine in x86_64 with gcc-multilib. I have not checked whether it compiles without gcc-multilib (grub2 1.99 compiles without multilib in x86_64). Would be helpful if someone confirms whether it compiles in x86_64 without multilib. I request current core/grub and aur/grub-gfx users to test this package and give your comments/suggestions. Regards. Keshav PS: The equivalent UEFI package is grub-legacy-efi-fedora https://aur.archlinux.org/packages.php?ID=47979 .

1 0