Hello Luca, Indeed, after further research I found that 802.11 does include a destination MAC address in the data-link frame.
This is an important 'gotcha' that may allow the protocol to work just as in wired networks, although I am not yet sure at which point the neighbor's node IP address is translated into its MAC address. I'll update my article, thanks, Michele On Mon, Jun 3, 2013 at 9:20 PM, Luca Dionisi <[email protected]> wrote: > Hi Michele > thank you for the contribution to the thread. > I don't know if the behaviour you describe IS something, such as > retrasmission as advanced feature of certain routers or similar. > It definitely is not the way TCP/IP works. > It goes more like this: > A wants to send a IP packet to D > A sends a frame to B, with the IP packet inside it that says that the final > destination is D. > B ears the frame and takes care of it. > B sends a NEW frame to C with the IP packet inside. > A ears the frame, but does not care. > C ears the frame and takes care of it. > ... and so on until D is reached. > > --Luca > > On Mon, Jun 3, 2013 at 7:24 PM, Michele Bini <[email protected]> wrote: >> >> Greetings list, >> >> I was the original writer of that article; I have updated the title, >> and added an example to better illustrate the issue I have noticed, >> the article is now available here: >> https://we.riseup.net/mbxxii/netsukuku-wireless-networks >> >> I'll illustrate briefly the problem to the list: >> >> To the best of my current knowledge, Netsukuku routing works by >> allowing each node to construct a routing table, based on each-node's >> fractal view of the network. >> >> In the case of networks of nodes having just wireless connection, the >> routing table for each can degenerate into basically just two entries >> (each for, including localhost), losing the ability to direct packets >> only in shortest path along the network: >> >> The current node's IP address ---> localhost >> Every other IP address --> wireless device >> >> Another issue is packet duplications and loops due to the fact that >> packets can be received by multiple peer simultaneously: >> >> Let's consider an ad-hoc wireless network composed of four nodes: >> >> A--B--C--D >> >> A can only reach only B >> B can only reach A and C >> C can only reach B and D >> D can only reach C >> >> A possible sequence of events leading to a loop: >> >> A wants to send an IP packet to D >> B receives the packet from A and re-transmits it; A and C receive it >> C receives the packet from B and re-transmits it; B and D receive it >> D finally receives the packet, however... >> B receives the packet from C and re-transmits it; A and C receive it >> C receives the packet from B and re-transmits it; B and D receive it >> B receives the packet from C (loop…) >> >> A possible solution I would suggest is to annotate each packet with >> information designating exactly which next node should re-transmit a >> packet. >> >> Anyway, keep up the work with Netsukuku! >> >> Ciao, >> Michele >> >> On Sun, Jun 2, 2013 at 6:19 PM, Ilario Gelmetti <[email protected]> >> wrote: >> > >> > Hi all! >> > What do you think about this article? >> > >> > "Netsukuku unsuitable for wireless networks" >> > https://we.riseup.net/mbxxii/netsukuk-unsuitable-for-wireless-networks >> > >> > Bye, >> > Ilario Gelmetti >> > >> _______________________________________________ >> Netsukuku mailing list >> [email protected] >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/netsukuku > > > > _______________________________________________ > Netsukuku mailing list > [email protected] > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/netsukuku > _______________________________________________ Netsukuku mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/netsukuku
