[gentoo-user] Re: Manually removing packages from world problem

[Kai Krakow]

Am Thu, 24 Dec 2015 20:22:45 -0200
schrieb João Matos :

> Dear list,
> 
> I was having problem with plasma, so I decided to change it.
> 
> I've removed all packages related from world, changed the profile,
> erased use-related files from /etc/portage.
> 
> Then I've used "emerge --depclean", that worked as should be.
> 
> However, when I tried "emerge -avuDN world" I got a problem: portage
> tries to emerge all these world packages I removed before.
> 
> What should be happening?
> 
> Thank you all,

Please have a look at the world_sets file. Chances are that it contains
KDE for you:

kakra@jupiter ~ $ cat /var/lib/portage/world_sets
@kde-applications
@kde-frameworks
@kde-plasma
@steam

Some modern Gentoo guides recommend installing KDE using sets, this is
what you may have ended up with.

BTW: @steam is a custom set I've created for pulling in steam specific
library versions/slot to ensure they stay installed without having them
in my world file explicitly.

-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] Gcc 5.3

[Andreas K. Huettel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Donnerstag, 24. Dezember 2015, 16:18:27 schrieb Alan Grimes:
> Hey, thanks for putting out gcc 5.3...
> 
> Unfortunately, it fails to bootstrap on my machine. I am getting
> differences between the stage 2 and stage 3 compilers and it's dying... =(
> 

"emerge --info" output pretty please! :)

- -- 
Andreas K. Huettel
Gentoo Linux developer (council, perl, libreoffice)
dilfri...@gentoo.org
http://www.akhuettel.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWfTrdAAoJEHRrah2soMK+T0IP/2ydazWAGK3+c+XKFl91dEiD
ucSbupfp2MsmrPgtWDS8JdHHaY3vRCOJOtH+TzfYHtIBCvGg19V3Z6LyEq/Ch6BL
iUK4gyT4JIsuYe24wsmFm4kcNpm7P7A7tnIyGl4T+E2sahZ1GUZhXfzRUm10D+Z0
LZod6Nyo2kgghw3DUqvWtDaOl2FrNA5EV63ZqVqr84S+ycGmFT+1KLAglYfE0/M/
Dc059New0/KRlDr+pbCOD3U+LNbVecLtudawhvkCfUZLsRc+p0PR2/bNp2pZn61/
WV1tQbC5q22qpwWP9ysyDPaFUZmFvFb5Ifs9o9qzgsitmdmPC/cjeNwSfHyORXaS
fhAPNDc9E0famxnXnWIWD50ujBk+XHb3Y9iCVXsk/fxV0KC0yBQI5iQlt9oCe5Mg
UYH4O8KRrPAbiMieqv4UML8ub7WRpopIVHhIHS2WxoP7oxti3E2WyjnHzV1YqJOd
UNyhJ36+Ma5uV30gddy8WDlxOmE7FobuDn603esZ5u12QjbuFfwdkToMqkTFdQFI
cvj/EQlUIxuRshb15qW1vO+gYPUElsRBOuKl8uNXvGeX4UkIKyO8x8cX1GgZaUj7
17ee4CLUs4bt+pFJ/EAGDrmlKOZr7bI5kWPwZ4T51gAzwY80/+pmZW1Qeoy92Ha8
ts5kUUEekh/xuLuPpiR2
=wg00
-END PGP SIGNATURE-

Re: [gentoo-user] Gcc 5.3

[Alan Grimes]

David Haller wrote:
> Hello,
>
> On Thu, 24 Dec 2015, Alan Grimes wrote:
>> Hey, thanks for putting out gcc 5.3...
>>
>> Unfortunately, it fails to bootstrap on my machine. I am getting
>> differences between the stage 2 and stage 3 compilers and it's dying... =(
> What compiler and C(XX)FLAGS are you using? It builds nicely with
> gcc-4.9 (and rather agressive flags) here. With how many processes
> (MAKEOPTS) are you compiling?.

6, one per core, because it doesn't go to 100% utilization, I can
continue to use the machine normally for desktop.

> Also, compiling gcc might expose flaky RAM (removing and reseating the
> RAM DIMMs might help there[0]). Have you e.g. encoded stuff with
> mencoder or ffmpeg lately[1]? If you're compiling with any MAKEOPTS
> '-j1' it could be the same phenomenon as I had in [1], so try with
> -j1. If that works ... Consider using prime95/mprime[2] for a test.

Been through that, I'm fairly confident with the integrity of the
machine right now.

> -dnh
>
> [0] stuff expands and shrinks depending on temps, so connections can
> get flaky even if the box isn't moved ;)
>
> [1] I've had mencoder segfault on me reproducibly on one box after
> 20-30 mins encoding with one process, and <= 10mins with two
> processes. Memtest86 found nothing in one round. New RAM (replaced
> on guarantee :) cured the problem for good.
>
> [2] http://www.mersenne.org/download/#download


-- 
IQ is a measure of how stupid you feel.

Powers are not rights.

Re: [gentoo-user] QEMU unable to initialize audio

[waltdnes]

On Fri, Dec 25, 2015 at 04:10:40AM +, Ian Bloss wrote
> I was saying the libsdl packages have a USE flag "sound" which builds the
> sound module for sdl. So if qemu makes any calls to the sound module not
> pure alsa calls, that might be causing your issue.
> 
> Wabes USE flag output shows he's building sdl with the "sound" use flag
> enabled and not just alsa alone.

  "sound" is a default USE flag for libalsa and libalsa2.  I.e. "+sound"
in IUSE in the ebuilds.  It shows up in the emerge, and both libsdl's
had it.  Apparently QEMU prefers libsdl2 over libsdl when both USE flags
are set.  I removed the "sdl2" flag from qemu, and re-emerged qemu.  I
no longer get the error message, apparently because the libsdl version
that qemu now uses does have "alsa" enabled.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Gcc 5.3

[Alan Grimes]

Andreas K. Huettel wrote:
> Am Donnerstag, 24. Dezember 2015, 16:18:27 schrieb Alan Grimes:
> > Hey, thanks for putting out gcc 5.3...
>
> > Unfortunately, it fails to bootstrap on my machine. I am getting
> > differences between the stage 2 and stage 3 compilers and it's
> dying... =(
>
>
> "emerge --info" output pretty please! :)

Like the other d00d, I'm also using and AMD processor.


atg@tortoise ~ $ emerge --info
Portage 2.2.26 (python 3.4.3-final-0, default/linux/amd64/13.0/desktop,
gcc-4.9.3, glibc-2.22-r1, 4.3.3 x86_64)
=
System uname:
Linux-4.3.3-x86_64-AMD_Phenom-tm-_II_X6_1090T_Processor-with-gentoo-2.2
KiB Mem:32877316 total,  21368792 free
KiB Swap:8000364 total,   8000364 free
Timestamp of repository gentoo: Fri, 25 Dec 2015 15:30:01 +
sh bash 4.3_p42
ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1
app-shells/bash:  4.3_p42::gentoo
dev-java/java-config: 2.2.0::gentoo
dev-lang/perl:5.22.1::gentoo
dev-lang/python:  2.7.11-r1::gentoo, 3.3.5-r1::gentoo,
3.4.3-r7::gentoo
dev-util/cmake:   3.4.1::gentoo
dev-util/pkgconfig:   0.29::gentoo
sys-apps/baselayout:  2.2::gentoo
sys-apps/openrc:  0.19.1::gentoo
sys-apps/sandbox: 2.10-r1::gentoo
sys-devel/autoconf:   2.13::gentoo, 2.69-r1::gentoo
sys-devel/automake:   1.10.3-r1::gentoo, 1.11.6-r2::gentoo,
1.12.6::gentoo, 1.13.4::gentoo, 1.14.1-r1::gentoo, 1.15-r1::gentoo
sys-devel/binutils:   2.25.1-r1::gentoo
sys-devel/gcc:4.9.3::gentoo
sys-devel/gcc-config: 1.8::gentoo
sys-devel/libtool:2.4.6-r1::gentoo
sys-devel/make:   4.1-r1::gentoo
sys-kernel/linux-headers: 4.3::gentoo (virtual/os-headers)
sys-libs/glibc:   2.22-r1::gentoo
Repositories:

gentoo
location: /usr/portage
sync-type: rsync
sync-uri: rsync://rsync.gentoo.org/gentoo-portage
priority: -1000
sync-rsync-extra-opts: --progress

hasufell
location: /var/lib/layman/hasufell
masters: gentoo
priority: 50





spike-community-overlay 




location: /var/lib/layman/spike-community-overlay
masters: gentoo
priority: 50

steam-overlay
location: /var/lib/layman/steam-overlay
masters: gentoo
priority: 50

wichtounet
location: /var/lib/layman/wichtounet
masters: gentoo
priority: 50

ABI="amd64"
ABI_X86="64 32"
ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="*"
ACCEPT_PROPERTIES="*"
ACCEPT_RESTRICT="*"
ADA_INCLUDE_PATH="/usr/lib64/gnat-gcc/x86_64-pc-linux-gnu/4.6/adainclude"
ADA_OBJECTS_PATH="/usr/lib64/gnat-gcc/x86_64-pc-linux-gnu/4.6/adalib"
ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci
emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0
intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci"
ANT_HOME="/usr/share/ant"
APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias
auth_basic authn_alias authn_anon authn_dbm authn_default authn_file
authz_dbm authz_default authz_groupfile authz_host authz_owner
authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir
disk_cache env expires ext_filter file_cache filter headers include info
log_config logio mem_cache mime mime_magic negotiation rewrite setenvif
speling status unique_id userdir usertrack vhost_alias"
ARCH="amd64"
AUTOCLEAN="yes"
BOOTSTRAP_USE="cxx unicode internal-glib python_targets_python3_4
python_targets_python2_7 multilib"
BROWSER="seamonkey"
CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon
braindump author"
CAMERAS="ptp2"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=native -pipe "
CFLAGS_amd64="-m64"
CFLAGS_x32="-mx32"
CFLAGS_x86="-m32"
CG_COMPILER_EXE="/opt/bin/cgc"
CG_INC_PATH="/opt/nvidia-cg-toolkit/include"
CG_LIB_PATH="/opt/nvidia-cg-toolkit/lib64:/opt/nvidia-cg-toolkit/lib32"
CHOST="x86_64-pc-linux-gnu"
CHOST_amd64="x86_64-pc-linux-gnu"
CHOST_x32="x86_64-pc-linux-gnux32"
CHOST_x86="i686-pc-linux-gnu"
CLEAN_DELAY="5"
COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog"
COLLISION_IGNORE="/lib/modules/* *.py[co] *$py.class */dropin.cache"
COLORFGBG="15;0"
CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc
/usr/share/config /usr/share/gnupg/qualified.txt
/usr/share/maven-bin-3.2/conf /usr/share/maven-bin-3.3/conf /var/lib/hsqldb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d
/etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release

Re: [gentoo-user] arp question

[lee]

Rich Freeman  writes:

> On Fri, Dec 25, 2015 at 9:00 PM, Adam Carter  wrote:
>>> grandstream.yagibdah.de (192.168.3.80) auf 00:0b:82:16:ed:9e [ether] auf
>>> enp2s0
>>> grandstream.yagibdah.de (192.168.3.80) auf 00:0b:82:16:ed:9e [ether] auf
>>> enp1s0
>>> spa.yagibdah.de (192.168.3.81) auf 88:75:56:07:44:c8 [ether] auf enp2s0
>>> spa.yagibdah.de (192.168.3.81) auf 88:75:56:07:44:c8 [ether] auf enp1s0
>>>
>>>
>>> enp2s0 is an interface dedicated to a PPPoE connection, and enp1s0
>>> connects to the LAN.
>>>
>>> IIUC, this is bound to cause problems.
>>>
>>> How is it possible for the wrong entries to be created, and what can I
>>> do to prevent them?
>>>
>>
>> arp mappings are untrusted so your machine will accept anything is sees on
>> the network. That's what makes MITM so easy on a connected subnet. What
>> makes you think they are wrong? Also, the output of ifconfig would be
>> helpful.
>
> I suspect those interfaces are getting bridged or something, but I'm
> not an expert on such things.

No physical interface is connected to the bridge interface, though
selected traffic from the devices can reach one of the VMs that are
connected to the bridge.

> If a given IP has a MAC on more than one interface, the interface the
> packets go out to is still controlled by the routing rules.  If the
> routing rule says that 1.1.1.1 is on eth0 it doesn't matter that eth0
> doesn't have an ARP entry and eth1 does - I believe it will just be
> undelivered or sent to the gateway for eth0 if it isn't on a local
> subnet for that interface.

There are no arp entries created for interfaces of the host.  No traffic
from the devices can make it to enp2s0.

> If you have some kind of routing loop it could actually make its way
> back to the interface on eth1.

The traffic would have to be routed back via enp2s0 from somewhere.
Since traffic from the devices doesn't go over enp2s0, it cannot be
routed back there.

> ARP doesn't come into play until the kernel goes to send something on
> an interface and determines it is on a subnet for that interface.

The devices are not on a subnet of the interface, hence no arp entries
for them should be created for that interface.

> Again, I'm not an expert in this and there could be some nuance to the
> rules that I'm missing.

Me neither ...  The devices are functional, though I can't tell if
traffic from or to them can be misdirected because of the arp entries
that shouldn't exist.  The devices might still work if some of their
traffic is misdirected, just not as well as they otherwise could.

Since they are VOIP devices, they are required to work well --- and the
VOIP quality is actually not good enough.  So I'm looking for possible
causes, and wrong arp entries might be one.

Re: [gentoo-user] arp question

[lee]

Adam Carter  writes:

>>
>> grandstream.yagibdah.de (192.168.3.80) auf 00:0b:82:16:ed:9e [ether] auf
>> enp2s0
>> grandstream.yagibdah.de (192.168.3.80) auf 00:0b:82:16:ed:9e [ether] auf
>> enp1s0
>> spa.yagibdah.de (192.168.3.81) auf 88:75:56:07:44:c8 [ether] auf enp2s0
>> spa.yagibdah.de (192.168.3.81) auf 88:75:56:07:44:c8 [ether] auf enp1s0
>>
>>
>> enp2s0 is an interface dedicated to a PPPoE connection, and enp1s0
>> connects to the LAN.
>>
>> IIUC, this is bound to cause problems.
>>
>> How is it possible for the wrong entries to be created, and what can I
>> do to prevent them?
>>
>>
> arp mappings are untrusted so your machine will accept anything is sees on
> the network. That's what makes MITM so easy on a connected subnet. What
> makes you think they are wrong?

They are wrong because there is no way for network traffic from the
devices on the LAN to make it to the interface enp2s0.  Or, if they do
make it there, then there is something else seriously wrong.

> Also, the output of ifconfig would be helpful.


,
| heimdali ~ # ifconfig -a
| br_dmz: flags=4419  mtu 1500
| inet 192.168.1.1  netmask 255.255.255.0  broadcast 192.168.1.255
| inet6 fe80::5cce:2bff:fedc:dce0  prefixlen 64  scopeid 0x20
| ether fe:18:b0:e9:78:47  txqueuelen 0  (Ethernet)
| RX packets 5124752  bytes 3554838408 (3.3 GiB)
| RX errors 0  dropped 0  overruns 0  frame 0
| TX packets 5080086  bytes 3508269156 (3.2 GiB)
| TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
| 
| enp1s0: flags=4163  mtu 1500
| inet 192.168.3.20  netmask 255.255.255.0  broadcast 192.168.3.255
| inet6 fe80::7aac:c0ff:fe3c:2dc8  prefixlen 64  scopeid 0x20
| ether 78:ac:c0:3c:2d:c8  txqueuelen 1000  (Ethernet)
| RX packets 998350  bytes 217325937 (207.2 MiB)
| RX errors 0  dropped 7332  overruns 0  frame 0
| TX packets 965281  bytes 274572349 (261.8 MiB)
| TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
| device interrupt 17  
| 
| enp2s0: flags=4163  mtu 1500
| inet 185.55.75.245  netmask 255.255.255.255  broadcast 185.55.75.245
| inet6 fe80::7aac:c0ff:fe3c:2dc9  prefixlen 64  scopeid 0x20
| ether 78:ac:c0:3c:2d:c9  txqueuelen 1000  (Ethernet)
| RX packets 5157535  bytes 4875664995 (4.5 GiB)
| RX errors 0  dropped 0  overruns 0  frame 0
| TX packets 3377329  bytes 413568759 (394.4 MiB)
| TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
| device interrupt 16  
| 
| lo: flags=73  mtu 65536
| inet 127.0.0.1  netmask 255.0.0.0
| inet6 ::1  prefixlen 128  scopeid 0x10
| loop  txqueuelen 0  (Lokale Schleife)
| RX packets 276299  bytes 78159006 (74.5 MiB)
| RX errors 0  dropped 0  overruns 0  frame 0
| TX packets 276299  bytes 78159006 (74.5 MiB)
| TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
| 
| ppp0: flags=4305  mtu 1492
| inet 185.55.75.245  netmask 255.255.255.255  destination 192.168.75.1
| ppp  txqueuelen 3  (Punkt-zu-Punkt Verbindung)
| RX packets 7250  bytes 3180943 (3.0 MiB)
| RX errors 0  dropped 0  overruns 0  frame 0
| TX packets 6123  bytes 711342 (694.6 KiB)
| TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
| 
| veth5CBR3D: flags=4163  mtu 1500
| inet6 fe80::fc18:b0ff:fee9:7847  prefixlen 64  scopeid 0x20
| ether fe:18:b0:e9:78:47  txqueuelen 1000  (Ethernet)
| RX packets 5077428  bytes 3616056439 (3.3 GiB)
| RX errors 0  dropped 0  overruns 0  frame 0
| TX packets 5031817  bytes 3495334672 (3.2 GiB)
| TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
| 
| vethYXJVKH: flags=4163  mtu 1500
| inet6 fe80::fcd0:65ff:fec5:7b44  prefixlen 64  scopeid 0x20
| ether fe:d0:65:c5:7b:44  txqueuelen 1000  (Ethernet)
| RX packets 47324  bytes 10528497 (10.0 MiB)
| RX errors 0  dropped 0  overruns 0  frame 0
| TX packets 48502  bytes 13062823 (12.4 MiB)
| TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
| 
| heimdali ~ # brctl show
| bridge name bridge id   STP enabled interfaces
| br_dmz  8000.fe18b0e97847   no  veth5CBR3D
| vethYXJVKH
| heimdali ~ # route -n
| Kernel IP Routentabelle
| ZielRouter  Genmask Flags Metric RefUse Iface
| 0.0.0.0 192.168.75.10.0.0.0 UG4005   00 ppp0
| 127.0.0.0   0.0.0.0 255.0.0.0   U 0  00 lo
| 192.168.1.0 0.0.0.0 

Re: [gentoo-user] Re: Gcc 5.3

[Paul Colquhoun]

On Sat, 26 Dec 2015 14:00:55 Paul Colquhoun wrote:
> On Fri, 25 Dec 2015 12:40:48 walt wrote:
> > On Thu, 24 Dec 2015 10:18:27 -0500
> > 
> > Alan Grimes  wrote:
> > > Hey, thanks for putting out gcc 5.3...
> > > 
> > > Unfortunately, it fails to bootstrap on my machine. I am getting
> > > differences between the stage 2 and stage 3 compilers and it's
> > > dying... =(
> > 
> > I'm waiting for 5.3.1 before I even try to install it on my main
> > desktop machine.  But I've installed it in a virtual gentoo ~amd64
> > machine, so I know that the failure you are seeing was introduced when
> > the 'jit' useflag was added to the gcc ebuild.
> > 
> > You can work around the failure by installing 5.3.0 with the -jit
> > useflag (which should succeed) and *then* switch to 5.3.0 using
> > gcc-config before re-installing 5.3.0 with +jit.
> > 
> > David mentioned that he succeeded by using gcc-4.9 but I had to use the
> > workaround I described above.
> 
> I disabled the 'jit' flag for gcc, and 5.3.0 compiled cleanly.
> 
> Now to turn the flag back on and see if that works.


Yes, using gcc-5.3.0 to recompile 5.3.0 with +jit worked.

Thanks.


-- 
Reverend Paul Colquhoun, ULC. http://andor.dropbear.id.au/
  Asking for technical help in newsgroups?  Read this first:
 http://catb.org/~esr/faqs/smart-questions.html#intro

[gentoo-user] Re: Gcc 5.3

[walt]

On Thu, 24 Dec 2015 10:18:27 -0500
Alan Grimes  wrote:

> Hey, thanks for putting out gcc 5.3...
> 
> Unfortunately, it fails to bootstrap on my machine. I am getting
> differences between the stage 2 and stage 3 compilers and it's
> dying... =(

I'm waiting for 5.3.1 before I even try to install it on my main
desktop machine.  But I've installed it in a virtual gentoo ~amd64
machine, so I know that the failure you are seeing was introduced when
the 'jit' useflag was added to the gcc ebuild.

You can work around the failure by installing 5.3.0 with the -jit
useflag (which should succeed) and *then* switch to 5.3.0 using
gcc-config before re-installing 5.3.0 with +jit.

David mentioned that he succeeded by using gcc-4.9 but I had to use the
workaround I described above.

Re: [gentoo-user] arp question

[Adam Carter]

>
> grandstream.yagibdah.de (192.168.3.80) auf 00:0b:82:16:ed:9e [ether] auf
> enp2s0
> grandstream.yagibdah.de (192.168.3.80) auf 00:0b:82:16:ed:9e [ether] auf
> enp1s0
> spa.yagibdah.de (192.168.3.81) auf 88:75:56:07:44:c8 [ether] auf enp2s0
> spa.yagibdah.de (192.168.3.81) auf 88:75:56:07:44:c8 [ether] auf enp1s0
>
>
> enp2s0 is an interface dedicated to a PPPoE connection, and enp1s0
> connects to the LAN.
>
> IIUC, this is bound to cause problems.
>
> How is it possible for the wrong entries to be created, and what can I
> do to prevent them?
>
>
arp mappings are untrusted so your machine will accept anything is sees on
the network. That's what makes MITM so easy on a connected subnet. What
makes you think they are wrong? Also, the output of ifconfig would be
helpful.

Re: [gentoo-user] arp question

[Adam Carter]

> Even after adding the static routes and creating firewall rules to drop
> all traffic from the devices to the internet, their arp entries continue
> to be renewed.  How is that possible?
>
>
Your iptables rules are IP based (layer 3), so will not match arp traffic
(layer 2)

Re: [gentoo-user] arp question

[Adam Carter]

> They are wrong because there is no way for network traffic from the
> devices on the LAN to make it to the interface enp2s0.  Or, if they do
> make it there, then there is something else seriously wrong.
>

tcpdump -i enp2s0 arp

will tell you if the arps are being generated from something on the wire
side. If there's not much traffic then clear the arp entry and ping the IP
address to generate traffic.


| heimdali ~ # route -n
> | Kernel IP Routentabelle
> | ZielRouter  Genmask Flags Metric RefUse
> Iface
> | 0.0.0.0 192.168.75.10.0.0.0 UG4005   00
> ppp0
> | 127.0.0.0   0.0.0.0 255.0.0.0   U 0  00
> lo
> | 192.168.1.0 0.0.0.0 255.255.255.0   U 0  00
> br_dmz
> | 192.168.3.0 0.0.0.0 255.255.255.0   U 0  00
> enp1s0
> | 192.168.3.800.0.0.0 255.255.255.255 UH0  00
> enp1s0
> | 192.168.3.810.0.0.0 255.255.255.255 UH0  00
> enp1s0
> | 192.168.75.10.0.0.0 255.255.255.255 UH0  00
> ppp0
> | heimdali ~ #
> `
>
> What it the purpose of the static host routes? The connected
192.168.3.0/24 route will take care of those hosts, so they shouldn't be
required.

What are enp1s0 and enp2s0 connected to? Same hub or same vlan on the
switch? If so they will both see all the layer 2 broadcast traffic from
each subnet.

Re: [gentoo-user] arp question

[Rich Freeman]

On Fri, Dec 25, 2015 at 9:00 PM, Adam Carter  wrote:
>> grandstream.yagibdah.de (192.168.3.80) auf 00:0b:82:16:ed:9e [ether] auf
>> enp2s0
>> grandstream.yagibdah.de (192.168.3.80) auf 00:0b:82:16:ed:9e [ether] auf
>> enp1s0
>> spa.yagibdah.de (192.168.3.81) auf 88:75:56:07:44:c8 [ether] auf enp2s0
>> spa.yagibdah.de (192.168.3.81) auf 88:75:56:07:44:c8 [ether] auf enp1s0
>>
>>
>> enp2s0 is an interface dedicated to a PPPoE connection, and enp1s0
>> connects to the LAN.
>>
>> IIUC, this is bound to cause problems.
>>
>> How is it possible for the wrong entries to be created, and what can I
>> do to prevent them?
>>
>
> arp mappings are untrusted so your machine will accept anything is sees on
> the network. That's what makes MITM so easy on a connected subnet. What
> makes you think they are wrong? Also, the output of ifconfig would be
> helpful.

I suspect those interfaces are getting bridged or something, but I'm
not an expert on such things.

If a given IP has a MAC on more than one interface, the interface the
packets go out to is still controlled by the routing rules.  If the
routing rule says that 1.1.1.1 is on eth0 it doesn't matter that eth0
doesn't have an ARP entry and eth1 does - I believe it will just be
undelivered or sent to the gateway for eth0 if it isn't on a local
subnet for that interface.  If you have some kind of routing loop it
could actually make its way back to the interface on eth1.  ARP
doesn't come into play until the kernel goes to send something on an
interface and determines it is on a subnet for that interface.  Again,
I'm not an expert in this and there could be some nuance to the rules
that I'm missing.

-- 
Rich

[gentoo-user] arp question

[lee]

Hi,

any idea why I have entries in the arp table like this:


grandstream.yagibdah.de (192.168.3.80) auf 00:0b:82:16:ed:9e [ether] auf enp2s0
grandstream.yagibdah.de (192.168.3.80) auf 00:0b:82:16:ed:9e [ether] auf enp1s0
spa.yagibdah.de (192.168.3.81) auf 88:75:56:07:44:c8 [ether] auf enp2s0
spa.yagibdah.de (192.168.3.81) auf 88:75:56:07:44:c8 [ether] auf enp1s0


enp2s0 is an interface dedicated to a PPPoE connection, and enp1s0
connects to the LAN.

IIUC, this is bound to cause problems.

How is it possible for the wrong entries to be created, and what can I
do to prevent them?

Re: [gentoo-user] Re: Gcc 5.3

[Paul Colquhoun]

On Fri, 25 Dec 2015 12:40:48 walt wrote:
> On Thu, 24 Dec 2015 10:18:27 -0500
> 
> Alan Grimes  wrote:
> > Hey, thanks for putting out gcc 5.3...
> > 
> > Unfortunately, it fails to bootstrap on my machine. I am getting
> > differences between the stage 2 and stage 3 compilers and it's
> > dying... =(
> 
> I'm waiting for 5.3.1 before I even try to install it on my main
> desktop machine.  But I've installed it in a virtual gentoo ~amd64
> machine, so I know that the failure you are seeing was introduced when
> the 'jit' useflag was added to the gcc ebuild.
> 
> You can work around the failure by installing 5.3.0 with the -jit
> useflag (which should succeed) and *then* switch to 5.3.0 using
> gcc-config before re-installing 5.3.0 with +jit.
> 
> David mentioned that he succeeded by using gcc-4.9 but I had to use the
> workaround I described above.


I disabled the 'jit' flag for gcc, and 5.3.0 compiled cleanly.

Now to turn the flag back on and see if that works.


-- 
Reverend Paul Colquhoun, ULC. http://andor.dropbear.id.au/
  Asking for technical help in newsgroups?  Read this first:
 http://catb.org/~esr/faqs/smart-questions.html#intro