| 06:20.32 | *** join/#elinux t0mmy (~tprrt@ram31-2-82-228-88-46.fbx.proxad.net) |
| 08:05.26 | *** join/#elinux t0mmy (~tprrt@217.114.201.133) |
| 11:14.37 | *** join/#elinux devnn (~devnn@mail.danelec-marine.com) |
| 11:15.02 | devnn | I set up eth1 with an IP to a switch, but traffik to that IP traffic comes in through eth0, not eth1 for some reason. Any clues how to debug this? dts: http://pastebin.com/WcEcNyAC ifconfig: http://pastebin.com/nVDmm9ZM |
| 11:21.30 | gustavoz | well both interfaces have the same subnet/mask so i'd bet your route(s) are the problem |
| 11:21.40 | gustavoz | also the dts has nothing to do with routing |
| 11:23.54 | devnn | gustavoz: I thought there might have been an error in the dts with regards to eth1 not having its own PHY, thus borking things and maybe using the PHY on eth0 in some weird way. |
| 11:24.14 | gustavoz | devnn: no, most likely your default gateway is assigned to eth0 |
| 11:25.12 | devnn | gustavoz: isn't this is for outgoing traffic only? |
| 11:26.14 | devnn | route: http://pastebin.com/Tt9aMeT3 |
| 11:28.13 | gustavoz | devnn: normally yes, incoming traffic is determined by the ip |
| 11:29.17 | gustavoz | devnn: that means if eth0 is "first" in line it will speak to other devices in the network with that ip, hence devices will answer to eth0 ip, unless they initiate connection to eth1 ip |
| 11:30.01 | devnn | gustavoz: the problem is that a tcpdump on eth0 shows pings oto the IP on eth1. tcpdump on eth1 shows nothing. |
| 11:30.33 | gustavoz | devnn: the kernel won't wire-route things that can be routed internally, for example traffic from eth0<->eth1 IPs |
| 11:31.02 | gustavoz | they're both on the same subnet and local with the same weight |
| 11:31.17 | devnn | gustavoz: I'm pinging from an another machine. |
| 11:32.24 | gustavoz | devnn: and which IP? |
| 11:32.24 | devnn | gustavoz: apparently this is frustrating me so much that my spelling goes to crap. sorry about that. |
| 11:32.43 | devnn | gustavoz: 10.15.0.95 |
| 11:34.17 | devnn | gustavoz: also eth1 shows no RX packets ever in ifconfig. Looks a bit fishy. |
| 11:35.22 | devnn | gustavoz: wait: I got on eth1: RX packets:793 errors:793 dropped:793 |
| 11:37.59 | gustavoz | devnn: is the interface working? |
| 11:38.34 | gustavoz | i.e. got link and all |
| 11:43.10 | devnn | gustavoz: eth1 says link when I bring it up with ifconfig. It is linked to a switch (dsa). When plugging cables in an out of the switch I get link updates on lanX ifaces. eth1 should be matched with the 'cpu' port of the switch. |
| 11:44.10 | devnn | gustavoz: I don't get RX packets on the lanX ifaces, so this is a problem too, but I figured that eth0 should not accept eth1's packets, for starters. |
| 11:46.30 | devnn | gustavoz: tbh, I'm not even sure if eth1 should have an IP, as a link mcu<->switch. lan1-4 ifaces are the ones that need to work. Maybe this is what is causing problems? |
| 11:48.38 | gustavoz | devnn: well apparently eth1 is connected to a switch, so having an ip on eth1 itself makes no sense |
| 12:12.10 | devnn | gustavoz: yeah, I'll remove it and see how it goes, but I'm still worried about the 0 RX packets on the lan ifaces. |
| 12:13.39 | gustavoz | devnn: normally for the internal-switch wired eth interfaces the link will always be up |
| 12:14.53 | devnn | gustavoz: mine is not up automatically, but it may be due to it not having a valid MAC addr. When it set it manually, I can bring it up afterwards. |
| 12:15.32 | gustavoz | devnn: i mean eth1, if you up the interface the link is always present since it's wired to the internal switch (the one that provides the lan* interfaces) |
| 12:17.10 | devnn | gustavoz: jep. it says 'up' also. there no problem there. I'll try to get traffic throug the lan ifaces without giving eth1 an ip. |
| 12:20.48 | devnn | gustavoz: ok, now I get a similar error to before. No ip on eth1. Ping on lan1-4 goes through eth0. If I unplug all cables from the switch, I can still ping all lan ifaces through eth0. Is this some kinde of routing problem, or is there something completely borked with the dsa setup? |
| 12:22.12 | gustavoz | devnn: what's the base os/firmware based on? because eth numbers may be renamed between what dts says and what linux says |
| 12:22.21 | devnn | lan1-4 says link up/down when plugging the cables, so that part is working. But no RX packets on the lan, everything goes to eth0. |
| 12:22.46 | gustavoz | also try bringing down eth0 |
| 12:23.01 | gustavoz | that way you'll discard any routing funkyness |
| 12:23.41 | devnn | gustavoz: I fetched a brand new 4.2.3 from kernel.org to get the lastest driver for the 88E6350R switch. |
| 12:23.59 | devnn | gustavoz: good idea, I'll try that. |
| 12:24.32 | devnn | os is Linux, obviously. |
| 12:31.10 | devnn | gustavoz: new interesting behaviour: boot, eth0 up, lan1-4 up. eth0 responds for all ifaces. Taking eth0 down, nothing responds anymore. Bringing eth0 back up, still nothing responds, not even eth0 ip. |
| 12:31.49 | devnn | gustavoz: eth0 is now at the buttom of the routing table, but does that mean anything? |
| 12:31.59 | *** join/#elinux diego_r (~diego@host65-246-static.10-188-b.business.telecomitalia.it) |
| 12:32.54 | gustavoz | devnn: yes, since all of the interfaces (trunk eth* ones and switched lan* ones) are on the same subnet/mask routing order does matter (they're all the same weight) |
| 12:33.30 | devnn | gustavoz: taking all lan ifaces down make eth0 respond again |
| 12:34.39 | gustavoz | devnn: normally the "virtual" interfaces (lan* via switch) need some extra config in the form of vlan tags to work properly, that's why i asked which os you're using (i know you're using a linux kernel, what i ask is what distribution/build tool/firmware/etc) |
| 12:34.57 | devnn | gustavoz: I'm a bit worried that I don't see any HW traffic on the lan ifaces (ifconfig). Are these numbers after routing? |
| 12:35.48 | devnn | gustavoz: ah, the rootfs is build through ptxdist. I then manually build a newer kernel. |
| 12:37.41 | devnn | gustavoz: I read saw something like this mentioned in the dsa docs. Was not sure if the meant I had to do anything, like enabling vlan support in the kernel. Figured the drive dependencies would have taken care of this. |
| 12:38.17 | gustavoz | devnn: VLANs are a software thing that's up to you, like ipv6, sctp or other networking support |
| 12:38.54 | gustavoz | devnn: in kernel options it's CONFIG_VLAN_8021Q, you'll also need the vconfig tool |
| 12:39.24 | gustavoz | (busybox has it if it's enabled) |
| 12:40.17 | devnn | gustavoz: yes, but internally, tagged packets from lan ifaces to eth1, isn't this completely taken cared of by drivers? |
| 12:41.01 | devnn | gustavoz: vlan is not enabled in my kernel. |
| 12:41.17 | gustavoz | devnn: that depends on the default setup for the switch |
| 12:41.33 | devnn | gustavoz: can rebuild with this option, but not sure what to do from there |
| 12:42.41 | gustavoz | devnn: in general terms you say "eth1 has tags 1,2,3,4" and "lan1 has tag1", "lan2 has tag2" and so on |
| 12:42.51 | devnn | gustavoz: and still, shouldn't I see to RX packets on the ifaces, gardless of internal VLAN not being setup propperly? |
| 12:43.02 | gustavoz | devnn: hence eth1 is the connection for all of the lan ports but they don't see traffic between them |
| 12:43.10 | devnn | gustavoz: that makes good sense. |
| 12:43.51 | gustavoz | devnn: vlan tagging is done at the switch level, what default it has is up to the driver/hardware, so if eth1 isn't tagging then they'll just be isolated |
| 12:45.36 | devnn | gustavoz: ok, but I read RX packets as physical ethernet traffic that should count something regardless of content. Is this a wrong assumption? |
| 12:46.32 | gustavoz | devnn: you should see incoming lanX traffic in eth1 normally, however the kernel will dump it as invalid frames if it doesn't understand 802.1q |
| 12:47.00 | gustavoz | https://en.wikipedia.org/wiki/IEEE_802.1Q |
| 12:47.49 | devnn | gustavoz: ok. I like the down-top approach, so I'm just looking for sign of life at the lowest levels. I loading a new kernel now. |
| 12:51.13 | devnn | gustavoz: The lan iface don't receive vlan tagged packets, but I guess if the RX packet statistics are done by the kernel, they would remain 0. I just thought those numbers came from the actual phys on the switch, regardless of what the kernel thinks of it. |
| 12:52.18 | devnn | gustavoz: not sure I have the vlan tools, checking up on that. |
| 12:56.22 | devnn | gustavoz: ok, got the kernel with VLAN support now. The behaviour is exactly the same as before. Will look into vlan setup. Any ideas to see quickly if any of the lan ifaces work, before going through tons of doc? |
| 12:56.28 | gustavoz | devnn: PHYs are pretty dumb, they normally don't understand any protocol other than physical negotiation |
| 12:57.11 | devnn | gustavoz: makes sense, I assumed too much. |
| 13:01.09 | devnn | gustavoz: I found a VLAN setup on another HW using this dist, I can probably use some of that. |
| 13:10.24 | devnn | gustavoz: ok, I've set up the VLAN eth1 to lan1 as this: http://pastebin.com/0zUf3w8x (ifconfig). Still got all traffic to eth0 and no RX on lan1. Do you know what could be missing? |
| 13:12.40 | devnn | hmm eth1 is dropping packets for some reason. |
| 13:22.33 | devnn | gustavoz: got a breakthrough. eth1 packets drops are only increasing when theres a cable in lan1, so it seems they come from there. I'll investigate how to debug dropped packets, but there seems to be hope now. |
| 14:43.06 | *** join/#elinux darkschneider (~gab@93-32-59-44.ip32.fastwebnet.it) |
| 17:51.42 | *** join/#elinux gustavoz (~gustavoz@186.22.136.136) |
| 18:13.06 | *** join/#elinux t0mmy_ (~tprrt@ram31-2-82-228-88-46.fbx.proxad.net) |