SG-3100 fail to get WAN IP from Frontier fiber ONT
-
@mer I read an article about Frontier that said a hostname would be required for the ONT to give an IP. I dont know if this is true, I don't think the 1100 has anything specified in that field and who knows about the unifi.
I tried it. I put SG3100WAN as the hostname in the WAN DHCP Client Configuration section. That did not help. You can select advanced options and it gives fields for timing. I did not find anything online about what those should be so I left them at default (unchecked the advanced options checkbox).
If someone has the link to DHCP tweak thread, I will give those items a try. I will also packet capture this evening as it is a busy monday.
-
@mer said in SG-3100 fail to get WAN IP from Frontier fiber ONT:
Didn't someone recently ....
Don't know who it was, but he used the DHCP client used by OSense which permitted to used DHCP OPTIONS, needed by the ISP.
But .... if a SG-1100 works, the SG-3100 should work also. I'm pretty sure it's the same code.
Anyway : capturing would shows the details.
No "help me" PM's please. Use the forum, the community will thank you.
Edit : and where are the logs ?? -
@gertjan Agreed the code should be the same and pcap on each should make it obvious.
-
@gertjan said in SG-3100 fail to get WAN IP from Frontier fiber ONT:
if a SG-1100 works, the SG-3100 should work also.
You would expect that. The big difference there is that the 1100 WAN is connected via the switch that will link to some things the raw NIC will not. So I would want to check the 3100 WAN interface link state directly in ifconfig.
Secondly, as implied above, this could just be a bad WAN port on the 3100 until it's proven working on something else. I would also try swapping the WAN and OPT NIC assignments and seeing if that changes anything.The dhcp client will send the hostname configured in general setup by default. You shouldn't need any special options there. Most of the threads detailing that are for ISPs using MAC Encapsulated Routing.
Steve
-
Packet capture data for Sg-3100. Here is the procedure used.
- disconnect WAN cable from cable modem
- start packet capture on WAN port in netgate router
- plug WAN cable into ONT
- end packet capture after a short time.
First few DHCP requests the 3100 asks for the last IP it had, which was a cable company IP, the ONT returns NAK each time, message is address not available (makes sense as it is not in Frontier's pool).
3100 finally begins to send DHCP discover messages and for each one, the ONT replies with an offer with ip address within their pool. The 3100 does not accept the offer but just continues to send discover packets, each one replied to by the ONT with a valid offer.
I will post another post with SG-1100 data separate from this post for clarity.
Thank you for your help.
-
Packet capture data from the SG-100 for comparison (this unit has no trouble getting an IP from the ONT). Same procedure as with the 3100.
- disconnect WAN cable from cable modem
- start packet capture on WAN port in netgate router
- plug WAN cable into ONT
- end packet capture after a short time.
Just one picture below with the following numbers explained
(1) 1100 request DHCP supplying the last known IP - the cable modem IP
(2) NAK from ONT with message 'address not available'
(3) 1100 sends DHCP discover packet (the 3100 tried requesting the same IP 4 times before moving on to discover)
(4) DHCP Offer from the ONT - displayed below for detail
(5) ACK from 1100 and were off to the races with ARPs, PINGs and NTP requests (not shown)
Thank you for your help with this and any insight you might give to resolve problem.
-
Is there anything logged in the 3100 dhcp log?
Are the replies coming into the correct MAC address?
Was the pcap filtered at all?
I note the DHCP offer to the 1100 appears to come from the relay agent IP but the offer to the 3100 from the DHCP server directly. Though I'm not sure what difference that could make.
Steve
-
@stephenw10 said in SG-3100 fail to get WAN IP from Frontier fiber ONT:
Is there anything logged in the 3100 dhcp log?
Here is what I got from the log. Starts with when I disconnected the cable to the WAN port (from cable modem). You can see the 4 requests and then several discovers. Note after that it logs 'No DHCPOFFERS received'
Dec 20 16:16:34 STSpfSense dhclient[30428]: connection closed
Dec 20 16:16:34 STSpfSense dhclient[30428]: exiting.
Dec 20 16:17:09 STSpfSense dhclient[7665]: Cannot open or create pidfile: No such file or directory
Dec 20 16:17:09 STSpfSense dhclient[8333]: PREINIT
Dec 20 16:17:09 STSpfSense dhclient[7665]: DHCPREQUEST on mvneta2 to 255.255.255.255 port 67
Dec 20 16:17:11 STSpfSense dhclient[7665]: DHCPREQUEST on mvneta2 to 255.255.255.255 port 67
Dec 20 16:17:15 STSpfSense dhclient[7665]: DHCPREQUEST on mvneta2 to 255.255.255.255 port 67
Dec 20 16:17:19 STSpfSense dhclient[7665]: DHCPREQUEST on mvneta2 to 255.255.255.255 port 67
Dec 20 16:17:24 STSpfSense dhclient[7665]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 2
Dec 20 16:17:26 STSpfSense dhclient[7665]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 2
Dec 20 16:17:28 STSpfSense dhclient[7665]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 5
Dec 20 16:17:33 STSpfSense dhclient[7665]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 7
Dec 20 16:17:40 STSpfSense dhclient[7665]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 21
Dec 20 16:18:01 STSpfSense dhclient[7665]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 17
Dec 20 16:18:18 STSpfSense dhclient[7665]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 7
Dec 20 16:18:25 STSpfSense dhclient[7665]: No DHCPOFFERS received.
Dec 20 16:18:25 STSpfSense dhclient[7665]: Trying recorded lease 67.xx.xx.xx
Dec 20 16:18:25 STSpfSense dhclient[16519]: TIMEOUT
Dec 20 16:18:25 STSpfSense dhclient[16721]: Starting add_new_address()
Dec 20 16:18:25 STSpfSense dhclient[16770]: ifconfig mvneta2 inet 67.xx.xx.xx netmask 255.255.252.0 broadcast 67.xx.xx.xx
Dec 20 16:18:25 STSpfSense dhclient[16867]: New IP Address (mvneta2): 67.xx.xx.xx
Dec 20 16:18:25 STSpfSense dhclient[17204]: New Subnet Mask (mvneta2): 255.255.252.0
Dec 20 16:18:25 STSpfSense dhclient[17367]: New Broadcast Address (mvneta2): 67.xx.xx.xx
Dec 20 16:18:25 STSpfSense dhclient[17600]: New Routers (mvneta2): 67.xx.xx.xx
Dec 20 16:18:26 STSpfSense dhclient[21176]: New Routers (mvneta2): 67.xx.xx.xx
Dec 20 16:18:27 STSpfSense dhclient[22685]: Deleting old routes
Dec 20 16:18:27 STSpfSense dhclient[7665]: No working leases in persistent database - sleeping.
Dec 20 16:18:27 STSpfSense dhclient[23293]: FAIL@stephenw10 said in SG-3100 fail to get WAN IP from Frontier fiber ONT:
Are the replies coming into the correct MAC address?
Yes correct MAC assigned to mvneta2
@stephenw10 said in SG-3100 fail to get WAN IP from Frontier fiber ONT:
Was the pcap filtered at all?
No. I selected 'Enable promiscuous mode', left everything else at default, and set count to 0
-
Ok, to be clear, you have verified that WAN port connects as expected to some other DHCP server? On the 1100 LAN for example?
Did you try reassigning the 3100 WAN to mvneta0 (opt)?
Steve
-
This :
First few DHCP requests the 3100 asks for the last IP it had, which was a cable company IP, the ONT returns NAK each time, message is address not available (makes sense as it is not in Frontier's pool).
The dhclient actually receives the multiple NACKs ?
edit : me thinking : is it normal that client continues asking for a know - used before - IP ?
I mean, I've this impression that there is a one way communication ....3100 finally begins to send DHCP discover messages and for each one, the ONT replies with an offer with ip address within their pool. The 3100 does not accept the offer but just continues to send discover packets, each one replied to by the ONT with a valid offer.
Again : (does it) look like he dhclient process never sees the DHCP answers.
But they are there, the capture is clear about it. The captures are taken from pfSense, right ?
-
@stephenw10 said in SG-3100 fail to get WAN IP from Frontier fiber ONT:
Ok, to be clear, you have verified that WAN port connects as expected to some other DHCP server? On the 1100 LAN for example?
Did you try reassigning the 3100 WAN to mvneta0 (opt)?
SteveThe WAN port has been plugged into for more than a year, and remains plugged into a cable modem. This is our office and we have been running it flawlessly everyday now. Frontier fiber was installed on friday. We attempt to make frontier work but remain with cable until this is figured out. Both services (cable modem, fiber ONT) are next to each other in our server room.
I have not tried assigning mvneta0, I can try that. You say re-assign. I never assigned 2 over 0, I ran the wizard and started with that base setup more than a year ago. I believe the wizard assigned 2 to WAN.
-
@gertjan said in SG-3100 fail to get WAN IP from Frontier fiber ONT:
The dhclient actually receives the multiple NACKs ?
edit : me thinking : is it normal that client continues asking for a know - used before - IP ?
I mean, I've this impression that there is a one way communication ....Yes, the 3100 makes 4 attempts at request for known IP and gets 4 NAKs. The 1100 we are using as the 'control' makes 1 request for known IP, gets 1 NAK and then makes DHCP request.
@gertjan said in SG-3100 fail to get WAN IP from Frontier fiber ONT:
The captures are taken from pfSense, right ?
Yes. under Diagnostics > Packet Capture with the settings 'Enable promiscuous mode', left everything else at default, and set count to 0
-
Ah, OK. Then if the OPT port is not used I would just set that as DHCP and connect the finer to it instead. See if it pulls a lease there.
Are you running Snort or Suricata in blocking mode? Has it somehow blocked the DHCP server IP? (which should not be possible)
Steve
-
Under Interfaces, WAN the section "DHCP Client Configuration" have you compared this section between the 3100 and 1100? Mine is blank, on mine, but if you check the "Advanced Configuration" box, you get some more items, a new section "Lease Requirements and Requests". Again on mine, it's blank, but perhaps there is a difference on your 3100 and 1100.
-
@jaredo said in SG-3100 fail to get WAN IP from Frontier fiber ONT:
Yes, the 3100 makes 4 attempts at request for known IP and gets 4 NAKs. The 1100 we are using as the 'control' makes 1 request for known IP, gets 1 NAK and then makes DHCP request.
Exactly.
The 1100 tries to validate the old know IP, get a - just one - 'NAK' and behaves accordingly : it goes for a 'discover'.
The 3100 goes for the old IP ..... a NAK comes in, but the 3100 repeats itself, as if it is ignorant of the NAK. After some time, the 3100 takes note 'of the silence' (!) and switches to 'discover' which is the normal procedure.Just to be sure : shut down the firewall completely for a moment.
I guess it's "pfctl -d".
The info - the NAKs etc from the opposite side are coming in, as the capture shows. -
@stephenw10 said in SG-3100 fail to get WAN IP from Frontier fiber ONT:
Ah, OK. Then if the OPT port is not used I would just set that as DHCP and connect the finer to it instead. See if it pulls a lease there
On your suggestion I enabled OPT1. It also fails to get IP from ONT but will get one from arris router. I did not dive deeper with packet capture and such.
@stephenw10 said in SG-3100 fail to get WAN IP from Frontier fiber ONT:
Are you running Snort or Suricata in blocking mode? Has it somehow blocked the DHCP server IP? (which should not be possible)
I run Suricata but not in blocking mode. I turned it off anyways as a test (and it would have not been enabled during the test where I factory defaulted the 3100. Anyways, no luck, still will not get an IP from ONT.
-
Hmm, might need to check the pcap directly then. Something appears to be dropping those packets before the dhclient process ever sees them. Are they arriving tagged somehow and the 1100 switch is doing something with that?
-
@stephenw10 said in SG-3100 fail to get WAN IP from Frontier fiber ONT:
Hmm, might need to check the pcap directly then. Something appears to be dropping those packets before the dhclient process ever sees them. Are they arriving tagged somehow and the 1100 switch is doing something with that?
On your comment I went back into the pcap. Every packet from the ONT has this 208.1Q VLAN tag. Above my pay grade here but from wikipedia seems like it is only inserted if using tagging. "802.1Q VLAN frames are distinguished from ordinary Ethernet frames by the insertion of a 4-byte VLAN tag into the Ethernet header". This 0x8100 would not be in a non-vlag tagged packet.
From my rudimentary understanding, the ID is 0. How do you have a vlan tag of 0?
Also reading forums there is mention of Verizon or Frontier fiber using vlan tags. I think a friend found a reference to verizon using 100 and frontier using 0. Not sure about that.
-
Yeah, I didn't realise you also have a ticket open with us but now I do I've reviewed the pcaps there. The interesting thing is that the pcap from the 1100 does not show tagged traffic. That's probably because in the 1100 the switch always runs in dot1q mode so it tags the traffic into the interface itself. When you capture on WAN there you are actually only seeing traffic in mvneta0.4090 which the interface allows.
It looks like the raw NIC/driver is dropping the VLAN 0 tagged packets.As suggested on the ticket there though the simplest workaround here just to configure one of the 3100 LAN ports as the WAN which replicates what the 1100 WAN does.
Steve
-
Steve I didn’t realize you are an actual netgate employee. I really appreciate you helping here and on the actual support site since I don’t have paid support. It means a lot.
I was out all day at a client site. I will try this fix tomorrow.
