Jonas Mellander

Det gäller dock bara Expressen med 11n-stöd.
Inte den gamla som bara har 11bg.

Det kan man väl göra. Men de flesta 11a/11n-produkter står default på 36 eller 40, så risken att någon annan är på kanal 44 eller 48 är ännu lite mindre...
Om de inte läst på det här forumet vill säga
Ingen annan orsak än det.

OK, då kanske osynken inte gör så mycket som jag trodde.

Vad fick du för länk enligt Alt-Airportmenysymbolen-tricket då?
Låter ju inte som att den gick upp till 40MHz kanalbredd om du fick 60-65Mbps. Eller var det bandbredd i respektive riktning samtidigt som du menade?

Jag tror inte att det går. Dels skickas väl paketen med unicast normalt (även om en omställning till multicast inte vore omöjlig).
Men du skulle aldrig få dem att spela upp ljudet tillräckligt i synk för att det ska vara uthärdligt. Tror jag iaf... (jag kanske överskattar örats förmåga i detta fall, har inte heller orkat räkna på vad fasförskjutningen mellan de två skulle bli)

När du säger att du får 50/50, är det samtidigt eller i respektive riktning var för sig?

Eftersom 802.11n har så många inställningar och parametrar, och olika accesspunkter och klienter har stöd för olika uppsättningar så är det inte alla som når upp till 300Mbps datarate. Det beror på antal "spatial streams" och kanalbredd etc.
Mitt tips är att du testar att köra på kanal 44 eller 48 (dvs på 5GHz-bandet). Där har du färre störningar. Dessutom är risken mindre att du har grannar med icke-11n som kan göra att den går in i 20Mhz-kanalbredd.
Du bör dessutom öka avståndet mellan AP och klient avsevärt. Är de för nära får du distortion och paketförluster/omsändningar etc. 5-10 meter skulle jag rekommendera att testa.
Tekniken bakom stora delar av 802.11n , MIMO, vill gärna använda sig av reflektioner för att skapa flera (i detta fall två till 3) vägar för dessa spatial streams.
När du Alt-klickar på Airport-ikonen i menyn ser du vilken datarate den använder just för stunden. Den bör kunna komma upp i 270 eller 300Mbps.
Och med detta borde du kunna skyffla 100-150Mbps. (Om du kan testa dubbelriktat vore inte 75+75 omöjligt.)

Som jag skrivit tidigare verkar Apple för övrigt vara på väg med produker för 3 spatial streams, vilket ska ge upp till 450Mbps datarate. Då borde du kunna närma dig max för ditt bredband, det vill säga 100Mbps i full-duplex.

Apple har tidigare i denna månad fått två produkter Wi-Fi-certifierade av Wi-Fi Alliance. Inget nytt tänker kanske någon. Men när man studerar certifikatet upptäcker man att de är bland de första att få produkter certifierade med MIMO i 3x3:3-läge. (Multiple Input Multiple Output, 3 Transmit Chains, 3 Receive Chains, 3 Spatial streams)
Även om Apple själva inte skriver mycket om datahastigheter i sina specifikationer (vilket troligen är ganska klokt) så innebär detta möjlighet för datahastigheter på 450Mbps om klienten stöder 3x3:3 också. Idagsläget vet jag bara en enda klient som nått marknaden som gör detta, och det är Intel's 5300/5350-kort. Alla övriga med 3x3-MIMO har 2 spatial streams (och 300Mbps (när man kör i 40 MHz-läge)).

Eftersom dagens 3x3:2-system klarar 160-180Mbps i faktisk genomströmning som max (ungefär, när man pressar på) så borde maxhastigheten för dessa bli närmare 50% högre, eftersom bandbreddsökningen införs med en teknik som inte innebär någon extra overhead (dock tillförs ju inte någon vinning för managementramar och kontrollramar, så det lär inte bli exakt 50%).
Dock ska det påpekas att ju fler spatial streams man använder, dessto större krav ställs på miljön och möjligheten till multi-path. Att sitta en meter från basstationen behöver inte innebära ideala förhållanden för MIMO att verka.

En annan sak som var nytt för mig, när jag forskade lite i detta är att AirPort Extreme och Time Capsule verkar stödja både 2,4 och 5GHz _samtidigt_. Det måste innebära att det i själva verket rör sig om två radio.

Frågan man ställer sig är om dessa nycertifierade enheter är de som säljs nu, eller om nya är på gång. Det är ju nämligen rimligt att tro att Apple inom kort även uppgraderar alla klienter (datorer), annars är det inte så logiskt. Och detta är med väldigt stor sannolikhet (på gränsen till säkerhet) något som innebär byte av hårdvara. (Läs: Man ska inte räkna med någon mjukvaruuppdatering av sin MacBook för att gå från 300 till 450Mbps.)

Länk till certifikaten

Nja, vissa program kan ju känna av förändringar i länkstatus och agera på det. Huruvida VPN-anslutningen signalerar på samma sätt vet jag inte.
Men oavsett så finns det ju inget som säger applikationen att destinations-IP-adressen inte går att nå via den anslutning som finns kvar. (Applikationen vet ju inte att det är VPN (tunnel och säkerhet), för den är det ju bara en anslutning som vilken annan. Så den bör ju rimligen försöka via den andra anslutningen. Har man privata IP-adresser på kontoret brukar trafik till dessa kastas i första bästa router hos din ISP. Du skulle ju kunna lägga in spärrfilter i din lokala router/brandvägg också som tar bort trafik till privata adresser, eftersom det inte finns någon anledning till sådan (om inte din ISP har privata adresser i sitt nät, vilket borde vara straffbart... )

Erik_J har rätt. 130 Mbps är bra blås. Glöm det där med 300Mbps. Det är bara dataraten... Sen får man tänka på att om man köra trådlöst till en accesspunkt som sedan ska skicka vidare till nästa så belastar man ju luften/kanalen två gånger med samma data, och då halveras bandbredden.
Jag vet inte om du redan kör det, men en sak som kan vara bra ät att köra på 5GHz-bandet förutsatt att alla dina klienter stöder det.

Nja, jag tycker det verkar finns lite olika problem, eftersom vissa tycker att uppdatering i endera änden löser problemet.
Mitt problem, som iaf gav samma felnummer, löste jag genom att aktivera IPv6 i TCP/IP-inställningarna på min Mac. APE:n har sedan länge 6.3. Nedgradera iTunes vet jag inte om det låter sig göras så lätt.
Hoppas det är svar på din fråga. Och kanske lösning på ditt problem.

Det verkar finnas lite olika lösningar på samma problem.
Jag har haft problemet, men eftersom jag inte streamar så ofta så har jag inte utrett det utan hoppats att Apple ska fixa det i någon uppdatering av APE eller iTunes.

Nu ikväll gjorde jag iaf en protokollanalys och såhär är det:
Brandväggen måste vara öppen för iTunes, eller tillåta UDP, eller vara avstängd (vilket den var i mitt fall). Det är lite dumt att det i vissa artiklar från Apple står att brandväggen måste stå i läget för att specificera per applikation, när detta inte är det enda alternativet....
Mjukvaruversioner måste säkert vara rätt också, vilket de var i mitt fall. (APE 6.3 och iT 8.0.2)

Sedan var det det här med IPv6, något som väl knappast kan behövas kan man tycka. Jag hade stängt av det eftersom jag stänger av allt som känns onödigt. Jag har även testat att aktivera det utan framgång.
Tricket, eller det jag missade, var att faktiskt starta om iTunes efter att IPv6 var aktiverat.

Och i protokollanalysen kan man se att att utan IPv6 så börjar iT och APE prata via TCP (minns inte vilken port) där RTSP används och en RTSP-URL skickas och tas emot.
Sedan börjar några få UDP-paket att utvecklas. Och sedan får APE:n för sig att avbryta kommunkationen och stänger snällt TCP-sessionen. So far so good.

Kör man med IPv6 så sker allt detta över IPv6 istället för IPv4 istället. Och då får man inte problemet.

Slutsats: Det finns en bugg i iTunes 8.0 (kanske någon mer) som bara drabbar IPv4. Och istället för att fixa denna så ändrar Apple kravet till att köra IPv6. Lite kasst om ni frågar mig.
Framför allt eftersom stödet för IPv6 i AirPort Express är något hemligt eftersom det inte finns tillstymelse till indikation bland parametrar till att IPv6 skulle stödjas.
Det innebär också att all utrustning emellan måste stödja IPv6. Och jag vet att det finns system som kan framstå som bryggande men som i själva verket bara är IPv4-kompatibla. Och då blir det problem. Nu vet jag inte om något gjort något sådant, men man skulle ju kunna sätta upp APE i en routad miljö och använda multicast för att hitta rätt APE i AirPort (själva musiken går ju som UDP unicast). Men det betyder att routing av IPv6 måste stödjas också. Men det kanske man ofta har om man bemödat sig med att routa multicast?

Jag tycker i alla fall att detta är lite kasst av Apple. Varför kan de inte bara fixa buggen över IPv4? Det finns verkligen INGET i IPv6 som man är beroende av för att göra det man gör i det här fallet....

Jag tror mig ha upptäckt något buggliknande i MacOS X och/eller QuickTime.
Jag har en MPEG-4-ström från en Axis-kamera som står och sänder konstant. Denna ström öppnar jag sedan i QuickTIme Player via en SPD (stream description protocol) eller QuickTime reference movie (.mov).
Saken är den att förbindelsen med kameran bara fungerar dryga minuten i stöten, och sedan tappar de kontakten i cirka 20-25 minuter. Sedan kommer kontakten tillbaka. (Detta är alltså fullt naturligt och en del av hur nätet fungerar pga täckning mellan två radioenheter som bryts längre perioder.)
Problemet är att QuickTIme Player oftast (dock inte alltid) inte plockar upp strömmen igen när den kommer tillbaka. Detta ska normalt ske automatiskt. Och om jag, när jag vet att nätkontakten finns, provar att öppna .spd-filen eller .mov-filen så plockar den snällt in strömmen. Att bara trycka på Pause och Play hjälper dock inte.

Till saken hör att när jag testar med en Windows-dator (XP) med QuickTime Player (eller VLC Player) och kör dem sida vid sida i samma nät så plockas strömmen upp automatiskt utan problem. Detta får mig att tro att problemet kanske inte ligger i QuickTime i sig, utan i MacOS X.
Jag kör 10.4.11.
Jag har även testat med VLC Player för Mac, men den får någon bugg direkt när man försöker öppna .spd-filen....
Båda datorerna har sina mjukvarubrandväggar avstängda (vilket annars naturligtvis kunde ha varit en förklaring)

Nu är frågan, hur rapporterar jag detta till Apple på bästa och effektivaste sätt?
Kollar man på supportsidorna finns inte mailadresser vare sig för MacOS X-frågor eller QuickTimefrågor.

Då är det nog något annat WPA-relaterat som är fixat också, för jag betvivlar att någon kör EAP-TLS och IAS mot en sån.... Även om det säkert går rent tekniskt.

Om det är EAP-LEAP eller EAP-PEAP som används så är det ju bara servern som autenticeras med certifikat. Så vad du behöver göra i klienten är att antingen välja att inte verifiera servercertet (då tappar du halva säkerheten, i och med att du inte kan vara säker på att du ansluter och förhandlar kryptonyckeln med rätt nätverk) eller så måste du importera rotcertifikatet (certifikatet från den certifikatsutgivare (CA) som utfärdat RADIUS-serverns (som sitter i bakkant av WLAN:et) certifikat).
Om inte iPhone stöder import av nya/fler rotcertifikat så är det ju lite beklagligt. Då har Apple missat delar av poängen med certifikat.

Kan meddela att lösningen blev att installera version 6, som turligt nog är tillgänglig gratis pga andra brister i iMovie '08 (7.1). 7.1 verkar ju således inte vara någon höjdare ut något avseende, eller?