| rsalveti | apw: opened bug 1597573 and bug 1597574 for amd overdrive, including the patches | 05:24 |
|---|---|---|
| ubot5 | bug 1597573 in linux (Ubuntu Yakkety) "Network installer fails to detect network on AMD Overdrive (ARM64)" [Undecided,Confirmed] https://launchpad.net/bugs/1597573 | 05:24 |
| ubot5 | bug 1597574 in linux (Ubuntu Yakkety) "Config: missing AMD Seattle platform support" [Undecided,Confirmed] https://launchpad.net/bugs/1597574 | 05:24 |
| rsalveti | still testing if something else is still missing | 05:25 |
| === eichiro_ is now known as eichiro | ||
| === davmor2_ is now known as davmor2 | ||
| === zyga_ is now known as zyga | ||
| === kloeri_ is now known as kloeri | ||
| === PaulW2U_ is now known as PaulW2U | ||
| lamont | 4.4.0-24-generic kernel (xenial), trying to talk ipv6 through a firewall running 3.13.0-91-generic (trusty), and it unearths issues with ipv6 neighbor discovery?? http://paste.ubuntu.com/18170606/ (on the firewall, I see the icmp6 echo reply come in, which tells me that's why were doing neighbor solicitation) the trace is from the xenial host | 14:13 |
| lamont | apw: ^^ was it you who said you saw something similar? | 14:13 |
| lamont | and with ipv6 hurting, google is not talking to me. | 14:14 |
| apw | i have been seeing some oddness, but it all seems to have gone happier for me recently | 14:14 |
| lamont | just don't reboot the firewall.... | 14:14 |
| apw | my firewall is not ubuntu so i won't see that any more | 14:15 |
| lamont | ah.. this is one that happens to me everytime I reboot the (trusty) firewall, and then it's broken until I start really poking at it to debug it, and then it starts working for reasons unknown until I reboot again | 14:28 |
| lamont | apw: neighbor discovery, the last 4 of the ff02:: address have bit 3 flipped? | 14:29 |
| apw | i am not sure what the algoithm for workgin out the multicast group to broadcast at is | 14:32 |
| === `jpg_ is now known as `jpg | ||
| apw | lamont, no that is correct, you just happen to have fexx:yyyy as your address, but the multicast group addres is :ffxx:yyyy | 14:35 |
| apw | it is only dropping in three octets worth | 14:36 |
| apw | Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX | 14:36 |
| lamont | ah, ok | 14:39 |
| lamont | 'twas a headscratcher there. | 14:39 |
| apw | lamont, had me going for a bit there, especially as you have to follow through like 3 rfcs to find the info | 14:39 |
| lamont | inet6 2601:282:8100:3500:24c:40ff:fe1a:c570/64 scope global mngtmpaddr dynamic | 14:55 |
| lamont | valid_lft 299sec preferred_lft 119sec | 14:55 |
| lamont | apw: ^^ fwiw, that's the addres line on the host that's ignoring the solicitations | 14:56 |
| apw | where are these solicitations passing to from ? | 14:56 |
| apw | you are implying they are through the firewall i think ? | 14:57 |
| lamont | apw: the firewall is attempting to solicit the host, so that it can send the icmp6 echo reply | 15:00 |
| lamont | you ready for how to fix it? | 15:00 |
| lamont | on the affected host: ip link set promisc on dev br0; sleep 1; ip link set promisc off dev br0 | 15:00 |
| lamont | which is to say, 4.4.0-24-generic (and others, sooo many others) are sometimes failing to correctly set a multicast address on the nic | 15:01 |
| lamont | 04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection | 15:01 |
| apw | hrm, how can you tell whether the multi-cast address is set ? | 15:01 |
| lamont | damn fine question there | 15:02 |
| apw | i wonder if ethtool can tell | 15:02 |
| lamont | http://paste.ubuntu.com/18173670/ | 15:02 |
| lamont | of note: br0 is a bridge containing the eth0.2 interface | 15:03 |
| lamont | presumably this would be a bug to file against the linux ubuntu source package? | 15:03 |
| apw | yeah i guess so | 15:04 |
| === caribou_ is now known as caribou | ||
| lamont | it also fails on another box which has br0 ontaining eth0 | 15:05 |
| apw | interesting, that must be the trigger somehow | 15:06 |
| lamont | Setting the bridge to promisc and turning it back off works around the issue. | 15:11 |
| lamont | Tcpdump on the underlying eth0.2 does not. | 15:11 |
| apw | lamont, lets get allllll that in a bug | 15:12 |
| lamont | yep | 15:13 |
| lamont | that was cut-n-waste from my bug window | 15:13 |
| lamont | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1597806 <-- apw | 15:17 |
| ubot5 | Launchpad bug 1597806 in linux (Ubuntu) "ipv6 neighbor discovery broken (on a bridge)" [Undecided,New] | 15:17 |
| lamont | apw: for additional hilarity, I have some windows 10 users on the network, who also experience the issue | 15:18 |
| apw | sounds liek the same problem | 15:23 |
| lamont | yep | 15:24 |
| lamont | win 8.1 aparently, not 10 | 15:25 |
| apw | lamont, https://www.v13.gr/blog/?p=378 i wonder if this helps any ... tl;dr disable igmp snooping on the bridge | 15:30 |
| lamont | ip neigh <-- TIL | 15:31 |
| lamont | cat /sys/devices/virtual/net/br0/bridge/multicast_snooping | 15:31 |
| lamont | 1 | 15:31 |
| lamont | iface br0:ipv6 inet6 auto | 15:32 |
| lamont | up ip addr add fe80::2/64 dev $IFACE | 15:32 |
| lamont | up ip addr add fdd7:308c:d9cf::20/64 dev $IFACE | 15:32 |
| lamont | down ip addr del fe80::2/64 dev $IFACE | 15:32 |
| lamont | ^^ my eni | 15:32 |
| apw | if tis reproducible, itmight be good to try turning her off | 15:32 |
| lamont | apw: and if it fixes it, it would be likely a good thing to JFD in the kernel... | 15:38 |
| apw | lamont, right ... and it is a good starting point to understand as well | 15:44 |
| lamont | comment added | 15:45 |
| lamont | apw: bug updated | 15:46 |
| apw | lamont, nice, is that definitaive proof that helps then, or do we need to wait a bit for confirmation | 15:47 |
| lamont | positively fixes the issue | 15:48 |
| lamont | what's missing from the comment is that the ping started working once the neighbor advertisement hit | 15:48 |
| lamont | (duh) | 15:48 |
| apw | cool. then we need to decide if we just turn that off by default on bridges | 15:48 |
| lamont | I would recommend either turning that off, or ipv6 off. :p | 15:49 |
| apw | :) | 15:49 |
| lamont | just sayin' | 15:49 |
| lamont | apw: I think actually, the preferred answer is (c) make multicast_snooping not break neighbor discovery | 19:09 |
| lamont | I suspect it's just nomming on too much | 19:10 |
| === ben_r_ is now known as ben_r | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!