| === tarman is now known as zyga | ||
| rtg | tyhicks, I assume jjohansen has enough context to proceed on the 3 apparmor bugs you filed. there isn't a lot of detail in them about kernel versions, etc. | 13:40 |
|---|---|---|
| tyhicks | rtg: he knows the details but I'll go ahead and add some more info so everyone else won't be in the dark | 14:00 |
| rtg | tyhicks, thanks | 14:00 |
| chiluk | rtg apw can you take a look at bug 1124250 | 15:17 |
| ubot5 | bug 1124250 in linux (Ubuntu) "Partially incorrect uid mapping with nfs4/idmapd/ldap-auth" [Low,Confirmed] https://launchpad.net/bugs/1124250 | 15:17 |
| chiluk | basically organizations with large numbers of users are quickly hitting the limits. | 15:17 |
| === bladernr_ is now known as bladernr_30kFeet | ||
| apw | apb1963, is that source address remote? ie it has been forwarded by one of your routers ? | 16:37 |
| apb1963 | apw: I have an ssh connection to each machine from .12, that sits in place all day | 16:38 |
| apb1963 | apw: including 2xx.1xx.2xx.xx4 | 16:39 |
| apb1963 | apw: It is not local, it is remote. | 16:39 |
| apb1963 | apw: So yes, it's forwarded by way of the ssh port. | 16:40 |
| apb1963 | apw: Does that answer the question? | 16:40 |
| apw | apb1963, i think i understand, so the router you loose from .12 is none of the other machines you control | 16:41 |
| apb1963 | apw: umm.... what? | 16:41 |
| apb1963 | apw: the router is at .1 | 16:41 |
| apw | apb1963, the .12 machine looses the router, the router is which it cannot speak to any more is none of the others mentioned, it is a 4th thing | 16:42 |
| apb1963 | apw: I control all the machines/devices | 16:42 |
| apb1963 | apw: correct. It's at .1 | 16:42 |
| apb1963 | apw: and of course has an outward facing IP address from my ISP | 16:43 |
| apw | apb1963, does .12 get its address via dhcp ? | 16:43 |
| apb1963 | apw: No. Static address. | 16:43 |
| apw | apb1963, well i guess we need to figure out what the state of .12 is when this occurs, ie take like an ifconfig -a and ip route while its working and compare that to when it stops | 16:44 |
| apb1963 | apw: the route _appears_ fine in the route table | 16:45 |
| apb1963 | apw: and the interface maintains its IP address | 16:46 |
| apb1963 | apw: is that what you're asking? | 16:46 |
| apw | apb1963, indeed, and i assume the .12 and the other local machine and .1 are all on a simple switch together ? | 16:46 |
| apb1963 | apw: connected via the router | 16:47 |
| apw | so it is going to be hard to tell if .12 is actually transmitting | 16:47 |
| apw | other than on the router lights, i guess | 16:47 |
| apw | i am not sure i expect an ifdown ifup to really reset the interface | 16:48 |
| apw | at the mac level | 16:48 |
| apb1963 | I'm not sure what you mean by transmitting exactly. I do not know if the interface gets reset at the mac level... I know what the mac is, but I'm not quite sure what resetting at the mac level is.... other than hardware? | 16:49 |
| apw | i note you say that if you ifdown ifup "and i readd the default route" that sounds unusual, that the default route is not part of that configuration | 16:49 |
| apw | yes at the h/w levle | 16:49 |
| apb1963 | oh crap.... that's wrong. I meant ifconfig up/down | 16:49 |
| apb1963 | sorry about that | 16:50 |
| apb1963 | ifup/down didn't do the trick. | 16:51 |
| apb1963 | apw: I presume that changes things? | 16:52 |
| apw | apb1963, not sure to be fair | 16:53 |
| apb1963 | ok :) | 16:54 |
| apb1963 | apw: Let me know if you think of something please | 16:54 |
| === ev__ is now known as ev | ||
| infinity | apb1963: ifconfig down/up will usually hard reset the MAC (well, depending on driver), so you could be dealing with a firmware bug, or even something external to your machine (bad switch port, switch that just needs a long power cycle to cleanse a corrupt mac cache, etc). | 17:09 |
| apb1963 | infinity: it's an atheros9k chipset, but it uses the generic driver for whatever reason... I don't know how to validate whether the mac is reset. Firmware bug in what - the router? The other machine on the LAN doesn't lose connectivity to the router. | 17:14 |
| infinity | apb1963: No, the NIC. | 17:14 |
| infinity | apb1963: Also, atk9k, so this is wireless, not wired? | 17:15 |
| infinity | I missed that bit of info. | 17:15 |
| infinity | ath9k, even. | 17:15 |
| apb1963 | It take it back.. it does use the ath9k driver | 17:15 |
| apb1963 | correct, wireless. | 17:15 |
| infinity | So, that pretty much puts all the blame back on the local machine. | 17:16 |
| infinity | Firmware or driver. | 17:16 |
| apb1963 | configuration: broadcast=yes driver=ath9k driverversion=3.2.0-67-generic-pae firmware=N/A ip=192.168.0.12 latency=0 multicast=yes wireless=IEEE 802.11bgn | 17:16 |
| apb1963 | apparently it has no firmware :/ | 17:16 |
| infinity | It's possible sforshee may have some insight. I have some ath9k devices that stop working after a suspend/resume cycle, but nothing that just randomly stops working. | 17:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!