Greetings. Up until very recently I was using a patch called ethalias to provide virtual ethernet ports on my setup, however ethalias has become unmaintained (indeed I patched the patch to bring it forward to 2.6.27) - When I emailed the original author he suggested I look at macvlan as a suitable replacement. I have followed his suggestion however, macvlan doesn't appear to behave the same as ethalias did -------------------- ~# uname -a Linux gw 2.6.27-gentoo-r7 #7 Tue Jan 27 23:13:16 UTC 2009 i586 unknown -------------------- I tested two setups - the first being my preferred and based exactly on my old ethalias setup. -------------------- ip link set eth0 up ip link set ath0 up brctl addbr br0 brctl addif br0 eth0 brctl addif br0 ath0 ip link set br0 up ip link add link eth0 address F0:0B:AA:00:00:00 eth0v0 type macvlan ip link add link eth0 address F0:0B:AA:00:00:01 eth0v1 type macvlan ip link set eth0v0 up ip link set eth0v1 up -------------------- In summary - bridge eth0 to ath0 and add two virtual ethernet ports to eth0 The second setup was just to test without the bridging -------------------- ip link set eth0 up ip link add link eth0 address F0:0B:AA:00:00:00 eth0v0 type macvlan ip link add link eth0 address F0:0B:AA:00:00:01 eth0v1 type macvlan ip link set eth0v0 up ip link set eth0v1 up -------------------- Essentially the same as the first one, just no bridge. My problem is, the virtual ports in the first setup aren't doing PPPoE properly (or as expected). Here are my tests for macvlan (in brackets the outcome for ethalias). All tcpdump output was obtained with "tcpdump -i eth0 -s 0 -e not ip and not arp" and is included mostly to show that the traffic was correctly sent and received on the root interface. "success" being returns an access concentrator to the console, "fail" being times out # pppoe-discovery -I eth0v0 - fail (ethalias: success) 18:48:15.735467 f0:0b:aa:00:00:00 (oui Unknown) > Broadcast, ethertype PPPoE D (0x8863), length 24: PPPoE PADI [Service-Name] 18:48:15.754201 00:90:1a:a0:70:45 (oui Unknown) > f0:0b:aa:00:00:00 (oui Unknown), ethertype PPPoE D (0x8863), length 61: PPPoE PADO [AC-Name "qlz3-lutwyche"] [Service-Name] [AC-Cookie 0x54EF2CC5C073FF859DB31A112B95E5AE] # pppoe-discovery -I eth0 - fail (ethalias: fail) 18:47:33.726173 00:0d:b9:00:d8:cc (oui Unknown) > Broadcast, ethertype PPPoE D (0x8863), length 24: PPPoE PADI [Service-Name] 18:47:33.745275 00:90:1a:a0:70:45 (oui Unknown) > 00:0d:b9:00:d8:cc (oui Unknown), ethertype PPPoE D (0x8863), length 61: PPPoE PADO [AC-Name "qlz3-lutwyche"] [Service-Name] [AC-Cookie 0x146E080BCC01CD2B0307BA380D89A630] # pppoe-discovery -I br0 - success (ethalias: success) 18:48:46.779337 00:0b:6b:34:b0:c5 (oui Unknown) > Broadcast, ethertype PPPoE D (0x8863), length 24: PPPoE PADI [Service-Name] 18:48:46.797455 00:90:1a:a0:70:45 (oui Unknown) > 00:0b:6b:34:b0:c5 (oui Unknown), ethertype PPPoE D (0x8863), length 61: PPPoE PADO [AC-Name "qlz3-lutwyche"] [Service-Name] [AC-Cookie 0x7EBF90B6B5268E50357B2FF706C02FF5] So as you can see, the important test (first one) fails, where it "should" succeed. The results of the second test are mostly academic, just to test that I hadn't messed up the whole macvlan creation bit. # pppoe-discovery -I eth0v0 - success 18:52:28.504271 f0:0b:aa:00:00:00 (oui Unknown) > Broadcast, ethertype PPPoE D (0x8863), length 24: PPPoE PADI [Service-Name] 18:52:28.522121 00:90:1a:a0:70:45 (oui Unknown) > f0:0b:aa:00:00:00 (oui Unknown), ethertype PPPoE D (0x8863), length 61: PPPoE PADO [AC-Name "qlz3-lutwyche"] [Service-Name] [AC-Cookie 0x54EF2CC5C073FF859DB31A112B95E5AE] # pppoe-discovery -I eth0</b> - success 18:51:38.800524 00:0d:b9:00:d8:cc (oui Unknown) > Broadcast, ethertype PPPoE D (0x8863), length 24: PPPoE PADI [Service-Name] 18:51:38.818589 00:90:1a:a0:70:45 (oui Unknown) > 00:0d:b9:00:d8:cc (oui Unknown), ethertype PPPoE D (0x8863), length 61: PPPoE PADO [AC-Name "qlz3-lutwyche"] [Service-Name] [AC-Cookie 0x146E080BCC01CD2B0307BA380D89A630] Any ideas on what's going wrong? and more importantly how to fix it without adding a second interface and using the second test case (bridging the wireless to eth1)? - only solution I could come up with - as it's a fixed hardware platform. Cheers Shannon. -- To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
