Re: [gentoo-user] /usr/bin/python: no supported Python implementation variant found!

[Urs Schütz]

On 12/26/15 13:31, cov...@ccs.covici.com wrote:

Hi.  I am doing my world update, and although it has noe finished, I am
now getting the message in the subject line if I try to execute any
python script!  I found a gentoo topic which said to emerge python-exec,
but it has already done so in the update, and no joy.

Thanks in advance for any ideas.



Please post the output of
eselect python list

Re: [gentoo-user] arp question

[Rich Freeman]

On Sat, Dec 26, 2015 at 9:14 AM, lee  wrote:
>
> They are connected to different vlans on the same switch, so they don't
> share the same broadcast domain.  The switch shows the mac addresses of
> the phones only in the expected vlan.
>

Out of curiosity, have you tried actually sending a broadcast on the
VLAN to verify that it actually is implemented correctly?  If your
switch is mixing ARP across VLANs that would explain this behavior.

I've never messed with VLAN on linux but I'd think that you could
probably implement VLAN in software and actually save yourself a
physical network interface as well (both interfaces could go out over
the same wire and be handled appropriately by the switch).

-- 
Rich

Re: [gentoo-user] /usr/bin/python: no supported Python implementation variant found!

[covici]

Urs Schütz  wrote:

> On 12/26/15 13:31, cov...@ccs.covici.com wrote:
> > Hi.  I am doing my world update, and although it has noe finished, I am
> > now getting the message in the subject line if I try to execute any
> > python script!  I found a gentoo topic which said to emerge python-exec,
> > but it has already done so in the update, and no joy.
> >
> > Thanks in advance for any ideas.
> >
> 
> Please post the output of
> eselect python list

hmmm, its back now, I have no clue, it came back by itself without me
doing anything -- very odd.


-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici
 cov...@ccs.covici.com

[gentoo-user] Re: arp question

[James]

lee  yagibdah.de> writes:


> >> 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.


Absolutely. ARP has been around a very long time (rfc 826). There are
thousands of code snippets out there that contain 'arp chatter'; many are
benign,  some are still useful, other are parts of sploits. *usually* after
an extensive search, the source of the chatter is very sporadic and found in
a product from a vendor. In the early days, many vendors used codes from a
variety of sources to get their products to work with a variety of other
devices that supported 'ethernet'.

Unfortunately many companies put these codes into mal-form 'ip stacks'
in products with embedded controllers. The turn over of corporate coding
staff has resulted in many of the these code snippets remaining because 'the
new guy' with full stack responsibility did not want to mess with parts of
other folks codes. This situation varies widely and is a mild problem from
big name gear (starts with a C) to the little vendors.

As a consultant, it's a source of billable hours for those that can find the
source (very common with industrial ethernet based control systems).
It is an unmanaged irritant that mostly goes ignored from overworked coders
at various vendor corps running their 'own ip stack'.

And again your source(s) of nefarious arp issues many have no relationship
at all to these 'arp quirks' I have characterised.

> > 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.
> Yes, I already tried that and didn't get any traffic listed.


For me, it usually takes a while to find these 'buggers' as most are
vendor vestibules in my experience.


good hunting,
James

Re: [gentoo-user] Re: Gcc 5.3

[David Haller]

Hello,

On Fri, 25 Dec 2015, 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... =(
[..]
>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.

# eix sys-devel/gcc$
[..]
Installed versions: 
4.9.3(4.9)^s{tbz2}(18:19:02 23/10/15)(cilk cxx doc fortran gcj
graphite multilib nls nptl objc objc++ objc-gc openmp sanitize
-altivec -awt -debug -fixed-point -go -hardened -libssp -multislot
-nopie -nossp -regression-test -vanilla)
5.3.0(5)^s{tbz2}(20:14:23 24/12/15)(cilk cxx doc fortran gcj graphite
multilib nls nptl objc objc++ objc-gc openmp sanitize -altivec -awt
-debug -fixed-point -go -hardened -jit -libssp -multislot -nopie
-nossp -regression-test -vanilla)
  
# gcc-config -l
 [1] x86_64-pc-linux-gnu-4.9.3 *
 [2] x86_64-pc-linux-gnu-5.3.0

No wonder I didn't stumble on that ... ;)

-dnh

-- 
The steady state of disks is full.-- Ken Thompson

Re: [gentoo-user] arp question

[lee]

Adam Carter  writes:

>> 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.

Yes, I already tried that and didn't get any traffic listed.

> | 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.

They shouldn't be needed.  I added them manually only to see if it would
make a difference.

> 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.

They are connected to different vlans on the same switch, so they don't
share the same broadcast domain.  The switch shows the mac addresses of
the phones only in the expected vlan.


Even when enp2s0 is not connected to the switch but directly to the wire
the PPPoE connection comes from, the arp entries are updated.

Having that said, there's one more test I can make: disconnect enp2s0
entirely and see if the arp entries still persist.


As to the other reply: The firewall is IP based, and what reason and
what way would any traffic have to go from a device on the LAN to an
interface that is not connected to the LAN but to the internet, and on a
different network than the LAN, when all IP traffic from the device to
the internet is being dropped?

The firewall doesn't know enp2s0 but ppp0.  But still, I don't see how
these arp entries could appear on enp2s0, yet they do.


On a side note: I've verified that VOIP quality issues do not come from
anything on the LAN (by playing music to the phones and making internal
phone calls) but from the rather poor internet connection.  So at least
the wrong arp entries don't interfere with VOIP.

[gentoo-user] /usr/bin/python: no supported Python implementation variant found!

[covici]

Hi.  I am doing my world update, and although it has noe finished, I am
now getting the message in the subject line if I try to execute any
python script!  I found a gentoo topic which said to emerge python-exec,
but it has already done so in the update, and no joy.

Thanks in advance for any ideas.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici
 cov...@ccs.covici.com

Re: [gentoo-user] Re: Gcc 5.3

[Philip Webb]

151225 walt wrote:
> 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.

So this is one of the  50 %  cases where  USE="-* ... "  helps (smile).

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca

Re: [gentoo-user] arp question

[Adam Carter]

> Yes, I already tried that and didn't get any traffic listed.
>

In that case it sounds like linux has bridged them across from the other
interface. Does this find anything?
tcpdump -i enp2s0 net 192.168.1.0/24

If it doesn't maybe generate some layer2 broadcast traffic on enp1s0 to see
if you can see that traffic in the tcpdump on enp2s0. Something like;
echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
ping 192.168.1.255

After the test is done turn it back on with;
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

I've never bridged with linux. Bridging is usually a bad option - if you
can I suggest you move to a routed and/or NATed solution. Clean and simple
is best.