VLAN woes (by alaric)
So I got daapd announcing itself on the wifi vlan, and excitedly rushed down to tell Sarah that she could now play my music collection from her laptop with iTunes; I brought up the listing, and started a track playing - but it cut out after a few tens of seconds.
"I know what that means," I said; "it means I need to sort out that MTU problem." You see, since 802.1Q involves adding an extra vlan ID to every frame sent, you have to either use slightly larger frames (which not all network cards support) or use a lower MTU (1496 rather than 1500), shaving off user data payload to make room for the vlan ID. Since my vr network interface on the server didn't support bigger frames, the MTU had to be reduced - a change that would have to be made on all the other machines on the local networks, lest they send it a packet too large for it to consume.
So I edited my dhcpd.conf to read:
option interface-mtu 1496;
But it turns out that Mac OS X has no interest in this option, and takes no notice of it. Ok.
So, knowing that she rarely reboots her machine and that I have a stack of fxp network cards in the garage that can support large frames, that I could install one of when I get round to it, I manually told Sarah's laptop to use the smaller MTU on the wireless interface:
ifconfig en1 mtu 1496
However, this did not fix the problem. DAAP still gave up after playing 30 seconds or so of any given song. SMB file sharing worked, until you listed a large directory, when it also bombed. But I could open large files via SMB, and SCP large files about, and ping with 8KB packets which were correctly fragmented to fit within the MTU - the problem seems oddly specific to certain protocols.
Tue 16th Jan 2007 12:51 am 
Subscribe
By Ben, Tue 16th Jan 2007 @ 8:30 am
Is OpenBSD's pf in the mix? If so, you might want a line like
scrub out on $if max-mss 1440
or something.