Navigation
« 

Anonymous




Register
Login
« 
« 

Amiga Future

« 

Community

« 

Knowledge

« 

Last Magazine

The Amiga Future 167 was released on the March 5th.

The Amiga Future 167 was released on the March 5th.
The Amiga Future 167 was released on the March 5th.

The Amiga Future 167 was released on the March 5th.
More informations

« 

Service

« 

Search




Advanced search

Unanswered topics
Active topics
« 

Social Media

Twitter Amigafuture Facebook Amigafuture RSS-Feed [german] Amigafuture RSS-Feed [english] Instagram YouTube Patreon
« 

Advertisement

Amazon

Patreon

« 

Partnerlinks

DHCP problems with own sana driver

Support Roadshow

Moderators: AndreasM, olsen

Post Reply
lallafa
Newbie
Newbie
Posts: 8
Joined: 01.05.2013 - 21:10

DHCP problems with own sana driver

Post by lallafa »

I am using roadshow with a patched magplip sana II driver from my plipbox project.

The current version of the plipbox.device registers itself as an Ethernet type device with a default MTU of 1500 and essentially bridges to a real Ethernet device via parallel port.

While setting up everything with a static IP works without problems I have trouble getting DHCP to work.

I have run a tcpdump -vv and got the following output:

Code: Select all

21:09:46.632933 IP (tos 0x0, ttl  64, id 33938, offset 0, flags [DF], length: 328) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request [|bootp]
21:09:47.723831 IP (tos 0x0, ttl  64, id 33938, offset 0, flags [none], length: 576) 192.168.2.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 548, xid:0x4528d660, secs:4, flags: [Broadcast] (0x8000)
	  Your IP: 192.168.2.51
	  Server IP: 192.168.2.1 [|bootp]
21:09:53.650653 IP (tos 0x0, ttl  64, id 33946, offset 0, flags [DF], length: 328) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request [|bootp]
21:09:54.741327 IP (tos 0x0, ttl  64, id 33946, offset 0, flags [none], length: 576) 192.168.2.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 548, xid:0x3752ccbc, secs:11, flags: [Broadcast] (0x8000)
	  Your IP: 192.168.2.51
	  Server IP: 192.168.2.1 [|bootp]
21:10:08.665924 IP (tos 0x0, ttl  64, id 33948, offset 0, flags [DF], length: 328) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request [|bootp]
21:10:09.754719 IP (tos 0x0, ttl  64, id 33948, offset 0, flags [none], length: 576) 192.168.2.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 548, xid:0x57db4ae3, secs:26, flags: [Broadcast] (0x8000)
	  Your IP: 192.168.2.51
	  Server IP: 192.168.2.1 [|bootp]
You can see the DHCP Request sent by Roadshow and also the Reply/Offer sent by my Fritz.Box.... What's missing is the DHCP_Request from Roadshow that actually accepts the offer...

Do you have any idea what my device is doing wrong?

(I have tested on the same A1200 with a Netgear device and the cnet16.device driver and there DHCP works... So I assume there is something wrong in plipbox.device...)
olsen
CygnusEd Developer
Posts: 167
Joined: 06.06.2006 - 16:27

Re: DHCP problems with own sana driver

Post by olsen »

lallafa wrote:I am using roadshow with a patched magplip sana II driver from my plipbox project.

The current version of the plipbox.device registers itself as an Ethernet type device with a default MTU of 1500 and essentially bridges to a real Ethernet device via parallel port.

While setting up everything with a static IP works without problems I have trouble getting DHCP to work.

I have run a tcpdump -vv and got the following output:

Code: Select all

21:09:46.632933 IP (tos 0x0, ttl  64, id 33938, offset 0, flags [DF], length: 328) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request [|bootp]
21:09:47.723831 IP (tos 0x0, ttl  64, id 33938, offset 0, flags [none], length: 576) 192.168.2.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 548, xid:0x4528d660, secs:4, flags: [Broadcast] (0x8000)
	  Your IP: 192.168.2.51
	  Server IP: 192.168.2.1 [|bootp]
21:09:53.650653 IP (tos 0x0, ttl  64, id 33946, offset 0, flags [DF], length: 328) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request [|bootp]
21:09:54.741327 IP (tos 0x0, ttl  64, id 33946, offset 0, flags [none], length: 576) 192.168.2.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 548, xid:0x3752ccbc, secs:11, flags: [Broadcast] (0x8000)
	  Your IP: 192.168.2.51
	  Server IP: 192.168.2.1 [|bootp]
21:10:08.665924 IP (tos 0x0, ttl  64, id 33948, offset 0, flags [DF], length: 328) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request [|bootp]
21:10:09.754719 IP (tos 0x0, ttl  64, id 33948, offset 0, flags [none], length: 576) 192.168.2.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 548, xid:0x57db4ae3, secs:26, flags: [Broadcast] (0x8000)
	  Your IP: 192.168.2.51
	  Server IP: 192.168.2.1 [|bootp]
You can see the DHCP Request sent by Roadshow and also the Reply/Offer sent by my Fritz.Box.... What's missing is the DHCP_Request from Roadshow that actually accepts the offer...

Do you have any idea what my device is doing wrong?

(I have tested on the same A1200 with a Netgear device and the cnet16.device driver and there DHCP works... So I assume there is something wrong in plipbox.device...)
I suspect that this may have something to do with how your driver handles incoming broadcast packets. For Roadshow to accept the "reply" packet, the IOSana2Req->ios2_Req.io_Flags field has to have the SANA2IOB_BCAST bit set.

If this is not the case, then Roadshow will treat the packet as sent in unicast mode, and for that to work out, the IPv4 address inside the packet has to match the IPv4 address of the respective network interface. Since the DHCP server has not yet assigned Roadshow such an address, this case is unlikely to happen here.

That's as far as I could explain the matter, unless the packets themselves are not in good shape.

If you can, please capture a packet exchange with the "tcpdump -s0 -wdump.pcap" options (interface specified as necessary) and send me the capture file for closer inspection (via personal mail). What tcpdump prints on the console may not tell the whole story.
lallafa
Newbie
Newbie
Posts: 8
Joined: 01.05.2013 - 21:10

Post by lallafa »

Thanks for the hint!!!

That did the trick :)

I was almost sure that I did the broadcast flagging correctly... but me getting old or'ed SANA2IOB_BCAST and not SANA2IOF_BCAST into io_Flags :))
Post Reply